Probleme caractères coréens

**eric1970** · 02/06/2010, 18h08

Bonjour,
J'ai un problème sous oracle. Je voudrais afficher les caractères coréens comme 아해글 dans ma table, mais j'obtiens des points d'interrogations( ????).

Pour information : Mon champ est de type NVARCHAR2, et les caractères sont codés par : WE8ISO8859P15

En revanche quand je l'ajoute manuellement dans la table avec Copier-Coller ca fonctionne normalement, mais avec une requête, j'obtient des ????

Le soucis c'est que je ne pourrai pas modifier les caractères de la base car cela impactera énormément de choses.

Merci d'avance pour votre aide.

**tibal** · 02/06/2010, 19h47

Bonjour,

Pouvez-vous nous fournir le résultat de la requète suivante :

Code :

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

select * from NLS_DATABASE_PARAMETERS ;

De plus, lorsque vous dites

J'ai un problème sous oracle. Je voudrais afficher les caractères coréens comme 아해글 dans ma table, mais j'obtiens des points d'interrogations( ????).

A partir de quel outil interrogez-vous votre table ?

**pifor** · 02/06/2010, 20h56

Il faut lire et comprendre le tutoriel suivant http://fadace.developpez.com/oracle/nls/ pour bien comprendre le rôle de NLS_LANG lorsque les données sont écrites dans la base et lorsqu'elles sont lues.

**eric1970** · 03/06/2010, 17h17

Bonsoir,
Voici ce que me rend ma requête :

SELECT * FROM NLS_DATABASE_PARAMETERS ;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
NLS_LANGUAGE			AMERICAN
NLS_TERRITORY			AMERICA
NLS_CURRENCY			$
NLS_ISO_CURRENCY			AMERICA
NLS_NUMERIC_CHARACTERS		.,
NLS_CHARACTERSET			WE8ISO8859P15
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		CHAR
NLS_NCHAR_CONV_EXCP		FALSE
NLS_NCHAR_CHARACTERSET		AL16UTF16
NLS_RDBMS_VERSION		10.2.0.4.0

L'outil que j'intéroge est Sql Developer.
Pour confirmer un truc, quand je fais copier coler le coréen dans le champ ca marche, mais avec un Insert ç marche pas.

Merci

**tibal** · 03/06/2010, 20h56

Bonjour Eric,

Dans l'absolu, votre base aurait du être créée en KO16MSWIN949 (MS Windows Code Page 949 Korean) sur un OS Windows.

Vu que ce n'est pas le cas, avant de lancer votre outil pour requêter, modifiez votre character comme suit :

Code :

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

SET NLS_LANG=.KO16MSWIN949

Puis lancez SQL Developer et dites nous si ça corrige votre problème d'affichage.

**eric1970** · 04/06/2010, 10h59

Bonjour Tibal,
C’est vrai que dans l’absolu la base doit être autrement. Mais il faut savoir qu’il n y a pas que du coréen. La base est sensé recevoir tout caractère, puisque il s’agit d’une application qui gère l’internationalisation. Il y’a de L’hébreu, chinois, Arabe et autre….

La base est sur un serveur Linux et les postes clients sont variés, soit Windows, soit Linux...

Pour répondre à ta question

Code :

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

SET NLS_LANG=.KO16MSWIN949

Je ferai ça où ? Étant donné que je ne suis pas l’administrateur de la base. Le seul outil que j’ai à ma disposition est SQL Developer.

Merci

**tibal** · 04/06/2010, 11h06

Bonjour Eric,

La base est sur un serveur Linux et les postes clients sont variés, soit Windows, soit Linux...

Pour répondre à ta question
Code :
SET NLS_LANG=.KO16MSWIN949 Je ferai ça où ? Étant donné que je ne suis pas l’administrateur de la base. Le seul outil que j’ai à ma disposition est SQL Developer.

Pour les utilisateurs Windows :

Code :

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

1
2
3
Ouvrir une fenêtre DOS
SET NLS_LANG=.KO16MSWIN949 (Enter)
Lancer SQLDeveloper à partir de cette fenêtre DOS

Pour les utilisateurs Linux :

Code :

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

1
2
3
Ouvrir un SHELL
export NLS_LANG=.KO16MSWIN949 (Enter)
Lancer SQLDeveloper à partir de ce SHELL

Si ça fonctionne, faire un fichier BAT pour les Windows, un fichier .sh qui enchaîne tout ça.

**eric1970** · 04/06/2010, 13h20

Merci Tibal,
Malheursement ça ne marche pas en lançant la commande

Code :

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

SET NLS_LANG=.KO16MSWIN949

Est ce qu'il n ya pas de méthodes, de classes intermidiaires à utiliser pour stocker en mode qu'ont veut ?

Aussi j'ai utilisé la fonction Convert, mais ça ne marche toujours pas.

**neo9922** · 07/06/2010, 12h34

