Un configuración regional es un conjunto de información que aborda los requisitos lingüísticos y culturales correspondientes a un idioma y país determinados. Desde hace tiempo, los datos asociados a una configuración regional nos permiten formatear y analizar fechas, horas, números, divisas, etc. El suministro de datos correctos y actuales para la configuración regional siempre ha sido responsabilidad de cada propietario o proveedor de plataforma, lo que ha provocado incoherencias y errores en estos datos.

La forma más sencilla de especificar el comportamiento de la configuración regional para el software Oracle es emplear el parámetro de entorno NLS_LANG. Establece el idioma y la zona utilizadas por la aplicación cliente y el servidor de la base de datos. También indica el conjunto de caracteres del cliente, que será el mismo que el de los datos a introducir o mostrar por el programa cliente.

NLS_LANG se configura como una variable de entorno local en las plataformas UNIX. En plataformas Windows, NLS_LANG se configura en el registro.

El parámetro NLS_LANG tiene tres componentes: idioma, territorio y conjunto de caracteres. Especifícalo en el siguiente formato, incluyendo la puntuación:
NLS_LANG = language_territory.charset

Cada componente del parámetro NLS_LANG controla el funcionamiento de un subconjunto de características de soporte de globalización:

Language (idioma)
Especifica convenciones como el idioma utilizado para mensajes Oracle, el orden y los nombres de los días y meses. Todos los idiomas tienen un nombre exclusivo; por ejemplo: AMERICAN, FRENCH o GERMAN. El parámetro del lenguaje especifica valores predeterminados para los parámetros de región y conjunto de caracteres. Si no se especifica el idioma, el valor predeterminado es AMERICAN

Territory (región)
Especifica convenciones como la fecha predeterminada o los formatos de número y divisa. Cada región admitida tiene un nombre único; por ejemplo, AMERICA, FRANCE o CANADA. Si no se especifica la región, el parámetro se obtiene del valor idioma.

Charset (conjunto de caracteres)
Especifica el conjunto de caracteres utilizado por la aplicación del cliente (normalmente el conjunto de caracteres de Oracle del terminal del usuario o del sistema operativo). Cada conjunto de caracteres admitido tiene un acrónimo exclusivo; por ejemplo: US7ASCII, WE8ISO8859P1, WE8DEC, WE8MSWIN1252 o JA16EUC. Cada idioma tiene un conjunto de caracteres predeterminado asociado.

Nota:

Todos los componentes de la definición NLS_LANG son opcionales; cualquier elemento que no se especifique utiliza su valor determinado. Si se especifica un territorio o un conjunto de caracteres, entonces debe incluir el delimitador anterior [guión bajo (_) para el territorio, punto (.) para el conjunto de caracteres]. De lo contrario, el valor se analiza como un nombre de idioma.

Por ejemplo, para configurar solo la región en NLS_LANG, usa el siguiente formato: NLS_LANG=_JAPAN

El resto de este documento se centrará en el componente "charset" de la configuración NLS_LANG, ya que es la parte menos comprendida y la más importante para realizar una configuración adecuada.

• Establecer el NLS_LANG según el conjunto de caracteres de la base de datos PUEDE ser correcto, pero a menudo NO LO ES. NO asuma que NLS_LANG deba tener el mismo juego de caracteres que la base de datos. A MENUDO NO ES VERDAD.
• El juego de caracteres definido con el parámetro NLS_LANG NO CAMBIA el conjunto de caracteres del cliente. Se utiliza para informar a Oracle sobre qué conjunto de caracteres se está USANDO en el lado del cliente, para que Oracle pueda realizar la conversión adecuada. No puede cambiar el juego de caracteres de su cliente utilizando un NLS_LANG diferente.
• Si no configura el NLS_LANG en el cliente, se utilizará el NLS_LANG del servidor. Esto TAMPOCO es cierto. Por ejemplo, si el instalador Oracle no completa NLS_LANG y no se configura de otra manera, su valor por defecto es AMERICAN_AMERICA.US7ASCII. El idioma es AMERICAN, la región es AMERICA y el conjunto de caracteres es US7ASCII.
• La configuración los parámetros LANGUAGE y TERRITORY en NLS_LANG no tiene nada que ver con la capacidad de almacenar caracteres en una base de datos. Un NLS_LANG configurado en JAPANESE_JAPAN.WE8MSWIN1252 no le permitirá almacenar japonés, ya que WE8MSWIN1252 no admite caracteres japoneses. Sin embargo, un NLS_LANG configurado como AMERICAN_AMERICA.JA16SJIS sí le permitirá almacenar japonés, siempre que los datos de entrada sean realmente JA16SJIS y si la base de datos también está en un conjunto de caracteres que pueda almacenar japonés, como UTF8 o JA16SJIS.

En muchos casos, NLS_LANG ya se ha configurado durante la instalación de Oracle o posteriormente de forma manual. Para asegurarse de que puede usar estos métodos para recuperar el valor de NLS_LANG para SQL*Plus:

En UNIX:

Esta instrucción devuelve el valor del parámetro.

En Windows:
En Windows tienes dos opciones: normalmente NLS_LANG se configura en el registro, pero también se puede configurar en el entorno; sin embargo, esto no se hace con frecuencia. El valor en el entorno tiene prioridad sobre el valor en el registro y se utiliza para TODOS los Oracle_Homes en el servidor. Recuerde que cualquier variable de entorno USER tiene prioridad sobre cualquier variable de entorno SYSTEM (este es el comportamiento de Windows y no tiene nada que ver con Oracle) si se configura.

