Les paramètres régionaux sont un ensemble d’informations répondant à des exigences linguistiques et culturelles correspondant à une langue et à un pays donnés. Traditionnellement, les données associées à des paramètres régionaux prennent en charge le formatage et l’analyse de dates, d’heures, de chiffres et de devises, etc. dans les données locales. La fourniture de données de paramètres régionaux actuelles et correctes a toujours été la responsabilité de chaque propriétaire ou fournisseur de plate-forme, ce qui a entraîné des incohérences et des erreurs dans les données de paramètres régionaux.

La définition du paramètre d’environnement NLS_LANG est le moyen le plus simple de spécifier le comportement des paramètres régionaux pour le logiciel Oracle. Il définit la langue et le territoire utilisés par l’application client et le serveur de base de données. Il indique également le jeu de caractères du client, qui correspond au jeu de caractères pour les données à saisir ou à afficher par un programme client.

NLS_LANG est défini en tant que variable d’environnement local sur les plates-formes UNIX. NLS_LANG est défini dans le registre sur les plates-formes Windows.

Le paramètre NLS_LANG comporte trois éléments : la langue, le territoire et le jeu de caractères. Définissez-le dans le format suivant, en respectant la ponctuation :
NLS_LANG = langue_territoire.jeudecaractères

Chaque composant du paramètre NLS_LANG contrôle le fonctionnement d’un sous-ensemble de fonctionnalités de prise en charge de la globalisation :

La langue
Indique des conventions telles que la langue utilisée pour les messages Oracle, la classification, les noms de jours et les noms de mois. Chaque langue prise en charge a un nom unique ; par exemple, AMERICAN, FRENCH ou GERMAN. L’argument language spécifie les valeurs par défaut pour les arguments de territoire et de jeu de caractères. Si la langue n’est pas spécifiée, la valeur par défaut est AMERICAN.

Le territoire
Indique des conventions telles que la date par défaut, les formats monétaires et numériques. Chaque territoire pris en charge a un nom unique ; par exemple, AMERICA, FRANCE ou CANADA. Si le territoire n’est pas spécifié, la valeur est dérivée de la valeur de langue.

Le jeu de caractères
Indique le jeu de caractères utilisé par l’application du client (normalement le jeu de caractères Oracle qui correspond au jeu de caractères du terminal de l’utilisateur ou au jeu du système d’exploitation). Chaque jeu de caractères pris en charge a un acronyme unique, par exemple US7ASCII, WE8ISO8859P1, WE8DEC, WE8MSWIN1252 ou JA16EUC. Chaque langue est associée à un jeu de caractères par défaut.

Remarque :

Tous les éléments de la définition NLS_LANG sont facultatifs. Tout élément qui n'est pas précisé aura une valeur par défaut. Si vous indiquez un territoire ou un jeu de caractères, vous devez ajouter un séparateur qui le précède [le tiret bas (_) pour le territoire, point (.) pour le jeu de caractères]. Sinon, la valeur est analysée comme un nom de langue.

Par exemple, pour configurer uniquement le composant territoire du paramètre NLS_LANG, utilisez le format suivant : NLS_LANG=_JAPAN

Le reste de ce document se concentrera sur le composant charset du paramètre NLS_LANG, car il s’agit du composant le moins compris et le plus important à définir correctement.

• Définir le paramètre NLS_LANG sur le jeu de caractères de la base de données PEUT être correct, mais EST souvent non correct. NE supposez PAS que NLS_LANG doit être identique au jeu de caractères de la base de données. C’EST SOUVENT FAUX.
• Le jeu de caractères défini avec le paramètre NLS_LANG NE CHANGE PAS le jeu de caractères de votre client. Il est utilisé pour permettre à Oracle de savoir quel jeu de caractères vous UTILISEZ côté client afin qu’Oracle puisse effectuer la conversion appropriée. Vous ne pouvez pas changer le jeu de caractères de votre client en utilisant un paramètre NLS_LANG différent !
• Si vous ne définissez pas le paramètre NLS_LANG sur le client, il utilise le paramètre NLS_LANG du serveur. Ce N’EST PAS vrai non plus ! Par exemple, si le programme d’installation Oracle ne renseigne pas le paramètre NLS_LANG et qu’il n’est pas défini autrement, sa valeur par défaut est A MERICAN_AMERICA.US7ASCII. La langue est AMERICAN, le territoire est AMERICA et le jeu de caractères est US7ASCII.
• La définition des composants LANGUAGE et TERRITORY du paramètre NLS_LANG n’a rien à voir avec la possibilité d’enregistrer dans une base de données. Un paramètre NLS_LANG défini sur JAPANESE_JAPAN.WE8MSWIN1252 ne vous permettra pas de stocker le japonais, car WE8MSWIN1252 ne prend pas en charge les caractères japonais. Toutefois, un paramètre NLS_LANG défini sur AMERICAN_AMERICA.JA16SJIS vous permettra de stocker le japonais, à condition que les données d’entrée soient réellement JA16SJIS et si la base de données est également dans un jeu de caractères pouvant stocker le japonais, comme UTF8 ou JA16SJIS.

Dans de nombreux cas, le paramètre NLS_LANG a déjà été défini lors de l’installation d’Oracle ou ultérieurement. Pour être sûr, vous pouvez utiliser ces méthodes pour récupérer la valeur du paramètre NLS_LANG pour SQL*Plus :

Sous UNIX :

Ceci retourne la valeur du paramètre.

Sous Windows :
Sous Windows, vous avez deux options. Normalement, NLS_LANG est défini dans le registre, mais il peut également l’être dans l’environnement. Cependant, ce cas est rare. La valeur de l’environnement a priorité sur la valeur du registre et est utilisée pour TOUS les répertoires d’accueil Oracle_Home sur le serveur. Notez également que toute variable d’environnement USER a priorité sur toute variable d’environnement SYSTEM (il s’agit du comportement de Windows et n’a aucun rapport avec Oracle) si elle est définie.

Pour vérifier s’il est défini dans l’environnement :

Si cela ne renvoie que %NLS_LANG%, la variable n’est pas définie dans l’environnement.

S’il est défini, il signale quelque chose comme

ENGLISH_UNITED KINGDOM.WE8ISO8859P1
If NLS_LANG n’est pas défini dans l’environnement, vérifiez la valeur dans le registre :

