Sqlplus sous Windows et lettres accentuées

Bonjour,

D'habitude, j'utilise presque exclusivement SQL Developer pour accéder à mes BDD Oracle et je peux modifier des données avec des lettres accentuées sans problème.

Depuis le confinement, avec mon ordi de télétravail, je ne peux accéder au serveur de prod que via ssh depuis un autre serveur et donc n'utiliser que Sqlplus. Et sous Windows, en plus ! :calim2:
Si je fais une requête UPDATE avec une donnée comportant une lettre accentuée, lorsque je SELECT ensuite la donnée, j'ai ?? à la place de la lettre accentuée.

Que faut-il faire pour que les lettres accentuées soient correctement interprétées ?

Comment faire les majuscules accentuées ?

Et vive Linux où je n'ai pas ces problèmes ! :)

Bonjour,

Quel est le characterset de ta base?
Il me semble que depuis Windows il faut que tu changes le code page en 850:

Code:

---

chcp 850

---

et en plus il faut que tu changes la police d'affichage du prompt (lucida console par exemple)

Pièce jointe 571201

Au temps pour moi...

Je suis en SSH dans une console Linux via Bitvise sous Windows. Ce que je fais se passe donc dans le serveur Oracle Linux et ne semble pas lié au fait que j'y accède depuis un poste Windows. :oops:

Code:

---

1 2 3 4 5 6 7 8 9

UPDATE matable SET prenom = 'élodie' WHERE id = 12345;   COMMIT;   SELECT prenom FROM matable WHERE id = 12345;

---

=> Affiche :

Citation:

---

prenom
------
??lodie

---

Et dans une application qui récupère cette donnée, ça devient 'lodie'. Il semble donc que ce soit mal enregistré en BDD.

Quand tu fais:

Code:

---

select 'élodie' from dual

---

ça s'affiche correctement?

Non, c'est pareil : ??lodie

Peut-être une piste ici : http://dbaoraclesql.canalblog.com/ar.../35339429.html

Est-ce que le NLS_LANG est bien setté avant de lancer sql*plus? Par exemple si la base est en AL32UTF8:

Code:

---

export NLS_LANG=FRENCH_FRANCE.AL32UTF8

---

Pièce jointe 571256

Merci, ça fonctionne.

Tu peux dire quelle solution a fonctionné?

Citation:

---

Tu peux dire quelle solution a fonctionné?

---

Le export NLS_LANG=FRENCH_FRANCE.AL32UTF8

Cinephil, depuis la 12c Oracle a créé un nouvel outil en mode caractère, sqlcl, as-tu essayé avec lui?
Il gère l'unicode en natif, peut-être que ça aurait résolu ton problème.

Citation:

---

Envoyé par CinePhil

Depuis le confinement, avec mon ordi de télétravail, je ne peux accéder au serveur de prod que via ssh depuis un autre serveur et donc n'utiliser que Sqlplus.

---

Bonjour, en faisant un tunnel ssh tu peux peut-être continuer à utiliser SQL Developer.
SQL Developer peut même le gérer: https://www.thatjeffsmith.com/archiv...g-ssh-tunnels/

Citation:

---

Envoyé par vanagreg

Est-ce que le NLS_LANG est bien setté avant de lancer sql*plus? Par exemple si la base est en AL32UTF8:

Code:

---

export NLS_LANG=FRENCH_FRANCE.AL32UTF8

---

---

Non non non, absolument pas !!!
NLS_LANG n'a pas à refléter le jeu de caractères de la base. Son rôle est d'indiquer quel est le jeu de caractères utilisé par l'OS client, de sorte que le serveur Oracle, correctement informé, puisse faire les conversions nécessaires dans les deux sens.

Dans votre démonstration, vous avez (involontairement) fait un tour de passe passe qui donne l'impression que ça marche, alors que fondamentalement, vous avez fait une totale erreur de paramétrage.


Pour prendre une métaphore, imaginons un système polyglotte, qui comprend et sait traduire toutes les langues, mais stocke les informations dans une seule langue, l'allemand.
Il travaille en fonction du drapeau que vous avez sur votre casquette.