Para verificar si se ha configurado en el entorno:

Si esto solo devuelve %NLS_LANG%, la variable no se ha configurado en el entorno.

Si se ha configurado, enviaría algo así:

ENGLISH_UNITED KINGDOM.WE8ISO8859P1
Si NLS_LANG no está configurado en el entorno, verifica el valor en el registro:

Si aparece algo como:
No se puede abrir el archivo.[ENGLISH_UNITED KINGDOM.WE8ISO8859P1].
El valor del parámetro en el registro es el "nombre de archivo" entre corchetes.

Si recibes esto como resultado:
No es posible abrir el archivo ".[% NLS_LANG%].", el parámetro NLS_LANG tampoco está configurado en el registro.

Tenga en cuenta que la técnica @.[% NLS_LANG%]. informa sobre el NLS_LANG conocido por el ejecutable SQL*Plus; no leerá el registro en sí. Sin embargo, si ejecuta el comando HOST primero y el NLS_LANG no está configurado en el entorno, entonces puede estar seguro de que la variable está configurada en el registro si @.[% NLS_LANG%]. devuelve un valor válido.

Todos los demás parámetros de NLS se pueden obtener mediante:

Nota:

SELECT USERENV ('language') FROM DUAL; da el <Lenguaje>_<territorio> de la sesión, pero el conjunto de caracteres de la BASE DE DATOS no el cliente, por lo que el valor devuelto no es la configuración NLS_LANG completa del cliente.

Esta sección explica el orden en el que los parámetros NLS se tienen en cuenta en el modelo cliente/servidor de la base de datos. (Esto NO abarca conexiones Thin JDBC)

Hay 3 niveles en los que puedes definir parámetros NLS: base de datos, instancia y sesión. Si un parámetro se define en más de un nivel, las reglas de prioridad son bastante sencillas:

1. 1. La configuración de la base de datos NLS es reemplazada por la configuración de la instancia NLS.
2. 2. Los ajustes de la base de datos y la instancia NLS se sustituyen por la configuración de sesión NLS.

Estos son los ajustes utilizados para la sesión SQL actual.

Reflejan lo siguiente (en este orden):

1. 1) Los valores de los parámetros NLS establecidos por "ALTER SESSION"
   ALTER SESSION configura NLS_DATE_FORMAT='DD/MM/AAAA'.
2. 2) Si no hay una expresión "ALTER SESSION" específica, refleja la configuración del parámetro NLS correspondiente en el cliente obtenido de la variable NLS_LANG.
3. 3) Si se especifica NLS_LANG solo con esta parte, AMERICAN se usa por defecto.

   Así que si configura NLS_LANG =_BELGIUM. WE8MSWIN1252, obtendrá esto:

   VALOR DE PARÁMETRO

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY BELGIUM
   NLS_CURRENCY <símbolo de euro aquí>
   NLS_ISO_CURRENCY BELGIUM

   Nota:

   La diferencia entre NLS_LANG=_BELGIUM.WE8MSWIN1252 (correcto) y

   NLS_LANG=BELGIUM.WE8MSWIN1252 (incorrecto) es que debe usar "_" como separador.

4. 4) Si se especifica NLS_LANG solo con esta parte, los valores predeterminados se basan en .

   Por lo tanto, si configura NLS_LANG=ITALIAN_.WE8MSWIN1252, obtendrá esto:

   VALOR DE PARÁMETRO

   NLS_LANGUAGE ITALIAN
   NLS_TERRITORY ITALY
   NLS_CURRENCY <símbolo del euro aquí>
   NLS_ISO_CURRENCY ITALY

   Nota:

   Ten en cuenta la diferencia entre NLS_LANG=ITALIAN_.WE8MSWIN1252 (correcto) y

   NLS_LANG=ITALIAN.WE8MSWIN1252 (incorrecto); debe usar "_" como separador.

5. 5) Si se especifica NLS_LANG sin la sección _, entonces esta tiene el valor predeterminado AMERICAN_AMERICA.

   Por lo tanto, si configura NLS_LANG=.WE8MSWIN1252, obtendrá esto:

   VALOR DE PARÁMETRO

   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 se configura NLS_LANG (ya sea como en el punto 3, 4 o 5), los parámetros como

   NLS_SORT, NLS_DATE_FORMAT, etc. se pueden establecer como "independientes" y anularán los valores predeterminados derivados de la sección_ en NLS_LANG.

   En ese caso, si configura NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 y NLS_ISO_CURRENCY=FRANCE, obtendrá esto:

   VALOR DE PARÁMETRO

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY AMERICA
   NLS_CURRENCY $
   NLS_ISO_CURRENCY FRANCE

   Valores predeterminados:
   * Si no se definen NLS_DATE_LANGUAGE o NLS_SORT, se obtienen 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 no se definen, se obtienen de NLS_TERRITORY

7. 7) Si NLS_LANG no está configurado de ningún modo, el valor predeterminado es

   <Language>_<Territory>.US7ASCII y los valores para la sección
   <Language>_<Territory> utilizada son las que se encuentran en

   NLS_INSTANCE_PARAMETERS. Se ignoran los parámetros como NLS_SORT definidos como "independientes"en el lado del cliente.

   
   
   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.
   