Si vous obtenez quelque chose comme :
Impossible d’ouvrir le fichier. [ENGLISH_UNITED KINGDOM.WE8ISO8859P1].
Le "nom de fichier" entre les accolades est la valeur du paramètre de registre.

Si vous obtenez comme résultat :
Impossible d’ouvrir le fichier « .[%NLS_LANG%]. », alors le paramètre NLS_LANG n’est pas non plus défini dans le registre.

Notez que la technique @.[%NLS_LANG%]. signale le paramètre NLS_LANG connu par l’exécutable SQL*Plus, il ne lira pas le registre lui-même. Mais si vous exécutez d’abord la commande HOST et que le paramètre NLS_LANG n’est pas défini dans l’environnement, vous pouvez être sûr que la variable est définie dans le registre si @.[%NLS_LANG%]. renvoie une valeur valide.

Tous les autres paramètres NLS peuvent être récupérés par :

Remarque :

SELECT USERENV ('language') FROM DUAL; donne le <Language>_<territory> de la session mais le jeu de caractères DATABASE n'indique pas le client, donc la valeur renvoyée n’est pas le paramètre NLS_LANG complet du client !

Cette section explique l’ordre dans lequel les paramètres NLS sont pris en compte dans le modèle client/serveur de base de données. (Ceci ne couvre PAS les connexions Thin JDBC)

Vous pouvez définir les paramètres NLS sur 3 niveaux : Base de données, Instance et Session. Si un paramètre est défini à plusieurs niveaux, les règles sur lesquelles l’un a priorité sont assez simples :

1. 1. Les paramètres de base de données NLS sont remplacés par les paramètres d’instance NLS
2. 2. Les paramètres de base de données NLS et d’instance NLS sont remplacés par les paramètres de session NLS

Ce sont les paramètres utilisés pour la session SQL en cours.

Ceux-ci reflètent (dans cet ordre) :

1. 1) Les valeurs des paramètres NLS définies par "ALTER SESSION "
   ALTER SESSION set NLS_DATE_FORMAT = 'DD/MM/YYYY';
2. 2) Si aucune instruction "ALTER SESSION " explicite n’est réalisée, elle reflète la définition du paramètre NLS correspondant sur le client dérivé de la variable NLS_LANG.
3. 3) Si NLS_LANG est indiqué avec un seul élément, AMERICAN est utilisé par défaut.

   Ainsi, si vous définissez NLS_LANG = _BELGIUM. WE8MSWIN1252, vous obtenez ceci :

   VALEUR DES PARAMÈTRES

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY BELGIUM
   NLS_CURRENCY <signe euro ici>
   NLS_ISO_CURRENCY BELGIUM

   Remarque :

   La différence qui existe entre NLS_LANG=_BELGIUM.WE8MSWIN1252 (correct) et

   NLS_LANG=BELGIUM.WE8MSWIN1252 (incorrect) est l'ajout du « _ » comme séparateur.

4. 4) Si NLS_LANG est indiqué avec une seule partie, la valeur par défaut est un paramètre basé sur .

   Donc, si vous définissez NLS_LANG=ITALIAN_.WE8MSWIN1252, vous obtenez ceci :

   VALEUR DES PARAMÈTRES

   NLS_LANGUAGE ITALIAN
   NLS_TERRITORY ITALY
   NLS_CURRENCY <signe euro ici>
   NLS_ISO_CURRENCY ITALY

   Remarque :

   Notez la différence entre NLS_LANG=ITALIAN_.WE8MSWIN1252 (correct) et

   NLS_LANG=ITALIAN.WE8MSWIN1252 (incorrect), liée à l'ajout du « _ » comme séparateur.

5. 5) Si NLS_LANG est indiqué sans l'élément _, l'élément _ par défaut est AMERICAN_AMERICA.

   Donc, si vous définissez NLS_LANG=.WE8MSWIN1252, vous obtenez ceci :

   VALEUR DES PARAMÈTRES

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY AMERICA
   NLS_CURRENCY $
   NLS_ISO_CURRENCY AMERICA

   
   
   
   Note:
   
   The difference between NLS_LANG=.WE8MSWIN1252 (correct) and
   
   NLS_LANG=WE8MSWIN1252 (incorrect), you need to set the "." as separator.
   

6. 6) Si le paramètre NLS_LANG est défini (comme au point 3, 4 ou 5), des paramètres comme

   NLS_SORT, NLS_DATE_FORMAT, etc. peuvent être définis comme un paramètre "autonome" et remplacera les valeurs par défaut dérivées de la partie _ de NLS_LANG.

   Ainsi, si vous définissez NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 et NLS_ISO_CURRENCY=FRANCE, vous obtenez ceci :

   VALEUR DES PARAMÈTRES

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY AMERICA
   NLS_CURRENCY $
   NLS_ISO_CURRENCY FRANCE

   Valeurs par défaut :
   * Si NLS_DATE_LANGUAGE ou NLS_SORT ne sont pas définis, ils seront dérivés de
   NLS_LANGUAGE.
   * Si NLS_CURRENCY, NLS_DUAL_CURRENCY, NLS_ISO_CURRENCY, NLS_DATE_FORMAT, NLS_TIMESTAMP_FORMAT, NLS_TIMESTAMP_TZ_FORMAT, NLS_NUMERIC_CHARACTERS ne sont pas définis, ils seront dérivés de NLS_TERRITORY

7. 7) Si NLS_LANG n’est pas du tout défini, alors, sa valeur par défaut est

   <Language>_<Territory>.US7ASCII et les valeurs pour l'élément
   <Language>_<Territory>utilisées sont celles que vous pouvez trouver dans

   NLS_INSTANCE_PARAMETERS. Les paramètres tels que NLS_SORT définis comme "autonomes" côté client sont ignorés.

   
   
   Note:
   
   * If set, client parameters (NLS_SESSION_PARAMETERS) always take precedence over NLS_INSTANCE_PARAMETERS and NLS_DATABASE_PARAMETERS.
   
   * This behavior cannot be disabled on/from the server, so a parameter set on the client always has precedence above an instance or database parameter.
   
   * NLS_LANG cannot be changed by ALTER SESSION, NLS_LANGUAGE and NLS_TERRITORY can. However NLS_LANGUAGE and /or NLS_TERRITORY cannot be set as "standalone" parameters in the environment or registry on the client.
   
   * NLS_SESSION_PARAMETERS is NOT visible for other sessions. If you need to trace this then you have to use a logon trigger to create your own logging table (based on session parameters)
   
   * The <clients characterset> part of NLS_LANG is NOT shown in any system table or view.
   
   * On Windows you have two possible options, normally the NLS_LANG is set in the registry, but it can also be set in the environment, however this is not often done and generally not recommended to do so. The value in the environment takes precedence over the value in the registry and is used for ALL Oracle_Homes on the server if defined as a system environment variable.
   
   * NLS_LANGUAGE in the session parameters also declares the language for the client error messages.
   
   * You cannot "set" a NLS parameter in an SQL script; you need to use ALTER SESSION.
   

