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 lenguaje 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 (PRC) 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 GB/T 2312 , CP936 , [b] y GBK 1.0.
El Consorcio Unicode ha advertido a los implementadores que la última versión de este estándar chino, GB 18030-2022 , introduce lo que ellos describen como "cambios disruptivos" con respecto a la versión anterior GB 18030-2005 "que involucran 33 caracteres diferentes y 55 posiciones de código". [2] GB 18030-2022 se aplicó a partir del 1 de agosto de 2023. [3] Se ha implementado en ICU 73.2; y en Java 21, [4] y se ha retroportado a versiones anteriores de Java 8, 11, 17 (versiones LTS) y 20.0.2. [5]
Además del método de codificación, esta norma contiene requisitos sobre qué escrituras e idiomas adicionales deben representarse y a quién se aplica esta norma. [6] Sin embargo, esta norma no define las formas oficiales de los caracteres chinos; esto está estandarizado en la Lista de caracteres chinos estándar de uso común .
El conjunto de caracteres GB18030 se denomina formalmente "Estándar nacional chino GB 18030-2005: Tecnología de la información: conjunto de caracteres codificados en chino". GB es la abreviatura de Guójiā Biāozhǔn (国家标准), que significa estándar nacional en chino. El estándar fue publicado por China Standard Press, Pekín, el 8 de noviembre de 2005. Solo una parte del estándar es obligatoria. [6] Desde el 1 de mayo de 2006, la compatibilidad con el subconjunto obligatorio es oficialmente obligatoria 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 con ideogramas chinos para el intercambio de información—Extensión para el conjunto básico". 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 asignaba 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 asignación. [7] : 534 Ahora se asocian más puntos de código con caracteres debido a la actualización de Unicode , especialmente la aparición de CJK Unified Ideographs Extension B. También se han añadido algunos caracteres utilizados por minorías étnicas en China , como los caracteres mongoles y tibetanos (GB 16959-1997 y GB/T 20542-2006), lo que explica el cambio de nombre del estándar.
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 luego se han codificado en Unicode. [8] Esto se especifica en el Apéndice E de GB 18030. [7] : 534 [9] : 499 Hay 24 caracteres en GB 18030-2005 que todavía están asignados a Unicode PUA. [10]
En la actualización GB 18030-2022, se eliminaron por completo los requisitos para que los caracteres se asignen a PUA y todos los caracteres deben asignarse a sus puntos de código Unicode estándar. De estos, 18 asignaciones se actualizaron mediante intercambio de posiciones, de manera similar a lo que sucedió entre GBK y GB 18030. Los seis restantes mantuvieron las asignaciones PUA de dos bytes, por lo que se necesita un cambio en la secuencia de 4 bytes para seguir la preferencia de no PUA. [11]
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 la extensión A de ideogramas unificados CJK 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 el BMP . Estas partes son completamente obligatorias en GB 18030-2000. [6] : 2 La mayoría de las principales empresas informáticas ya habían estandarizado alguna versión de Unicode como formato principal para su uso en sus formatos binarios y llamadas al sistema operativo. Sin embargo, en su mayoría solo habían admitido 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 se codificaba 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: conjunto de caracteres codificados chinos, tiene el mismo subconjunto obligatorio que GB 18030-2000 de codificaciones de 1, 2 y 4 bytes. [7] : 3 Esta versión también incluye la extensión B de ideogramas unificados CJK completa en la sección de codificación de 4 bytes que está fuera del BMP [10] como un requisito de soporte de sugerencias. [14] Sin embargo, como se requiere mantener la inclusión de la extensión B de ideogramas unificados CJK en una región de 4 bytes durante el procesamiento de la información, el software ya no puede salirse con la suya tratando los caracteres como entidades de ancho fijo de 16 bits ( UCS-2 ). Por lo tanto, deben procesar los datos como un formato de ancho variable (como con 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 proporcionó soporte para Hangul ( coreano ), mongol (incluyendo manchú , script claro , 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 chinos , exige la parte de soporte de sugerencias de la extensión B de los ideogramas unificados del CJK en GB 18030-2005, junto con actualizaciones hasta Unicode 11.0, incluidos los radicales Kangxi y los ideogramas unificados del CJK URO , extensiones C, D, E y F. GB 18030-2022 también reconoce idiomas adicionales, como parte del árabe , el tai le , el nuevo tai lue , el tai tham , el lisu y el miao . GB 18030-2022 también introduce tres niveles de implementación, con el requisito de que "todos los productos que utilicen 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 Lista de caracteres chinos estándar comúnmente utilizados , y el nivel de implementación 3 requiere todas las demás regiones especificadas en el estándar. [11]
Desde finales de 2022 hasta 2023, se pondrán a disposición del público borradores de una nueva enmienda a GB 18030-2022 para consulta pública. El borrador actual actualiza hasta Unicode 15.1 los caracteres de descripción ideográfica , ideogramas unificados CJK URO, extensiones A, B, C, G, H e I. [15] [16] [17] Originalmente, a finales de 2022, habría colocado 897 nuevos caracteres sinográficos en el plano 10 ( hexadecimal : 0A), un plano Unicode astral aún sin título , para la certificación del nombre real de los ciudadanos en China, pero finalmente el repertorio (reducido a 622 caracteres después de la revisión de expertos) se incorporó rápidamente a Unicode 15.1 en septiembre de 2023, como el bloque de extensión I de ideogramas unificados CJK . [18] Después de esto, el borrador de la enmienda se modificó para utilizar los puntos de código de la extensión I. [17]
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 (es decir, algorítmicamente) para llenar partes no codificadas en UCS . GB 18030 hereda los aspectos negativos de GBK , en particular la necesidad de un código especial para encontrar de forma segura caracteres ASCII en una secuencia GB18030.
Los puntos de código de uno y dos bytes son esencialmente GBK con el símbolo del euro, asignaciones PUA para puntos no asignados/definidos por el usuario y puntuaciones verticales. Se puede pensar 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 de dos bytes GBK, pero con un rango de valores para el segundo byte de 0x30–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 [ aclaración necesaria ] 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) puntos de código asignados, reservados y no característicos de Unicode .
Lamentablemente, 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 (el primer byte contiene la parte más significativa y el último la parte menos significativa) solo a los puntos de código Unicode que no se asignan 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
En la versión WHATWG y W3C de GB 18030 se utiliza una tabla de desplazamiento para traducir de manera eficiente los puntos de código. [20] ICU [19] y glibc utilizan definiciones de rango similares para evitar desperdiciar espacio en bloques secuenciales grandes.
GB 18030 ha sido compatible con Windows desde el lanzamiento de Windows 95 , como página de códigos 54936. [21] Windows 2000 y XP ofrecen un paquete de soporte GB18030. [22] La base de datos PostgreSQL de código abierto admite GB18030 a través de su compatibilidad total con UTF-8, es decir, convirtiéndolo a y desde UTF-8. De manera similar, Microsoft SQL Server admite GB18030 mediante la conversión a y desde UTF-16.
Más específicamente, la compatibilidad con 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 936 heredada, es decir, GBK, incluso si la página de códigos 54936 no es compatible. Sin embargo, esto solo es así si el archivo en cuestión contiene solo caracteres GBK. La carga fallará o causará un resultado corrupto si el archivo contiene caracteres que no existen en GBK (consulte § Detalles técnicos para ver ejemplos).
La biblioteca de códecs de caracteres gconv de GNU glibc utilizada en la mayoría de las distribuciones Linux es compatible con GB 18030-2000 desde la versión 2.2, [23] y con GB 18030-2005 desde la versión 2.14; [24] glibc incluye notablemente asignaciones no PUA para GB 18030-2005 para lograr una conversión de ida y vuelta. [25] GNU libiconv , una implementación alternativa de iconv utilizada frecuentemente en entornos UNIX no glibc como Cygwin , es compatible con GB 18030 desde la versión 1.4. [26]
A partir de 2022, "la compatibilidad con escrituras distintas del chino sigue siendo opcional" [27] (presumiblemente solo para compatibilidad con pantallas y fuentes; y en China, ya que la codificación es UTF completa). Se sabe que el estándar admite inglés/ASCII y que "las siguientes escrituras distintas del chino son reconocidas por GB 18030-2022: árabe, tibetano, mongol, tai le, nuevo tai lue, tai tham, yi, lisu, hangul (coreano) y miao". [27]
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 [ aclaración necesaria ] en Unicode 2.1 más los caracteres nuevos encontrados 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 los puntos de código Unicode (alrededor de un millón) hasta U+10FFFF pueden codificarse como GB 18030. La certificación de conformidad con GB 18030 solo requiere el manejo y reconocimiento correctos de los glifos en la parte china obligatoria (dos bytes y CJK Ext. A). [6] : 4 Sin embargo, el requisito de caracteres PUA en el estándar ha obstaculizado esta implementación. [28]
Microsoft YaHei y DengXian proporcionados por Microsoft se actualizan en 2023 para que coincidan con el nivel de implementación 2 de GB 18030-2022, y SimSun se actualiza para que coincida con el nivel de implementación 3. [29]
Source Han Sans (y su contraparte Noto Sans CJK) ya cumplen con el nivel de implementación 2 de GB 18030-2022 cuando se anuncie la actualización estándar para GB 18030 a partir de noviembre de 2022. [actualizar]Sin embargo, Source Han Serif (y su contraparte Noto Serif CJK) no cumple en este momento, y se proporciona una actualización para garantizar que la fuente cumpla con el nivel de implementación 2. De manera similar, Microsoft YaHei y PingFang (Apple) requieren una pequeña cantidad de adiciones de URO que están asociadas con el nivel de implementación 1 para cumplir con el nivel de implementación 2 de GB 18030-2022. [27]
Otras familias de fuentes CJK como HAN NOM [30] y Hanazono Mincho [31] proporcionan una cobertura más amplia para los bloques de extensión CJK Unicode que SimSun-18030 o incluso SimSun (Founder Extended), pero no admiten todos los puntos de código definidos en GB 18030.
84 31 A4 39en la página 239 del estándar de 2005, aunque el estándar especifica lo necesario 84 39 FE 39para el mapeo BMP.Página 4
处理GB 18030-2005强制部分规定的全部汉字字符；②产品可以正确识别GB 18030-2005强制性部分规定的全部汉字字符对应的编码。 [Un producto que cumpla con la parte obligatoria de GB 18030 debe poder a) ingresar, generar y procesar correctamente 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 a) ingresar, generar y procesar correctamente 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 inviable, principalmente porque son tipos de letra Pan-CJK y el uso de PUA es extremadamente peligroso en tales contextos. [...] Uno de mis amigos de CESI compartió conmigo el texto del borrador final hace unos días. Esto confirmó que se eliminará el requisito de PUA para los 24 caracteres.