Estos son los ajustes en init.ora de la base de datos en el momento en que la base de datos se inició o configuró a través de ALTER SYSTEM.

Si el parámetro no está establecido explícitamente en init.ora o definido por ALTER SYSTEM, su valor NO se deriva de un parámetro "mayor" (son parámetros como NLS_SORT los que derivan un valor predeterminado de NLS_LANGUAGE en NLS_SESSION_PARAMETERS; NO ocurre lo mismo para 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.

El valor predeterminado es AMERICAN_AMERICA si no hay parámetros establecidos explícitamente en init.ora en el momento de la creación de la base de datos. Si hay parámetros establecidos en init.ora durante la creación de la base de datos, los verá aquí. No se pueden cambiar después de crear la base de datos. NO intente actualizar las tablas del sistema para omitir esta configuración. Esta configuración se utiliza para dar un valor predeterminado a la base de datos si los parámetros INSTANCE y SESSION no están establecidos.

Nota:

* NLS_LANG no es un parámetro init.ora; NLS_LANGUAGE y NLS_TERRITORY sí lo son.

Por lo tanto, debe establecer NLS_LANGUAGE y NLS_TERRITORY por separado.

* Estos parámetros son anulados por NLS_INSTANCE_PARAMETERS y NLS_SESSION_PARAMETERS.

* No puedes definir el <conjunto de caracteres de cliente> o NLS_LANG en init.ora. El juego de caracteres del cliente está definido por NLS_LANG en el sistema operativo del cliente.

* No puede definir el conjunto de caracteres de la base de datos en init.ora.

El conjunto de caracteres (nacional) NLS_(NCHAR)_CHARACTERSET) establecido de la base de datos está definido por la instrucción "Create Database".

* Los parámetros NLS_CHARACTERSET y NLS_NCHAR_CHARACTERSET no pueden ser anulados por parámetros de instancia o sesión.

Se definen por el valor especificado en la instrucción "CREATE DATABASE", y no están diseñados para cambiarse después de forma dinámica. NO actualice las tablas del sistema para cambiar el juego de caracteres. Esto puede dañar su base de datos y hacer potencialmente imposible una nueva apertura de la base de datos.

* La configuración de NLS_LANG durante la creación de la base de datos no influye en NLS_DATABASE_PARAMETERS.

* El NLS_LANG establecido durante la creación de la base de datos NO afecta al conjunto de caracteres nacional de la base de datos.

Instrucciones SELECT adicionales:
A) SELECT name,value$ from sys.props$ where name like '%NLS%';
Esto da la misma información que NLS_DATABASE_PARAMETERS.Deberías usar NLS_DATABASE_PARAMETERS en lugar de props$.

Tenga en cuenta la MAYÚSCULA '%NLS%'

B) SELECT * from v$nls_parameters;
Esta vista muestra los parámetros de sesión actuales y el conjunto de caracteres *DATABASE* como aparece en la vista NLS_DATABASE_PARAMETERS.

C) SELECT name,value from v$parameter where name like '%NLS%';
Esta vista proporciona la misma información que NLS_INSTANCE_PARAMETERS.
Tenga en cuenta la MINÚSCULA '%NLS%'

D) SELECT userenv ('language') from dual;
y
SELECT sys_context('userenv','language') from dual;
Ambas declaraciones SELECT dan el _ de la sesión y el juego de caracteres
DATABASE. El juego de caracteres de la base de datos no es el mismo que el juego de caracteres de NLS_LANG con el que inició esta conexión. Así que no se confunda, aunque el resultado de esta consulta se parece al valor de una variable NLS_LANG, NO lo es.

E) SELECT userenv ('lang') from dual;
Este SELECT proporciona el código corto que Oracle usa para el idioma definido por la configuración NLS_LANGUAGE para esta sesión. Si NLS_LANGUAGE está configurado en francés, esto devolverá "F"; si NLS_LANGUAGE está configurado en inglés, esto devolverá "GB"
; si NLS_LANGUAGE está configurado en estadounidense, esto devolverá "US", etc.

F) SHOW parameter NLS%
Esto devolverá lo mismo que NLS_INSTANCE_PARAMETERS

Se crea una base de datos en un sistema UNIX con el juego de caracteres US7ASCII. Un cliente de Windows que se conecta a la base de datos funciona con el juego de caracteres WE8MSWIN1252 (configuración regional -> Europa Occidental/ACP 1252) y el DBA; usa el shell UNIX (ROMAN8) para trabajar en la base de datos. NLS_LANG está configurado como american_america.US7ASCII en los clientes y el servidor.

Note:

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

Un punto muy importante (como ya se ha dicho):

Cuando el juego de caracteres NLS_LANG del cliente se configura con el mismo valor que el juego de caracteres de la base de datos, Oracle asume que los datos que se envían o reciben son de la misma codificación (correcta), por lo que no pueden producirse conversiones o validaciones por razones de rendimiento. Los datos se almacenan tal y como los entrega el cliente, bit a bit.

Desde Windows ingresa una (LETRA MINÚSCULA LATINA E CON TILDE) en una tabla NLS_TEST que contenga una columna TEST del tipo 'char'.

