¿Qué conjuntos de caracteres hay en la base de datos de Oracle? ¿Cuáles son las relaciones de subconjunto y superconjunto entre los conjuntos de caracteres?
1. Introducción
El juego de caracteres de la base de datos Oracle, es decir, soporte de globalización ORACLE o soporte de idioma nacional (NLS), se utiliza para almacenar y procesar en idiomas nacionales. y formatos y recuperar datos. Con el apoyo de la globalización, ORACLE proporciona a los usuarios su propio entorno de lenguaje nativo de base de datos familiar, como formato de fecha, formato de número y orden de almacenamiento. Oracle puede admitir múltiples idiomas y conjuntos de caracteres. Oracle8i admite 48 idiomas, 76 países y regiones y 229 conjuntos de caracteres, mientras que Oracle9i admite 57 idiomas, 88 países y regiones y 235 conjuntos de caracteres. Debido a la amplia variedad de conjuntos de caracteres de Oracle, muchos aspectos están estrechamente relacionados con la configuración de los conjuntos de caracteres de Oracle al almacenar, recuperar y migrar datos de Oracle. Por lo tanto, los desarrolladores y administradores de bases de datos a menudo encuentran problemas relacionados con los conjuntos de caracteres de Oracle en cuestiones de aplicaciones prácticas. . Este artículo analiza brevemente el juego de caracteres de Oracle a través de los siguientes aspectos.
2. Conocimientos básicos de los juegos de caracteres
2.1 Juegos de caracteres
Esencialmente, asignan diferentes caracteres a un conjunto específico de símbolos de acuerdo con un determinado esquema de codificación de caracteres. Conjunto de códigos numéricos. El esquema de codificación más antiguo admitido por la base de datos Oracle es US7ASCII.
La denominación del conjunto de caracteres de Oracle sigue las siguientes reglas de nomenclatura:
Es decir: & lt número de dígitos>; & lt código>
Por ejemplo, ZHS16GBK representa el formato de codificación GBK y el juego de caracteres chinos simplificados de 16 bits (dos bytes).
2.2 Esquema de codificación de caracteres
2.2.1 Codificación de un solo byte
(1) Juego de caracteres de un solo byte y 7 bits, que puede definir 128 caracteres. El juego de caracteres más utilizado es US7ASCII.
(2) Juego de caracteres de un solo byte y 8 bits, que puede definir 256 caracteres y es adecuado para la mayoría de los países europeos.
Por ejemplo: WE8ISO8859P1 (Europa occidental, 8 bits, codificación estándar ISO 8859P1)
Codificación multibyte
(1) Longitud variable codificación de bytes
Algunos caracteres están representados por un byte y otros están representados por dos o más caracteres. Las codificaciones multibyte de longitud variable se utilizan comúnmente para admitir idiomas asiáticos como el japonés, el chino y el hindi.
Por ejemplo: AL32UTF8 (AL significa todos, lo que indica que es aplicable a todos los idiomas), zhs 16 cgb 231280280.
(2) Codificación multibyte de longitud fija
Cada carácter utiliza un esquema de codificación de bytes de longitud fija. Actualmente, la única codificación multibyte de longitud fija admitida por Oracle es AF16UTF16, que solo se utiliza en juegos de caracteres nacionales.
Codificación Unicode
Unicode es un esquema de codificación único que cubre todos los caracteres conocidos que se utilizan actualmente en el mundo. Es decir, Unicode proporciona una codificación única para cada carácter. UTF-16 es el método de codificación Unicode de 16 bits y es una codificación multibyte de longitud fija. Dos bytes representan un carácter Unicode y AF16UTF16 es un conjunto de caracteres de codificación UTF-16.
UTF-8 es un método de codificación Unicode de 8 bits y una codificación multibyte de longitud variable. Esta codificación puede utilizar 1, 2 o 3 bytes para representar un carácter Unicode. AL32UTF8, UTF8 y UTFE son conjuntos de caracteres codificados en UTF8.
2.3 Juego de Caracteres Super
Cuando los valores de codificación de un juego de caracteres (Juego de Caracteres A) incluyen todos los valores de codificación de otro juego de caracteres (Juego de Caracteres A) conjunto B) y los dos conjuntos de caracteres. Cuando el mismo valor de codificación representa el mismo carácter, entonces el conjunto de caracteres A es un superconjunto del conjunto de caracteres B, o el conjunto de caracteres B es un subconjunto del conjunto de caracteres A.
Existe en los documentos oficiales de Oracle8i y oracle9i Pares subconjunto-superconjunto. Por ejemplo, WE8ISO8859P1 es un subconjunto de WE8MSWIN1252.
Debido a que US7ASCII es el formato de codificación de base de datos de Oracle más antiguo, muchos conjuntos de caracteres son superconjuntos de US7ASCII, como WE8ISO8859P1, zhs 16 cgb 231280280 y ZHS16GBK.
2.4 Juego de caracteres de la base de datos (juego de caracteres del lado del servidor Oracle)
El juego de caracteres de la base de datos se especifica cuando se crea la base de datos y, por lo general, no se puede cambiar después de la creación. Al crear una base de datos, puede especificar un juego de caracteres y un juego de caracteres nacional.
2.4.1 Juego de caracteres
(1) Se utiliza para almacenar datos de CHAR, VARCHAR2, CLOB, LONG y otros tipos.
(2) Se utiliza para marcar nombres de tablas, nombres de columnas y variables PL/SQL.
(3) Se utiliza para almacenar unidades de programa SQL y PL/SQL, etc.
2.4.2 Conjunto de caracteres nacionales:
(1) Se utiliza para almacenar NCHAR, NVARCHAR2, NCLOB y otros tipos de datos.
(2) El juego de caracteres nacional es esencialmente un juego de caracteres adicional seleccionado para Oracle. Su función principal es mejorar las capacidades de procesamiento de caracteres de Oracle, porque el tipo de datos NCHAR puede admitir el uso de múltiples caracteres de longitud fija. codificación de bytes en Asia, y el juego de caracteres de la base de datos no puede. El juego de caracteres nacional se redefinió en Oracle9i y solo se puede seleccionar entre AF16UTF16 y UTF8 en codificación Unicode. El valor predeterminado es AF16UTF16.
2.4.3 Consultar parámetros del juego de caracteres
Puede consultar el siguiente diccionario de datos o ver la configuración del juego de caracteres.
nls_database_parameters, props$, v$nls_parameters
En los resultados de la consulta, el juego de caracteres NLS representa el juego de caracteres y el juego de caracteres NLS representa el juego de caracteres nacional.
2.4.4 Modificar el juego de caracteres de la base de datos
De acuerdo con lo anterior, el juego de caracteres de la base de datos no se puede cambiar en principio después de su creación. Si necesita modificar el juego de caracteres, generalmente necesita exportar los datos de la base de datos, reconstruir la base de datos y luego importar los datos de la base de datos para la conversión, o modificar el juego de caracteres mediante la instrucción ALTER DATABASE CHARACTER SET. Sin embargo, existen algunas restricciones a la hora de modificar el juego de caracteres después de crear la base de datos. El juego de caracteres de la base de datos sólo se puede modificar si el nuevo juego de caracteres es un superconjunto del juego de caracteres actual. Por ejemplo, UTF8 es un superconjunto de US7ASCII y puede utilizar ALTER DATABASE CHARACTER SET UTF8 para modificar el juego de caracteres de la base de datos.
2.5 Juego de caracteres del cliente (parámetro NLS_Language)
2.5.1 Significado del juego de caracteres del cliente
El juego de caracteres del cliente define el método de codificación de datos de caracteres del cliente. Cualquier dato de caracteres enviado hacia o desde el cliente está codificado por el juego de caracteres definido por el cliente. El cliente puede considerarse como varias aplicaciones que pueden conectarse directamente a la base de datos, como sqlplus, exp/imp, etc. El juego de caracteres del cliente se establece configurando el parámetro NLS_LONG.
2 . 5 . 2 Formato del parámetro NLS _lang
NLS _lang=_.
Idioma: Muestra mensajes de Oracle, cheques, denominación de fechas.
Región: especifique la fecha, el número, la moneda y otros formatos predeterminados.
Juego de caracteres del cliente: Especifique el juego de caracteres que utilizará el cliente.
Por ejemplo: nls_lang=American_America. US7ASCII
Estados Unidos es el idioma, Estados Unidos es la región y US7ASCII es el juego de caracteres del cliente.
2.5.3 Método de configuración del juego de caracteres del cliente
1) Entorno UNIX
$NLS_LANG= "Chino simplificado" _china.zhs16gbk
$Exportar NLS_lang
Editar perfil de usuario de Oracle
2) Entorno Windows
Editar el registro
Regedit.exe -HKEY _ LOCAL _ MACHINE-SOFTWARE-ORACLE-home 0
2.5.4 Consulta de parámetros NLS
Oracle proporciona muchos parámetros NLS para personalizar la base de datos y la computadora del usuario para adaptarse al formato local, como NLS idioma, formato de fecha NLS, calendario NLS, etc. , que se puede ver consultando el diccionario de datos a continuación o v$ view.
NLS Parámetros de la base de datos NLS: muestra los valores de los parámetros NLS actuales de la base de datos, incluido el valor del juego de caracteres de la base de datos.
NLS_NLS_SESSION_PARAMETERS: muestra los valores de los parámetros establecidos por NLS_LONG o modificados por ALTER SESSION (excluyendo el conjunto de caracteres del cliente establecido por NLS_LONG).
NLS_NLS_instance_parameters: muestra los parámetros definidos por el archivo de parámetros init.ora V$NLS_parameters: muestra los valores de los parámetros NLS actuales de la base de datos.
Modificar parámetros NLS
Utilice el siguiente método para modificar los parámetros NLS.
(1) Modifique el archivo de parámetros de inicialización utilizado cuando se inicia la instancia.
(2) Modificar la variable de entorno NLS_lang
(3) Utilice la instrucción ALTER SESSION en la sesión de Oracle para modificarla.
(4) Utilice algunas funciones SQL
Prioridad de NLS: función Sql >Cambiar sesión>Variable de entorno o registro>; Archivo de parámetros>Parámetros predeterminados de la base de datos
Tres. Importación/Exportación y Conversión de Juego de Caracteres
3.1 Importación y Exportación
Exportar e importar son un par de herramientas para leer y escribir datos de Oracle. Export exporta datos de la base de datos Oracle a archivos del sistema operativo e Import lee datos de estos archivos a la base de datos Oracle. Cuando se utiliza exp/imp para la migración de datos, hay cuatro enlaces en el proceso de migración de datos desde la base de datos de origen a la base de datos de destino que involucran juegos de caracteres. Si los juegos de caracteres de estos cuatro enlaces son inconsistentes, se producirá la conversión del juego de caracteres.
Experiencia
____________ _______________ _____________
|Importar archivo|
- - -
Puntuaciones de competiciones internacionales
____________ _______________ _____________
|archivo de importación imp|->|variable de entorno NLS_lang|->|conjunto de caracteres de base de datos|
- - -
Estos cuatro juegos de caracteres son
(1) el juego de caracteres de la base de datos de origen
(2) el juego de caracteres de la sesión del usuario durante 2) exportación (por el conjunto NLS_lang)
(3) Juego de caracteres de la sesión del usuario durante la importación (establecido por NLS_lang)
(4) Juego de caracteres de la base de datos de destino
3.2 Proceso de conversión de exportación
Durante el proceso de exportación, si el juego de caracteres de la base de datos de origen no es coherente con el juego de caracteres de la sesión del usuario exportado, se producirá la conversión del juego de caracteres y el número de ID del juego de caracteres de la sesión del usuario exportado se almacenará en el archivo de exportación. los primeros bytes. Es posible que se pierdan datos durante este proceso de conversión.
Ejemplo: si la base de datos de origen usa ZHS16GBK, el juego de caracteres de la sesión de usuario exportada usa US7ASCII. Dado que ZHS16GBK es un juego de caracteres de 16 bits y US7ASCII es un juego de caracteres de 7 bits, durante este proceso de conversión, el chino. Los caracteres no pueden encontrar caracteres equivalentes en US7ASCII, por lo que todos los caracteres chinos se perderán y se convertirán al formato "", de modo que se generará Dmp después de la conversión.
Por lo tanto, si los datos de la base de datos de origen se van a exportar correctamente, el juego de caracteres de la sesión del usuario durante el proceso de exportación debe ser igual al juego de caracteres de la base de datos de origen o un superconjunto del juego de caracteres de la base de datos de origen.
3.3 Proceso de conversión de importación
(1) Determinar el entorno del juego de caracteres de la base de datos de exportación.
Al leer el encabezado del archivo exportado, puede obtener el juego de caracteres del archivo exportado.
(2) Determine el juego de caracteres de la sesión de importación, es decir, la variable de entorno NLS_Lang utilizada por la sesión de importación.
(3)IMP lee el archivo de exportación
Lee el ID del juego de caracteres del archivo de exportación y lo compara con el NLS_lang del proceso de importación.
(4) Si el juego de caracteres del archivo de exportación es el mismo que el juego de caracteres de la sesión de importación, no se requiere conversión en este paso, si son diferentes, los datos deben convertirse a; el juego de caracteres utilizado en la sesión de importación. Como puede ver, hay dos conversiones de juegos de caracteres durante la importación de datos a la base de datos.
Primera vez: Conversión entre el juego de caracteres del archivo de importación y el juego de caracteres utilizado por la sesión de importación. Si este proceso de conversión no se puede completar correctamente, el proceso de importación a la base de datos de destino no se puede completar.
Segunda vez: importe el juego de caracteres de la sesión y la conversión del juego de caracteres de la base de datos.
Sin embargo, esta conversión de oracle8i solo se puede realizar entre conjuntos de caracteres de un solo byte, y la sesión de importación de oracle8i no admite la conversión entre conjuntos de caracteres de varios bytes. Por lo tanto, para evitar la primera conversión, el NLS_LANG utilizado en la sesión de importación es el mismo que el conjunto de caracteres del archivo de exportación, y la segunda conversión (a través de SQL*Net) admite dos conjuntos de caracteres cualesquiera. La situación anterior es ligeramente diferente en Oracle9i.
Cuatro. El problema de los caracteres confusos
En el proceso de almacenamiento y migración de datos en Oracle, a menudo ocurre el problema de los caracteres confusos, que en última instancia se debe al uso inadecuado de los conjuntos de caracteres. Tomando el proceso de insertar datos en la base de datos e importar/exportar (EXP/IMP) usando el cliente sqlplus como ejemplo, las razones de los caracteres confusos se explican a continuación.
4.1 Utilice el cliente sqlplus para almacenar datos en la base de datos.
Hay tres configuraciones de juego de caracteres para este proceso.
(1) Juego de caracteres de la aplicación cliente
(2) Configuración del parámetro NLS_lang del cliente
(3) Configuración del juego de caracteres de la base de datos del lado del servidor.
El tipo de caracteres que se pueden mostrar en la aplicación cliente sqlplus depende de la configuración regional del sistema operativo del cliente (juego de caracteres de la aplicación cliente), pero si estos caracteres se pueden almacenar normalmente después de ingresarlos en la aplicación. También está estrechamente relacionado con la configuración de los otros dos conjuntos de caracteres en la base de datos. El parámetro NLS_Lang del cliente se utiliza principalmente para determinar la conversión durante la transmisión de datos de caracteres. Hay dos caracteres confusos comunes:
(1) los caracteres chinos se convierten en signos de interrogación "?";
Al convertir del juego de caracteres A al juego de caracteres B, NLS_lang usa caracteres de reemplazo "? " si no hay correspondencia entre los caracteres convertidos. Reemplazar caracteres no asignados
(2) Los caracteres chinos se han convertido en caracteres desconocidos (aunque algunos son caracteres chinos, pero sus significados son diferentes de los caracteres originales)
Existe una correspondencia entre las conversiones relación, pero las codificaciones de caracteres en el juego de caracteres A y el juego de caracteres B representan significados diferentes.
4.2 Razones de los códigos confusos
Los códigos confusos son causados por conversiones no coincidentes entre varios conjuntos de caracteres, que se dividen en las siguientes situaciones:
(Nota: si no hay correspondencia de subconjunto o superconjunto entre conjuntos de caracteres, no se considerará, porque en este caso, la conversión entre conjuntos de caracteres inevitablemente producirá caracteres confusos)
1) La base de datos del lado del servidor. es el mismo que el juego de caracteres de la aplicación cliente, pero diferente de la configuración del parámetro NLS_LONG del cliente.
Si el conjunto de caracteres NLS_Long del cliente es un subconjunto de los otros dos conjuntos de caracteres, el proceso de conversión será confuso.
Solución: establezca los tres conjuntos de caracteres en el mismo conjunto de caracteres, o el conjunto de caracteres NLS_Long es un superconjunto de los otros dos conjuntos de caracteres.
2) El juego de caracteres de la base de datos del lado del servidor es el mismo que la configuración del parámetro NLS_lang del lado del cliente, pero diferente del juego de caracteres de la aplicación del lado del cliente.
Si el juego de caracteres de la aplicación cliente es un superconjunto de los otros dos juegos de caracteres, aparecerán caracteres confusos durante el proceso de conversión. Sin embargo, para el problema de almacenar chino en codificación de un solo byte, consulte. análisis en el Capítulo 5 de este artículo.
3) El juego de caracteres de la aplicación cliente, la configuración del parámetro NLS_lang del cliente y el juego de caracteres de la base de datos del servidor son diferentes entre sí.
Esta situación es más complicada, pero mientras haya caracteres intraducibles entre los tres conjuntos de caracteres, se producirán caracteres confusos.
4.3 Razones de los caracteres confusos durante el proceso de importación/exportación
Hay cuatro configuraciones de juegos de caracteres en este proceso, que se analizaron en el Capítulo 3.1.
(1) Juego de caracteres de la base de datos de origen
(2) Parámetro NLS_lang en el proceso EXP
(3) Parámetro NLS_lang en el proceso IMP
(4) Juego de caracteres de la base de datos de destino
Causa de caracteres confusos
1) Cuando el juego de caracteres de la base de datos de origen no es igual al parámetro NLS_lang en el proceso EXP, y cuando el conjunto de caracteres de la base de datos de origen es un subconjunto de NLS_Lang en el proceso EXP; se puede garantizar que el archivo exportado sea correcto; de lo contrario, el archivo exportado será confuso;
2) El conjunto de caracteres NLS_Lang en el proceso EXP no es igual al conjunto de caracteres NLS_Lang en el proceso IMP. El conjunto de caracteres NLS_Lang en el proceso EXP es hijo del conjunto de caracteres NLS_Lang en el proceso IMP. , para garantizar que la primera conversión sea normal; de lo contrario, aparecerán caracteres confusos en la primera conversión.
3) Si la primera conversión es normal y el juego de caracteres NLS_Long durante IMP es un subconjunto del juego de caracteres de la base de datos de destino o el mismo juego de caracteres de la base de datos de destino, se garantiza que la segunda conversión sea Normal; de lo contrario, aparecerán caracteres confusos durante la segunda conversión.
Verb (abreviatura de verbo) almacena la codificación de un solo byte del chino.
Por razones históricas, los primeros Oracle no tenían conjuntos de caracteres chinos (como oracle6, oracle7, oracle7.1), pero luego algunos usuarios usaron la base de datos para almacenar el chino en el conjunto de caracteres US7ASCII, o algunos los usuarios estaban creando. No pensé claramente en la base de datos y seleccioné aleatoriamente un conjunto de caracteres predeterminado. Por ejemplo, WE8ISO8859P1 o US7ASCII, ninguno de estos dos conjuntos de caracteres tiene codificación de caracteres chinos. Aunque a veces parece que este juego de caracteres se puede utilizar normalmente, en principio es incorrecto utilizar este juego de caracteres para almacenar información de caracteres chinos, lo que traerá una serie de problemas al uso y mantenimiento de la base de datos.
Generalmente, para almacenar caracteres chinos en la base de datos, el juego de caracteres de la base de datos debe admitir chino. No es apropiado configurar el juego de caracteres de la base de datos en un juego de caracteres de un solo byte como US7ASCII. El juego de caracteres US7ASCII solo define 128 símbolos y no admite caracteres chinos. Además, si se puede ingresar chino en SQL*PLUS, entonces el sistema operativo debería admitir chino de forma predeterminada. Sin embargo, si el conjunto de caracteres en NLS_LANG está configurado en US7ASCII, obviamente es incorrecto y no refleja la situación real del cliente. . Pero en aplicaciones prácticas, la visualización de caracteres chinos es correcta. Esto se debe principalmente a que Oracle verifica que la configuración del juego de caracteres de la base de datos y del cliente sea la misma, por lo que los datos no se convertirán durante el proceso de acceso entre el cliente y la base de datos, pero esto en realidad genera inconsistencia entre el juego de caracteres. reconocido por la base de datos y el contenido almacenado real. Durante el proceso SELECT, Oracle también descubrió que los juegos de caracteres de la base de datos y del cliente eran los mismos, por lo que también envió el contenido almacenado al cliente intacto. El sistema operativo del cliente reconoció que era un código de caracteres chinos, por lo que pudo. mostrarse correctamente.
En este ejemplo, la base de datos y el cliente no están configurados con juegos de caracteres chinos, pero el chino se puede mostrar normalmente y no parece haber ningún problema desde el punto de vista de la aplicación. Sin embargo, existen grandes peligros ocultos, como resultados inesperados al aplicar funciones de cadena como longitud o substr.
Para los primeros datos que usaban la base de datos del juego de caracteres US7ASCII para migrar a Oracle8i/9i (usando zhs16gbk), dado que los datos originales se almacenaron en formato US7ASCII, en este caso, puede usar la herramienta de exportación. de oracle8i para exportar Establezca el juego de caracteres en US7ASCII. Después de exportar, utilice UltraEdit y otras herramientas para abrir el archivo dmp. Modifique el segundo y tercer carácter, cambiando 0001 a 0354, para que los datos del juego de caracteres US7ASCII se puedan importar correctamente a la base de datos ZHS16GBK.
Conclusión del verbo intransitivo
Para evitar la pérdida de datos causada por diferentes juegos de caracteres durante el proceso de migración de la base de datos, Oracle proporciona un escáner de juegos de caracteres a través del cual podemos probar el proceso de migración de datos. Posibles problemas causados por la conversión del juego de caracteres y luego determine la mejor solución del juego de caracteres durante la migración de datos según los resultados de la prueba.
Referencia
[1] Bijou Thomas, Bob Breila "Guía de estudio sobre conceptos básicos de Oracle9i DBA I" Electronic Industry Press, 2002