Discussion :

[tck-lt]

Bonjour,

je disposais d'une base en WE8MSWIN1252, je l'ai modifiée en suivant la doc en AL32UTF8. J'ai été contraint de faire un export (NLS_LANG=AMERICAN_AMERICA.AL32UTF8) puis un truncate de mes tables car les données étaient "Convertible" dans le csscan. J'ai ensuite réimporté mes données toujours avec cette valeur de NLS_LANG.

- Ai-je bien fait de réaliser mon export dans ce jeu de caractères ? Ne fallait-il pas le faire en WE8MSWIN1252 ?
- Si oui, quand je consulte mes données, l'accentuation n'est pas correcte (Ex pour le prénom Frédéric : Frédéric). Si j'ajoute un nouveau prénom accentué, il n'y a pas de souci. Je pensais que l'import permettrait la conversion des accents, je me trompe ? Vais-j être obligé de reprendre tous les enregistrements concernés svp ?

Merci d'avance pour vos savantes réponses.

[Pomalaix]

... quand je consulte mes données, l'accentuation n'est pas correcte ...

Avec quel outil le faites-vous ? Certains ont leur propre paramétrage NLS, qui ne repose pas sur la variable d'environnement NLS_LANG.

[pachot]

Bonjour,

- Ai-je bien fait de réaliser mon export dans ce jeu de caractères ? Ne fallait-il pas le faire en WE8MSWIN1252 ?

a priori les 2 fonctionnent:
export/import avec NLS_LANG=AMERICAN_AMERICA.AL32UTF8 fait la conversion lors de l'export, NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 aurait fait la même conversion lors de l'import.

2 possibilités:
1. soit les données sont bonnes dans la base (stockée avec le code correspondant au characterset de la base) mais une mauvaise conversion est faite à l'affichage
2. soit les données n'étaient pas bonnes au départ dans la base (elles n'étaient pas réellement stockées en MSWIN1252) et la conversion qui s'est faite n'était pas correcte.

Pour éliminer la 2ème solution, c'est facile: faire le select sous sqldeveloper. C'est en unicode, indépendant du NLS_LANG setté sur le client, donc la conversion base -> client sera toujours bonne.

Il semble que 'Frédéric' soit un 'Frédéric' qui a subi une transformation WE8MSWIN1252->AL32UTF8 de trop.
Par exemple, sur une base WE8MSWIN1252 avec un client UTF-8 je rajoute cette conversion:

Code :

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

1
2
3
4
> select convert('Frédéric','AL32UTF8','WE8MSWIN1252') from dual
CONVERT('FRÉDÉRIC','AL32UTF8','WE8MSWIN1252')
---------------------------------------------
Frédéric

C'est ce qu'a fait l'import/export. Donc mon hypothèse, c'est que vous aviez déjà stocké du UTF-8 dans l'ancienne base, inséré avec un client UTF8, mais avec un NLS_LANG qui faisait croire à Oracle que vous insériez du WE8MSWIN1252. Donc il n'a pas fait de conversion et a mis directement les codes UTF-8 dans la base.

vais-j être obligé de reprendre tous les enregistrements concernés svp ?

Si vous êtes certains que toutes les données ont été insérées de la sorte, alors il suffirait de convertir dans l'autre sens tous les VARCHAR:

Code :

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

1
2
3
4
> select convert('Frédéric','WE8MSWIN1252','AL32UTF8') from dual
CONVERT('FRéDéRIC','WE8MSWIN1252','AL32UTF8')
-----------------------------------------------
Frédéric

Mais s'il y avait un mix de clients bien configurés et mal configurés, alors il y a de tout

Cordialement,
Franck.

[tck-lt]

Tout d'abord merci à tous les 2.

Il subsiste encore quelques confusions dans ma tête.

Si j'ai une base en MSWIN1252 et un client en UTF8, si je fais des inserts, ceux-ci seront au format UTF8 ?
Dans ce cas, à quoi sert le NLS_CHARACTERSET de la base puisqu'à priori que ce soit en écriture ou en lecture, c'est le NLS_LANG du client qui prime.
C'est vraiment confus pour moi cette histoire de CHARACTERSET.

Pomalaix>en local sur mon serveur avec sqlplus. Du coup, j'ai fait les tests en modifiant mon NLS_LANg à souhait.

pachot>je vais me renseigner auprès de l'ingé qui a développé le site web. Je sais que vu que c'est du web, il me semble qu'il a du faire pas mal d'insert en UTF-8, mais tout ? ça c'est une autre paire de manche.

[Pomalaix]

Ce qu'il faut comprendre, c'est qu'on ne transmet pas des caractères (au sens de symbole graphique), mais des codes numériques.

