El código Unix extendido ( EUC ) es un sistema de codificación de caracteres multibyte que se utiliza principalmente para (caracteres) japonés , coreano y chino simplificado .
Los códigos EUC más comúnmente utilizados son codificaciones de longitud variable con un carácter que pertenece a un juego de caracteres codificados compatible con ISO/IEC 646 (como ASCII ) que ocupa un byte, y un carácter que pertenece a un juego de caracteres codificados de 94×94 (como GB 2312 ) representado en dos bytes. La forma EUC-CN de GB 2312 y EUC-KR son ejemplos de códigos EUC de dos bytes. EUC-JP incluye caracteres representados por hasta tres bytes, incluido un código de cambio 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 con menos desviaciones y errores de proveedores. Sin embargo, EUC sigue siendo muy popular, especialmente EUC-KR para Corea del Sur.
La estructura de EUC se basa en el estándar ISO/IEC 2022 , que especifica un sistema de juegos 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 es un octavo bit. está disponible. Esto permite conjuntos de 94 caracteres gráficos, o 8836 (94 2 ) caracteres, o 830584 (94 3 ) caracteres. Aunque inicialmente 0x20 y 0x7F siempre fueron el carácter de espacio y eliminación y 0xA0 y 0xFF no se usaron, las 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, permitiendo 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 juegos de caracteres que cumplen con ISO 2022 pueden tener formularios EUC. Con el esquema EUC se pueden representar hasta cuatro juegos de caracteres codificados (denominados G0, G1, G2 y G3 o juegos de códigos 0, 1, 2 y 3). El conjunto G0 se establece en un conjunto de caracteres codificados que cumple con ISO/IEC 646 , como US-ASCII , ISO 646:KR ( KS X 1003 ) o ISO 646:JP (la mitad inferior de JIS X 0201 ) y se invoca a través de GL (es decir, 0x21–0x7E, con el bit más significativo borrado). [1] Si se utiliza US-ASCII, esto convierte el código en una codificación ASCII extendida ; La desviación más común de US-ASCII es que 0x5C ( barra invertida en US-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 a través de GR (es decir, con el conjunto de bits más significativo). 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 el prefijo de los códigos de control SS2 (0x8E) y SS3 (0x8F) respectivamente, y se invocan a través de GR. Además del código de cambio 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 utiliza las secuencias de anuncios y designaciones de ISO 2022 . [1] Sin embargo, la especificación del código es equivalente a la siguiente secuencia de cuatro secuencias de anuncios ISO 2022 , con significados desglosados de la siguiente manera. [1]
La codificación de longitud variable basada en ISO-2022 descrita anteriormente a veces se denomina formato empaquetado EUC , que es el formato de codificación generalmente etiquetado como EUC. Sin embargo, el procesamiento interno de datos EUC puede utilizar un formato de transformación de longitud fija llamado formato EUC completo de dos bytes . Esto representa: [2]
Los bytes iniciales de 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 normalmente no se encuentran en el intercambio.
EUC-JP está registrado ante 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 se incluye en el estándar de codificación WHATWG utilizado por HTML5 . [4]
EUC-CN [6] es la forma codificada habitual del estándar GB 2312 para caracteres chinos simplificados . A diferencia del caso de los japoneses JIS X 0208 e ISO-2022-JP , GB 2312 normalmente no se usa en una versión de código ISO 2022 de 7 bits , [a] aunque existe una forma variante llamada HZ (que delimita el texto GB 2312 con secuencias ASCII) A veces se usaba en USENET .
Un carácter ASCII se representa en su codificación habitual. Un carácter de GB 2312 está representado por dos bytes, ambos del rango 0xA1–0xFE.
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 nuevo sistema de composición tipográfica FITS). El código 748 contiene todo GB 2312 , pero no cumple 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 configurado y uno con su bit más significativo borrado y, por lo tanto, es más similar en estructura a Big5 y otros DBCS que no cumplen con ISO 2022. sistemas de codificación.) La parte del código 748 que no es GB2312 contiene caracteres tradicionales y de Hong Kong y otros glifos utilizados en la tipografía de periódicos.
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 nuevamente a 0x8C, agregando 31 caracteres seleccionados por IBM en 0x8CE0 a 0x8CFE y agregando 1880 caracteres definidos por el usuario con bytes iniciales 0x8D a 0xA0. [8]
La página de códigos de 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 se diferencia por ajustarse a la estructura EUC, agregando los 31 seleccionados por IBM caracteres en 0xFEE0 a 0xFEFE en su lugar, e incluye solo 1360 caracteres definidos por el usuario, intercalados en las posiciones no utilizadas por GB 2312. [10] El CCSID alternativo 5479 [11] se usa para la página de códigos EUC-CN puro: usa 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 es una extensión de GB 2312 . Define una forma extendida de la codificación EUC-CN capaz de representar una gama más amplia de caracteres CJK provenientes en gran medida de Unicode 1.1 , incluidos los caracteres chinos tradicionales y los caracteres utilizados sólo 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 individuales, pueden aparecer como bytes iniciales o finales), debido a que se requiere un espacio de codificación mayor.
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 .
Otras variantes de EUC-CN que se desvían del mecanismo EUC incluyen la escritura simplificada china de Mac OS (conocida como página de códigos 10008 o x-mac-chinesesimp). [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 sin separación , el signo de copyright (©), el signo de marca (™) y puntos suspensivos (…) respectivamente. [6] Esto difiere en lo que se considera un carácter de un solo byte versus el primer byte de un carácter de dos bytes tanto de EUC (donde, de ellos, 0xFD y 0xFE se definen como bytes iniciales) como de GBK (donde, de esos , 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 porción de doble byte de Mac OS chino simplificado es la inclusión de dos extensiones al GB 2312-80 básico establecido en las filas 6 y 8. [6] Estas se consideran "extensiones estándar para 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 es una codificación de longitud variable que se utiliza para representar los elementos de tres estándares de juegos de caracteres japoneses , a saber, JIS X 0208 , JIS X 0212 y JIS X 0201 . Otros nombres para esta codificación incluyen JIS Unixized (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 3,0% de los sitios web en japonés utilizan esta codificación [17] (menos utilizada que Shift JIS o UTF-8 ). IBM la 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 mezclar fácilmente 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 juego de caracteres, y sin que los bytes ASCII aparezcan como bytes de seguimiento. (a diferencia de Shift JIS ).
Una codificación relacionada y parcialmente compatible, llamada 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 tuvo una adopción tan amplia en sistemas PC y Macintosh en Japón, que utilizaban Shift JIS o sus extensiones ( página de códigos de Windows 932 en Microsoft Windows y MacJapanese en Mac OS clásico ). , aunque llegó a ser muy utilizado por Unix o sistemas operativos similares a Unix (excepto HP-UX ). Por lo tanto, si los sitios web japoneses utilizan EUC-JP o Shift_JIS a menudo depende del sistema operativo que utilice el autor.
Los caracteres están codificados 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 la codificación JIS X 0208 sobre GR, pero no siguen la estructura EUC empaquetada. A menudo, estos no incluyen el uso de cambios únicos de EUC-JP y, por lo tanto, no son extensiones directas de EUC-JP, con la excepción de Super 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 guardan cierta semejanza con el formato completo de dos bytes. El formato general de la codificación "DEC Kanji" corresponde principalmente a EUC de longitud fija (dos bytes completos); sin embargo, no es necesario rellenar el conjunto de códigos 0 con bytes nulos a la izquierda (de forma similar al formato empaquetado). [28] JIS X 0208 se utiliza, como de costumbre, 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 usa para caracteres de dos bytes definidos por el usuario en lugar de especificarse para JIS X 0212. [28] En la codificación básica "DEC Kanji", sólo 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 EUC en formato empaquetado, para un total de cinco conjuntos de códigos. [28] También permite que todo el conjunto de códigos definido 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 códigos definidos por el usuario. caracteres. [29]
Hewlett-Packard define una codificación denominada "HP-16". Esto acompaña a su codificación "HP-15", que es una variante de Shift JIS . HP-16 codifica JIS X 0208 usando los mismos bytes que en EUC-JP, pero no usa códigos de turno único (omitiendo así los conjuntos de códigos 2 y 3) y agrega tres regiones definidas por el usuario que no siguen el formato empaquetado. Estructura de la EUC: [28]
La codificación IKIS (Sistema de información kanji interactivo) utilizada por Data General se parece a EUC-JP sin cambios 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 (que choca con el cuadro- caracteres de dibujo 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]
KEIS (Sistema de información extendido de procesamiento de kanji) 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 del 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 anteriores a JIS X 0208. El rango de bytes iniciales se extiende hasta 0x59, de los cuales los bytes iniciales 0x81–A0 se designan para caracteres definidos por el usuario, [28] y el resto se utiliza para caracteres definidos por la empresa, incluidos kanji y no kanji. [29]
JEF (función extendida de procesamiento japonés) [29] es una codificación EBCDIC utilizada en las computadoras centrales Fujitsu FACOM, en contraste con FMR (una variante de Shift JIS) utilizada en las 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 nuevamente 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 del 101 al 163 para fines de Kuten , aunque la fila 162 (byte inicial 0x7E) no se utiliza. [28] [29] Las filas 101 a 148 se usan para kanji extendidos, mientras que las filas 149 a 163 se usan para no kanji extendidos. [29]
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] e ISO 646 :KR ( KS X 1003 , anteriormente KS C 5636 ) o US-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 US-ASCII (G0, conjunto de códigos 0) ocupa un byte en GL ( 0x21–0x7E).
Generalmente se le conoce como Wansung ( coreano : 완성 , romanizado : Wanseong , literalmente 'precompuesto [33] ') en la República de Corea . 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 ("Korean Wansung") [38] [39] y página de códigos 51949 ("EUC Korean"). [38]
En abril de 2024 [actualizar], menos del 0,08% de todas las páginas web a nivel mundial utilizan EUC-KR, [40] pero el 4,6% de las páginas web de Corea del Sur utilizan EUC-KR, [41] Incluyendo las extensiones, es la codificación de caracteres heredada más utilizada. en Corea en las tres plataformas principales ( macOS , otros sistemas operativos similares a Unix y Windows), pero su uso ha ido cambiando muy lentamente a UTF-8 a medida que gana popularidad, especialmente en Linux y macOS.
Como ocurre con la mayoría de las otras codificaciones, ahora se prefiere UTF-8 para nuevos usos, lo que resuelve problemas de coherencia entre plataformas y proveedores.
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 EUC-KR mediante el uso de códigos que no se ajustan a la estructura EUC para incorporar bloques de sílabas adicionales, completando la cobertura de los bloques de sílabas compuestos 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]
Otras codificaciones que incorporan EUC-KR como subconjunto incluyen la escritura coreana de Mac OS (conocida como página de códigos 10003 o x-mac-korean), [13] que fue utilizada por HangulTalk (MacOS-KH), la localización coreana del Mac OS clásico . Fue desarrollado por Elex Computer ( 일렉스 ), quien 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 espacio no utilizado dentro del plano EUC-KR GR (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 para combinar secuencias , para aproximar asignaciones con un carácter de uso privado adjunto como modificador para fines de ida y vuelta, o para 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 de won (₩), 0x82 para un guión final (–), 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 adicionales de un solo byte está dentro del rango de bytes iniciales de 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).
De manera similar a 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 no EUC, de manera similar al Código Hangul Unificado. [49]
Aunque ciertas codificaciones de un solo byte, como la serie ISO/IEC 8859, técnicamente se ajustan a la estructura EUC, rara vez están etiquetadas como EUC. Sin embargo, eucTHse utiliza en Solaris como etiqueta para TIS-620 . [50]
EUC-TW es una codificación de longitud variable que admite US-ASCII y 16 planos de CNS 11643 , cada uno de los cuales es de 94×94. Es una codificación poco utilizada para los caracteres chinos tradicionales como los que se utilizan 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.
Tenga en cuenta que el plano 1 de CNS 11643 está codificado dos veces como conjunto de códigos 1 y como parte del conjunto de códigos 2.
10 65y 10 66) enumeradas por Lunde. [28] Lunde enumera las formas hexadecimales para ambos como 0xA0 0x42, aparentemente por error.ULMBCS_GRP_KOy está asignado al "windows-949"códec ICU. en la OptGroupByteToCPNamematriz más adelante en el archivo.