stringtranslate.com

Código Unix extendido

El Código Unix Extendido ( EUC ) es un sistema de codificación de caracteres multibyte utilizado principalmente para caracteres japoneses , coreanos y chinos simplificados .

Los códigos EUC más utilizados son codificaciones de longitud variable en las que un carácter perteneciente a un conjunto de caracteres codificados conforme a la norma ISO/IEC 646 (como ASCII ) ocupa un byte, y un carácter perteneciente a un conjunto de caracteres codificados de 94×94 (como GB 2312 ) se representa en dos bytes. La forma EUC-CN de GB 2312 y EUC-KR son ejemplos de dichos códigos EUC de dos bytes. EUC-JP incluye caracteres representados por hasta tres bytes, incluido un código de desplazamiento inicial , mientras que un solo carácter en EUC-TW puede ocupar hasta cuatro bytes.

Es más probable que las aplicaciones modernas utilicen UTF-8 , que admite todos los glifos de los códigos EUC y más, y generalmente es más portátil y presenta menos desviaciones y errores de los proveedores. Sin embargo, el EUC sigue siendo muy popular, especialmente el EUC-KR para Corea del Sur.

Estructura de codificación

Relación entre el EUC empaquetado y otros perfiles ISO 2022 de 8 bits

La estructura de EUC se basa en el estándar ISO/IEC 2022 , que especifica un sistema de conjuntos de caracteres gráficos que se pueden representar con una secuencia de 94 bytes de 7 bits 0x 21–7E, o alternativamente 0xA1–FE si hay un octavo bit disponible. Esto permite conjuntos de 94 caracteres gráficos, u 8836 (94 2 ) caracteres, u 830584 (94 3 ) caracteres. Aunque inicialmente 0x20 y 0x7F siempre fueron el espacio y el carácter de eliminación y 0xA0 y 0xFF no se usaron, ediciones posteriores de ISO/IEC 2022 permitieron el uso de los bytes 0xA0 y 0xFF (o 0x20 y 0x7F) dentro de conjuntos bajo ciertas circunstancias, lo que permitió la inclusión de conjuntos de 96 caracteres. Los rangos 0x00–1F y 0x80–9F se utilizan para los códigos de control C0 y C1 .

EUC es una familia de perfiles de 8 bits de ISO/IEC 2022 , a diferencia de los perfiles de 7 bits como ISO-2022-JP . Como tal, solo los conjuntos de caracteres compatibles con ISO 2022 pueden tener formas EUC. Se pueden representar hasta cuatro conjuntos de caracteres codificados (denominados G0, G1, G2 y G3 o conjuntos de códigos 0, 1, 2 y 3) con el esquema EUC. El conjunto G0 se establece en un conjunto de caracteres codificados compatible con ISO/IEC 646 como ASCII , ISO 646:KR ( KS X 1003 ) o ISO 646:JP (la mitad inferior de JIS X 0201 ) y se invoca sobre GL (es decir, 0x21–0x7E, con el bit más significativo borrado). [1] Si se utiliza ASCII, esto hace que el código sea una codificación ASCII extendida ; La desviación más común de ASCII es que 0x5C ( barra invertida en ASCII) se usa a menudo para representar un signo de yen en EUC-JP (ver más abajo) y un signo de won en EUC-KR.

Los demás conjuntos de códigos se invocan sobre GR (es decir, con el bit más significativo establecido). Por lo tanto, para obtener la forma EUC de un carácter, se establece el bit más significativo de cada byte de codificación (equivalente a sumar 128 a cada byte de codificación de 7 bits, o sumar 160 a cada número en el código kuten ); esto permite que el software distinga fácilmente si un byte particular en una cadena de caracteres pertenece al código ISO 646 o al código extendido. Los caracteres en los conjuntos de códigos 2 y 3 tienen como prefijo los códigos de control SS2 (0x8E) y SS3 (0x8F) respectivamente, y se invocan sobre GR. Además del código de desplazamiento inicial, cualquier byte fuera del rango 0xA0–0xFF que aparezca en un carácter de los conjuntos de códigos 1 a 3 no es un código EUC válido. [1]

El código EUC en sí no hace uso de las secuencias de anuncios y designaciones de la norma ISO 2022. [1] Sin embargo, la especificación del código es equivalente a la siguiente secuencia de cuatro secuencias de anuncios de la norma ISO 2022 , con significados que se desglosan de la siguiente manera. [1]