Ce sont les paramètres du fichier init.ora de la base de données au moment où la base de données a été démarrée ou définie via ALTER SYSTEM.

Si le paramètre n’est pas défini explicitement dans le fichier init.ora ou défini par ALTER SYSTEM, sa valeur n’est PAS dérivée d’un paramètre "plus élevé" (nous parlons de paramètres comme NLS_SORT qui dérivent une valeur par défaut de NLS_LANGUAGE dans NLS_SESSION_PARAMETERS, ce n’est PAS le cas pour NLS_INSTANCE_PARAMETERS).

Note:

* NLS_LANG is not an init.ora parameter; NLS_LANGUAGE and NLS_TERRITORY are so you need to set NLS_LANGUAGE and NLS_TERRITORY separately.

* You cannot define the  or NLS_LANG in the init.ora

The client characterset is defined by the NLS_LANG on the client OS (see above).

* You cannot define the database characterset in the init.ora. The database characterset is defined by the "Create Database" command.

* These settings take precedence above the NLS_DATABASE_PARAMETERS.

* These values are used for the NLS_SESSION_PARAMETERS if the client the

NLS_LANG is NOT set.

* Oracle strongly recommends that you set the NLS_LANG on the client at least to

NLS_LANG=.<clients characterset>

* The NLS_LANGUAGE in the instance parameters also declares the language for the server error messages in alert.log and in trace files.

La valeur par défaut est AMERICAN_AMERICA si aucun paramètre n’est explicitement défini dans le fichier init.ora lors de la création de la base de données. Si des paramètres sont définis dans le fichier init.ora lors de la création de la base de données, vous les voyez ici. Il n’y a aucun moyen de les modifier après la création de la base de données. N’essayez PAS de mettre à jour les tables système pour contourner ces paramètres ! Ces paramètres sont utilisés pour attribuer une valeur par défaut à la base de données si les paramètres INSTANCE et SESSION ne sont pas définis.

Remarque :

* NLS_LANG n’est pas un paramètre du fichier init.ora, alors que NLS_LANGUAGE et NLS_TERRITORY le sont.

Vous devez donc définir NLS_LANGUAGE et NLS_TERRITORY séparément.

* Ces paramètres sont remplacés par NLS_INSTANCE_PARAMETERS et NLS_SESSION_PARAMETERS.

* Vous ne pouvez pas définir le <jeu de caractères client> ou NLS_LANG dans le fichier init.ora. Le jeu de caractères du client est défini par NLS_LANG sur le système d’exploitation client.

* Vous ne pouvez pas définir le jeu de caractères de la base de données dans le fichier init.ora.

Le jeu de caractères de la base de données (national) NLS_(NCHAR)_CHARACTERSET) est défini par la commande « Create Database ».

* Les paramètres NLS_CHARACTERSET et NLS_NCHAR_CHARACTERSET ne peuvent pas être remplacés par des paramètres d’instance ou de session.

Ils sont définis par la valeur spécifiée par la commande « CREATE DATABASE » et ne sont pas destinés à être modifiés dynamiquement par la suite. Ne mettez PAS à jour les tables système pour changer le jeu de caractères. Cela peut corrompre votre base de données et rendre potentiellement impossible son ouverture à nouveau.

* La définition de NLS_LANG lors de la création de la base de données n’influence pas NLS_DATABASE_PARAMETERS.

* Le NLS_LANG défini lors de la création de la base de données n’a AUCUN impact sur le jeu de caractères national de la base de données.

Instructions de sélection supplémentaires :
A) SELECT name,value$ from sys.props$ where name like '%NLS%';
Cette requête renvoie les mêmes informations que NLS_DATABASE_PARAMETERS.
Vous devriez utiliser NLS_DATABASE_PARAMETERS au lieu de props$.
Notez le '%NLS%' en MAJUSCULES.

B) SELECT * from v$nls_parameters;
Cette vue affiche les paramètres de session actuels et le jeu de caractères *DATABASE*, tels qu’ils apparaissent dans l'aperçu NLS_DATABASE_PARAMETERS.

C) SELECT name,value from v$parameter where name like '%NLS%';
Cette vue fournit les mêmes informations que NLS_INSTANCE_PARAMETERS.
Notez le '%NLS%' en minuscules.

D) SELECT userenv ('language') from dual;
et
SELECT sys_context('userenv','language') from dual;
Ces deux instructions SELECT donnent le _ et le jeu de caractères
DATABASE de la session. Le jeu de caractères de la base de données n’est pas identique au jeu de caractères du NLS_LANG avec lequel vous avez démarré cette connexion ! Donc, ne vous y trompez pas, même si le résultat de cette requête ressemble à la valeur d’une variable NLS_LANG, il n’en est pas une.

E) SELECT userenv ('lang') from dual;
Cette instruction SELECT donne le code abrégé utilisé par Oracle pour le paramètre Language défini par NLS_LANGUAGE pour cette session. Si NLS_LANGUAGE est défini sur français, le résultat sera « F », si NLS_LANGUAGE est défini sur anglais, le résultat sera « GB »
Si NLS_LANGUAGE est défini sur American, le résultat sera « US », etc...

F) SHOW parameter NLS%
Cette action donnera le même résultat que NLS_INSTANCE_PARAMETERS

Une base de données est créée sur un système UNIX avec le jeu de caractères US7ASCII. Un client Windows qui se connecte à la base de données fonctionne avec le jeu de caractères WE8MSWIN1252 (paramètres régionaux -> Europe occidentale/ACP 1252) et le DBA, utilisez le shell UNIX (ROMAN8) pour fonctionner sur la base de données. NLS_LANG est défini sur american_america.US7ASCII sur les clients et le serveur.

Note:

This is an INCORRECT setup to explain character set conversion, don't use it in your environment!