Siempre que inserte y seleccione en la columna Windows con el juego de caracteres WE8MSWIN1252, todo funcionará correctamente. No se realiza ninguna conversión, y se insertan y vuelven a leer 8 bits, aunque el conjunto de caracteres de la base de datos esté definido en 7 bits. Esto sucede porque un byte son 8 bits y Oracle SIEMPRE usa 8 bits, incluso con un conjunto de caracteres de 7 bits. En una configuración correcta, el bit más significativo no se usa y solo se tienen en cuenta 7 bits.

Por una razón u otra, debe insertarlo desde el servidor UNIX. Cuando se hace SELECT desde tablas donde los clientes de Windows ingresan datos, obtienes una Ò (LETRA O MAYÚSCULA LATINA CON TILDE) en lugar de ‘é’.

Si inserta ‘é’ en el servidor UNIX y SELECT la fila en el cliente de Windows, obtienes una ‘Å’ (LETRA MAYÚSCULA LATINA A CON UN ANILLO ENCIMA).

La conclusión es que tiene datos INCORRECTOS en la base de datos. Se almacena el valor numérico para 'é' del conjunto de caracteres WE8MSWIN1252 en la base de datos, pero se le dice a Oracle que son datos US7ASCII, por lo que Oracle NO convierte nada y sólo almacena el valor numérico (de nuevo: Oracle piensa que el cliente está dando códigos US7ASCII porque el NLS_LANG está configurado como US7ASCII, y el conjunto de caracteres de la base de datos también es US7ASCII -> no se realiza ninguna conversión).

Cuando SELECCIONA la misma columna de nuevo en el servidor UNIX, Oracle sigue esperando que el valor sea correcto, y pasa el valor al terminal UNIX sin ninguna conversión.

Ahora el problema es que en el conjunto de caracteres WE8MSWIN1252 la 'é' tiene el valor hexadecimal 'E9'y en el conjunto de caracteres Roman8 el valor hexadecimal para 'é' es 'C5'. Oracle simplemente pasa el valor almacenado en la base de datos ('E9') al terminal UNIX, y el terminal UNIX piensa que se trata de la letra '?' porque en su conjunto de caracteres (Roman8) el valor hexadecimal 'E9' está representando la letra 'Ò'. Así que en lugar de la 'é' se obtiene la 'Ò' en la pantalla del terminal UNIX.

Ocurre lo mismo al revés (la inserción se produce en UNIX y SELECT en el cliente Windows), pero se obtienen otros resultados.

La solución es crear la base de datos con un conjunto de caracteres que contenga ‘é’

(WE8MSWIN1252, WE8ISO89859P1, UTF-8, etc.) y configurar NLS_LANG en el cliente como WE8MSWIN1252, y en el servidor como WE8ROMAN8. Si luego insertas una ‘é’ en ambos lados, obtendrás una ‘é’, independientemente del lugar en el que los SELECCIONES. Oracle sabe entonces que un valor hexadecimal de 'C5' insertado por el UNIX y un 'E9' de un cliente WE8MSWIN1252 son ambos 'é' e inserta 'é' en la base de datos (el código en la base de datos depende del conjunto de caracteres que haya elegido).

No es necesario cambiar entre UNIX, Windows u otros clientes del sistema operativo para encontrar este tipo de problemas. El mismo problema aparece si agrega clientes de Windows que están usando otro juego de caracteres y tienen un conjunto NLS_LANG incorrecto.

Para especificar el comportamiento de la configuración regional de su cliente Oracle, debe configurar el parámetro NLS_LANG. Establece el idioma, el territorio y también el conjunto de caracteres de su cliente. Debe verificar la configuración del entorno regional para establecer el tercer campo de NLS_LANG (conjunto de caracteres) en consonancia. Para hacerlo, use la instrucción "locale" de esta manera:

$ 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 salida de este comando no es exactamente la misma en todos los entornos Unix. En algunas plataformas, puede ser útil usar la siguiente sintaxis para tener más detalles sobre la página de códigos utilizada:

$ locale LC_CTYPE | cabeza

         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 

En estos casos, el tercer campo de NLS_LANG debe configurarse como WE8ISO8859P15. En Solaris, AIX y TRU64, esta sintaxis no aporta información complementaria interesante. Para obtener más información sobre estos ajustes:

En Solaris, busca en /usr/lib/locale
En AIX, busca en /usr/lib/nls/README
En TRU64, busca en /usr/lib/nls
En HP-UX, busca en /usr/lib/nls/config
En Linux, busca en /usr/share/locale/locale.alias

Para establecer un valor elegido para estos ajustes "locale" (regionales), es necesario saber qué valores están disponibles. Para averiguarlo, utilice la siguiente sintaxis:

A continuación, cuando haya escogido un valor, por ejemplo UTF-8 en Linux, puede configurarlo así:

o

 
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

En este caso, el tercer campo (juego de caracteres) de NLS_LANG debe configurarse como UTF8.

% setenv NLS_LANG American_America.UTF8

En los sistemas Windows, el esquema de codificación (juego de caracteres) se especifica mediante una página de códigos. Las páginas de códigos se definen para admitir idiomas específicos, o grupos de idiomas, que comparten sistemas de escritura comunes. Desde el punto de vista de Oracle, los términos 'página de códigos' y 'juego/conjunto de caracteres' significan lo mismo. Tenga en cuenta que en entornos ajenos a la escritura china-japonesa-coreana, la GUI de Windows y el símbolo del sistema de DOS no usan la misma página de códigos.

