Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Evitez les erreurs de conversion grâce aux NLS par Fabien Celaia (fadace) Date

Evitez les erreurs de conversion grâce aux NLS par Fabien Celaia (fadace) Date de publication : 29.07.2006 Dernière mise à jour : 15.02.2009 Evitez de pourrir la qualité de vos données en saisissant la notion de conversion de tables de caractères en mode client serveur Evitez les erreurs de conversion grâce aux NLS par Fabien Celaia (fadace) - 2 - Copyright © 2006 - fadace. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. http://developpez.com/oracle/nls/ I - Introduction..............................................................................................................................................................3 II - Choix du jeu de caractères au niveau serveur..................................................................................................... 3 III - Cas d'exemple.......................................................................................................................................................4 IV - La problématique..................................................................................................................................................4 V - Explication..............................................................................................................................................................5 VI - Résolution............................................................................................................................................................. 7 VII - Modification du jeu de caractères d'une base existante..................................................................................... 8 VIII - Derniers pièges à éviter..................................................................................................................................... 8 VIII-A - JDBC..........................................................................................................................................................8 VIII-B - Editeur graphique ou texte........................................................................................................................ 9 VIII-C - Polices de caractères................................................................................................................................9 IX - Documentation......................................................................................................................................................9 Evitez les erreurs de conversion grâce aux NLS par Fabien Celaia (fadace) - 3 - Copyright © 2006 - fadace. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. http://developpez.com/oracle/nls/ I - Introduction Oracle, comme la plupart des SGBDR client-serveur, est en mesure de gérer divers formats de paramètres locaux, tels le format de la date, celui de l'heure, des jours de la semaine, du format de monnaie, le jeu de caractères, etc. Plusieurs personnes (clients) n'ayant pas les mêmes paramètres peuvent ainsi faire cohabiter sur une même base (serveur) leurs données. Chacune de ces valeurs est spécifiée au niveau du serveur comme nous le verrons plus bas, mais peut l'être au niveau d'une base de registre ou de variables d'environnements au niveau du client. Concepts de base : au moment où les valeurs diffèrent entre client et serveur, Oracle se met à convertir. Tout devrait donc aller pour le mieux dans le meilleur des mondes. Malheureusement, la méconnaissance des paramètres influençant ces configuration peut générer un remède pire que le mal : des erreurs de conversions irrécupérables car multiples et diverses. Nul besoin d'être en environnement international pour se trouver confronté à ce genre de problème : Windows, la plateforme cliente la plus répandue, nous offre un cas d'école. En effet, ce système d'exploitation gère à lui seul au moins deux genres de pages de caractères : le ANSI pour sa partie graphique, et le ASCII pour sa partie mode texte (session Dos, cmd ou command, c'est selon.) Dès lors, comment Oracle s'y retrouve-t-il ? Et bien par défaut, force est de constater qu'il ne s'y retrouve pas très bien !!! En voici un exemple probant. En fait, nombre de DBA renseignent incorrectement NLS_LANG sur leurs clients en la faisant coïncider avec le code de la base. Le résultat - double erreur de conversion s'annulant - est traître. Tout semble correct à première vue, mais lorsqu'une application externe arrive ou lorsqu'une session gère correctement la conversion, c'est le souk au niveau de vos données... Avoir un client et un serveur avec le même NLS_LANG empêche une quelconque conversion par Oracle. Oracle stocke donc de mauvais caractères dans ses tables mais cela ne se voit pas dans l'application fautive, et les performances s'en retrouve améliorées puisqu'aucune conversion n'est faite. II - Choix du jeu de caractères au niveau serveur Bien des administrateurs ont fait de mauvais shoix en imposant le jeu de caractères du système d'exploitation, en invoquant l'excuse que ce choix éviterait des conversions coûteuses en performance. Ce choix est erroné : les conversions se joueront entre client et base de données, et pas entre système d'exploitation hébergeant le serveur de données et ce dernier. Il est vrai cependant que souvent les scripts de batch sont exécutés sur la achine même, celle-ci jouant alors les deux rôles : client et serveur. Voici donc quelques règles régissant le choix correct du jeu de caractères au niveau de la base de données. 1 Dans le cas où l'application cliente principale fonctionne sous Windows, opter pour le jeu de caractère Windows sur la base 2 Dans le cas où l'application cliente est une application Java, optez pour l'UTF 3 Dans le cas où plusieurs applications de types divers cohabitent, optez pour le jeu de caractère le plus étendu 4 Dans le cas de purs traitements batchs lancés sur la machine hébergeant le serveur ou ayant même système d'exploitation, et dans le cas où vos traitements ne se font pas via java (sinon retour à la règle 2), optez pour le jeu de caractères similaire au système d'exploitation Evitez les erreurs de conversion grâce aux NLS par Fabien Celaia (fadace) - 4 - Copyright © 2006 - fadace. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. http://developpez.com/oracle/nls/ Oracle recommande de plus en plus souvent l'utilisation de l'UTF8, car il s'agit d'un superset de caractères (incluant la plupart des autres). Le coût à payer en est la place de stockage et quelques problèmes liés aux tailles des champs plus difficiles à déterminer. III - Cas d'exemple Imaginons un Serveur Oracle installé sur un système Sun Solaris, dont le jeu de caractère a été déterminé par le DBA en européen comprenant le signe de l'Euro. De plus, tous les clients sont sous Windows, mais certaines applications lancent des traitements batch. En résumé, nous avons donc, sans trop nous en rendre compte: • Un système d'exploitation utilisant du ISO1 • Un SGBDR utilisant un ISO modifiée (P15) • Un client graphique utilisant de l'ANSI • Des traitements batch lancés en mode Dos, utilisant donc du CP850 Traduisons cela en "Oracle" • Un système d'exploitation utilisant du AMERICAN_AMERICA.WE8ISO8859P1 • Un SGBDR utilisant un ISO1 modifié AMERICAN_AMERICA.WE8ISO8859P15 • Un client graphique utilisant de l'ANSI FRENCH_FRANCE.WE8MSWIN1252 • Des traitement batch lancés en mode Dos, utilisant donc du FRENCH_FRANCE.WE8PC850 Comme nous l'avons vu plus haut, le décodage est aisé : langue, territoire et jeu de caractères. IV - La problématique Créons-nous une table simple ne comportant qu'un champ "chaîne de caractères" et laissons tous les paramètres par défaut que l'Install Oracle nous a mis. CREATE TABLE TESTCONVERSION (V VARCHAR2(50)) ; COMMIT ; Insérons maintenant une ligne via chaque client: Via SQLPlusw (mode Windows graphique): SQL> INSERT INTO TESTCONVERSION VALUES('Test éphémère à Windows graphique.'); COMMIT ; Via SQLPlus (mode Dos): SQL> INSERT INTO TESTCONVERSION VALUES('Test éphémère à Windows texte.'); COMMIT ; Via SQLPlus sous Unix: SQL> INSERT INTO TESTCONVERSION VALUES('Test éphémère à Unix.'); COMMIT ; Affichons ensuite le résultat de notre gabegie: Evitez les erreurs de conversion grâce aux NLS par Fabien Celaia (fadace) - 5 - Copyright © 2006 - fadace. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. http://developpez.com/oracle/nls/ Sous SQLPlusw de Windows SQL> SELECT * FROM TESTCONVERSION ; V -------------------------------------------------- Test éphémère à Windows graphique. Test ¿ph¿mre ¿ Windows texte. Test ¿ph¿m¿re ¿ Unix. Sous SQLPlus sous ligne de commande Dos SQL> SELECT * FROM TESTCONVERSION ; V -------------------------------------------------- Test ÚphÚmÞre Ó Windows graphique. Test +ph+mère + Windows texte. Test +ph+m+re + Unix. Sous SQLPlus sous ligne de commande Unix SQL> SELECT * FROM TESTCONVERSION ; V -------------------------------------------------- Test ephemere a Windows graphique. Test ?ph?mSre ? Windows texte. Test ?ph?m?re ? Unix. Comme vous le voyez, rien ne va plus ! ... et même la conversion de mes copier/coller pour cet article me changent les caractères problématiques... Nous somme ne face d'un sérieux problème quant à la qualité de nos données. V - Explication En fait, que se passe-t-il réellement ? Et bien Oracle tente de traduire tant bien que mal les caractères accentués d'un code page à l'autre... en se basant sur de fausses indications. Comme vous le notez, il est incapable non seulement de rendre correctement les données des autres, mais aussi les données propres à chaque session... hormis celle sous Windows graphique... Une explication s'impose... Avant tout, déterminons avec certitude les paramètres attribués à l'instance Oracle, soit au niveau serveur. SQL> select * from NLS_DATABASE_PARAMETERS ; PARAMETER VALUE ------------------------------ ----------------------------- 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 Evitez les erreurs de conversion grâce aux NLS par Fabien Celaia uploads/Litterature/ oracle-nls.pdf