Envoyé par tibal

Bonjour Eric,

Dans l'absolu, votre base aurait du être créée en KO16MSWIN949 (MS Windows Code Page 949 Korean) sur un OS Windows.

Vu que ce n'est pas le cas, avant de lancer votre outil pour requêter, modifiez votre character comme suit :

Code :

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

SET NLS_LANG=.KO16MSWIN949

Puis lancez SQL Developer et dites nous si ça corrige votre problème d'affichage.

Bonjour Tibal,

Eric utilise les types de données N d'Oracle qui permettent de faire du multilingue dans une base de données non prévues initialement pour le faire (ancien projet qui voudrait conserver son existant mais en l'améliorant).
C'est pour ça que sa base est en P15 et qu'il a une problématique unicode (pour le KOREEN).

NB : la bonne syntaxe pour NLS_LANG est NLS_LANG=_.KO16MSWIN949 (le _ est important). Même si ça ne pose pas de problème à Oracle.

**tibal** · 07/06/2010, 12h40

Bonjour neo9922,

Que signifie exactement le _ dans

NLS_LANG=_.KO16MSWIN949

Merci par avance pour l'info.

**neo9922** · 07/06/2010, 12h44

Envoyé par tibal

Bonjour Eric,

Pour les utilisateurs Windows :

Code :

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

1
2
3
Ouvrir une fenêtre DOS
SET NLS_LANG=.KO16MSWIN949 (Enter)
Lancer SQLDeveloper à partir de cette fenêtre DOS

Pour les utilisateurs Linux :

Code :

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

1
2
3
Ouvrir un SHELL
export NLS_LANG=.KO16MSWIN949 (Enter)
Lancer SQLDeveloper à partir de ce SHELL

Si ça fonctionne, faire un fichier BAT pour les Windows, un fichier .sh qui enchaîne tout ça.

Re-bonjour Tibal,

C'est une bonne réponse en général mais pas pour SQL DEVELOPER.
Cf ce lien : http://download.oracle.com/docs/cd/B...a96529/ch9.htm

SQL DEV utilise en driver THIN. Le Driver THIN n'est pas influençable par NLS_LANG (dixit la documentation mais reste à vérifier).
SQL DEV est nativement UNICODE contrairement à SQLPLUSW.exe sous Windows.
Bref, positionner son charset en coréen dans l'environnement de lancement ne devrait pas influencer la communication (seul JDBC OCI est influençable avec cette méthode).
Les autres paramètres (TERRITORY et LANGUAGE) sont modifiables directement dans les properties de SQL DEV.

Je reste preneur de tout les tests que tu pourrai mener qui modifierait ces assertions.

NB : la solution de contournement que j'ai trouvé pour insérer des données coréennes dans cette BD est la suivante :

- génération d'un insert en format UTF-8 avec le notepad windows (compatible UNICODE)
- une fois le fichier enregistré avec option UTF-8 le transférer sous UNIX en mode BINAIRE
- sous UNIX, il faut retirer le BOM en début du fichier (BYTE ORDER MARK). Il existe des documents sur internet qui t'expliquent ce que c'est.
- positionner NLS_LANG=_.UTF8
- positionner NLS_NCHAR_CHARACTERSET=UTF8
- lancer sqlplus puis executer le script unicode.
- commiter (...)

A+
Virgile

**neo9922** · 07/06/2010, 12h47

Envoyé par tibal

Bonjour neo9922,

Que signifie exactement le _ dans

Merci par avance pour l'info.

Re ;o)

NLS_LANG est constitué de la composation de 3 variables : NLS_TERRITORY, NLS_LANGUAGE, et CHARSET. Les 2 séparateurs successifs sont "_" et ".".
Souvent nous voyons : NLS_LANG=french_france.WE8ISO8859P1 (par exemple).
Le charset modifie la comportement lié au transcodage (conversion cliente/serveur).
les 2 autres modifient le comportement des paramètres de localisation (séparateurs de milliers, la virgule, le format de date => qui est inversé pour le mois et les jours pour les EU ;o) ). Etc...

A+++
Virgile

**tibal** · 07/06/2010, 12h48

Merci Virgile pour ces informations.

**eric1970** · 08/06/2010, 14h27

Merci Virgile pour ton aide.
En effet, la solution que tu proposes est intéressante du point de vue technique vu qu’elle traite les choses d’une manière approfondie et cela permet de comprendre le fonctionnement de gestion des NLS_LANG.

Toutefois, il existe une solution (Proposer par notre collègue Romain) pour Sql Dveloper qui permet de prendre en compte l’insertion des caractères coréens. Je ne sais pas si cette solution est applicable pour d’autres outils autres que Sql Developer. Pour que tous le monde profite de la solution voici les grandes lignes à suivre.
Il s’agit de :
1- Editer sqldeveloper.conf qui se trouve dans le répertoire bin en ajoutant la ligne suivante :
AddVMOption -Doracle.jdbc.convertNcharLiterals=true

