Discussion :

[wstboss71]

Bonjour à tous,

Porduits utilisés et version:
- Borland Developper Studio 2006 (Delphi pour Win32)
- MySQL 5.0.54 (enterprise)

Le but de mon programme de test est tout simple:
- Lire un fichier contenant une instruction SQL (INSERT INTO...)
- Réaliser une connexion ADO entre Delphi et MySQL
- Executer l'instruction SQL
Et ceci doit marcher pour une base MySQL avec un charset défini soit en Latin1, soit en UTF8 ou soit en cp932 (japonais).

Tout fonctionne correctement pour latin1 et utf8.
Là ou tout commence à merder c'est avec le charset japonais cp932. Les caractères insérés dans la base ne sont pas correcte (je me retrouve avec des ???). Pourtant j'ai tout mis de mon côté pour que ça marche:
- OS japonais (win 2000)
- base + tables MySQL définies avec le charset cp932
- Drivers ODBC configuré sur le charset cp932
- le fichier a été testé en ANSI ou UNICODE
- la commande SQL du fichier est récupéré dans une widestring

J'ai l'impression qu'il manque quelque chose du côté de Delphi et de la connexion ADO pour que ça marche.

Je ne vois plus ce que je peux faire pour faire foncitonner cela, si quelqu'un a déjà rencontré ce problème ou a une idée, je suis preneur ! Si vous avez besoin de plus d'information, n'hésitez pas à me demander.

Merci d'avance à tous ceux qui m'aideront à résoudre ce problème.
Cordialement,
Vincent

[ShaiLeTroll]

Dans ton système, toutes les autres applications s'affichent en Japonais correctement ?

Sinon tout ce qui affichage de police UNICODE pose bcp de soucis avec Delphi, tu devrais voir si mettre des composants TNT

dans "[D6] Comment afficher du turc dans un TMenuItem ?" on parlait d'une lib qui permet de gérer l'UniCode avec les composants delphi standard, je n'ai pas réussi à que cela fonctionne, mais d'autre si, c'est que cela doit fonctionner sur un OS adapté

[wstboss71]

Dans ton système, toutes les autres applications s'affichent en Japonais correctement ?

Oui il n'y a aucun problème.

Sinon tout ce qui affichage de police UNICODE pose bcp de soucis avec Delphi, tu devrais voir si mettre des composants TNT

Je vais faire un test avec les composants TNT pour voir, bonne idée.

[ALWEBER]

J'exploite une base de donnée en caractères japonais. Il n'y a pas de problème particulier. Comme je n'ai pas touché à cette base depuis deux ou trois ans je vais regarder dans mes programmes pour te donner une solution.
Pour le chinois et le japonais j'utilise les polices suivantes :

Cjsongs.ttf
Cukaim.ttf
Cumings.ttf
JMINCHOS.TTF
JROUNDGM.TTF

[wstboss71]

dans "[D6] Comment afficher du turc dans un TMenuItem ?" on parlait d'une lib qui permet de gérer l'UniCode avec les composants delphi standard, je n'ai pas réussi à que cela fonctionne, mais d'autre si, c'est que cela doit fonctionner sur un OS adapté

je pense qu'il te manquait l'ajout de de tables de conversion des page de codes dans Windows.

[wstboss71]

J'exploite une base de donnée en caractères japonais. Il n'y a pas de problème particulier. Comme je n'ai pas touché à cette base depuis deux ou trois ans je vais regarder dans mes programmes pour te donner une solution

oui ce serait intéressant parce que là je séche. Merci d'avance.

[ALWEBER]

Voir mon précédent message j'ai listé les polices utilisées

[ShaiLeTroll]

je pense qu'il te manquait l'ajout de de tables de conversion des page de codes dans Windows.

Euh, surement, et cela s'ajoute comment ? en ajoutant des langues dans les paramètres régionnaux ???
J'en ai plein de coché (y compris le turc 10081 et le 1254)

[wstboss71]

Euh, surement, et cela s'ajoute comment ? en ajoutant des langues dans les paramètres régionnaux ???

Sous XP, paramètres régionaux et linguistiques -> onglet Options avancées
il faut cohcer la case qui va bien.

[ALWEBER]

Penser à traiter le "Font.Charset"
en ANSI_CHARSET ou en DEFAULT_CHARSET
suivant les cas.

[ShaiLeTroll]

lol, le temps que tu me répondes wstboss71, j'avais trouvé, ... et donc mince, pourquoi donc cette lib ne fonctionnait pas ... vu que c'est coché ...

[wstboss71]

Penser à traiter le "Font.Charset"
en ANSI_CHARSET ou en DEFAULT_CHARSET
suivant les cas.

oui mais en ce qui me concerne, je n'utilise pas de composant visuel avec une propriété font. J'utilise un chaine (sIUD:WideString) donc la valeur vient d'un fichier et qui est transmise à un TADOQuery (TQue.SQL.SetText(PWideChar(sIUD)); ).

[ShaiLeTroll]

Ah, mais SQL c'est une TStrings, ça support le Wide ??? un petit UTF8Encode serait judicieux ...

[ALWEBER]

Quelques éléments
- A mon avis tu peux laisser ton driver ODBC en charset standard
- D'autre part tu gère simultanément de l'UNICODE (UTF8)
et de l'ANSI (Latin et cp932) ce qui n'est pas forcément une bonne chose.
- L'ordre de tri de ta base doit être binaire et non alphabétique.

[wstboss71]

Ah, mais SQL c'est une TStrings, ça support le Wide ??? un petit UTF8Encode serait judicieux ...

A priori il doit supporter le Wide, puisqu'il réclame un PWideChar en parametre de TQue.SQL.SetText(param).

[wstboss71]

- A mon avis tu peux laisser ton driver ODBC en charset standard

C'est ce que j'ai essayé mais ça ne change rien.

- D'autre part tu gère simultanément de l'UNICODE (UTF8)
et de l'ANSI (Latin et cp932) ce qui n'est pas forcément une bonne chose.

oui c'est bien ce que je pense aussi mais j'ai pas vraiment le choix, il faut que ça marche pour tous ces charset.

- L'ordre de tri de ta base doit être binaire et non alphabétique.

si le tri est binaire, ça veut dire que les champs de mes tables sont de type binaire ? donc plus de tri suivant l'alphabet du pays. Ce n'est pas envisageable, j'ai un client tcheque qui m'a déjà reclamé son petit charset et sa petite collation (utf8 / utf8_czech_ci) pour que ces données soit bien triées.

[wstboss71]

j'ai comparé l'encode de la valeur inséré et celle que je devrais avoir, la différence se trouve sur le premier octet qui devrait etre en Hexa 83 et qui se retrouve etre 3F. Je me demande bien pourquoi ?

[ShaiLeTroll]

Je suis en D7, c'est un peu vieux mais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

procedure SetText(Text: PChar); virtual;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
constructor TADOQuery.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FSQL := TStringList.Create;
  TStringList(FSQL).OnChange := QueryChanged;
  Command.CommandTextAlias := 'SQL'; { Do not localize }
end;

Donc je confirme, qu'une conversion est nécessaire ...

[wstboss71]

en D2006, c'est du Wide:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
constructor TADOQuery.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FSQL := TWideStringList.Create;
  TWideStringList(FSQL).OnChange := QueryChanged;
  Command.CommandTextAlias := 'SQL'; { Do not localize }
end;

Par acquis de conscience, j'ai testé avec une conversion, ça ne change rien à la situation.

[ALWEBER]

A titre d'exemple tu peux aller sur ce lien :
http://frank.college-de-france.fr
C'est la base dont je te parlais