Como resultado, Windows utiliza dos juegos de caracteres diferentes para los entornos ANSI (sqlplusw.exe) y OEM (dos box - sqlplus.exe).

En el registro:
En los sistemas Windows, debes asegurarte de haber definido una subclave de registro NLS_LANG para cada uno de tus directorios raíz de Oracle:
puedes modificar fácilmente esta subclave con el editor de registro de Windows:
Iniciar -> Ejecutar...
Escribe "regedit" y haz clic en "ok"
Edita la siguiente entrada de registro:

Para la versión 7 de Oracle:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE

Para las versiones 8, 8i y 9i de Oracle Database:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx\

donde "x" es el número único que identifica el Oracle Home.

HOME0 es la primera instalación

Para Oracle Database 10g:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_

Esta es una entrada con el nombre NLS_LANG

Al iniciar herramientas Oracle (como SQL*Plusw), esta leerá el contenido del archivo oracle.key ubicado en el mismo directorio para determinar qué jerarquía de registro se usará y, por lo tanto, qué subclave NLS_LANG se utilizará.

Nota:

Algunas personas se confunden al encontrar un NLS_LANG configurado como "NA" en HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE si no hay una versión 7 instalada. Esto se usa para la compatibilidad con versiones anteriores y puede ignorarse.

Como sistema o variable de entorno del usuario en las propiedades del sistema:

Aunque el registro es el repositorio principal para la configuración en Windows, no es el único lugar donde se pueden configurar los parámetros. Aunque no es recomendable, es posible configurar NLS_LANG como una variable de sistema o de entorno de usuario en las propiedades del sistema.

Esta configuración se usará para TODAS las Oracle Homes.

Para verificar y modificar:

Haz clic con el botón derecho en el icono de 'My Computer -> 'Properties'

Seleccione 'Advanced Tab -> haga clic en 'Environment Variables'

La lista de variables de usuario contiene la configuración para el usuario específico del sistema operativo actualmente conectado y las 'variables del sistema o variables de todo el sistema para todos los usuarios.

Dado que estas variables de entorno tienen prioridad sobre los parámetros ya establecidos en su registro, no debe establecer los parámetros Oracle en esta ubicación a menos que tenga una muy buena razón para hacerlo.

Como una variable de entorno definida en el símbolo del sistema:

Antes de utilizar una herramienta de línea de comandos Oracle, debe CONFIGURAR MANUALMENTE el parámetro NLS_LANG. En un símbolo del sistema de MS-DOS, use el comando set, por ejemplo:

C:\> set NLS_LANG=american_america.WE8PC850

Ahora que ya conoce la configuración de NLS_LANG, puede verificar si coincide con la página de códigos ANSI actual. La ACP (página de códigos ANSI) está definida por la "configuración regional predeterminada" de Windows, por lo que si tiene un cliente de Windows 2000 en el Reino Unido y desea introducir cirílico (ruso), debe cambiar el ACP (cambiando la "configuración regional predeterminada").

El valor está en el registro:

Inicio -> Ejecutar...

Escriba "regedit" y haga clic en "ok"

Busque la siguiente entrada de registro:

Aquí encontrará (al final) una entrada con el nombre ACP. El valor de ACP es su página de códigos GUI actual para la asignación al nombre Oracle. Como hay muchas entradas de registro con nombres muy similares, asegúrese de buscar en el lugar correcto del registro.

Además, la siguiente URL proporciona una lista de las páginas de códigos predeterminadas para todas las versiones de Windows:

http://www.microsoft.com/globaldev/reference/ (debajo de la pestaña REFERENCE, a la izquierda de la página)

OEM = la página de códigos de la línea de comandos; ANSI = la página de códigos de la GUI

Tenga en cuenta que Honk Kong HKSCS está aquí: http://www.microsoft.com/hk/hkscs/

Busque el correspondiente conjunto de caracteres del cliente Oracle:

Busque el conjunto de caracteres del cliente Oracle en la siguiente tabla en función del ACP que haya encontrado antes. Tenga en cuenta que solo hay UN valor CORRECTO para un ACP determinado.

Este es el conjunto de caracteres utilizado por GUI SQL*Plus (sqlplusW.exe / plus80W.exe / plus33W.exe) que se inicia con el menú de inicio de Windows. Tenga en cuenta la diferencia entre GUI SQL*Plus y SQL*Plus del "modo DOS".

Puede usar UTF8 como conjunto de caracteres del cliente Oracle (=NLS_LANG) en Windows NT, 2000 y XP, pero solo podrá usar programas de cliente que admitan explícitamente esta configuración. Esto se debe a que la interfaz de usuario de Win32 no es UTF8; por lo tanto, el programa cliente debe realizar conversiones explícitas entre UTF8 (empleado en el lado Oracle) y UTF16 (en el lado Win32).

Configúrelo en su registro:

Use el editor del registro de Windows para configurar NLS_LANG en su Oracle Home con el valor que acaba de encontrar arriba.