Vous avez un drapeau français, et vous lui donnez le mot HIER à stocker dans le casier numéro 100. Il fait la conversion et stocke GESTERN.
Vous réclamez le contenu du casier numéro 100, le système traduit en retour et vous indique HIER.
Un autre individu qui porte un drapeau anglais réclame le contenu du casier numéro 100. Le système traduit en retour et lui indique YESTERDAY.

Autre scénario : vous êtes toujours français mais avez un peu trop fait la fête et portez par erreur une casquette avec un drapeau allemand.
Vous envoyez le mot HIER, que le système prend pour de l'allemand, à stocker dans le casier numéro 100. Il stocke HIER tel quel puisque pour lui il n'y a pas de traduction à faire.
Vous réclamez le contenu du casier numéro 100. Au vu de votre drapeau allemand, le système vous renvoie HIER tel quel, sans traduction. Vous vous dites que ça fonctionne parfaitement.
Un autre individu qui porte un drapeau anglais réclame le contenu du casier numéro 100. Le système traduit en retour et lui indique HERE.
C'est là que l'erreur est apparente.

Remplaçons le système polyglotte par le serveur Oracle, l'allemand par le jeu de caractères de la base, et le drapeau sur la casquette par NLS_LANG, et la logique devrait être claire...

Un peu de lecture :
https://www.oracle.com/fr/database/t...-nls-lang.html
https://fadace.developpez.com/oracle/nls/

Je donnais juste un exemple étant donné qu'aucune information n'a été fournie sur le paramétrage NLS de la base et du client. Puisque j'ai cru comprendre que le client était Oracle Linux, j'ai supposé qu'il était en utf8.

Donc si la base est en AL32UTF8 et le client en utf8, vous suggérez de ne pas indiquer AL32UTF8 dans NLS_LANG pour forcer une conversion?

Quel valeur aurait-il fallu mettre selon vous?

Comme on disait, il n'y a pas à considérer le jeu de caractères de la base pour paramétrer NLS_LANG.

NLS_LANG indique dans quel jeu de caractères fonctionne la fenêtre de travail du client.
S'il n'est pas défini, implicitement ce sera US7ASCII, donc les accents seront bouffés.

Code:

---

1 2 3 4 5 6 7 8

[oracle@v11rac2 ~]$ env | grep NLS NLS_LANG=french_france.US7ASCII   SQL> select 'élodie', dump('élodie') from dual;   '??LODI DUMP('??LODIE') ------- ----------------------------------------- ??lodie Typ=96 Len=7: 191,191,108,111,100,105,101

---

Sous Linux, c'est la commande nommée locale qui indique le jeu de caractères du client :

Code:

---

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=

---

On paramètre NLS_LANG en conséquence :

Code:

---

export NLS_LANG=FRENCH_FRANCE.UTF8

---

Code:

---

1 2 3 4 5

SQL> select 'élodie', dump('élodie') from dual;   'ÉLODIE' DUMP('ÉLODIE') ------------------ --------------------------------------------------------------------------------------------------------------- élodie Typ=96 Len=6: 233,108,111,100,105,101

---

Et quand on est sous Windows dans SQL*Plus classique, la fenêtre DOS d'un environnement français fonctionne dans la page de code 850 (vérifier par la commande chcp sans paramètre), et donc on fera :

Code:

---

set NLS_LANG=FRENCH_FRANCE.WE8PC850

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

SQL> select value from v$nls_valid_values where parameter='CHARACTERSET' and value like '%UTF8%';   VALUE ------------------------------ UTF8 AL32UTF8   SQL> select value from v$nls_valid_values where parameter='CHARACTERSET' and value like '%850%';   VALUE ------------------------------ WE8PC850

---

Oui tu as raison. Je me suis mal exprimé et merci pour le rappel. Comme j'utilise MobaXterm et que ma locale est en utf8 alors j'ai fais un raccourci trop rapide.