Problème d'encodage avec MySQL

[Samuel Proulx]

Bonjour à tous et à toutes

J'utilise l'API mysql afin de communiquer avec une base de données. Par défaut, les tables sont encodées en latin1_swedish_ci.

Lorsque je reçois des données (champs VARCHAR(64) par exemple pour un username), et bien ça m'affiche des caractères bizarres dans la console et dans la fenêtre SFML.

Comment dois-je encoder ma bdd pour qu'elle soit compatible avec SFML (et la console si possible) ?

ps. Les données circule de façon adéquate puisque quand je compare un string 'Neo007ca' avec un MYSQL_ROW row qui contient une chaîne de caractères 'Neo007ca', mais non affichage, ça dit que les deux sont identiques (puisque le serveur accepte la connexion du client).

Merci et bonne journée

[Chaore]

J'ai regardé ici: http://www.sfml-dev.org/documentation/2.0/classsf_1_1String.php#details


Selon la doc, Je cite:

 " Utility string class that automatically handles conversions between types and encodings.

sf::String is a utility string class defined mainly for convenience.
 
It is a Unicode string (implemented using UTF-32), thus it can store any character in the world (european, chinese, arabic, hebrew, etc.).
 
It automatically handles conversions from/to ANSI and wide strings, so that you can work with standard string classes and still be compatible with functions taking a sf::String. "


En conclusion, essaye UTF-32.  Sauf que selon ce que je viens de lire, la SFML est suposé faire elle-même la conversion.


EDIT: Je viens de penser à ton problème, je crois que tu dois utilisé la classe string de base du c++ et non celle de la sf.  Si tu pourrais aller vérifier.

[Laurent]

Latin-1 est compatible avec UTF-32, il n'y a rien à changer normalement. Le tout est de savoir comment tu trimballes tes caractères depuis la source jusqu'à l'affichage, de nombreux encodages intermédiaires peuvent venir parasiter le résultat. Il faut donc voir tous les types et fonctions impliqués dans le transport et la conversion des chaînes dans ton code.

[Samuel Proulx]

J'utilisais des std::string et il semblerait qu'eux n'apprécie pas le latin1. J'ai donc fait un petit code rapide qui récupère les données, les stocke dans un sf::String et les affiche dans le titre de la fenêtre et ça fonctionne nickel !

[Chaore]

J'utilisais des std::string

C'est ce que je pensais  .


Sujet résolu alors !

[Samuel Proulx]

Merde... j'ai perdu mon code qui fonctionnait et voilà qu'un code simple ne fonctionne plus...

#include <iostream>
#include <SFML/Network.hpp>
#include <SFML/Graphics.hpp>
#include <winsock2.h>
#include <MYSQL/mysql.h>

using namespace std;
using namespace sf;

int main()
{
    MYSQL* mysql = mysql_init(0);
    if(mysql_real_connect(mysql,"127.0.0.1","root","","darkspace",0,NULL,0))
    {
        MYSQL_RES *result;
        MYSQL_ROW row;
        mysql_query(mysql,"SELECT * FROM accounts");
        result = mysql_use_result(mysql);
        if((row = mysql_fetch_row(result))){
            mysql_free_result(result);
            String string1 = row[1];
                RenderWindow app(VideoMode(800, 600, 32), string1);
                while (app.isOpen())
                {
                    app.clear();
                    app.display();
                }
        }
    }
    return 0;
}
 

row[1] est le deuxième champs de la table accounts. Ses champs sont id, accountname et password. Les deux sont des VARCHAR(32). Je les ai essayé en utf8_unicode_ci, latin1_swedish_ci, utf32_unicode_ci... Que dalle. Ça affiche n'importe quoi dans le titre de la fenêtre et de plus, ce n'importe quoi change à chaque fois que je redémarre l'application. Le code ci-dessus est EXACTEMENT ce que j'ai compilé et tenté de faire fonctionner...

Solution ?

[Samuel Proulx]

Ok. Si quelqu'un a une explication... !!!???

Si je tente d'accéder aux champs supérieur à 2 (donc tous les champs excepté les deux premiers de la table) j'obtiens le résultat correctement.

Par contre, si j'accède donc à row[0] ou row[1] pour n'importe quelle table, ça me renvoie n'importe quoi...

J'ai testé en changeant le jeu de caractère, le type de champ et plein d'affaire : rien à y faire. Les deux premiers champs sont toujours inaccessible

Je vais réinstaller la lib... peut-etre un bug ?...

Ah... c'est un bug enfin si on peut le dire ainsi : les deux premières entrées bug si on fait un mysql_free_result et que par la suite on accède à row[].

Voilà un truc assez étrange... tk bonne journée !

Et petite question : si je veux que les joueurs puissent utiliser des pseudos avec plein de caractères bizarres, il est mieux d'utiliser les sf::String ? (j'imagine que oui).

Si c'est le cas, est-ce que je dois changer mes tables en utf32_unicode_ci (non sensible donc) afin qu'elles supportent correctement l'enregistrement de tous les caractères ?

[Laurent]

Attention : le constructeur de RenderWindow prend un std::string en paramètre, donc le fait de passer par un sf::String ne garantit pas à coup sûr que tous les caractères vont passer sans encombre. Ca va dépendre de la locale courante.

En ce qui concerne ce que tu stockes dans ta BDD, ça peut être à peu près n'importe quoi du moment que tu le gères correctement. UTF-32 fonctionnera sans souci, mais prendra beaucoup de place pour rien. UTF-8 serait peut-être plus judicieux, mais il faudra utiliser la fonction de conversion qui va bien avant de coller tes chaînes dans des sf::String.

[Samuel Proulx]

Dans ce cas je vais rester en utf32 pour la simple raison que je n'ai que trois champs dans les tables concernées par le joueur qui contiennent des caractères. ce qui fait 9 octets de plus par joueur. Donc si il y a 1 million de joueur (ce qui est énorme), ça va rajouter environ 9 Mo au total, ce qui me dérange pas du tout

Pour la barre de titre, c'était simplement ma façon rapide de voir si les caractères reçues (qui n'étaient que 'NeO007ca') était correctement transféré jusqu'au client et maintenant c'est la cas

Merci de votre aide et conseils et bonne journée !

[Laurent]

ce qui fait 9 octets de plus par joueur.

UTF-32, c'est (pour la plage Latin-1) 3 octets de plus par caractère par rapport à UTF-8

[Samuel Proulx]

ah ouais c'est vrai... hum... c'est peut-être pas une très bonne idée dans ce cas

[Samuel Proulx]

Hum... mais attend ! Le utf8, ça supporte tout de même n'importe quel caractère de la table unicode Parce que si c'est juste encodé sur 8 bits, ça limite à 256 caractères... À moins que le utf8 s'adapte en fonction du caractère que tu tente d'insérer

[Hiura]

En fait, l'UTF-8 n'a pas une taille fixe. Elle varie de 8 à 48 bits.