Formato de longitud fija

Diseño del formato de longitud fija para japonés

La codificación de longitud variable basada en ISO-2022 descrita anteriormente se conoce a veces como formato empaquetado EUC , que es el formato de codificación que normalmente se etiqueta como EUC. Sin embargo, el procesamiento interno de datos EUC puede hacer uso de un formato de transformación de longitud fija llamado formato completo de dos bytes EUC . Esto representa: [2]

Los bytes iniciales 0x00 y 0x80 se utilizan en los casos en que el conjunto de códigos utiliza solo un byte. También existe un formato de longitud fija de cuatro bytes. [2] Estos formatos de codificación de longitud fija son adecuados para el procesamiento interno y no suelen encontrarse en el intercambio.

EUC-JP está registrado en la IANA en ambos formatos, el formato empaquetado como "EUC-JP" o "csEUCPkdFmtJapanese" y el formato de ancho fijo como "csEUCFixWidJapanese". [3] Solo el formato empaquetado está incluido en el estándar de codificación WHATWG utilizado por HTML5 . [4]

EUC-CN

EUC-CN [6] es la forma codificada habitual del estándar GB 2312 para caracteres chinos simplificados . A diferencia del caso de los códigos JIS X 0208 e ISO-2022-JP japoneses , GB 2312 no se utiliza normalmente en una versión de código ISO 2022 de 7 bits , [a] aunque a veces se utilizaba en USENET una forma variante denominada HZ (que delimita el texto de GB 2312 con secuencias ASCII) .

Un carácter ASCII se representa en su codificación habitual. Un carácter de GB 2312 se representa mediante dos bytes, ambos del rango 0xA1–0xFE.

Código 748

Una codificación relacionada con EUC-CN es el código "748" utilizado en el sistema de composición tipográfica WITS desarrollado por Founder Technology de Beijing (ahora obsoleto por su sistema de composición tipográfica más nuevo, FITS). El código 748 contiene todo GB 2312 , pero no es compatible con ISO 2022 y, por lo tanto, no es un verdadero código EUC. (Utiliza un byte inicial de 8 bits, pero distingue entre un segundo byte con su bit más significativo establecido y uno con su bit más significativo borrado y, por lo tanto, es más similar en estructura a Big5 y otros sistemas de codificación DBCS no compatibles con ISO 2022 ). La parte no GB2312 del código 748 contiene caracteres tradicionales y de Hong Kong y otros glifos utilizados en la composición tipográfica de periódicos.

Páginas de códigos IBM 1380, 1381, 1382 y 1383

La página de códigos IBM 1381 ( CCSID 1381) comprende la página de códigos de un solo byte 1115 (CPGID 1115 como CCSID 1115) y la página de códigos de doble byte 1380 (CPGID 1380 como CCSID 1380), [7] que codifica GB 2312 de la misma manera que EUC-CN, pero se desvía de la estructura EUC al extender el rango de bytes iniciales hasta 0x8C, agregar 31 caracteres seleccionados por IBM en 0x8CE0 a 0x8CFE y agregar 1880 caracteres definidos por el usuario con los bytes iniciales 0x8D a 0xA0. [8]

La página de códigos IBM 1383 (CCSID 1383) comprende la página de códigos de un solo byte 367 y la página de códigos de doble byte 1382 (CPGID 1382 como CCSID 1382), [9] que difiere en que se ajusta a la estructura EUC, añadiendo los 31 caracteres seleccionados por IBM en 0xFEE0 a 0xFEFE en su lugar, e incluyendo solo 1360 caracteres definidos por el usuario, intercalados en las posiciones no utilizadas por GB 2312. [10] El CCSID alternativo 5479 [11] se utiliza para la página de códigos EUC-CN pura: utiliza CCSID 9574 como su conjunto de doble byte, que utiliza CPGID 1382 pero excluye los caracteres seleccionados por IBM y definidos por el usuario. [12]

GBK y GB 18030

GBK es una extensión de GB 2312. Define una forma extendida de la codificación EUC-CN capaz de representar una matriz más grande de caracteres CJK provenientes en gran parte de Unicode 1.1 , incluidos caracteres chinos tradicionales y caracteres usados ​​solo en japonés . Sin embargo, no es un código EUC verdadero, porque los bytes ASCII pueden aparecer como bytes finales (y los bytes C1 , sin limitarse a los desplazamientos simples, pueden aparecer como bytes iniciales o finales), debido a que se requiere un espacio de codificación más grande.