2 – Redémarrer SQL Developer

Merci Virgile.

**neo9922** · 09/06/2010, 15h11

Envoyé par eric1970

Merci Virgile pour ton aide.
En effet, la solution que tu proposes est intéressante du point de vue technique vu qu’elle traite les choses d’une manière approfondie et cela permet de comprendre le fonctionnement de gestion des NLS_LANG.

Toutefois, il existe une solution (Proposer par notre collègue Romain) pour Sql Dveloper qui permet de prendre en compte l’insertion des caractères coréens. Je ne sais pas si cette solution est applicable pour d’autres outils autres que Sql Developer. Pour que tous le monde profite de la solution voici les grandes lignes à suivre.
Il s’agit de :
1- Editer sqldeveloper.conf qui se trouve dans le répertoire bin en ajoutant la ligne suivante :
AddVMOption -Doracle.jdbc.convertNcharLiterals=true

2 – Redémarrer SQL Developer

Merci Virgile.

Yes ;o) de rien Eric.

La manipulation fonctionne nickel sur sqldeveloper 2.1.0.63.

A+++

**Pomalaix** · 09/06/2010, 15h33

Envoyé par eric1970

Pour que tous le monde profite de la solution voici les grandes lignes à suivre.
Il s’agit de :
1- Editer sqldeveloper.conf qui se trouve dans le répertoire bin en ajoutant la ligne suivante :
AddVMOption -Doracle.jdbc.convertNcharLiterals=true

2 – Redémarrer SQL Developer

Bonjour

Je viens de tester cette manipulation, mais après l'insertion des valeurs coréennes données en exemple initialement, le SELECT persiste à me renvoyer des points d'interrogation (que ce soit dans une colonne VARCHAR2 ou NVARCHAR2).

Je suis en 11.2, avec SQL Developer 2.1.1.64. Jeu de caractères de base WE8MSWIN1252, jeu national AL16UTF16.

Il y a manifestement des conditions supplémentaires à respecter pour que ça fonctionne...

**pifor** · 09/06/2010, 15h43

Pour moi le test marche avec:
- Oracle 11.2.0.1 sur Oracle Entreprise Linux avec VirtualBox

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 select * from nls_database_parameters where parameter like '%SET%';
 
PARAMETER
------------------------------
VALUE
--------------------------------------------------------------------------------
NLS_CHARACTERSET
AL32UTF8
 
NLS_NCHAR_CHARACTERSET
AL16UTF16

Code :

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

1
2
3
4
SQL> desc t;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 X                                                  NVARCHAR2(10)

- SQL Developer 2.1.0.63 sur Windows 7
- sqldeveloper.conf ne contient que les valeurs par défaut de l'installation

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
IncludeConfFile ../../ide/bin/ide.conf
 
SetJavaHome ../../jdk
 
AddVMOption  -Doracle.ide.util.AddinPolicyUtils.OVERRIDE_FLAG=true
 
AddVMOption -Dsun.java2d.ddoffscreen=false
 
AddVMOption -Dwindows.shell.font.languages=
 
AddVMOption  -XX:MaxPermSize=128M
 
 
IncludeConfFile  sqldeveloper-nondebug.conf

**eric1970** · 09/06/2010, 15h45

As-tu redémarré le SQL Developer ?

Qu'est-ce que te renvoie le select de ton champ dump(ton_Champ) ?

**Pomalaix** · 09/06/2010, 16h11

Envoyé par eric1970

As-tu redémarré le SQL Developer ?

Qu'est-ce que te renvoie le select de ton champ dump(ton_Champ) ?

Yep !
Quant au dump, il n'a pas fière allure en effet :

Code :

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

Typ=1 Len=6: 0,191,0,191,0,191

**neo9922** · 09/06/2010, 16h12

Envoyé par Pomalaix

Bonjour

Je viens de tester cette manipulation, mais après l'insertion des valeurs coréennes données en exemple initialement, le SELECT persiste à me renvoyer des points d'interrogation (que ce soit dans une colonne VARCHAR2 ou NVARCHAR2).

Je suis en 11.2, avec SQL Developer 2.1.1.64. Jeu de caractères de base WE8MSWIN1252, jeu national AL16UTF16.

Il y a manifestement des conditions supplémentaires à respecter pour que ça fonctionne...

Oui, il faut utiliser une syntaxe spéciale d'insertion (je donne l'exemple ici, c'est le petit "n" qui fait la différence) :

insert into sfe_adm.T_MET_KEYWORD values (1, n'아해글' ,'KR','p057025',sysdate,2430700001);

sinon renvoie moi les informations complémentaires (ordre sql utilisé pour insérer dans la table, describe de ta table, et je ferai l'essai).
A++

Probleme caractères coréens

Administration Oracle

Discussions similaires

Partager

Partager