Un point très important (comme mentionné précédemment) :

Lorsque le jeu de caractères NLS_LANG du client est défini sur la même valeur que le jeu de caractères de la base de données, Oracle suppose que les données envoyées ou reçues ont le même codage (correct), de sorte qu’aucune conversion ou validation ne peut avoir lieu pour des raisons de performances. Les données sont simplement stockées telles que livrées par le client, bit par bit.

Depuis Windows, insérez un « é » (LETTRE MINUSCULE E AVEC ACCENT AIGU) dans une table NLS_TEST contenant une colonne TEST du type « char ».

Tant que vous insérez et sélectionnez dans la colonne sous Windows avec le jeu de caractères WE8MSWIN1252, tout se passe bien. Aucune conversion n’est effectuée et 8 bits sont insérés et relus, même si le jeu de caractères de la base de données est défini sur 7 bits. Cela se produit car un octet est composé de 8 bits et Oracle utilise TOUJOURS 8 bits, même avec un jeu de caractères de 7 bits. Dans une configuration correcte, le bit le plus significatif n’est tout simplement pas utilisé et seuls 7 bits sont pris en compte.

Pour une raison ou une autre, vous devez insérer à partir du serveur UNIX. Lorsque vous effectuer une requête SELECT depuis des tables où les données sont ajoutées par les clients Windows, vous obtenez un « Ò » (LETTRE MAJUSCULE O AVEC UN ACCENT GRAVE) au lieu de « é ».

Si vous insérez « é » sur le serveur UNIX et que vous faites une requête SELECT la ligne au niveau du client Windows, vous obtenez un « Å » (LETTRE MAJUSCULE AVEC UN ANNEAU EN CHEF).