Las variantes de GBK se implementan mediante la página de códigos 936 de Windows (la página de códigos de Microsoft Windows para chino simplificado) y mediante la página de códigos 1386 de IBM.

La codificación de caracteres GB 18030 basada en Unicode define una extensión de GBK capaz de codificar la totalidad de Unicode . Sin embargo, Unicode codificado como GB 18030 es una codificación de longitud variable que puede utilizar hasta cuatro bytes por carácter, debido a que se requiere un espacio de codificación aún mayor. Al ser una extensión de GBK, es un superconjunto de EUC-CN, pero no es en sí mismo un verdadero código EUC. Al ser una codificación Unicode, su repertorio es idéntico al de otros formatos de transformación Unicode como UTF-8 .

Mac OS chino simplificado

Otras variantes de EUC-CN que se desvían del mecanismo EUC incluyen el script chino simplificado de Mac OSx-mac-chinesesimp (conocido como Página de códigos 10008 o ). [13] Utiliza los bytes 0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE y 0xFF para la U con diéresis (ü), dos caracteres métricos de fuente especiales, el espacio indivisible , el signo de copyright (©), el signo de marca registrada (™) y los puntos suspensivos (...) respectivamente. [6] Esto difiere en lo que se considera un carácter de un solo byte frente al primer byte de un carácter de dos bytes tanto de EUC (donde, de estos, 0xFD y 0xFE se definen como bytes iniciales) como de GBK (donde, de estos, 0x81, 0x82, 0xFD y 0xFE se definen como bytes iniciales).

Este uso de 0xA0, 0xFD, 0xFE y 0xFF coincide con la variante Shift_JIS de Apple .

Además de estos cambios en el rango de bytes iniciales, la otra característica distintiva de la parte de doble byte del sistema operativo chino simplificado de Mac OS es la inclusión de dos extensiones al conjunto básico GB 2312-80 en las filas 6 y 8. [6] Estas se consideran "extensiones estándar de GB 2312", ninguna de las cuales es propiedad de Apple: la extensión de la fila 8 se tomó de GB 6345.1 , [6] ambas extensiones están incluidas en GB/T 12345 (la variante china tradicional de GB 2312), [14] y ambas extensiones están incluidas en GB 18030 (el sucesor de GB 2312). [15]

EUC-JP

EUC-JP es una codificación de longitud variable que se utiliza para representar los elementos de tres estándares de conjuntos de caracteres japoneses , a saber, JIS X 0208 , JIS X 0212 y JIS X 0201. Otros nombres para esta codificación incluyen Unixized JIS (o UJIS ) y AT&T JIS . [2] El 0,1% de todas las páginas web utilizan EUC-JP desde septiembre de 2022, [16] mientras que el 2,6% de los sitios web escritos en japonés utilizan esta segunda codificación más popular (para japonés) [17] (que es más que para Shift JIS, ambos son mucho menos utilizados que UTF-8 ). IBM lo llama página de códigos 954. [18] [19] Microsoft tiene dos números de página de códigos para esta codificación (51932 y 20932).

Este esquema de codificación permite la fácil mezcla de ASCII de 7 bits y japonés de 8 bits sin la necesidad de los caracteres de escape empleados por ISO-2022-JP , que se basa en los mismos estándares de conjuntos de caracteres, y sin que los bytes ASCII aparezcan como bytes finales (a diferencia de Shift JIS ).

Una codificación relacionada y parcialmente compatible, denominada EUC-JISx0213 o EUC-JIS-2004 , codifica JIS X 0201 y JIS X 0213 [20] (de manera similar a Shift_JISx0213 , su contraparte basada en Shift_JIS).

En comparación con EUC-CN o EUC-KR, EUC-JP no se adoptó tan ampliamente en los sistemas PC y Macintosh en Japón, que usaban Shift JIS o sus extensiones ( página de códigos de Windows 932 en Microsoft Windows y MacJapanese en Mac OS clásico ), aunque se usó ampliamente en sistemas operativos Unix o similares (excepto HP-UX ). Por lo tanto, si los sitios web japoneses usan EUC-JP o Shift_JIS a menudo depende del sistema operativo que use el autor.

