Soucis de NLS_LANG

[Ryle]

Bonjour,

Je poste sur ce forum le début de ma conversation avec Fadace, ayant un problème de conversion de caractères que je ne parviens pas à résoudre malgré les explications du tutoriel.

Voici le contexte :

- J'ai un serveur Win 2k avec easyphp 1.8, un site en php et un client oracle, dont le charset en base de registre est FRENCH_FRANCE.WE8MSWIN1252
- J'ai une base de données oracle sous linux, qui est installée en AMERICAN_AMERICA.WE8ISO8859P1

=> quand je saisie certains caractères spéciaux (genre euro, le caractère 3pts de word "…", le "œ", etc.) ceux-ci sont stockés dans la base sous forme de "¿" (#0191) au lieu de #164 pour l'euro (qu'il ne sait pas interpréter en WE8ISO8859P1, mais qu'il peut si j'ai bien compris restituer quand php l'interroge). Or lorsque je les récupères (toujours en php), ils apparaissent tous sous la forme de points d'interrogations inversés...

Application et base ont été changés de serveur et je n'ai plus accès aux précédents, sur lesquels la conversion fonctionnait bien. Il doit donc y avoir un réglage à faire sur le système ou le fichier de configuration d'apache/php, mais impossible pour moi de trouver lequel..

Quand je fais un getenv() du NLS avec php, j'obtiens bien WE8MSWIN1252, donc celui du serveur, qui est en théorie transmis à oracle pour qu'il fasse la conversion avec son charset à lui.

Infos complémentaires :
La base est sous linux 2.6.8, distribution debian 3.1 (sarge).
La variable shell "LANG" du compte système oracle utilisé pour faire tourner Oracle est positionnée à "POSIX".
En interne, la variable Oracle nsl_language est positionnée à AMERICAN.

Merci d'avance pour toute suggestion

(et n'hésitez pas à y aller en explications, car les jeux de caractères est domaine dans lequel je ne connais vraiment pas grand chose )

[pifor]

Le caractère Euro n'est pas pris en compte par WE8ISO8859P1
mais par WE8ISO8859P15: voir les tables Microsoft qui détaille les jeux de caractères ISO sur lesquels Oracle se base: http://www.microsoft.com/globaldev/reference/iso.mspx

Je vous conseille:
1. de faire des tests avec SQL*Plus en mode graphique sous Windows en positionnant la variable NLS_LANG dans la fenêtre DOS avant d'appeler sqlplusw.exe pour reproduire les problèmes que vous avez sans passer par PHP.
2. de migrer votre base en WE8ISO8859P15.

[laurentschneider]

il est préférable de migrer en WE8MSWIN1252 qu'en WE8ISO8859P15, parceque WE8MSWIN1252 est un superset de WE8ISO8859P1

Note 264294.1 :
Choosing from WE8ISO8859P1, WE8ISO8859P15 or WE8MSWIN1252 as db character set

c'est vrai que d'utiliser un characterset Microsoft sous Linux/Unix peut poser des problèmes éthiques , mais sinon c'est ce que je conseille

[Ryle]

Bonjour et merci pour ces réponses !

La migration est effectivement une des options que j'envisage, mais comme ça ne se fait généralement pas sans problème, je la garde à défaut de mieux.

Ce que je cherche à faire dans un premier temps, c'est de retrouver la configuration du serveur précédent. En effet, sur ce dernier, avec la même base en WE8ISO8859P1, les caractères euros et autres étaient correctement restitués. Je ne dis pas qu'ils étaient bien stockés et il y avait alors déjà des "¿" dans sqlplus, mais la conversion se faisait bien avec php dans un sens comme dans l'autre... c'est cette configuration que j'essaie de retrouver avant de commencer à envisager des migrations

[fadace]

Malgré Metalink, je ne partage pas l'avis général de prendre le characterset Win pour un serveur Linux..., mais par contre, celui d'éviter le ISOP1...

Si avec un ISOP1, vous aviez effectivement un retour dans PHP d'un €, c'est que vous aviez déjà une double erreur de conversion et que le caractère en question était mal géré dans la base (puiqu'en P1, il n'y a pas de €) bien qu'il apparaisse correctement en retour.

En résumé, vous avez maintenant :

Sur le serveur Linux : jeu de caractère natif = iso_1 (je suppose ?)
Sur le serveur Oracle : jeu de caractère natif = AMERICAN_AMERICA.WE8ISO8859P1
Sur le client PHP : jeu de caractère natif = ANSI-Win
Sur le client Oracle : jeu de caractère natif = FRENCH_FRANCE.WE8MSWIN1252

Du moment que php retourne bien le jeu de caractère de Windows, on peut dire alors que votre configuration cliente est correcte. Pour vous en assurer, essayez de retourner via PHP l'output d'un

Code :

SELECT * FROM NLS_SESSION_PARAMETERS

Ensuite, via sqlplus sur Linux, effectuez la même opération pour bien déterminer ce que vous avez.

En dernier lieu, retournez-nous un

Code :

SELECT * FROM NLS_DATABASE_PARAMETERS

Pour retrouver ce que vous aviez à la base, essayez d'utiliser le même NLS_LANG sur le client que sur le serveur. ce faisant, vous pousserez le servezr à ne pas faire de conversion... mais ce n'est pas la solution à envisager en finale.

[laurentschneider]

je tiens à souligner que je conseille plutôt de migrer de WE8ISO8859P1 vers WE8MSWIN1252 que vers P15, attendu que MSWIN est un superset binaire de P1, donc probablement pas de problème de migration

Pour une nouvelle base, il te faut considérer AL32UTF8, le set universel

[Ryle]

Bonsoir,

Je prends bonne note de vos remarques
En attendant, voici le résultat des différentes requêtes, si jamais vous y trouviez quelque chose :

*** SQL+ Worksheet ***

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
> SELECT * FROM NLS_SESSION_PARAMETERS;
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   FRENCH
NLS_TERRITORY                  FRANCE
NLS_CURRENCY                   ¿
NLS_ISO_CURRENCY               FRANCE
NLS_NUMERIC_CHARACTERS         ,
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD/MM/RR
NLS_DATE_LANGUAGE              FRENCH
NLS_SORT                       FRENCH
NLS_TIME_FORMAT                HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT           DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT             HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT        DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY              ¿
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
 
17 ligne(s) sélectionnée(s).

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
> SELECT * FROM NLS_DATABASE_PARAMETERS
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               WE8ISO8859P1
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              10.2.0.1.0
 
20 ligne(s) sélectionnée(s).

*** PHP ***

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
NLS_LANGUAGE 		FRENCH 
NLS_TERRITORY 		FRANCE 
NLS_CURRENCY 		¿ 
NLS_ISO_CURRENCY 	FRANCE 
NLS_NUMERIC_CHARACTERS 	, 
NLS_CALENDAR 		GREGORIAN 
NLS_DATE_FORMAT 	DD/MM/RR 
NLS_DATE_LANGUAGE 	FRENCH 
NLS_SORT 		FRENCH 
NLS_TIME_FORMAT 	HH24:MI:SSXFF 
NLS_TIMESTAMP_FORMAT 	DD/MM/RR HH24:MI:SSXFF 
NLS_TIME_TZ_FORMAT 	HH24:MI:SSXFF TZR 
NLS_TIMESTAMP_TZ_FORMAT DD/MM/RR HH24:MI:SSXFF TZR 
NLS_DUAL_CURRENCY 	¿ 
NLS_COMP 		BINARY 
NLS_LENGTH_SEMANTICS 	BYTE 
NLS_NCHAR_CONV_EXCP 	FALSE

[fadace]

Il manque quelques lignes au niveau PHP, non (le CHARSET par ex)

[remi4444]

Envoyé par fadace

Il manque quelques lignes au niveau PHP, non (le CHARSET par ex)

Le charset étant invariant, il n'apparait que dans la vue au niveau database, c'est tout à fait normal...

[pifor]

OK pour le charset de la base mais NLS_LANG est une option de config qui est toujours définie en-dehors de la base au niveau OS (variable d'environnement ou registre Windows), qui peut être modifiée et qu'on ne peut pas consulter avec une commande SQL.

Sous Windows la commande SQL*Plus suivante permet d'afficher la valeur
(c'est le message d'erreur):

Code :

1
2
3
 
SQL> @.[%NLS_LANG%]
SP2-0310: impossible d'ouvrir le fichier ".[FRENCH_FRANCE.WE8MSWIN1252]"

[Ryle]

Bonjour,

En exéccutant ta commande sous SQL+ :

Code :

1
2
SQL> @.[%NLS_LANG%]
SP2-0310: impossible d'ouvrir le fichier ".[FRENCH_FRANCE.WE8MSWIN1252]"

J'obtiens donc bien la valeur définie en base de registre pour le client oracle

Base de registre :
HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/KEY_XE
La variable NLS_LANG a pour valeur FRENCH_FRANCE.WE8MSWIN1252

Au cas où, il n'y a pas de NLS_LANG défini dans les variables d'envrionnement.