Le bilan est que vous avez des données INCORRECTES dans la base de données. Vous stockez la valeur numérique de « é » du jeu de caractères WE8MSWIN1252 dans la base de données, mais vous indiquez à Oracle qu'il s'agit de données US7ASCII. Oracle ne convertit donc rien et ne stocke que la valeur numérique (rappel : Oracle pense que le client donne des codes US7ASCII car NLS_LANG est défini sur US7ASCII et le jeu de caractères de la base de données est également US7ASCII -> donc aucune conversion n'est effectuée).

Lorsque vous SÉLECTIONNEZ la même colonne sur le serveur UNIX, Oracle attend à nouveau que la valeur soit correcte et la transmet au terminal UNIX sans conversion.

Le problème est que dans le jeu de caractères WE8MSWIN1252, le « é » a la valeur hexadécimale « E9 », alors que dans le jeu de caractères Roman8, la valeur hexadécimale de«  é » est « C5 » . Oracle ne fait que transmettre la valeur stockée dans la base de données (« E9 ») au terminal UNIX, et le terminal UNIX pense qu’il s’agit du caractère « ? » car dans son jeu de caractères (Roman8), la valeur hexadécimale « E9 » représente la lettre « Ò ». Ainsi, au lieu d'un « é » , vous obtenez un « Ò » sur l’écran du terminal UNIX.

L’inverse (l’insertion sur UNIX et la commande SELECT sur le client Windows) correspond au même récit, mais vous obtenez d’autres résultats.

La solution consiste à créer la base de données avec un jeu de caractères contenant « é ».

(WE8MSWIN1252, WE8ISO89859P1, UTF-8, etc.) et à définir NLS_LANG sur le client sur WE8MSWIN1252 et sur le serveur sur WE8ROMAN8. Si vous insérez ensuite un « é » des deux côtés, vous obtiendrez un « é » quel que soit l’endroit où vous faites les requêtes SELECT. Oracle sait alors qu’une valeur hexadécimale de « C5 » insérée par UNIX et une valeur « E9 » d'un client WE8MSWIN1252 sont tous les deux « é » et insèrent « é » dans la base de données (le code dans la base de données dépend du jeu de caractères que vous avez choisi).

Il n’est pas nécessaire de basculer entre UNIX, Windows ou d’autres clients OS pour rencontrer ce type de problème. Le même problème apparaît si vous ajoutez des clients Windows qui utilisent un autre jeu de caractères et dont le jeu NLS_LANG est incorrect.

Pour spécifier le comportement des paramètres régionaux de votre logiciel client Oracle, vous devez définir votre paramètre NLS_LANG. Il définit la langue, le territoire et le jeu de caractères de votre client. Vous devez vérifier les paramètres d’environnement local pour définir votre troisième champ NLS_LANG (jeu de caractères) en conséquence. Pour ce faire, utilisez la commande "locale" comme ceci :

$ locale

Example of output:

LANG=fr_FR 
LC_CTYPE="fr_FR.iso885915@euro" 
LC_COLLATE="fr_FR.iso885915@euro" 
LC_MONETARY="fr_FR.iso885915@euro" 
LC_NUMERIC="fr_FR.iso885915@euro" 
LC_TIME="fr_FR.iso885915@euro" 
LC_MESSAGES="fr_FR.iso885915@euro" 
LC_ALL=fr_FR.iso885915@euro

La sortie de cette commande n’est pas exactement la même sur tous les environnements UNIX. Sur certaines plates-formes, il peut être utile d’utiliser la syntaxe suivante pour avoir plus de détails sur la page de code réellement utilisée :

$ locale LC_CTYPE | head

         Example of output     
         in a HP-UX environment   
         :   

""
  

   


 
 
 
""
  

   


 
 
 
"iso885915"
  

   


 
 
 
""
  

   


 
 
 
          Example of output in a Linux environment:   
  

   


 
 
 
upper;lower;alpha;digit;xdigit;space;print;graph;blank;cntrl;
punct;alnum;
combining;combining_level3 
toupper;tolower;totitle 
16 
1 
ISO-8859-15 
70 
84 
1 
0 

Dans ces cas, le troisième champ NLS_LANG doit être défini sur WE8ISO8859P15. Sous Solaris, AIX et TRU64, cette syntaxe ne fournit aucune information complémentaire intéressante. Pour trouver plus de détails sur ces paramètres :

Sous Solaris, effectuez une recherche dans/usr/lib/locale
Sous AIX, effectuez une recherche dans /usr/lib/nls/README
Sous TRU64, effectuez une recherche dans /usr/lib/nls
Sous HP-UX, effectuez une recherche dans /usr/lib/nls/config
Sous Linux, effectuez une recherche dans /usr/share/locale/locale.alias

Pour définir une valeur choisie pour ces paramètres "locale", il faut savoir quelles valeurs sont disponibles. Pour le savoir, utilisez la syntaxe suivante :

Ensuite, lorsque vous avez choisi une valeur, par exemple UTF-8 sous Linux, vous pouvez la définir comme suit :

ou

 
Example of output after the setenv:

$ locale 

LANG=fr_FR 
LC_CTYPE="UTF-8" 
LC_NUMERIC="UTF-8" 
LC_TIME="UTF-8" 
LC_COLLATE="UTF-8" 
LC_MONETARY="UTF-8" 
LC_MESSAGES="UTF-8" 
LC_PAPER="UTF-8" 
LC_NAME="UTF-8" 
LC_ADDRESS="UTF-8" 
LC_TELEPHONE="UTF-8" 
LC_MEASUREMENT="UTF-8" 
LC_IDENTIFICATION="UTF-8" 
LC_ALL=UTF-8 

$ locale LC_CTYPE | head 
upper;lower;alpha;digit;xdigit;space;print;

graph;blank;cntrl;punct;alnum;combining;combining_level3 
toupper;tolower;totitle 
16 
6 
UTF-8 
70 
84 
1 
0 
1

Dans ce cas, le troisième champ (jeu de caractères) de NLS_LANG doit être défini sur UTF8.

% setenv NLS_LANG American_America.UTF8

Sur les systèmes Windows, le schéma de codage (jeu de caractères) est spécifié par une page de code. Les pages de code sont définies pour prendre en charge des groupes de langues ou des langues spécifiques partageant des systèmes d’écriture communs. Du point de vue d’Oracle, la page de code des termes et le jeu de caractères ont la même signification. Notez que dans les environnements autres que le chinois, le japonais et le coréen, l’invite de commande DOS et l’interface graphique Windows n’utilisent pas la même page de code.

Par conséquent, Windows utilise 2 jeux de caractères différents pour les environnements ANSI (sqlplusw.exe) et OEM (dos box - sqlplus.exe).

Dans le registre :
Dans les systèmes Windows, vous devez vous assurez d'avoir défini une sous-clé de registre NLS_LANG pour chacun de vos Oracle Homes :
Vous pouvez facilement modifier cette sous-clé à l'aide de Windows Registry Editor :
Start -> Run...
Saisissez "regedit", et cliquez sur "ok"
Modifiez l'entrée de registre suivante :

Pour Oracle version 7 :

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE

Pour Oracle Database versions 8, 8i et 9i :

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx\

où "x" est le numéro unique identifiant le répertoire d’accueil Oracle.

HOME0 est la première installation

Pour Oracle Database 10g :

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_

Vous avez une entrée avec le nom NLS_LANG

Lors du démarrage d’un outil Oracle, tel que SQL*Plusw, il lira le contenu du fichier oracle.key situé dans le même répertoire afin de déterminer quelle arborescence de registre sera utilisée et donc quelle sous-clé NLS_LANG sera utilisée.

Remarque :

Certaines personnes sont désemparées en trouvant un NLS_LANG défini sur « NA » dans HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE lorsqu’aucune version 7 n’a été installée. Ceci est utilisé pour la compatibilité ascendante et peut être ignoré.

En tant que variable d’environnement système ou utilisateur, dans les propriétés système :

Bien que le registre soit le référentiel principal pour les paramètres sous Windows, ce n’est pas le seul endroit où les paramètres peuvent être définis. Même si cela n’est pas du tout recommandé, vous pouvez définir NLS_LANG en tant que variable d’environnement système ou utilisateur dans les propriétés système.

Ce paramètre sera utilisé pour TOUS les répertoires d’accueil Oracle.

Pour les vérifier et les modifier :

Cliquez avec le bouton droit sur 'Icône de mon ordinateur -> 'Propriétés'

Sélectionnez l’'onglet Avancé -> Cliquez sur 'Variables d’environnement'

La liste 'Variables utilisateur contient les paramètres de l’utilisateur OS actuellement connecté et des 'Variables système à l’échelle du système pour tous les utilisateurs.

Étant donné que ces variables d’environnement ont préséance sur les paramètres déjà définis dans votre registre, vous ne devez pas définir les paramètres Oracle à cet emplacement, sauf si vous avez une très bonne raison.

En tant que variable d’environnement définie dans l’invite de commande :

Avant d’utiliser un outil de ligne de commande Oracle, vous devez DÉFINIR MANUELLEMENT le paramètre NLS_LANG. Dans une invite de commande MS-DOS, utilisez la commande set, par exemple :

C:\> set NLS_LANG=american_america.WE8PC850

Maintenant que vous savez sur quoi le paramètre NLS_LANG est actuellement défini, vous pouvez vérifier s’il concorde correctement avec la page de code ANSI actuelle. Le code ACP (ANSI Code Page) est défini par les "paramètres régionaux par défaut" de Windows. Si vous avez un client Windows 2000 britannique et que vous souhaitez saisir le cyrillique (russe), vous devez modifier le code ACP (en modifiant les "paramètres régionaux par défaut") afin de pouvoir saisir le russe.

Vous trouverez sa valeur dans le registre :

Démarrez -> Run...

Entrez "regedit", puis cliquez sur "OK"

Accédez à l’entrée de registre suivante :

Là vous avez (tout en bas) une entrée portant le nom ACP. La valeur de l’entrée ACP est la page de code de votre interface graphique actuelle, pour le mappage vers le nom Oracle. Comme il existe de nombreuses entrées de registre portant des noms très similaires, veillez à regarder au bon endroit dans le registre.

De plus, l’URL suivante fournit une liste des pages de codes par défaut pour toutes les versions de Windows :

http://www.microsoft.com/globaldev/reference/ (sous l’onglet RÉFÉRENCE, dans la partie gauche de la page)

OEM = la page de code de la ligne de commande, ANSI = la page de code de l’interface graphique

Notez que le HKSCS de Hong Kong est répertorié ici : http://www.microsoft.com/hk/hkscs/

Recherchez le jeu de caractères du client Oracle correspondant :

Recherchez le jeu de caractères du client Oracle dans le tableau ci-dessous en fonction de la valeur ACP que vous avez trouvée ci-dessus. Notez qu’il n’y a qu’UNE VALEUR CORRECTE pour une valeur ACP donnée.

Il s’agit du jeu de caractères utilisé par l’interface graphique SQL*Plus (sqlplusW.exe / plus80W.exe / plus33W.exe) que vous démarrez via le menu Démarrer de Windows. Veuillez noter la différence entre le SQL*Plus de l’interface graphique et le SQL*Plus du "mode DOS".

Vous pouvez utiliser UTF8 en tant que jeu de caractères du client Oracle (=NLS_LANG) sous Windows NT, 2000 et XP, mais vous ne pouvez utiliser que des programmes client prenant explicitement en charge cette configuration. En effet, l’interface utilisateur de Win32 n’est pas UTF8. Par conséquent, le programme client doit effectuer des conversions explicites entre UTF8 (utilisé du côté Oracle) et UTF16 (utilisé du côté Win32).

Définissez-le dans votre registre :

Utilisez l’Éditeur de registre Windows pour configurer NLS_LANG dans votre répertoire d’accueil Oracle avec la valeur que vous venez de trouver ci-dessus.

Le mode MS-DOS utilise, à quelques exceptions près, comme CJK (japonais, coréen, chinois simplifié et chinois traditionnel) une page de code différente (appelée page de code OEM) par rapport à l’interface graphique Windows (page de code ANSI). Cela signifie qu’avant d’utiliser un outil de ligne de commande Oracle tel que SQL*Plus (sqlplus.exe / plus80.exe / plus33.exe) et svrmgrl dans une invite de commande, vous devez DÉFINIR MANUELLEMENT le paramètre NLS_LANG comme une variable d’environnement avec la commande DOS définie AVANT d’utiliser l’outil.

Pour les japonais, coréen, chinois simplifié et chinois traditionnel, la page de code OEM MS-DOS (CJK) est identique à la page de code ANSI, ce qui signifie que, dans ce cas particulier, il n’est pas nécessaire de définir le paramètre NLS_LANG en mode MS-DOS.

Dans tous les autres cas, vous devez le définir pour écraser la clé de registre NLS_LANG qui correspond déjà à la page de code ANSI. Le nouveau paramètre NLS_LANG "MS-DOS dédié" doit correspondre à la page de code OEM MS-DOS pouvant être récupérée en entrant chcp dans une invite de commande :

C:\> chcp

Page de code active : 437

C:\> set NLS_LANG=american_america.US8PC437

Si le paramètre NLS_LANG pour la session en mode MS-DOS n’est pas défini correctement, les données et les messages d’erreur peuvent être altérés en raison d’une conversion incorrecte du jeu de caractères.

Utilisez la liste suivante pour trouver le jeu de caractères Oracle qui correspond à votre page de code MS-DOS utilisée sur votre système de paramètres régionaux :

Note : Il s’agit du paramètre correct pour la version SQL*Plus de l’interface graphique, (sqlplusW.exe / plus80W.exe / plus33W.exe)

Si vous testez avec des caractères "spéciaux", veuillez utiliser l’interface graphique et non le fichier sqlplus.exe de la "fenêtre de commande DOS" !

Note : Il s’agit du paramètre correct pour la version de SQL*Plus de la fenêtre de commande DOS (sqlplus.exe / plus80.exe / plus33.exe)

Que contrôle le composant LANGUAGE du paramètre NLS_LANG ?

Le composant de langue du paramètre NLS_LANG contrôle le fonctionnement d’un sous-ensemble de fonctionnalités de prise en charge de la globalisation. Il spécifie des conventions telles que la langue utilisée pour les messages Oracle, le tri, les noms de jours et les noms de mois. Chaque langue prise en charge a un nom unique ; par exemple, AMERICAN, FRENCH ou GERMAN. L’argument language spécifie les valeurs par défaut pour les arguments de territoire et de jeu de caractères. Si la langue n’est pas spécifiée, la valeur par défaut est AMERICAN.

Que contrôle le composant TERRITORY du paramètre NLS_LANG ?

Le composant de territoire du paramètre NLS_LANG contrôle le fonctionnement d’un sous-ensemble de fonctionnalités de prise en charge de la globalisation. Il spécifie des conventions telles que la date par défaut, les formats monétaire et numérique. Chaque territoire pris en charge a un nom unique ; par exemple, AMERICA, FRANCE ou CANADA. Si le territoire n’est pas spécifié, la valeur est dérivée de la valeur de langue.

Pour trouver la valeur numérique réelle d’un caractère stocké dans la base de données, utilisez la commande dump :

La syntaxe de l’appel de fonction est la suivante :

où :

valeur - est la valeur à afficher

format - est un nombre qui décrit le format dans lequel les octets de la valeur doivent être affichés : 8 - signifie octal, 10 - signifie décimal, 16 - signifie hexadécimal ; les autres valeurs comprises entre 0 et 16 signifient décimal ; les valeurs supérieures à 16 sont un peu déroutantes et signifient : imprimer les octets sous forme de caractères ASCII s’ils correspondent à des codes ASCII imprimables, les impriment en tant que « ^x » s’ils correspondent à des codes de contrôle ASCII et sinon les imprimer en hexadécimal ; l’ajout de 1000 au numéro de format ajoutera des informations de jeu de caractères pour les valeurs de type de données de caractère à la valeur de retour décalage - est le décalage du premier octet de la valeur à afficher ; les valeurs négatives signifient compter à partir de la fin longueur - est le nombre d’octets à afficher. Donc par exemple,

Typ=1 Len=39 CharacterSet=UTF8 : 227,131,143,227,131,170

renvoie la valeur d’une colonne composée de 3 caractères japonais en codage UTF8. Par exemple, le premier caractère est 227(*255)+131. Vous devrez probablement convertir ceci en UCS2 pour vérifier la valeur du point de code avec la page de code Unicode Standard.

Où est la conversion de caractère effectuée ?

Normalement, la conversion est effectuée côté client pour des raisons de performances. Cela est vrai à partir de la version 8.0.4. Si la base de données utilise un jeu de caractères inconnu du client, la conversion est effectuée côté serveur. Cela est vrai à partir de la version 8.1.6.

Windows SQL*Plus ne montre pas tous mes caractères étendus ?

Vous voyez des carrés noirs au lieu des caractères pour lesquels vous n’avez probablement pas la bonne police définie pour votre page de code. Une police est une collection de glyphes (de hiéroglyphes) qui partagent une apparence commune (police de caractères, taille du caractère). Le système d’exploitation utilise une police pour convertir une valeur numérique en une représentation graphique à l’écran. Une police ne contient pas nécessairement une représentation graphique de toutes les valeurs numériques définies dans la page de code que vous utilisez. C’est pourquoi vous obtenez parfois des carrés noirs à l’écran si vous changez de police et que la nouvelle police n’a aucune représentation pour un symbole donné.

L’utilitaire "Carte du jeu de caractères " de Windows peut être utilisé pour voir quels glyphes font partie d’une police donnée.

Sous Windows 2000 et XP :

Démarrez -> Run...

Entrez "charmap", puis cliquez sur "OK".

Je reçois un point d’interrogation ou un point d’interrogation inversé lors de la sélection de caractères insérés ?

Lorsque des caractères sont convertis entre le client et le jeu de caractères de la base de données, ou inversement, le caractère doit exister dans les deux. S’il n’existe pas dans le jeu de caractères en cours de conversion (destination), un caractère de remplacement est utilisé. Certains jeux de caractères ont des caractères de remplacement spécifiques définis lors de la conversion à partir d’autres jeux de caractères spécifiques, mais dans ce cas, un caractère de remplacement par défaut, tel qu’un « ? », est utilisé. La conversion d’un caractère de remplacement en caractère d’origine n’est pas possible.

iSQL*Plus est-il le seul client compatible UTF8/Unicode que nous prenons en charge ?

Sous Windows, oui, sous Unix, non. Tous les utilitaires de base de données, y compris Import, Export, SQL*Loader, SQL*Plus, peuvent agir en tant que client UTF-8 si les paramètres régionaux du système d’exploitation sont UTF-8 (par exemple, en_US.UTF-8 sous Linux) et le jeu de caractères NLS_LANG est défini sur UTF8 ou AL32UTF8.

Comment vérifier les points de code gérés par un système d’exploitation UNIX ?

Pour savoir quel point de code est généré pour un caractère dans un environnement UNIX, vous pouvez utiliser la commande "od" :

Vous pouvez également vérifier le caractère correspondant à un point de code à l’aide de la commande "echo" comme ceci :

Pour Solaris, AIX, HP-UX, TRU64 :

Pour Linux :

Vous pouvez utiliser Locale Builder ou une page de code imprimée (voir les liens ci-dessous) pour vérifier que votre page de code native et le paramètre NLS_LANG correspondent correctement. S’il y a une ambiguïté, utilisez la commande ci-dessus pour obtenir les valeurs de plusieurs caractères. Pour la page de code imprimée :

http://www.unicode.org

http://www.iso.org

http://czyborra.com/charsets/iso8859.html

En règle générale, le paramètre NLS_LANG doit correspondre à la page de code OEM MS-DOS pouvant être extraite en entrant chcp dans une invite de commande :

C:\> chcp

Page de code active : 437

C:\> set NLS_LANG=american_america.US8PC437

Pour des outils tels que SQL*Loader, vous pouvez temporairement remplacer NLS_LANG par le jeu de caractères du FILE que vous chargez. Une alternative à la modification du paramètre NLS_LANG consiste à spécifier le jeu de caractères des données du fichier de données à l’aide du mot-clé characterset du fichier .ctl. Dans ce cas, SQL*Loader interprétera les données du fichier de données comme ce jeu de caractères, quel que soit le paramètre de jeu de caractères client défini pour NLS_LANG. Voici un exemple de fichier .ctl pour utf16. Cet exemple est livré dans la zone de démonstration :

-- Copyright (c) 2001 by Oracle Corporation
--   NAME
--     ulcase11.ctl - Load Data in the Unicode Character Set UTF-16
--   DESCRIPTION
--     Loads data in the Unicode character set UTF-16. The data is in little
--     Endean byte order. This means that depending on whether SQL*Loader is
--     running on a little Endean or a big Endean system, it will have to
--     byte swap the UTF-16 character data as necessary. This load uses
--     character length semantics, the default for the character set UTF-16.
-- 
--     This case study is modeled after case study 3 (ulcase3), which loads
--     variable length delimited (terminated and enclosed) data.
-- 
--   RETURNS
-- 
--   NOTES
--     None
--   MODIFIED   (MM/DD/YY)
--    rpfau     02/06/01  - Merged rpfau_sqlldr_add_case_study_11
--    rpfau     01/30/01 -  Creation
--

LOAD DATA
CHARACTERSET utf16
BYTEORDER little
INFILE ulcase11.dat
REPLACE

INTO TABLE EMP
FIELDS TERMINATED BY X'002c' OPTIONALLY ENCLOSED BY X'0022'
(empno integer external (5), ename, job, mgr,
 hiredate DATE(20) "DD-Month-YYYY",
 sal, comm,
 deptno   CHAR(5) TERMINATED BY ":",
 projno,
 loadseq  SEQUENCE(MAX,1) )
 

Dans Oracle9i, l’utilitaire Export exporte toujours les données utilisateur, y compris les données Unicode, dans le jeu de caractères de la base de données. L’utilitaire Import convertit automatiquement les données en jeu de caractères de la base de données cible.

Dans Oracle8i, l’utilitaire Export exporte les données utilisateur en les convertissant du jeu de caractères de la base de données au jeu de caractères du paramètre NLS_LANG de la session d’exportation. L’utilitaire Import convertit d’abord les données en jeu de caractères du paramètre NLS_LANG de la session d’importation, puis les convertit en jeu de caractères de la base de données cible. Il faut veiller à ce que le jeu de caractères du paramètre NLS_LANG pour les sessions d’exportation et d’importation contienne tous les caractères à migrer. Ce jeu de caractères est généralement choisi pour correspondre à la base de données source ou cible et il est généralement identique pour les sessions d’exportation et d’importation. Ce choix est recommandé en particulier avec les jeux de caractères multi-octets, qui imposent certaines restrictions aux fichiers d’exportation. Les conversions Oracle8i vers et à partir du jeu de caractères NLS_LANG ont lieu dans Oracle9i pour les instructions DDL contenues dans le fichier d’exportation.

Le paramètre NLS_LANG sur le serveur (ou le client) n’a aucune influence sur la conversion du jeu de caractères via un lien de base de données. Oracle effectuera la conversion du jeu de caractères de la base de données source en jeu de caractères de la base de données cible (ou inversement).

Il n’y a rien de spécial avec le paramètre NLS_LANG et les multiples répertoires d’accueil sous Windows. Le paramètre pris en compte est celui spécifié dans la clé de registre ORACLE_HOME utilisée par l’exécutable. Si le paramètre NLS_LANG est défini dans l’environnement, il est prioritaire sur la valeur du registre et est utilisé pour tous les répertoires d’accueil Oracle_Home sur le serveur/client.

Vous pouvez trouver le paramètre NLS_LANG dans ces clés de registre :

ou

Sous Windows, il existe deux types d’outils/applications :

1. 1) Une application entièrement compatible Unicode qui accepte les points de code Unicode et qui peut les rendre. C’est l’application qui doit gérer le format Unicode. Windows fournit l'API Unicode, mais le système GUI en tant que tel N'EST PAS Unicode de par sa conception.
   Une application entièrement Unicode ne peut afficher qu’un seul glyphe pour un point de code Unicode donné. Donc, il n’y a PAS de confusion possible ici, cette application devra utiliser une police Unicode complète. Si vous avez une application Unicode complète, vous devez définir le paramètre NLS_LANG sur UTF8.
   Notez qu’il n’y a actuellement pas beaucoup d’applications de ce type et que, s’il n’est pas indiqué explicitement par le fournisseur, il s’agit probablement d’une application ANSI. Donc, ne définissez pas NLS_LANG sur UTF8 si vous n’êtes pas sûr !

   iSQL*Plus est le seul client compatible avec Unicode inclus dans la base de données Oracle.