Los caracteres se codifican de la siguiente manera:

Las extensiones de proveedores de EUC-JP (de, por ejemplo, Open Software Foundation , IBM o NEC ) a menudo se asignaban dentro de los conjuntos de códigos individuales, [25] [26] en lugar de utilizar secuencias EUC no válidas (como en las extensiones populares de EUC-CN y EUC-KR).

Sin embargo, algunas codificaciones específicas de proveedores son parcialmente compatibles con EUC-JP, debido a que codifican JIS X 0208 sobre GR, pero no siguen la estructura compacta de EUC. A menudo, no incluyen el uso de los cambios simples de EUC-JP y, por lo tanto, no son extensiones directas de EUC-JP, con la excepción de Super DEC Kanji.

DEC Kanji

Digital Equipment Corporation define dos variantes de EUC-JP que se ajustan sólo parcialmente al formato empaquetado EUC, pero que también tienen cierta similitud con el formato completo de dos bytes. El formato general de la codificación "DEC Kanji" corresponde en su mayor parte al EUC de longitud fija (dos bytes completos); sin embargo, no es necesario rellenar el conjunto de códigos 0 con bytes nulos por la izquierda (de manera similar al formato empaquetado). [28] Como es habitual, se utiliza JIS X 0208 para el conjunto de códigos 1; el conjunto de códigos 2 (katakana de ancho medio) está ausente; El conjunto de códigos 3 está codificado como el formato de ancho fijo de dos bytes (es decir, sin un byte de desplazamiento y con solo el primer bit alto establecido), pero se utiliza para caracteres definidos por el usuario de dos bytes en lugar de estar especificado para JIS X 0212. [28] En la codificación básica "DEC Kanji", solo las primeras 31 filas del conjunto de códigos 3 se utilizan para caracteres definidos por el usuario: las filas 32 a 94 están reservadas, de manera similar a las filas no utilizadas en el conjunto de códigos 1. [29]

La codificación "Super DEC Kanji" acepta códigos tanto de la codificación "DEC Kanji" como de la codificación EUC en formato empaquetado, para un total de cinco conjuntos de códigos. [28] También permite que todo el conjunto de códigos definidos por el usuario y las filas no utilizadas en los extremos de los conjuntos de códigos JIS X 0208 y JIS X 0212 (filas 85-94 y 78-94 respectivamente) se utilicen para caracteres definidos por el usuario. [29]

HP-16

Hewlett-Packard define una codificación denominada "HP-16". Esta codificación acompaña a su codificación "HP-15", que es una variante de Shift JIS . HP-16 codifica JIS X 0208 utilizando los mismos bytes que en EUC-JP, pero no utiliza los códigos de desplazamiento simple (omitiendo así los conjuntos de códigos 2 y 3), y añade tres regiones definidas por el usuario que no siguen la estructura EUC de formato empaquetado: [28]

IKIS

La codificación IKIS (Sistema de Información Kanji Interactivo) utilizada por Data General se parece a la EUC-JP sin desplazamientos simples, es decir, con solo los conjuntos de códigos 0 y 1. En cambio, los katakana de ancho medio se incluyen en la fila 8 de JIS X 0208 (en conflicto con los caracteres de dibujo de caja agregados al estándar en 1983). Las filas 9 a 12 de JIS X 0208 se utilizan para caracteres definidos por el usuario. [28] [29]

Adaptaciones de EUC-JP para EBCDIC

KEIS (Kanji-processing Extended Information System) es una codificación EBCDIC utilizada por Hitachi [29] , con caracteres de doble byte (una codificación DBCS-Host) incluidos mediante secuencias de desplazamiento, lo que la convierte en una codificación con estado . Específicamente, la secuencia 0x0A 0x41cambia al modo de un solo byte y la secuencia 0x0A 0x42cambia al modo de doble byte. [b] Sin embargo, los caracteres JIS X 0208 se codifican utilizando las mismas secuencias de bytes utilizadas para codificarlos en EUC-JP. Esto da como resultado codificaciones duplicadas para el espacio ideográfico : 0x4040 según la estructura de código DBCS-Host y 0xA1A1 como en EUC-JP. Esto difiere de la codificación DBCS-Host de IBM para japonés, cuyo diseño se basa en versiones que son anteriores a JIS X 0208 por completo. El rango de bytes iniciales se extiende hasta 0x59, de los cuales los bytes iniciales 0x81–A0 están designados para caracteres definidos por el usuario, [28] y el resto se utilizan para caracteres definidos por la empresa, incluidos kanji y no kanji. [29]

