Discussion :

[Michalak]

Bonjour,

Je veux extraire des données d'une base ORACLE 11 à partir d'un sqlplus dans un script sur un serveur LINUX.
La base ORACLE quand j'exécute via TOAD : select * from NLS_DATABASE_PARAMETERS ,
me renvoie ça :

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                   FRENCH
NLS_TERRITORY                  FRANCE
NLS_CURRENCY                   ?
NLS_ISO_CURRENCY               FRANCE
NLS_NUMERIC_CHARACTERS         ,.
NLS_CHARACTERSET               WE8ISO8859P15
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
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              10.2.0.4.0

J'ai donc positionné dans mon script :

Code :

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

1
2
 
export NLS_LANG=FRENCH_FRANCE.WE8ISO8859P15

Mais les caractères spéciaux ne s'exportent pas correctement :
select dans la base sous TOAD donne : ALCOOL 70 ° FL 250 ML
via mon script qui exécute la même requête via sqlplus: ALCOOL 70 <B0> FL 250 ML

Pourriez-vous m'éclairer sur ce sujet?
Merci d'avance

[Ikebukuro]

Le pb est certainement côté SQL*Plus, j'ai eu un pb similaire dernièrement.
Si tu as accès à SQL Developer, quel est le résultat?

Essaye d'appliquer l'astuce suivante : http://dbaoraclesql.canalblog.com/ar.../35339429.html

[pachot]

Bonjour,
Non il ne faut pas mettre NLS_LANG identique à la base. Ca n'aurait aucun interêt d'avoit un paramètre pour ça. C'est à vous de décider du format à exporter. Par exemple si vous voulez exporter avec les dates en format français, en langue anglaise et dans le jeu de caractère DOS 850 westen europe alors vous alez mettre NLS_LANG=ENGLISH_FRANCE.WE8PC850
Cordialement,
Franck.

[Michalak]

D'accord merci, mais je ne vois toujours pas quel paramètre utiliser pour récupérer mes données telles qu'elles sont en base.
Si je ne positionne pas dans mon script, le paramètre NLS_LANG, j'obtiens des ? au lieu du caractère ° par exemple.
J'ai déjà essayé par mal de combinaisons mais je n'aboutis pas à décoder proprement les caractères spéciaux.

[Pomalaix]

Etonnamment, le jeu de caractères de la base n'a aucune importance.
Qu'il soit X ou Y, peu importe, ce qui est décisif, c'est de configurer correctement la session CLIENTE.

Je fais l'hypothèse que vos données sont correctes en base.
Car si ce n'est pas le cas, et qu'elles ont été enregistrées avec un mauvais transcodage de caractères, vous n'arriverez probablement pas à les restituer sans "déformation".

Il faut déterminer le jeu de caractères de votre client.
Sous Linux, la commande "locale" vous indique le paramétrage en vigueur.

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
locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

Ici, il faut donc indiquer au serveur Oracle que les caractères qu'on échange avec lui seront codés en UTF-8.
Charge à lui de faire la conversion correcte en fonction du jeu de caractères de la base, mais ce qu'il lui faut, c'est savoir quelle "langue" parle le client.

C'est la variable NLS_LANG qui permet de déclarer au serveur le jeu de caractères que l'on utilise ; cette information est transmise lors de la connexion.
Par conséquent, on fait la déclaration suivante avant de lancer SQL*Plus :

Code :

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

export NLS_LANG=FRENCH_FRANCE.UTF8

Ce principe est à adapter selon la valeur LANG retournée par la commande "locale".

Enfin, pourquoi ai-je mis UTF8 dans NLS_LANG, et non UTF-8 comme le renvoie "locale" ?
Parce qu'Oracle a sa propre nomenclature des jeux de caractères.
Il faut donc rechercher le nom du jeu de caractères Oracle correspondant à celui de votre session OS.

Code :

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

1
2
3
select * from V$NLS_VALID_VALUES
where parameter='CHARACTERSET'
order by value;

[pachot]

pour récupérer mes données telles qu'elles sont en base.

On ne récupère jamais les données telles qu'elles sont en base. En base il y a des types date, numérique, des charactères internationaux... Si on exporte dans un fichier il n'y a que du texte. Il y a obligatoirement une transformation. Donc il faut décider comment. Si NLS_LANG définit un caracterset qui contient '°' alors il devrait sortir dans le fichier. Mais encore faut-il être sur de lire le fichier avec un outil qui utilise le bon caracterset. Peut-être qu'il est bien en WE8ISO8859P15 dans le fichier mais le terminal ne l'affiche pas correctement.

[Michalak]

La commande locale renvoie

Code :

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

LANG=fr_FR.UTF-8

mais en appliquant

Code :

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

export NLS_LANG=FRENCH_FRANCE.UTF8

, ce n'est pas mieux.

Pachot a raison, c'est mon terminal qui interprète mal, une fois transféré sur ma plateforme EAI et en utilisant aussi le bon encodage, je récupère bien les caractères spéciaux.

J'ai donc bien appliqué

Code :

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

export NLS_LANG=FRENCH_FRANCE.WE8ISO8859P15

pour que cela fonctionne.

Merci à tous pour ces éclaircissements.