El modo MS-DOS utiliza, con algunas excepciones como CJK (japonés, coreano, chino simplificado y chino tradicional), una página de códigos diferente (llamada página de códigos OEM) a la GUI de Windows (página de códigos ANSI). Esto significa que, antes de usar una herramienta de línea de comandos Oracle como SQL*Plus (sqlplus.exe / plus80.exe / plus33.exe) para svrmgrl en un símbolo del sistema, debe CONFIGURAR MANUALMENTE el parámetro NLS_LANG como una variable de entorno con el comando 'set' en DOS ANTES de usar la herramienta.

Para japonés, coreano, chino simplificado y chino tradicional, la página de códigos OEM (CJK) de MS-DOS es idéntica a la página de códigos ANSI; por lo tanto, en este caso particular, no es necesario establecer el parámetro NLS_LANG en modo MS-DOS.

En todos los demás casos, debe configurarlo para sobrescribir la clave de registro NLS_LANG que ya coincide con la página de códigos ANSI. El nuevo NLS_LANG "específico de MS-DOS" debe coincidir con la página de códigos OEM de MS-DOS, que se puede obtener escribiendo 'chcp' en un símbolo del sistema:

C:\> chcp

Página de códigos activa: 437

C:\> set NLS_LANG=american_america.US8PC437

Si el parámetro NLS_LANG para la sesión en modo MS-DOS no está configurado correctamente, los mensajes de error y los datos pueden corromperse debido a la conversión incorrecta del juego de caracteres.

Use la siguiente lista para encontrar el conjunto de caracteres Oracle que se ajuste a su página de códigos MS-DOS actual en el sistema de configuración regional:

Nota: Esta es la configuración correcta para la versión GUI SQL*Plus, (sqlplusW.exe / plus80W.exe / plus33W.exe)

Si está haciendo pruebas con caracteres "especiales" USE la GUI y no el sqlplus.exe de "DOS box".

Nota: Esta es la configuración correcta para la versión DOS BOX SQL*Plus, (sqlplus.exe / plus80.exe / plus33.exe)

¿Qué controla el componente LANGUAGE del parámetro NLS_LANG?

El componente de idioma (language) del parámetro NLS_LANG controla el funcionamiento de un subconjunto de características de soporte de globalización. Especifica convenciones como el idioma utilizado para mensajes Oracle, el orden y los nombres de los días y meses. Todos los idiomas tienen un nombre exclusivo; por ejemplo: AMERICAN, FRENCH o GERMAN. El parámetro del lenguaje especifica valores predeterminados para los parámetros de región y conjunto de caracteres. Si no se especifica el idioma, el valor predeterminado es AMERICAN.

¿Qué controla el componente TERRITORY del parámetro NLS_LANG?

El componente de región (territory) del parámetro NLS_LANG controla el funcionamiento de un subconjunto de características de soporte de globalización. Especifica convenciones como la fecha predeterminada o los formatos de número y divisa. Cada región admitida tiene un nombre único; por ejemplo, AMERICA, FRANCE o CANADA. Si no se especifica la región, el parámetro se obtiene del valor idioma.

Para encontrar el valor numérico real de un carácter almacenado en la base de datos, use el comando 'dump':

La sintaxis de la llamada a la función es:

donde:

value: el valor a mostrar

formato - es un número que describe el formato en el que deben mostrarse los bytes del valor: 8 - significa octal, 10 - significa decimal, 16 - significa hexadecimal; otros valores entre 0 y 16 significan decimal; los valores superiores a 16 son un poco confusos y significan imprimir los bytes como caracteres ASCII si corresponden a códigos ASCII imprimibles, imprimirlos como "^x" si corresponden a códigos de control ASCII e imprimirlos en hexadecimal en caso contrario; si se añade 1000 al número de formato se añadirá la información del conjunto de caracteres para los valores del tipo de datos de caracteres al valor de retorno de compensación - es el desplazamiento del primer byte del valor a mostrar; los valores negativos significan contar desde el final delongitud - es el número de bytes a mostrar. Por ejemplo:

Tipo=1 Len=39 Conjuntodecaracteres=UTF8: 227,131,143,227,131,170

devuelve el valor de una columna que consta de 3 caracteres japoneses en codificación UTF8. Por ejemplo, el primer carácter es 227(*255) + 131. Probablemente necesitará convertir esto a UCS2 para contrastar el valor de punto de código con la página de códigos estándar Unicode.

¿Dónde se realiza la conversión de caracteres?

Normalmente, la conversión se realiza en el lado del cliente por razones de rendimiento. Así es desde la versión 8.0.4 en adelante. Si la base de datos está utilizando un juego de caracteres desconocido por el cliente, la conversión se realiza en el lado del servidor. Así es desde la versión 8.1.6 en adelante.

¿Por qué no muestra Windows SQL*Plus todos mis caracteres extendidos?

Si ves cuadrados negros en lugar de caracteres, probablemente no has definido la fuente adecuada para tu página de códigos. Una fuente es una colección de glifos (de "jeroglíficos") que comparten una apariencia común (tipo de letra, tamaño de caracteres). El sistema operativo utiliza una fuente para convertir un valor numérico en una representación gráfica en la pantalla. Una fuente no contiene necesariamente una representación gráfica para todos los valores numéricos definidos en la página de códigos que está utilizando. Por eso a veces aparecen cuadrados negros en la pantalla si cambia las fuentes y la nueva fuente no tiene ninguna representación para un determinado símbolo.