JEF (Japanese-processing Extended Feature) [29] es una codificación EBCDIC utilizada en mainframes Fujitsu FACOM, en contraste con FMR (una variante de Shift JIS) utilizada en PC Fujitsu. Al igual que KEIS, JEF es una codificación con estado, que cambia a un modo DBCS-Host de doble byte mediante secuencias de cambio (donde 0x29cambia al modo de un solo byte y 0x28cambia al modo de doble byte). [30] También de manera similar a KEIS, los códigos JIS X 0208 se representan de la misma manera que en EUC-JP. [28] El rango de bytes iniciales se extiende de nuevo a 0x41, con 0x80–0xA0 designado para la definición del usuario; a los bytes iniciales 0x41–0x7F se les asignan los números de fila 101 a 163 para fines de kuten , aunque la fila 162 (byte inicial 0x7E) no se utiliza. [28] [29] Las filas 101 a 148 se utilizan para kanji extendidos, mientras que las filas 149 a 163 se utilizan para no kanji extendidos. [29]

EUC-KR

EUC-KR es una codificación de longitud variable para representar texto coreano utilizando dos conjuntos de caracteres codificados, KS X 1001 (anteriormente KS C 5601) [31] [32] y ISO 646 :KR ( KS X 1003 , anteriormente KS C 5636 ) o ASCII , según la variante. KS X 2901 (anteriormente KS C 5861 ) estipula la codificación y RFC  1557 la denominó EUC-KR.

Un carácter extraído de KS X 1001 (G1, conjunto de códigos 1) se codifica como dos bytes en GR (0xA1–0xFE) y un carácter de KS X 1003 o ASCII (G0, conjunto de códigos 0) ocupa un byte en GL (0x21–0x7E).

En la República de Corea se le suele denominar Wansung ( coreano :  완성 ; RR :  Wanseong ; lit.  precompuesto [33] ) . IBM se refiere al componente de doble byte como Página de códigos 971 , [34] y a EUC-KR con ASCII como Página de códigos 970. [ 35] [36] [37] Microsoft lo implementa como Página de códigos 20949 ("Wansung coreano") [38] [39] y Página de códigos 51949 ("EUC coreano"). [38]

En abril de 2024 , menos del 0,08% de todas las páginas web a nivel mundial usan EUC-KR, [40] pero el 4,6% de las páginas web de Corea del Sur usan EUC-KR, [41] Incluidas las extensiones, es la codificación de caracteres heredada más utilizada en Corea en las tres plataformas principales ( macOS , otros sistemas operativos tipo Unix y Windows), pero su uso ha ido cambiando muy lentamente a UTF-8 a medida que gana popularidad, especialmente en Linux y macOS.

Al igual que con la mayoría de las otras codificaciones, ahora se prefiere UTF-8 para nuevos usos, lo que resuelve problemas de consistencia entre plataformas y proveedores.

Código Hangul Unificado

Una extensión común de EUC-KR es el Código Hangul Unificado ( 통합형 한글 코드 ; Tonghabhyeong Hangeul Kodeu , [42] o 통합 완성형 ; Tonghab Wansunghyung ), que es la página de códigos coreana predeterminada en Microsoft Windows. Microsoft le asigna el número de página de códigos 949 y IBM 1261 [43] o 1363 [44] . La página de códigos 949 de IBM es una extensión EUC-KR diferente y no relacionada.

El código Hangul unificado amplía el EUC-KR mediante el uso de códigos que no se ajustan a la estructura EUC para incorporar bloques de sílabas adicionales, completando así la cobertura de los bloques de sílabas compuestas disponibles en Johab y Unicode. El estándar de codificación W3C / WHATWG utilizado por HTML5 incorpora las extensiones del código Hangul unificado en su definición de EUC-KR. [45]

Mac OS coreano (HangulTalk)

Otras codificaciones que incorporan EUC-KR como subconjunto incluyen el sistema de escritura coreano de Mac OS (conocido como Página de códigos 10003 o x-mac-korean), [13] que fue utilizado por HangulTalk (MacOS-KH), la localización coreana del Mac OS clásico . Fue desarrollado por Elex Computer ( 일렉스 ), que en ese momento era el distribuidor autorizado de computadoras Apple Macintosh en Corea del Sur. [46] [29]

