Bonjour à tous,
Merci pour toutes vos réponses.
Il semblerait que mes explications ne soient pas très claires. Soyez
heureux, ce n'est pas tout à fait clair pour moi non plus !
Je vais essayez de simplifier mon problème :
* Ma base MySQL a été créée avec UTF8 comme jeu de caractères.
* RB stockant les chaînes de caractères en UTF8, je pensais que le
fait d'écrire ou lire directement dans la base suffisait, mais non,
cela ne marche pas
* Si j'écris une chaîne de caractères accentuées UTF8 (de RB) dans
ma base, MySQL Browser ne la vois pas correctement.
* Si j'écris une chaîne de caractères accentuées via MySQL Browser
dans la base, RB ne la vois pas correctement.
1 - Jacques nous dit : la base MySQL encode systématiquement en
IsoLatin parcequ'elle a été écrite pour çà.
Je ne suis pas certain de cela. Depuis MySQL 5, le jeu de caractères
peut être indiqué (latin1, utf8,...). Evidemment, cela ne nous dit
pas quel est le jeu de caractères réel utilisé en interne dans MySQL.
On peut espérer que cela soit le jeu de caractères indiqué, sinon
cela voudrait dire qu'il y a une conversion interne constante du jeu
de caractères. Ce ne serait pas terrible au niveau des performances.
2 - Jacques nous dit : quand on va relire ces données, il faudra
préciser à RB que l'on va lire de l'UTF8, puisqu'il semble qu'il
attende de l'isoLatin par défaut
Si les données de la base sont en UTF8, c'est tout de même bête,
voire idiot, que RB considère que cela soit de l'isoLatin1 lors de la
lecture, alors que l'écriture s'effectue correctement ! Mais
effectivement, la conversion suivante fonctionne :
chaine = rs.Field("element").StringValue.DefineEncoding
(encodings.UTF8)
Pour l'écriture, il n'y a aucune conversion à effectuer. C'est très
bien
3 - Jacques nous dit : MySQL n'encode rien du tout, il reçoit les
caractères qu'on lui envoie avec l'encodage d'origine.
Tout à fait, mais si on n'envoie de l'UTF8, dans une base IsoLatin1,
on ne pourra pas utiliser MySQL Browser pour voir le contenu de la
base. Ce serait bien dommage.
4 - dazz nous dit : ouais c'est un bug du plug si j'ai bien compris
ton blem chaque fois que tu te connect, faut envoyer :
hisdb.SQLExecute ("SET NAMES'utf8'; SET CHARACTER_SET 'utf8'; ")
Ben là, je sèche. Bon, si le plug-in est en cause, il serait peut-
être temps que RealSoftware corrige la chose. Il ne date pas d'hier
ce plug-in ! D'ailleurs, j'ai l'impression que les plugins sont
fournis parce qu'il faut en fournir, mais que c'est plutôt REAL SQL
Server qui est privilégié... mais c'est une remarque personnelle...
et mon côté désabusé qui prend le dessus.
Le fait d'envoyer à la connexion .SQLExecute ("SET NAMES'utf8'; SET
CHARACTER_SET 'utf8'; ") ne change rien. Ca me parait d'ailleurs
logique, car si c'est le plug-in qui a un problème, modifier le jeu
de caractères de MySQL ne change rien.
Voilà, ça marche... mais il faut toujours passer pas un
DefineEncoding. Ceci doit ralentir les choses... Si ce sacré plug-in
pouvait fonctionner correctement, cela serait merveilleux !
Encore merci à tous
Christian BAUDRANT
|