2. 2) Une application ANSI standard (telle que sqlplusw.exe) ne peut pas utiliser de points de code Unicode. Ainsi, le point de code Unicode stocké dans la base de données doit être converti en un point de code ANSI en fonction du paramètre correct de NLS_LANG. Cela permet à Oracle de mapper le point de code Unicode sur le jeu de caractères du client. Si le point de code Unicode n’a pas de correspondance avec le jeu de caractères du client, un caractère de remplacement est utilisé.

Un jeu de caractères est simplement un accord sur la valeur numérique d’un symbole. Un ordinateur ne sait pas ce que sont A et B, il ne connaît que les valeurs numériques (binaires) de ces symboles, définie dans le jeu de caractères utilisé par son système d’exploitation (OS) ou dans le matériel (micrologiciel) des terminaux. Un ordinateur ne peut manipuler que des nombres, raison pour laquelle des jeux de caractères sont nécessaires. Un exemple est ASCII, un ancien jeu de caractères de 7 bits, ROMAN8, un jeu de caractères de 8 bits sous UNIX ou UTF8, un jeu de caractères multi-octets.

Une page de code est le nom des schémas de codage Windows/DOS. Pour Oracle NLS, vous pouvez le considérer comme un jeu de caractères. Vous devez également faire la distinction entre une police et un jeu de caractères ou une page de code. Le système d’exploitation utilise une police pour convertir une valeur numérique en une impression graphique à l’écran. La police Wingdings sous Windows est le meilleur exemple de police où un A n’est pas indiqué comme un A à l’écran, mais pour le système d’exploitation, la valeur numérique représente un A. Donc, vous ne le voyez PAS comme un A, mais pour Windows c’est un A et sera enregistré (ou utilisé) comme un A.

