ES 18030

GB 18030 es un estándar del gobierno chino, descrito como Tecnología de la información — Conjunto de caracteres codificados chinos y define el idioma requerido y el soporte de caracteres necesarios para el software en China. GB18030 es el nombre registrado en Internet para el conjunto de caracteres oficial de la República Popular China (RPC) que reemplaza a GB2312. Como formato de transformación Unicode (es decir, una codificación de todos los puntos de código Unicode), GB18030 admite caracteres chinos tradicionales y simplificados. También es compatible con codificaciones heredadas, incluidas GB2312, CP936 y GBK 1.0.

Además de la "codificación de caracteres GB18030", este estándar contiene requisitos sobre qué secuencias de comandos deben ser compatibles, compatibilidad con fuentes, etc.

El estándar actualizado GB18030-2022, es incompatible y tenía fecha de entrada en vigor el 1 de agosto de 2023. Se ha implementado ICU 73.2; y en Java 21, y con versiones anteriores de Java 8, 11, 17 (versiones LTS) y 20.0.2.

A partir de 2022, en términos de implementaciones de fuentes, "solo las fuentes en chino simplificado de Noto Sans CJK (Google), Source Han Mono (Adobe), y las familias tipográficas Source Han Sans (Adobe) ya cumplen con GB 18030-2022 Nivel de implementación 2 [..] Microsoft YaHei (Microsoft), Noto Serif CJK (Google), PingFang (Apple) y Source Han Serif (Adobe), al menos las versiones de noviembre de 2022, requieren una pequeña cantidad de adiciones de URO que están asociadas con el Nivel de implementación 1 para cumplir con GB 18030-2022 Nivel de implementación 2."

Historia

El juego de caracteres GB18030 se denomina formalmente "Estándar nacional chino GB 18030-2005: tecnología de la información: juego de caracteres codificados en chino". GB abrevia Guójiā Biāozhǔn (国家标准), que significa estándar nacional en chino. La norma fue publicada por China Standard Press, Beijing, el 8 de noviembre de 2005. Sólo una parte de la norma es obligatoria. Desde el 1 de mayo de 2006, se exige oficialmente la compatibilidad con el subconjunto obligatorio para todos los productos de software vendidos en la República Popular China.

El 17 de marzo se publicó una versión anterior del estándar, conocida como "Estándar nacional chino GB 18030-2000: tecnología de la información: conjunto de caracteres codificados de ideogramas chinos para el intercambio de información; extensión para el conjunto básico"»., 2000. El esquema de codificación sigue siendo el mismo en la nueva versión, y la única diferencia en la asignación de GB a Unicode es que GB 18030-2000 asignó el carácter A8 BC (ḿ) a un punto de código de uso privado U+E7C7 y carácter 81 35 F4 37 (sin especificar ningún glifo) a U+1E3F (ḿ), mientras que GB 18030 -2005 intercambia estas dos asignaciones cartográficas. Ahora se asocian más puntos de código con caracteres debido a la actualización de Unicode, especialmente la aparición de la Extensión B de Ideógrafos Unificados CJK. Algunos caracteres utilizados por minorías étnicas en China, como los caracteres mongoles y tibetanos (GB 16959-1997 y GB/T 20542 -2006), también se han agregado, lo que explica el cambio de nombre de la norma.

En comparación con sus antecesores, la asignación de GB 18030 a Unicode se ha modificado para los 81 caracteres a los que se les asignó provisionalmente un punto de código de área de uso privado Unicode (U+E000–F8FF) en GBK 1.0 y que posteriormente se codificado en Unicode. Esto se especifica en el Apéndice E de GB 18030. Hay 24 caracteres en GB 18030-2005 que todavía están asignados a PUA Unicode.

En la actualización GB 18030-2022, los requisitos para que los caracteres se asignen a PUA se eliminaron por completo y todos los caracteres deben asignarse a sus puntos de código Unicode estándar. De estas, 18 asignaciones se actualizaron mediante intercambio de posición similar a lo que sucedió entre GBK y GB 18030. Los seis restantes mantuvieron las asignaciones de PUA de dos bytes, por lo que se necesita un cambio en la secuencia de 4 bytes para seguir las asignaciones que no son PUA. preferencia.

Como estándar nacional