Par exemple, le client envoie 144 au serveur, dont la base fonctionne en MSWIN1252.
144 ne correspond pas au même caractère dans tous les jeux de caractères. Disons (c'est bidon mais le principe est là), que 144 correspond à É en UTF8, mais à @ en MSWIN1252.

Quand le serveur reçoit 144, il faut qu'il sache de quel jeu de caractères on parle. Eh bien c'est le NLS_LANG du client qui donne cette information.
Si le client mentionne dans son NLS_LANG le même jeu de caractères que celui de la base, alors les deux parties sont considérées comme parlant nativement la même langue, et il n'y a pas de conversion à faire. Le serveur enregistre alors 144 tel quel.
Si le client a un NLS_LANG qui correspond à un jeu de caractères différent de celui de la base, alors une conversion sera effectuée.
Par exemple, le client a envoyé 144, mais le serveur, à l'aide de ses tables de conversion, enregistre 333 (en admettant que 333 est le code numérique correspondant au caractère É en MSWIN1252, et que le client mentionnait correctement UTF8 dans son NLS_LANG).

Maintenant, si vous avez indiqué un mauvais jeu de caractères au niveau du NLS_LANG, alors une mauvaise conversion aura lieu.
En particulier, si vous avez mis par erreur MSWIN1252 dans le NLS_LANG du client (alors que dans les faits il fonctionne en UTF8), et que la base fonctionne en MSWIN1252, aucune conversion n'aura lieu alors qu'il en fallait une. Vous avez tapé É sur votre client, mais vous enregistrez (selon mon exemple bidon) @ dans la base.

[tck-lt]

Ce qu'il faut comprendre, c'est qu'on ne transmet pas des caractères (au sens de symbole graphique), mais des codes numériques.

Par exemple, le client envoie 144 au serveur.
144 ne correspond pas au même caractère dans tous les jeux de caractères. Disons (c'est bidon mais le principe est là), que 144 correspond à É en UTF8, mais à @ en MSWIN1252.

Si le client a un NLS_LANG qui correspond à un jeu de caractères différent de celui de la base, alors une conversion sera effectuée. Par exemple, le client a envoyé 144, mais le serveur enregistre 333, si 333 est le code numérique correspondant au caractère É en MSWIN1252.

Je pense que c'est ce dernier cas dans lequel j'étais lors de l'insertion.
Des conversions sont-elles faites lors des exports/imports svp ? Et pensez-vous que je puisse refaire ma manipulation de modification de NLS_CHARACTERSET en jouant sur les exports/imports et le NLS_LANG pour régler mes problèmes d'accent des données déjà existantes ou dois-je régler cela de la manière dont le suggère pachot à savoir reprendre tous les varchar ?

Merci.

[pachot]

Bonjour,

Le soucis, c'est qu'une mauvaise config ne se voit pas toujours lorsqu'on reste sur le même client.

Un exemple, sachant que le 'é' a le code E9 en MSWIN1252 et le code C3A9 en UTF-8 et que par contre en MSWIN1252 le code C3 est 'Ã' et le code A9 est '©

Bonne config:
1) l'utilisateur saisit 'é' sous windows non-unicode, donc E9, avec NLS_LANG=WE8MSWIN1252 , la conversion client->base fait MSWIN1252->MSWIN1252 , c'est E9 qui est stocké
2) l'utilisateur fait un select sous sqldeveloper, en unicode, conversion base->client fait MSWIN1252->UTF-8, c'est C3A9 qui est affiché. en unicode, c'est donc bien un 'é'

Pas de problème.

Maintenant, mauvaise config:
1) l'utilisateur saisit 'é' dans un client unicode, donc C3A9, mais avec NLS_LANG=WE8MSWIN1252. Oracle croit que C3A9 est en MSWIN1252, donc qu'on a saisit les 2 caractères 'Ã' et '©'. Il fait sa conversion MSWIN1252->MSWIN1252 qui ne change rien, et il stocke donc C3A9.
2) ce même client, lorsqu'il fait un select va faire la conversion base->client MSWIN1252->MSWIN1252 et va donc afficher C3A9, donc 'é' pour le client unicode, donc il ne voit pas d'erreur même si ce qui est stocké ne correspond pas au characterset de la base.
3) par contre, un client correctement configuré, lui, va faire la conversion correcte en pensant que C3A9 est du MSWIN1252 (celui de la base) et va voir 'é'

Avec l'export/import, il y a 2 conversions qui sont faites:
l'export va faire base->fichier dump en fonction du NLS_LANG lors de l'export
l'import va faire fichier dump->base en fonction du NLS_LANG lors de l'import
On est donc censé avoir le même NLS_LANG pour l'export et pour l'import - et qui correspond à ce qu'on veut stocker dans le fichier dump.

Si vous voulez corriger le cas de 'Frédéric' qui a été inséré avec un client mal configuré vous pouvez refaire l'export/import de la sorte:
export avec NLS_LANG=WE8MSWIN1252 qui est le même que la base source. Donc C3A9 restera C3A9 dans le dump, comme dans la base source (même si 'en vrai' c'est du unicode)
import avec NLS_LANG=AL32UTF8 puisqu'on sait qu'en réalité c'est du unicode. Donc on aura toujours C3A9 quand on l'importe dans une base AL32UTF8

Par contre, si d'autres clients bien configurés ont eux aussi fait des inserts, ils auront stocké E9. Mais en unicode, ça donnera des choses bizarres...
La première chose à faire, c'est donc de vérifier les configs des clients qui ont inséré dans la base pour savoir ce qu'on a réellement.

Cordialement,
Franck.