HangulTalk agrega caracteres de extensión con bytes iniciales entre 0xA1 y 0xAD, tanto en espacios no utilizados dentro del plano GR EUC-KR (bytes finales 0xA1–0xFE), como utilizando códigos no EUC fuera de él (bytes finales 0x41–0xA0). Algunos de estos caracteres son dingbats estilizados independientes del estilo de fuente . [29] Muchos de estos caracteres no tienen asignaciones Unicode exactas, y el software de Apple asigna estos casos de diversas formas a secuencias de combinación , a asignaciones aproximadas con un carácter de uso privado adjunto como modificador para fines de ida y vuelta, o a caracteres de uso privado. [47]

Apple también utiliza ciertos códigos de un solo byte fuera del plano EUC-KR para caracteres adicionales: 0x80 para un espacio requerido , 0x81 para un signo won (₩), 0x82 para un guión corto (–), 0x83 para un signo de copyright (©), 0x84 para un guión bajo ancho (＿) y 0xFF para puntos suspensivos (...). [47] Aunque ninguno de estos códigos de un solo byte adicionales está dentro del rango de bytes iniciales del EUC-KR simple (a diferencia de las extensiones de Apple a EUC-CN, ver arriba), algunos están dentro del rango de bytes iniciales del Código Hangul Unificado (específicamente, 0x81, 0x82, 0x83 y 0x84).

EUC-KP

De manera similar al KS X 1001, el estándar norcoreano KPS 9566 se utiliza normalmente en formato EUC; en estos contextos, a veces se lo denomina EUC-KP. [48] Las ediciones más recientes del estándar amplían la representación EUC con caracteres que utilizan códigos de dos bytes que no son EUC, de manera similar al Código Hangul Unificado. [49]

UEC-TH

Aunque ciertas codificaciones de un solo byte, como la serie ISO/IEC 8859, se ajustan técnicamente a la estructura EUC, rara vez se las etiqueta como EUC. Sin embargo, eucTHse utiliza en Solaris como etiqueta para TIS-620 . [50]

UEC-TW

EUC-TW es una codificación de longitud variable que admite ASCII y 16 planos de CNS 11643 , cada uno de los cuales es de 94×94. Es una codificación poco utilizada para caracteres chinos tradicionales como los que se usan en Taiwán . Las variantes de Big5 son mucho más comunes que EUC-TW, aunque Big5 solo codifica los dos primeros planos de CNS 11643 hanzi , mientras que UTF-8 se está volviendo más común.

Téngase en cuenta que el plano 1 del CNS 11643 está codificado dos veces como conjunto de códigos 1 y como parte del conjunto de códigos 2.

Véase también

Notas

  1. ^ Las versiones de código ISO 2022 de 7 bits que admiten GB 2312 incluyen ISO-2022-CN (con códigos de desplazamiento) e ISO-2022-JP-2 (sin códigos de desplazamiento), las cuales también admiten otros conjuntos que no sean ASCII.
  2. ^ Estas secuencias coinciden con las formas hexadecimales mostradas por DEC [30] y las formas decimales ( 10 65y 10 66) enumeradas por Lunde. [28] Lunde enumera las formas hexadecimales para ambas como 0xA0 0x42, aparentemente por error.