La función de "mapa de juego de caracteres" en Windows se puede utilizar para ver qué glifos son parte de una fuente determinada.

En Windows 2000 y XP:

Inicio -> Ejecutar...

escriba "charmap" y haga clic en "ok".

Obtengo un signo de apertura o cierre de interrogación al seleccionar de nuevo los caracteres insertados. ¿A qué se debe esto?

Cuando se convierten caracteres entre el conjunto de caracteres del cliente y de la base de datos, o viceversa, el carácter debe estar en ambos. Si este no está en el conjunto de caracteres de destino, se utiliza un carácter de sustitución. Algunos juegos de caracteres tienen caracteres de sustitución específicos definidos al traducir desde otros juegos de caracteres; sin embargo, cuando no es así, se usa un carácter de sustitución predeterminado, como '?'. No es posible convertir un carácter de sustitución de nuevo al original.

¿Es iSQL*Plus el único cliente para UTF8/Unicode soportado?

Es el único en Windows pero no en Unix. Todas las utilidades de la base de datos (incluyendo Import, Export, SQL*Loader, SQL*Plus) pueden actuar como cliente UTF-8 si la configuración regional del sistema operativo es UTF-8 (por ejemplo, en_US.UTF-8 en Linux) y el conjunto de caracteres NLS_LANG está configurado en UTF8 o AL32UTF8.

¿Cómo se pueden verificar los puntos de código administrados por un sistema operativo UNIX?

Para saber qué punto de código se genera para un carácter en un entorno Unix, puede usar el comando "od":

También puede verificar el carácter correspondiente a un punto de código utilizando el comando "echo" de la siguiente manera:

para Solaris, AIX, HP-UX, TRU64:

para Linux:

Puede usar Locale Builder o una página de códigos impresa (ver enlaces a continuación) para verificar que su página de códigos nativa y la configuración NLS_LANG tengan la correspondencia adecuada. Si hay alguna ambigüedad, utilice el comando anterior para obtener los valores de más de un carácter. Para la página de códigos impresa:

http://www.unicode.org

http://www.iso.org

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

Normalmente, NLS_LANG debe coincidir con la página de códigos OEM de MS-DOS que se puede recuperar escribiendo 'chcp' en el símbolo del sistema:

C:\> chcp

Página de códigos activa: 437

C:\> set NLS_LANG=american_america.US8PC437

Para herramientas como SQL*Loader, puede cambiar temporalmente el NLS_LANG al juego de caracteres del ARCHIVO que está cargando. Una alternativa para cambiar NLS_LANG es especificar el conjunto de caracteres de los datos en el archivo de datos utilizando la palabra clave del conjunto de caracteres en el archivo .ctl. En ese caso, SQL*Loader interpretará los datos en el archivo de datos como ese juego de caracteres, independientemente de la configuración de conjunto de caracteres del cliente de NLS_LANG. A continuación puede ver un ejemplo de archivo .ctl para utf16. Este ejemplo se distribuye en el área de demostración:

-- 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) )
 

En Oracle9i, la utilidad Exportar siempre exporta los datos del usuario, incluidos los datos Unicode, en el juego de caracteres de la base de datos. La utilidad Importar convierte automáticamente los datos al conjunto de caracteres de la base de datos de destino.

En Oracle8i, la utilidad Exportar exporta los datos del usuario, y los convierte desde el juego de caracteres de la base de datos al juego de caracteres del NLS_LANG en la sesión de exportación. La utilidad Importar convierte primero los datos al conjunto de caracteres de NLS_LANG de la sesión de importación y luego los convierte al conjunto de caracteres de la base de datos de destino. Se debe tener cuidado de que el juego de caracteres de NLS_LANG para las sesiones de exportación e importación contenga todos los caracteres a migrar. Por lo general, este conjunto de caracteres se elige para que sea la base de datos de origen o el conjunto de caracteres de la base de datos de destino y, normalmente, es el mismo para las sesiones de exportación e importación. Esta opción es especialmente recomendable con juegos de caracteres multibyte, que presentan algunas restricciones en los archivos de exportación. Las conversiones Oracle8i con el juego de caracteres NLS_LANG se producen en Oracle9i para las expresiones DDL contenidas en el archivo de exportación.

El NLS_LANG en el servidor (o cliente) no tiene influencia en la conversión del juego de caracteres a través de un enlace de base de datos. Oracle realizará la conversión del juego de caracteres de la base de datos de origen al de la base de datos de destino (o al revés).

No hay ninguna instrucción especial sobre NLS_LANG y las múltiples Homes en Windows. El parámetro tomado en cuenta es el especificado en la clave de registro ORACLE_HOME utilizada por el ejecutable. Si NLS_LANG está configurado en el entorno, tiene prioridad sobre el valor del registro y se usa para TODOS los Oracle_Homes en el servidor/cliente.

El NLS_LANG se puede encontrar en estas claves de registro:

o

En Windows hay dos tipos de herramientas/aplicaciones:

1. 1) Una aplicación totalmente habilitada para Unicode que acepta puntos de código Unicode y que puede representarlos. Es la aplicación que necesita trabajar con Unicode. Windows proporciona la API Unicode pero el sistema GUI NO es "de naturaleza" Unicode.
   Un aplicación completamente Unicode solo puede mostrar un glifo para un punto de código Unicode determinado. Así que no hay confusión posible, este aplicación tendrá que usar una fuente Unicode completa. Si tienes una aplicación totalmente Unicode, debes configurar NLS_LANG a UTF8.
   Tenga en cuenta que actualmente no hay muchas aplicaciones como esta y, si el proveedor no lo indica explícitamente, es muy probable que sea una aplicación ANSI. Así que no configures NLS_LANG como UTF8 si no estás seguro.

   El único cliente compatible con Unicode que está incluido en Oracle Database es iSQL*Plus.

2. 2) Una aplicación ANSI estándar (como sqlplusw.exe) no puede usar puntos de código Unicode. Por lo tanto, el punto de código Unicode almacenado en la base de datos debe CONVERTIRSE a un punto de código ANSI basado en la configuración correcta de NLS_LANG. Esto permite que Oracle asigne el punto de código Unicode al juego de caracteres del cliente. Si el punto de código Unicode no tiene una asignación al conjunto de caracteres del cliente, se utiliza un carácter de sustitución.

Un juego o conjunto de caracteres no es más que un acuerdo sobre el valor numérico de un símbolo. Un ordenador no entiende 'A' o 'B', solo conoce el valor numérico (binario) para ese símbolo, definido en el conjunto de caracteres utilizado por tu sistema operativo (SO) o en el hardware (firmware) para los terminales. Un ordenador solo puede manipular números, por lo que se necesitan conjuntos de caracteres. Algunos ejemplos: 'ASCII', un antiguo conjunto de caracteres de 7 bits; 'ROMAN8' un conjunto de caracteres de 8 bits en UNIX o 'UTF8' un conjunto de caracteres multibyte.

Una página de códigos es el nombre de los esquemas de codificación de Windows/DOS. En Oracle NLS se puede considerar igual a un conjunto de caracteres. También debe distinguir entre una FUENTE y un juego de caracteres/página de códigos. El sistema operativo utiliza una fuente para convertir un valor numérico en una 'impresión' gráfica en pantalla. La fuente Wingdings en Windows es el mejor ejemplo de una fuente en la que una 'A' NO se muestra como una 'A' en la pantalla, pero para el sistema operativo el valor numérico representa una 'A'. Así que no lo vemos como una 'A', pero eso es lo que es para Windows y así es como se almacena (o se usa).

Para entender mejor la explicación anterior, simplemente abre MS Word, elige la fuente Wingdings, escribe tu nombre (verás símbolos) y guarda esto como html, si abres el archivo html con el Bloc de notas verás que en la sección <style> se declaran las fuentes y más abajo en la sección <body> encontrarás tu nombre en texto plano pero con style='font-family: Wingdings'. Si lo abre en Internet Explorer o Netscape, volverá a ver los símbolos de Wingdings. La presentación cambia, pero no los datos.

También es posible que, con una fuente en particular, no vea todos los símbolos definidos en la página de códigos que está utilizando, debido a que el creador de la FUENTE no haya incluido una representación gráfica para todos los símbolos en esa fuente. Es por eso que a veces aparecen cuadrados negros en la pantalla si cambia las fuentes. En Windows puede usar la herramienta 'Mapa de caracteres' para ver todos los símbolos definidos en una fuente.

Dos razones principales:

Históricamente los proveedores han definido diferentes 'conjuntos de caracteres' para su hardware y software, principalmente porque no había estándares oficiales.

Se han definido nuevos conjuntos de caracteres para admitir nuevos idiomas. Con un conjunto de caracteres de 8 bits hay un número limitado de símbolos admitidos; es por eso que hay diferentes conjuntos de caracteres para diferentes idiomas escritos.

Un juego de caracteres de 7 bits solo reconoce 128 símbolos (2^7)

Un juego de caracteres de 8 bits reconoce 256 símbolos (2^8)

Unicode (UTF-8) es un juego de caracteres multibyte. Unicode tiene la capacidad de definir más de un millón de caracteres. Para obtener más información sobre Unicode, consulte el documento técnico Oracle Unicode Database Support (PDF)

Un elemento básico a tener en cuenta para elegir un conjunto de caracteres es asegurarse de que pueda gestionar cualquier lenguaje que necesite soporte inmediatamente y en un futuro indeterminado. Otra consideración que se pasa por alto es pensar qué aplicaciones y tecnologías es posible que desee utilizar con la base de datos o con cuáles desearía que esta interactuase. Use Locale Builder (desde Oracle Database 9i y versiones posteriores) para ver qué caracteres están definidos para un conjunto de caracteres Oracle en particular.

La elección de Unicode como el conjunto de caracteres de la base de datos garantiza una base sólida para todo lo que está integrado en la base de datos y sobre esta. Oracle recomienda usar Unicode para todas las nuevas implementaciones de sistema. También se recomienda migrar los sistemas antiguos a Unicode. Si implementa hoy sus sistemas en Unicode, disfrutará de muchas ventajas en términos de compatibilidad y capacidad de uso y ampliación. El soporte integral de Oracle le permite desplegar sistemas de alto rendimiento de manera más rápida y fácil, a la vez que aprovecha el verdadero potencial de Unicode. Aunque no necesite admitir ahora datos multilingües ni tenga ningún requisito para Unicode, es probable que sea la mejor opción para un nuevo sistema a largo plazo y, en última instancia, le ahorrará tiempo y dinero y le dará ventajas competitivas.