Pour mieux comprendre l’explication ci-dessus, ouvrez simplement MS Word, choisissez la police Wingdings, entrez votre nom (vous verrez des symboles) et enregistrez-le au format HTML. Si vous ouvrez le fichier html avec Notepad, vous verrez que les polices sont indiquées dans la section <style>, et plus bas, dans la section <body>, vous trouverez votre nom en texte brut mais avec l’attribut style='font-family: Wingdings. Si vous ouvrez le fichier dans Internet Explorer ou Netscape, vous verrez à nouveau les symboles Wingdings. Il s’agit de la présentation qui change, et non les données elles-mêmes.

Il est également possible que vous ne voyiez pas avec une police particulière tous les symboles définis dans la page de code que vous utilisez, simplement parce que le créateur de la police n’a pas inclus de représentation graphique de tous les symboles dans cette police. C’est pourquoi vous obtenez parfois des carrés noirs à l’écran si vous changez de police. Sous Windows, vous pouvez utiliser l’outil Table des caractères pour voir tous les symboles définis dans une police.

Deux raisons principales :

Historiquement, les fournisseurs de matériel et de logiciels définissaient différents « jeux de caractères », principalement en raison de l’absence de normes officielles.

De nouveaux jeux de caractères ont été définis pour prendre en charge de nouvelles langues. Avec un jeu de caractères 8 bits, le nombre de symboles que vous pouvez prendre en charge est limité. Il existe donc différents jeux de caractères pour différentes langues écrites.

