GB 18030 es un estándar del gobierno chino , descrito como Tecnología de la información: conjunto de caracteres codificados en chino y define el idioma y el soporte de caracteres necesarios para el software en China . GB18030 es el nombre registrado en Internet para el juego de caracteres oficial de la República Popular China (RPC) que reemplaza a GB2312 . [1] Como formato de transformación Unicode [a] (es decir, una codificación de todos los puntos de código Unicode ), GB18030 admite caracteres chinos simplificados y tradicionales . También es compatible con codificaciones heredadas, incluidas GB2312, CP936 , [b] y GBK 1.0.
Además de la "codificación de caracteres GB18030", este estándar contiene requisitos sobre qué scripts deben ser compatibles, compatibilidad con fuentes, etc. [2]
El estándar actualizado GB18030-2022 , es incompatible, [3] y tenía fecha de entrada en vigor el 1 de agosto de 2023. [4] Se ha implementado ICU 73.2; y en Java 21, [5] y con versiones anteriores de Java 8, 11, 17 (versiones LTS) y 20.0.2. [6]
A partir de 2022, en términos de implementaciones de fuentes, "solo las fuentes chinas simplificadas de las familias tipográficas Noto Sans CJK (Google), Source Han Mono (Adobe) y Source Han Sans (Adobe) ya cumplen con la implementación de GB 18030-2022. Nivel 2 [..] Microsoft YaHei (Microsoft), Noto Serif CJK (Google), PingFang (Apple) y Source Han Serif (Adobe), al menos las versiones a partir de noviembre de 2022 [actualizar], requieren una pequeña cantidad de adiciones de URO que son asociado con el Nivel de implementación 1 para cumplir con el Nivel de implementación 2 de GB 18030-2022 ". [7]
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. [2] Desde el 1 de mayo de 2006, el soporte para el subconjunto obligatorio es oficialmente obligatorio para todos los productos de software vendidos en la República Popular China.
El 17 de marzo de 2000 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". Lo mismo en la nueva versión, y la única diferencia en el mapeo 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 el carácter 81 35 F4 37(sin especificar ningún glifo) a U+. 1E3F (ḿ), mientras que GB 18030-2005 intercambia estas dos asignaciones de mapeo. [8] : 534 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 ideogramas 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 del estándar.
En comparación con sus antepasados, 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 luego se codificaron en Unicode. [9] Esto se especifica en el Apéndice E de GB 18030. [8] : 534 [10] : 499 Hay 24 caracteres en GB 18030-2005 que todavía están asignados a Unicode PUA. [11]
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. [12]
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 byte y 2 bytes, junto con una codificación de 4 bytes para ideogramas unificados CJK. Extensión A que coincide con las de Unicode 3.0. Los puntos de código Unicode correspondientes de este subconjunto, incluidas las asignaciones privadas provisionales, se encuentran completamente en BMP . Estas partes son totalmente obligatorias en GB 18030-2000. [2] : 2 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: el juego de caracteres codificados en chino tiene el mismo subconjunto obligatorio que GB 18030-2000 de codificaciones de 1, 2 y 4 bytes. [8] : 3 Esta versión también incluye la extensión B completa de ideogramas unificados CJK en la sección de codificación de 4 bytes que está fuera del BMP [11] como requisito de soporte de sugerencias. [15] 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 brindó 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 la extensión B de CJK Unified Ideographs 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", que 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. [12]
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 [ se necesita aclaración ] 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 Unicode puntos de código asignados, reservados y sin caracteres.
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. [h] Por ejemplo:
U+00DE (Þ) → 81 30 89 37U+00DF (ß) → 81 30 89 38U+00E0 (à) → A8 A4U+00E1 (á) → A8 A2U+00E2 (â) → 81 30 89 39U+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. [17] ICU [16] y glibc utilizan definiciones de rango similares para evitar desperdiciar espacio en grandes bloques secuenciales.
GB 18030 ha sido compatible con Windows desde el lanzamiento de Windows Vista , como página de códigos 54936. [18] Windows 2000 y XP ofrecen un paquete de soporte GB18030. [19] 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 MultiByteToWideChary 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, [20] y GB 18030-2005 desde 2.14; [21] glibc incluye en particular asignaciones que no son PUA para GB 18030-2005 con el fin de lograr una conversión de ida y vuelta. [22] GNU libiconv , una implementación alternativa de iconv utilizada frecuentemente en entornos tipo UNIX que no son glibc como Cygwin , soporta GB 18030 desde la versión 1.4. [23]
A partir de 2022, "la compatibilidad con escrituras no chinas sigue siendo opcional" [7] (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 es compatible con 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." [7]
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 [ se necesita aclaración ] en 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, como 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 correcto de los glifos en la parte china obligatoria (dos bytes y CJK Ext. A). [2] : 4 Sin embargo, el requisito de caracteres PUA en el estándar ha obstaculizado esta implementación. [24]
Otras familias de fuentes CJK como HAN NOM [25] y Hanazono Mincho [26] brindan una cobertura más amplia para los bloques Unicode CJK Extension que SimSun-18030 o incluso SimSun (Founder Extended), pero no admiten todos los puntos de código definidos en Unicode 5.0. 0 tampoco.
84 31 A4 39en la página 239 del estándar de 2005, aunque el estándar da lo mismo 84 39 FE 39para el mapeo BMP.Página 4
: GB 18030-2005理GB 18030-2005强制部分规定的全部汉字字符；②产品可以正确识别GB 18030 -2005强制性部分规定的全部汉字字符对应的编码。 [Un producto que cumpla con la parte obligatoria de GB 18030 debe poder correctamente a) ingresar, generar y procesar todos los caracteres chinos definidos en el conjunto obligatorio;
b) reconocer codificaciones de caracteres en el conjunto obligatorio.]
URL alternativa
{{cite book}}: |work=ignorado ( ayuda )Página 4
理GB 18030-2005强制部分规定的全部汉字字符；②产品可以正确识别GB 18030 -2005强制性部分规定的全部汉字字符对应的编码。 [Un producto que cumpla con la parte obligatoria de GB 18030 debe poder correctamente a) ingresar, generar y procesar todos los caracteres chinos definidos en el conjunto obligatorio;
b) reconocer codificaciones de caracteres en el conjunto obligatorio.]
Además, admitir puntos de código PUA en el contexto de las fuentes Noto CJK y Source Han es totalmente imposible, principalmente porque son tipos de letra Pan-CJK, y el uso de PUA es extremadamente peligroso en tales contextos.[...] Uno de Mis amigos del CESI compartieron conmigo el texto del borrador final hace unos días.
Esto confirmó que se está eliminando el requisito de PUA para los 24 caracteres.