Referencias

  1. ^ abcd IBM . "Arquitectura de representación de datos de caracteres (CDRA)". IBM . págs. 157–162.
  2. ^ abc Lunde, Ken (2008). Procesamiento de información CJKV: computación china, japonesa, coreana y vietnamita. O'Reilly. págs. 242-244. ISBN 9780596800925.
  3. ^ "Conjuntos de caracteres". IANA.
  4. ^ "4.2. Nombres y etiquetas". Estándar de codificación . WHATWG.
  5. ^ Zhu, Haifeng; Hu, Daoyuan; Wang, Zhiguan; Kao, Tien-cheu; Chang, Wen-chung; Crispin, Mark (marzo de 1996). Codificación de caracteres chinos para mensajes de Internet. Grupo de Trabajo de Red. doi : 10.17487/RFC1922 . RFC 1922. Informativo. sec. 2.1: CN-GB).
  6. ^ abcd "Mapa (versión externa) de la codificación chino simplificado de Mac OS a Unicode 3.0 y posteriores". Apple, Inc.
  7. ^ "Datos de PC S-Ch mixtos (IBM GB) que incluyen 1880 UDC, 31 caracteres seleccionados de IBM y 5 caracteres SAA SB". IBM Globalization: Coded character set identifiers (Identificadores de conjuntos de caracteres codificados) . IBM . Archivado desde el original el 26 de marzo de 2016.
  8. ^ "Conjunto de caracteres gráficos chinos simplificados de IBM" (PDF) . IBM . 1993. CH 3-3220-130 1993-11.
  9. ^ "CCSID 1383: conjunto S-Ch EUC G0, conjunto ASCII G1, conjunto GB 2312-80 (1382)". IBM Globalization: Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 28 de marzo de 2016.
  10. ^ "Conjunto de caracteres gráficos chinos simplificados de IBM para código UNIX extendido (EUC)" (PDF) . IBM . 1994. CH 3-3220-132 1994-06.
  11. ^ "CCSID 5479: conjunto S-Ch EUC G0, conjunto ASCII G1, conjunto GB 2312-80 (5478)". IBM Globalization: Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 27 de marzo de 2016.
  12. ^ "CCSID 9574: conjunto S-Ch DBCS PC GB 2312-80, excluyendo 31 IBM seleccionados y 1360 UDC. También se utiliza en T-Ch 2022-CN TCP". IBM Globalization: Coded character set identifiers (Globalización de IBM: identificadores de conjuntos de caracteres codificados) . IBM . Archivado desde el original el 27 de marzo de 2016.
  13. ^ ab "Propiedad Encoding.WindowsCodePage – .NET Framework (versión actual)". MSDN . Microsoft.
  14. ^ Lunde, Ken (1998). "Procesamiento de información CJKV". Apéndice F: GB/T 12345 (PDF) . Medios O'Reilly . ISBN 9781565922242.
  15. ^ Administración de Normalización de China (SAC) (18 de noviembre de 2005). GB 18030-2005: Tecnología de la información: conjunto de caracteres codificados chinos.
  16. ^ "Tendencias históricas en el uso de codificaciones de caracteres para sitios web". W3Techs.
  17. ^ "Distribución de codificaciones de caracteres entre sitios web que utilizan japonés". w3techs.com . Consultado el 1 de noviembre de 2023 .
  18. ^ "Documento informativo del CCSID 954". Archivado desde el original el 27 de marzo de 2016.
  19. ^ Componentes internacionales para Unicode (ICU), ibm-954_P101-2007.ucm, 3 de diciembre de 2002
  20. ^ abcd "Tablas de mapeo de código JIS X 0213". x0213.org.
  21. ^ "Ambigüedades en la conversión de EUC japonés a Unicode (no normativo)". Perfil XML japonés . W3C.
  22. ^ "Decodificador EUC-JP". Estándar de codificación . WHATWG."Si el byte es un byte ASCII, devuelve un punto de código cuyo valor es un byte".
  23. ^ "3.1.1 Detalles de los problemas". Problemas y soluciones para caracteres Unicode y definidos por el usuario o el proveedor . The Open Group Japan. Archivado desde el original el 1999-02-03 . Consultado el 2019-08-14 .
  24. ^ Kaplan, Michael S. (17 de septiembre de 2005). "¿Cuándo una barra invertida no es una barra invertida?".
  25. ^ ab "4.2 Proceso de revisión de las reglas para la conversión de conjuntos de códigos entre eucJP-open y UCS". Problemas y soluciones para caracteres Unicode y definidos por el usuario o el proveedor . The Open Group Japan. Archivado desde el original el 1999-02-03 . Consultado el 2019-08-14 .
  26. ^ ab Lunde, Ken (13 de enero de 2009). "Apéndice J: Conjuntos de caracteres japoneses" (PDF) . Procesamiento de la información CJKV (2.ª ed.). ISBN 978-0-596-51447-1.
  27. ^ ab Chang, Hyeshik (8 de diciembre de 2021). "Léame para CJKCodecs". cPython . Python Software Foundation.
  28. ^ abcdefghi Lunde, Ken (13 de enero de 2009). "Apéndice F: Métodos de codificación de proveedores" (PDF) . Procesamiento de información CJKV (2.ª ed.). ISBN 978-0-596-51447-1.
  29. ^ abcdefghij Lunde, Ken (2009). "Apéndice E: Estándares de conjuntos de caracteres de proveedores" (PDF) . Procesamiento de información CJKV: computación china, japonesa, coreana y vietnamita (2.ª ed.). Sebastopol, CA : O'Reilly . ISBN 978-0-596-51447-1.
  30. ^ ab "2: Conjuntos de códigos y conversión de conjuntos de códigos". Referencia técnica de DIGITAL UNIX para el uso de funciones japonesas . Digital Equipment Corporation , Compaq .[ enlace muerto ]
  31. ^ "KS X 1001:1992" (PDF) .
  32. ^ Oficina de Normas de Corea (1 de octubre de 1988). KS C 5601:1987 (PDF) . ITSCJ/ IPSJ . ISO-IR -149.
  33. ^ Lunde, Ken (2009). "Capítulo 3: Estándares de conjuntos de caracteres". Procesamiento de información CJKV . "O'Reilly Media, Inc.", pág. 146. ISBN 978-0596514471.
  34. ^ "IBM Globalization – Coded character set identifiers – CCSID 971" (Globalización de IBM: identificadores de conjuntos de caracteres codificados – CCSID 971). Archivado desde el original el 2014-11-30 . Consultado el 2021-09-03 .
  35. ^ "CCSID 970". Globalización de IBM . IBM. Archivado desde el original el 1 de diciembre de 2014.
  36. ^ "ibm-970_P110_P110-2006_U2 (alias euc-kr)". Explorador de convertidores: demostración de la UCI . Componentes internacionales para Unicode.
  37. ^ Componentes internacionales para Unicode (ICU), ibm-970_P110_P110-2006_U2.ucm, 3 de diciembre de 2002
  38. ^ ab "Identificadores de páginas de códigos". Centro de desarrollo de Windows. Microsoft. 7 de enero de 2021.
  39. ^ Julliard, Alexandre (11 de marzo de 2021). "dump_krwansung_codepage: crea la tabla Wansung coreana a partir del archivo KSX1001". make_unicode: genera archivos .c de páginas de códigos a partir de descripciones de ftp.unicode.org . Proyecto Wine .
  40. ^ "Estadísticas de uso y cuota de mercado de EUC-KR para sitios web, abril de 2024". w3techs.com . Consultado el 9 de abril de 2024 .
  41. ^ "Distribución de codificaciones de caracteres entre sitios web que utilizan .kr". w3techs.com . Consultado el 9 de abril de 2024 .
  42. ^ "한글 코드에 대하여" (en coreano). W3C. Archivado desde el original el 24 de mayo de 2013 . Consultado el 7 de enero de 2019 .
  43. ^ En ucnv_lmb.cpp, un archivo originado en IBM e incluido en el árbol de origen de Componentes internacionales para Unicode , el byte inicial 0x11 está comentado como una referencia a "Korean: ibm-1261" después de la definición de ULMBCS_GRP_KO, y está asignado al "windows-949"códec ICU en la OptGroupByteToCPNamematriz más adelante en el archivo.
  44. ^ "Identificadores de conjuntos de caracteres codificados – CCSID 1363", IBM Globalization , IBM, archivado desde el original el 29 de noviembre de 2014
  45. ^ "5. Índices (§ índice EUC-KR)", Estándar de codificación , WHATWG
  46. ^ Gil, Hojin. "HangulTalk: entorno Hangul estándar de facto para Mac". Guía para usar Hangul en Macintosh .
  47. ^ ab Apple (5 de abril de 2005). "Mapa (versión externa) de la codificación coreana de Mac OS a Unicode 3.2 y posteriores". Consorcio Unicode .
  48. ^ Kim, Kyongsok (30 de noviembre de 2002). "Tablas de referencias cruzadas de 3 vías: KS X 1001, KPS 9566 y UCS" (PDF) . ISO/IEC JTC 1/SC 2 /WG 2 N2564.[Nota: enlaces actualizados para las tablas que acompañan al documento: [1] [2]]
  49. ^ Chung, Jaemin (5 de enero de 2018). "Información sobre la versión más reciente de KPS 9566 (KPS 9566-2011?)" (PDF) . UTC L2/18-011.
  50. ^ IBM (7 de mayo de 2001). "solaris-eucTH-2.7". icu-data . Consorcio Unicode / Componentes internacionales para Unicode .

Enlaces externos