Un jeu de caractères 7 bits ne connaît que 128 symboles (2^7)

Un jeu de caractères de 8 bits connaît 256 symboles (2^8)

Unicode (UTF-8) est un jeu de caractères multi-octets. Unicode a la capacité de définir plus d’un million de caractères. Pour plus d’informations sur Unicode, consultez le livre blanc Oracle Unicode Database Support (PDF).

Pour choisir un jeu de caractères, il est essentiel de s’assurer qu’il peut gérer toutes les langues devant être prises en charge immédiatement et dans un avenir indéterminé. Une autre considération négligée consiste à réfléchir aux applications et technologies que vous pouvez utiliser ou à utiliser avec la base de données. Utilisez le générateur de paramètres régionaux (à partir d’Oracle Database 9i) pour afficher les caractères définis pour un jeu de caractères Oracle particulier.

Choisir Unicode comme jeu de caractères de la base de données assure une base solide pour tout ce qui est construit dans et sur la base de données. Oracle recommande d’utiliser Unicode pour tout nouveau déploiement de système. La migration de systèmes hérités vers Unicode est également recommandée. Le déploiement actuel de vos systèmes au format Unicode offre de nombreux avantages en termes de convivialité, de compatibilité et d’extensibilité. La prise en charge complète d’Oracle vous permet de déployer des systèmes hautement performants plus rapidement et plus facilement, tout en exploitant la véritable puissance d’Unicode. Même si vous n’avez pas besoin de prendre en charge les données multilingues aujourd’hui ou si vous avez besoin d’Unicode, c’est toujours le meilleur choix pour un nouveau système à long terme. En fin de compte, vous gagnerez du temps et de l’argent, et elles vous donneront des avantages concurrentiels.