La primera versión de GB 18030, denominada GB 18030-2000 Tecnología de la información: conjunto de caracteres codificados chinos para el intercambio de información; extensión para el conjunto básico, consta de codificaciones de 1 y 2 bytes. junto con una codificación de 4 bytes para la extensión A de ideogramas unificados CJK que coincide con los de Unicode 3.0. Los puntos de código Unicode correspondientes de este subconjunto, incluidas las asignaciones privadas provisionales, se encuentran en su totalidad en el BMP. Estas partes son totalmente obligatorias en GB 18030-2000. La mayoría de las principales empresas de informática ya habían estandarizado alguna versión de Unicode como formato principal para su uso en sus formatos binarios y llamadas de sistema operativo. Sin embargo, en su mayoría solo admitían puntos de código en el BMP definido originalmente en Unicode 1.0, que admitía solo 65,536 puntos de código y a menudo estaba codificado en 16 bits como UCS-2. Este estándar es básicamente una extensión basada en GBK con caracteres adicionales en CJK Unified Ideographs Extension A.

La segunda versión denominada GB 18030-2005 Tecnología de la información: juego de caracteres codificados en chino tiene el mismo subconjunto obligatorio que GB 18030-2000 de codificaciones de 1, 2 y 4 bytes. Esta versión también incluye la extensión B completa de ideógrafos unificados de CJK en la sección de codificación de 4 bytes que está fuera del BMP como requisito de soporte de sugerencias. Sin embargo, como se requiere mantener la inclusión de CJK Unified Ideographs Extension B en una región de 4 bytes durante el procesamiento de la información, el software ya no puede salirse con la suya al tratar los caracteres como entidades de ancho fijo de 16 bits (UCS-2). Por lo tanto, deben procesar los datos en un formato de ancho variable (como UTF-8 o UTF-16), que es la opción más común, o pasar a un formato de ancho fijo más grande (es decir, UTF-32). Microsoft realizó el cambio de UCS-2 a UTF-16 con Windows 2000. Esta versión coincide con Unicode 3.1 y también brinda soporte para Hangul (coreano), mongol (incluido manchú, escritura clara, Sibe hergen)., Galik), Tai Nuea, tibetano, uigur/kazajo/kirguís y yi.

La tercera y última versión, GB 18030-2022 Tecnología de la información: conjunto de caracteres codificados en chino, exige la parte de soporte de sugerencias de CJK Unified Ideographs Extension B en GB 18030-2005, junto con actualizaciones hasta Unicode 11.0, incluidos Kangxi Radicals y CJK Unified Ideographs Extension C, D, E y F. GB 18030-2022 también reconoce idiomas adicionales, como parte del árabe, Tai Le, New Tai Lue, Tai Tham, Lisu y Miao. GB 18030-2022 también introduce tres niveles de implementación, con el requisito de que "todos los productos que utilizan este estándar deben implementar el Nivel de implementación 1" eso incluye 66 nuevos caracteres BMP en la región de codificación de 4 bytes que se agregaron entre Unicode 3.1 y Unicode 11.0. El nivel de implementación 2 requiere el soporte de la Tabla de caracteres chinos estándar generales y el nivel de implementación 3 requiere todas las demás regiones especificadas en el estándar.

Mapeo

GB 18030 define una codificación de uno (ASCII), dos (GBK extendido) o cuatro bytes (UTF). Los códigos de dos bytes se definen en una tabla de búsqueda, mientras que los códigos de cuatro bytes se definen secuencialmente (por lo tanto, algorítmicamente) para completar partes que de otro modo no estarían codificadas en UCS. GB 18030 hereda los aspectos negativos de GBK, en particular la necesidad de un código especial para encontrar caracteres ASCII de forma segura en una secuencia GB18030.

Los puntos de código de uno y dos bytes son esencialmente GBK con el signo del euro, asignaciones de PUA para puntos no asignados/definidos por el usuario y puntuaciones verticales. Se puede considerar que el esquema de cuatro bytes consta de dos unidades, cada una de dos bytes. Cada unidad tiene un formato similar a un carácter GBK de dos bytes, pero con un rango de valores para el segundo byte de 0x30 a 0x39 (los códigos ASCII para dígitos decimales). El primer byte tiene el rango de 0x81 a 0xFE, como antes. Esto significa que una rutina de búsqueda de cadenas que sea segura para GBK también debería ser razonablemente segura para GB18030 (de la misma manera que una rutina de búsqueda básica orientada a bytes es razonablemente segura para EUC).

