Discussion :

[j6m]

Bonjour,
j'ai installé une base Oracle XE sous Windows pour tester ruby on rails avec les exemples d'Oracle.
Après quelques galères avec le client, la variable TNS_ADMIN et autres alias de connexion, tout fonctionne correctement avec APEX sur le port 8080 si ce n'est les données :
quand je les saisis dans l'appli web codée en ruby, et que je les affiche par le même moyen, pas de problèmes. En revanche, quand je les visualise depuis APEX ou par SQL*Plus j'ai les vilains caractères du genre ¢ et autres.
Quand j'insére un "é" par SQL*Plus, c'est par l'appli web sous RoR que les caractères sont incohérents.
Du coup j'ai un doute sur le paramétrage de la partie Oracle :

database en AL32UTF8
client SQL en WE8PC850 => NLS_LANG=FRENCH_FRANCE.WE8PC850. Cette variable est aussi initialisée dans use_ruby.cmd
client Zindoz en WE8MSjesaisplusquoimaisje suis sûr que c'est le bon!

sous l'appli Web ruby
Title Text
é ééééééé

sous SQL*Plus :
ID
----------
TITLE
------------------

TEXT
------------------

68
├®
├®├®├®├®├®├®├®

réciproquement j'insère une ligne avec des accents depuis SQL:
ID
----------
TITLE
------------------------

TEXT
------------------------

68
├®
├®├®├®├®├®├®├®

81
à
ce à vient de sqlplus

et là c'est dans mon appli ruby que ça ne va plus :
é ééééééé Show Edit Destroy
� ce � vient de sqlplus Show Edit Destro

j'aurais tendance à penser que c'est ruby qui a tort mais je ne vois pas encore où le lui dire...


il est possible que les jeux de caractères de la base et de son serveur Web, mais surtout de SQL*Plus, soient insuffisants pour afficher ce qui vient l'appli web RoR (la fonte). Mais quand même un e accentué ça devrait être à leur portée. D'ailleurs ces caractères existent bien dans SQLPlus (voir ci-dessus).

Je suis un peu perdu et du coup j'ai des doutes sur mon install Oracle : quand je fais un "export csv" depuis APEX, j'ai les mêmes caractères ignobles.

Pouvez-vous au moins me rassurer sur ce point? Ça me mettra du coeur à l'ouvrage pour la partie ruby...

[j6m]

je me demande si ce n'est pas là qu'est le problème :
FRENCH_FRANCE pour la base, ne faudrait-il pas mieux AMERICAN_AMERICA (toujours en UTF8, et en laissant les clients positionner leur langue s'il y a lieu) ?

[pifor]

Les paramètres langage et territoire de NLS_LANG n'interviennent pas dans la conversion de caractères entre le client et le serveur.

sqlplus.exe (mode caractère) ne fonctionne pas exactement comme sqlplusw.exe (mode graphique): il ne faut pas mettre le même paramètrage pour NLS_LANG.Voir le tutoriel NLS.

Sous Windows, Oracle va cherche par défaut la valeur de NLS_LANG dans le registre mais on peut la redéfinir en tant que variable d'environnement avec:

Code :

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

1
2
 
set NLS_LANG=....

Cette valeur ne sera prise en compte que pour les exécutables démarrés depuis le processus qui a exécuté la commande DOS "set".

[j6m]

bonjour et merci de votre réponse ; sur la machine où tourne ruby, j'ai installé Oracle Client 10g Express Edition, je n'ai donc que sqlplus dos. Et je fais un "set NLS_LANG=FRENCH_FRANCE.WE8PC850" avant de lancer sqlplus, comme vous le conseillez. J'ai d'ailleurs consulté le tutoriel dont vous parlez, bien utile pour vérifier ma config.

C'est aussi dans le fichier de paramétrage de ruby, dans environment.rb.
Je pense que je vais essayer d'installer une autre base XE en AMERICAN_AMERICA, que ruby aura peut-être moins de difficultés à gérer.
Y a t'il d'autres utilisateurs ruby / oracle?

Je vous donnerai la suite des événements.
Encore merci.

[pifor]

Je pense que je vais essayer d'installer une autre base XE en AMERICAN_AMERICA

Ceci n'a pas vraiment de sens parce que le language et le territoire au niveau de la base ne sont que des paramètres dynamiques utilisés par défaut si le client ne définit pas NLS_LANG. Par contre, créer une nouvelle base avec un nouveau jeu de caractères a en général du sens car on ne le change pas facilement. Mais attention avec XE vous ne pouvez pas créer une nouvelle base sur la même machine où XE est déjà installé : il y a une limitation de 1 base par machine: avec XE, vous pouvez uniquement choisir le package d'installation qui impose le jeu de caractères de la base.

[j6m]

cette base est une ébauche de test donc pas de souci pour la supprimer.
Pour le jeu de caractères, selon vous c'est donc le characterset qu'il faudrait changer par exemple en WE8MSWIN1252 ?

[pifor]

Non , AL32UTF8 est le jeu le plus complet qui existe. Il faudrait plutôt utiliser un vrai client graphique pour Windows du style TOAD ou SQL Developer. Vous pouvez vérifiez le code binaire des caractères stockés dans la base avec la fonction DUMP (et 1017) et comparer avec http://www.utf8-chartable.de/.

[j6m]

j'avais essayé la fonction dump mais sans mémoriser le résultat. Entre-temps toutefois, je sens implicitement dans vore message que l'explication de mes problèmes d'affichage tiendrait dans les capacités d'affichage du SQL*Plus. Mais quand j'affiche mes données par l'interface d'administration Web de Oracle XE, ça devrait s'afficher correctement?
Je vais installer SQL dev et/ou récupérer la focntion dump pour vérifier.

Merci et à bientôt.

[j6m]

par SQL, dans ma table j'ai ça :
21
é
e accent aigu

2
premier
sans accents

ID
----------
TITLE
---------------------------------------------------------------------------

TEXT
---------------------------------------------------------------------------


4
deuxi+¿me
avec accents
et d'après dump ça correspond aux caractères suivants :
SQL> select dump(title,1017) from books where id = 4 or id = 21;

DUMP(TITLE,1017)
--------------------------------------------------------------------

Typ=1 Len=12 CharacterSet=AL32UTF8: d,e,u,x,i,e2,94,9c,c2,bf,m,e
Typ=1 Len=2 CharacterSet=AL32UTF8: c3,a9

et je ne trouve même pas de table Unicode avec ces caractères

[pifor]

Code :

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

Typ=1 Len=2 CharacterSet=AL32UTF8: c3,a9

semble correct pour "é" d'après la table citée plus haut.

Code :

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

1
2
 
Typ=1 Len=12 CharacterSet=AL32UTF8: d,e,u,x,i,e2,94,9c,c2,bf,m,e

semble incorrect.

[j6m]

oui en effet c'est cohérent côté Oracle ; je peux donc être rassuré quant à mes données dans la base?
J'ai fini par trouver une table de caractères qui contienne e2,94,9c, et c'est bien le code utf-8 de ce que m'affiche sql (├).
Donc c'est côté ruby qu'il y a quelque chose, j'ai déjà posté des messages à ce sujet mais ils auraient tendance à renvoyer sur les groupes rails (le framework qui génère le code ruby). Ça tombe bien, il y a d'autres soucis de ce coté-là : les IDs sont incrémentées de 2 en 2, les URL fabriquées travaillent avec "where ID=2.0" et autres joyeusetés.

[j6m]