Discussion :

[Invité]

Bonjour,

Je développe une application VB 6 sur une base Oracle 10g multilingue avec des jeux de caractères chinois, japonais, européen ( ouest et est ) notamment. Pour cela, l'Unicode semble être la bonne solution.
J'ai donc modifé les paramètres suivants sur le serveur de la base:

NLS_LANGUAGE='AMERICAN_AMERICA.UTF8'
NLS_CHARACTERSET='UTF8'

Et malgré ça, les caractères chinois dits "traditionnels" ne sont pas insérés correctement dans la base, c'est-à-dire qu'ils ne sont pas interprétés comme des caractères chinois. J'ai bien pris soin de réserver un espace suffisamment large pour ces champs puisqu'ils peuvent être codés sur 4 octets.
J'utilise un ordre SQL "insert into " pour faire des insertions dans la base

Merci

[bouyao]

Est ce que tu a vérifié l'affichage de ton select dans SQLPLUS sans passer par VB6 ?

[LeoAnderson]

VB6 sait gérer l'unicode ?
et il faut vérifier avec iSQL*Plus qui est en mode Web et non avec SQL*Plus qui est un programme "DOS" et donc qui sera incapable, dans tous les cas, de traiter l'unicode.


le "bon" test est avec iSQL*Plus :

1. En clavier "français", saisir tout l'ordre INSERT sauf la colonne chinoise
2. En clavier "chinois" saisir la chaine chinoise manquante
3. repasser en clavier français
4. faire un commit
5. faire un select

(et il faut vérifier en affichant les sources de la page que le jeu de caractère utilisé dans la page web est bien de l'unicode)

[Invité]

j'ai effectué le test sur isql*plus
la valeur retournée par le select dans le champ de caractères chinois est : ???????? => ce n'est interprété

Cependant, la valeur du champ dans VB correspond bien à des caractères chinois puisque j'ai pu les visualiser en sortie d'un fichier XML
Par contre, dans VB, j'ai bien un affichage de ??????? pour ces caractères
VB code bien les cacartères en Unicode

J'utilise le composant ADO 2.7 qui est théoriquement Unicode.

J'ai essayé de convertir ces caractères dans VB via StrConv(chaine, vbFromUnicode, 'page de code chinois')

Mais s'en résultat

Merci

[Skrink]

Le NLS ne gére pas le jeu de caractére de ta base mais le langage par défaut de discussion avec tes clients si ceci n'ont pas définies leur propre langues.

Pour enregistrer correctement des codes Unicode ou Utf dans ta base il est nécessiare que celle ci ait été créé avec ces jeux de caractères.

Autrement Oracle discute en UTF mais traduit les caractéres dans le langage da la base . Si celle ci est par exemple en langage Européen, la traduction du chinois est perdu puisque les caractéres sont inconnus.

[LeoAnderson]

Le NLS ne gére pas le jeu de caractére de ta base mais le langage par défaut de discussion avec tes clients si ceci n'ont pas définies leur propre langues.

ça, c'est le NLS_LANG.
Mais il y a aussi le NLS_CHARACTERSET qui lui définit bien le jeu de caractères de la base ! :-)

Pour enregistrer correctement des codes Unicode ou Utf dans ta base il est nécessiare que celle ci ait été créé avec ces jeux de caractères.

Autrement Oracle discute en UTF mais traduit les caractéres dans le langage da la base . Si celle ci est par exemple en langage Européen, la traduction du chinois est perdu puisque les caractéres sont inconnus.

Et justement, le U de UTF signifie bien Universal, donc le chinois de l'est ou de l'ouest devrait être codé sans problèmes...

[LeoAnderson]

j'ai effectué le test sur isql*plus
la valeur retournée par le select dans le champ de caractères chinois est : ???????? => ce n'est interprété

et dans les sources de la page, sous iSQL*Plus, est-ce que le jeu de caractères est bien de l'unicode ?

[Skrink]

Il y a confusion entre le langage et le support de base.

le cerveau enregistre en francais mais peut parler en anglais.

tu peux discuter avec oracle en utf, c'est pas un souci mais si ta base n'est pas capable d'enregistrer dans ces fichiers ces caractéres, quand tu les relira, il sera incapable de te les retraduire.

Si ta base n'a pas été créé avec un support de charactére UTF , elle sera incapable de les enregistrer. Il te faut alors traduire ta base par un jeu d'import export dans une nouvelle base UTF.

Tu ne peux ecrire un caractére sur 32bit, quand les caractéres dans tes fichiers ne font que 16bits.