Esto da un total de 1.587.600 (126×10×126×10) posibles secuencias de 4 bytes, lo que es fácilmente suficiente para cubrir los 1.112.064 (17×65536 − 2048 sustitutos) de códigos asignados, reservados y sin caracteres de Unicode. puntos.

Desafortunadamente, para complicar aún más las cosas, no existen reglas simples para traducir entre una secuencia de 4 bytes y su punto de código correspondiente. En cambio, los códigos se asignan secuencialmente (con el primer byte que contiene la parte más significativa y el último la parte menos significativa) solo a puntos de código Unicode que no están asignados de ninguna otra manera. Por ejemplo:

U+00DE (A) → 81 30 89 37
U+00DF (ß) → 81 30 89 38
U+00E0 (à) → A8 A4
U+00E1 (á) → A8 A2
U+00E2 (â) → 81 30 89 39
U+00E3 (ã) → 81 30 8A 30

Se utiliza una tabla de compensación en la versión WHATWG y W3C de GB 18030 para traducir puntos de código de manera eficiente. ICU y glibc utilizan definiciones de rango similares para evitar desperdiciar espacio en grandes bloques secuenciales.

Soporte

Codificación

GB 18030 ha sido compatible con Windows desde el lanzamiento de Windows Vista, como página de códigos 54936. Windows 2000 y XP ofrecen un paquete de soporte GB18030. La base de datos PostgreSQL de código abierto admite GB18030 a través de su soporte total para UTF-8, es decir, convirtiéndolo hacia y desde UTF-8. De manera similar, Microsoft SQL Server admite GB18030 mediante conversión hacia y desde UTF-16.

Más específicamente, admitir la codificación GB18030 en Windows significa que la página de códigos 54936 es compatible con MultiByteToWideChar y WideCharToMultiByte. Debido a la compatibilidad con versiones anteriores de la asignación, muchos archivos en GB18030 se pueden abrir correctamente como la página de códigos heredada 936, es decir, GBK, incluso si la página de códigos 54936 no es compatible. Sin embargo, esto sólo es cierto si el archivo en cuestión contiene sólo caracteres GBK. La carga fallará o provocará resultados corruptos si el archivo contiene caracteres que no existen en GBK (consulte § Detalles técnicos para ver ejemplos).

gconv de GNU glibc, la biblioteca de códecs de caracteres utilizada en la mayoría de las distribuciones de Linux, admite GB 18030-2000 desde 2.2 y GB 18030-2005 desde 2.14; En particular, glibc incluye asignaciones que no son PUA para GB 18030-2005 para lograr una conversión de ida y vuelta. GNU libiconv, una implementación alternativa de iconv que se utiliza con frecuencia en entornos similares a UNIX que no son glibc, como Cygwin, admite GB 18030 desde la versión 1.4.

A partir de 2022, "la compatibilidad con escrituras no chinas sigue siendo opcional" (presumiblemente solo para compatibilidad con visualización/fuentes; y en China, ya que la codificación es UTF completa). Se sabe que el estándar admite inglés/ASCII y GB 18030-2022 reconoce las siguientes escrituras no chinas: árabe, tibetano, mongol, Tai Le, New Tai Lue, Tai Tham, Yi, Lisu, Hangul (Coreano) y Miao."

Glifos

El paquete de soporte GB18030 para Windows contiene SimSun18030.ttc, un archivo de colección de fuentes TrueType que combina dos fuentes chinas, SimSun-18030 y NSimSun-18030. La fuente SimSun 18030 incluye todos los caracteres de Unicode 2.1 más los nuevos caracteres que se encuentran en el bloque Unicode CJK Unified Ideographs Extension A aunque, a pesar de su nombre, no contiene glifos para todos los caracteres codificados por GB 18030, ya que todos (alrededor de un millón) Los puntos de código Unicode hasta U+10FFFF se pueden codificar como GB 18030. La certificación de cumplimiento GB 18030 solo requiere el manejo y reconocimiento correctos de los glifos en la parte china obligatoria (dos bytes y CJK Ext. A). Sin embargo, el requisito de caracteres PUA en el estándar ha obstaculizado esta implementación.

Otras familias de fuentes CJK como HAN NOM y Hanazono Mincho brindan una cobertura más amplia para los bloques de extensión Unicode CJK que SimSun-18030 o incluso SimSun (Founder Extended), pero no admiten todos los puntos de código definidos en Unicode 5.0.0 cualquiera.