De Wikipedia, la enciclopedia libre
  (Redirigido desde EUC-KR )
Saltar a navegación Saltar a búsqueda

El código Unix extendido ( EUC ) es un sistema de codificación de caracteres multibyte que se usa principalmente para japonés , coreano y chino simplificado .

Los códigos EUC más comúnmente utilizados son codificaciones de ancho variable con un carácter que pertenece a un conjunto de caracteres codificados compatible con ISO / IEC 646 (como ASCII ) que toma un byte, y un carácter que pertenece a un conjunto de caracteres codificados de 94x94 (como GB 2312 ) representado 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 turno inicial , mientras que un solo carácter en EUC-TW puede ocupar hasta cuatro bytes.

Es más probable que las aplicaciones modernas usen 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 del proveedor. Sin embargo, EUC sigue siendo muy popular, especialmente EUC-KR para Corea del Sur.

Estructura de codificación [ editar ]

Relación entre 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 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, 8836 (94 2 ) caracteres o 830584 (94 3 ) caracteres. Aunque inicialmente 0x20 y 0x7F eran siempre el espacio y el carácter de eliminación y 0xA0 y 0xFF no se usaban, las ediciones posteriores de ISO / IEC 2022permitió 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 conjuntos de caracteres que cumplen con ISO 2022 pueden tener formularios 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 US-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 usa US-ASCII, esto hace que el código seacodificació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 otros 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 agregar 128 a cada byte de codificación de 7 bits, o agregar 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 de 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 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í mismo no hace uso de las secuencias de anuncio y designación 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 los significados desglosados ​​de la siguiente manera. [1]

Formato de ancho fijo [ editar ]

La codificación de ancho 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 hacer uso de un formato de transformación de ancho fijo llamado formato EUC completo de dos bytes . Esto representa: [2]

  • El código establece 0 como dos bytes en el rango 0x21–0x7E (excepto que el primero puede ser 0x00).
  • El código configurado 1 como dos bytes en el rango 0xA0–0xFF (excepto que el primero puede ser 0x80).
  • El conjunto de códigos 2 es un byte en el rango 0x20–0x7E (o 0x00) seguido de un byte en el rango 0xA0–0xFF.
  • El código 3 se establece como un byte en el rango 0xA0–0xFF (o 0x80) seguido de un byte en el rango 0x21–0x7E.

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 hay un formato de longitud fija de cuatro bytes. [2] Estos formatos de codificación de longitud fija son adecuados para el procesamiento interno y generalmente no se encuentran en el intercambio.

EUC-JP está registrado con 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 [ editar ]

EUC-CN [5] es la forma codificada habitual del estándar GB 2312 para caracteres chinos simplificados . A diferencia del caso de JIS X 0208 e ISO-2022-JP japoneses , GB 2312 no se usa normalmente en una versión de código ISO 2022 de 7 bits , [a] aunque 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.

Sistemas de codificación de China continental relacionados [ editar ]

748 código [ editar ]

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 el GB 2312 , pero no cumple con la norma 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 conjunto de bits más significativo y uno con el bit más significativo borrado y, por lo tanto, es más similar en estructura a Big5 y otros sistemas de codificación DBCS que no cumplen con ISO 2022. .) La parte que no es 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.

GBK y GB 18030 [ editar ]

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

Las variantes de GBK se implementan en la página de códigos 936 de Windows (la página de códigos de Microsoft Windows para chino simplificado) y en 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 ancho variable que puede usar 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 [ editar ]

Otras variantes de EUC-CN que se desvían del mecanismo EUC incluyen el script chino simplificado de Mac OS (conocido como página de códigos 10008 o x-mac-chinesesimp). [6] Utiliza los bytes 0x80, 0x81, 0x82, 0xA0, 0xFD, 0xFE y 0xFF para la U con diéresis (ü), dos caracteres métricos de fuentes especiales, el espacio sin interrupciones , el signo de copyright (©), la marca comercial signo (™) y puntos suspensivos (…) respectivamente. [5] 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 de ambos EUC (donde, de esos, 0xFD y 0xFE se definen como bytes iniciales) y 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 Chinese Simplified es la inclusión de dos extensiones al conjunto básico GB 2312-80 en las filas 6 y 8. [5] Estos 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 , [5] ambas extensiones están incluidas en GB / T 12345 (la variante de chino tradicional de GB 2312), [7 ] y ambas extensiones están incluidas en GB 18030 (el sucesor de GB 2312). [8]

EUC-JP [ editar ]

EUC-JP es una codificación de ancho variable que se utiliza para representar los elementos de tres estándares de juego 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 agosto de 2018, [9] mientras que el 2,8% de los sitios web en japonés utilizan esta codificación (menos utilizada que Shift JIS o UTF-8 ). IBM lo llama Code page 954 . [10] [11] 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 mezcla fácil 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 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 [12] (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ó tanto 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 el Mac OS clásico ) , aunque llegó a ser muy utilizado por Unix o sistemas operativos similares a Unix (a excepción de 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 se codifican de la siguiente manera:

  • Como codificación compatible con EUC / ISO 2022 , los caracteres de control C0 , el espacio y DEL se representan como en ASCII.
  • Un carácter gráfico de ASCII (conjunto de códigos 0) se representa como su representación habitual de un byte, en el rango 0x21 - 0x7E. Mientras que algunas variantes de EUC-JP codifican la mitad inferior de JIS X 0201 aquí, la mayoría codifica ASCII, [13] incluido el estándar de codificación W3C / WHATWG utilizado por HTML5 , [14] y también EUC-JIS-2004. [12] Si bien esto significa que 0x5C se asigna típicamente a Unicode como U + 005C REVERSE SOLIDUS (la barra invertida ASCII ), U + 005C puede mostrarse como un signo de Yen mediante ciertas fuentes de configuración regional japonesa, por ejemplo, en Microsoft Windows, para compatibilidad con la mitad inferior de JIS X 0201 . [15][dieciséis]
  • Un carácter de JIS X 0208 (conjunto de códigos 1) está representado por dos bytes, ambos en el rango 0xA1 - 0xFE. Esto se diferencia de la representación ISO-2022-JP por tener el bit alto establecido. Este conjunto de códigos también puede contener extensiones de proveedor en algunas variantes de EUC-JP. En EUC-JIS-2004, el primer plano de JIS X 0213 se codifica aquí, que es efectivamente un superconjunto del estándar JIS X 0208 . [12]
  • Un carácter de la mitad superior de JIS X 0201 ( kana de ancho medio , conjunto de códigos 2) está representado por dos bytes, el primero es 0x8E y el segundo es la representación habitual de JIS X 0201 en el rango 0xA1 - 0xDF. Este conjunto puede contener extensiones de proveedores de IBM en algunas variantes.
  • Un carácter de JIS X 0212 (conjunto de códigos 3) se representa en EUC-JP por tres bytes, el primero es 0x8F, los dos siguientes están en el rango 0xA1–0xFE, es decir, con el conjunto de bits alto. Además del estándar JIS X 0212 , el conjunto de códigos 3 de algunas variantes de EUC-JP también puede contener extensiones en las filas 83 y 84 para representar caracteres de las extensiones Shift JIS de IBM que carecen de asignaciones estándar JIS X 0212, que pueden estar codificadas en cualquiera de dos diseños, uno definido por los propios IBM y otro definido por la OSF . [17] [18] En EUC-JIS-2004, el segundo plano de JIS X 0213 se codifica aquí, [12] que no choca con las filas asignadas en el estándar JIS X 0212 . [19]Algunas implementaciones de EUC-JIS-2004, como la utilizada por Python , permiten tanto caracteres JIS X 0212 como JIS X 0213 plano 2 en este conjunto. [19]

Métodos de codificación japoneses relacionados [ editar ]

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

Sin embargo, algunas codificaciones específicas del proveedor 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 turnos únicos de EUC-JP y, por lo tanto, no son extensiones directas de EUC-JP, con la excepción de Super DEC Kanji.

DEC Kanji [ editar ]

Digital Equipment Corporation define dos variantes de EUC-JP que se ajustan solo en parte al formato empaquetado de EUC, pero que también tienen cierta semejanza con el formato completo de dos bytes. El formato general de la codificación "DEC Kanji" corresponde principalmente a EUC de ancho fijo (dos bytes completos); sin embargo, no se requiere que el conjunto de códigos 0 se complete a la izquierda con bytes nulos (de manera similar al formato empaquetado). [20] 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 se codifica como el formato de ancho fijo de dos bytes (es decir, sin un byte de desplazamiento y con solo el primer conjunto de bits alto), pero se utiliza para caracteres definidos por el usuario de dos bytes en lugar de especificarse para JIS X 0212. [20]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. [21]

La codificación "Super DEC Kanji" acepta códigos tanto de la codificación "DEC Kanji" como del formato empaquetado EUC, para un total de cinco conjuntos de códigos. [20] 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 caracteres. [21]

HP-16 [ editar ]

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 los 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 EUC: [20]

  • Bytes iniciales 0xA1 – C2, bytes finales 0x21–7E
  • Bytes iniciales 0xC3 – E3, bytes finales 0x21–3F
  • Bytes iniciales 0xC3 – E1, bytes finales 0x40–64

IKIS [ editar ]

La codificación IKIS (Interactive Kanji Information System) utilizada por Data General se asemeja a EUC-JP sin turnos únicos, es decir, con solo conjuntos de códigos 0 y 1. Los katakana de ancho medio se incluyen en la fila 8 de JIS X 0208 (chocando 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. [20] [21]

Adaptaciones de EUC-JP para EBCDIC [ editar ]

KEIS (Sistema de información extendido de procesamiento de kanji) es una codificación EBCDIC utilizada por Hitachi , [21] 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 anteriores a JIS X 0208. 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, [20] y el resto se usa para caracteres definidos por la empresa, incluidos kanji y no kanji. [21]

JEF (Función extendida de procesamiento japonés) [21] es una codificación EBCDIC utilizada en los mainframes 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 utilizando secuencias de desplazamiento (donde 0x29cambia al modo de un solo byte y 0x28cambia al modo de doble byte). [22] También de manera similar a KEIS, los códigos JIS X 0208 se representan igual que en EUC-JP. [20] El rango de bytes iniciales se amplía de nuevo a 0x41, con 0x80 – A0 designado para la definición del usuario; A los bytes iniciales 0x41–7F se les asignan los números de fila 101 a 163 para fines kuten , aunque la fila 162 (byte inicial 0x7E) no se utiliza. [20] [21]Las filas 101 a 148 se usan para kanji extendidos, mientras que las filas 149 a 163 se usan para no kanji extendidos. [21]

EUC-KR [ editar ]

EUC-KR es una codificación de ancho variable para representar texto coreano utilizando dos conjuntos de caracteres codificados, KS X 1001 (anteriormente KS C 5601) [23] [24] 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, juego 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, juego de códigos 0) toma un byte en GL ( 0x21–0x7E).

Por lo general, se le conoce como Wansung ( coreano : 완성 , romanizado :  Wanseong , literalmente  'precompuesto [25] ' ) en la República de Corea . Cuando se utiliza con ASCII, IBM la denomina Página de códigos 970 . [26] [27] [28] Está implementado como la página de códigos 20949 ("Korean Wansung") [29] [30] y la página de códigos 51949 ("EUC Korean") por Microsoft. [29]

En marzo de 2021 , el 0,1% de todas las páginas web a nivel mundial utilizan EUC-KR, [9] lo cual es engañoso ya que el 10,8% de las páginas web de Corea del Sur utilizan (el único país al que está destinada la codificación), [31] por lo que es la más popular. codificación no UTF-8 / Unicode para un idioma / dominio web, mientras que solo el 6,0% de las páginas web utilizan el idioma coreano (lo que hace que UTF-8 sea menos popular en Corea del Sur que en (aparentemente) todos los países del mundo). [32] Incluidas 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 avanza. 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, resolviendo problemas con coherencia entre plataformas y proveedores.

Sistemas de codificación coreanos relacionados [ editar ]

Código Hangul unificado [ editar ]

Una extensión común de EUC-KR es el Código Hangul Unificado ( 통합형 한글 코드 , Tonghabhyeong Hangeul Kodeu , [33] 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 [34] o 1363 [35] . La página de códigos 949 de IBM es una extensión EUC-KR diferente y no relacionada.

Unified Hangul Code 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. [36]

Mac OS Coreano (HangulTalk) [ editar ]

Otras codificaciones que incorporan EUC-KR como un subconjunto incluyen el script coreano de Mac OS (conocido como página de códigos 10003 o x-mac-korean), [6] 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. [37] [21]

HangulTalk agrega caracteres de extensión con bytes iniciales entre 0xA1 y 0xAD, ambos en el espacio no utilizado dentro del plano EUC-KR GR (bytes de ruta 0xA1–0xFE) y utilizando códigos que no son EUC fuera de él (bytes de ruta 0x41-0xA0). Algunos de estos personajes son dingbats estilizados independientes del estilo de fuente . [21] Muchos de estos caracteres no tienen mapeos Unicode exactos, y el software de Apple mapea estos casos de diversas formas para combinar secuencias , para aproximar mapeos con un carácter de uso privado agregado como modificador para propósitos de ida y vuelta, o para caracteres de uso privado. . [38]

Apple también usa ciertos códigos de un solo byte fuera del plano EUC-KR para caracteres adicionales: 0x80 para un espacio requerido , 0x81 para un signo ganado (₩), 0x82 para un guión (-), 0x83 para un signo de derechos de autor (© ), 0x84 para un subrayado ancho (_) y 0xFF para una elipsis (…). [38] Aunque ninguno de estos códigos adicionales de un solo byte se encuentra dentro del rango de bytes iniciales de EUC-KR simple (a diferencia de las extensiones de Apple para 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-TW [ editar ]

EUC-TW es una codificación de ancho variable que admite US-ASCII y 16 planos de CNS 11643 , cada uno de los cuales es 94x94. Es una codificación poco utilizada para los caracteres chinos tradicionales como se usa 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.

  • Como codificación EUC / ISO 2022 , los caracteres de control C0 , el espacio ASCII y DEL se codifican como en ASCII.
  • Un carácter gráfico de US-ASCII (G0, conjunto de códigos 0) se codifica en GL como su representación habitual de un solo byte (0x21–0x7E).
  • Un carácter del plano 1 de CNS 11643 (conjunto de códigos 1) se codifica como dos bytes en GR (0xA1–0xFE).
  • Un carácter en el plano 1 al 16 de CNS 11643 (conjunto de códigos 2) se codifica como cuatro bytes:
    • El primer byte es siempre 0x8E (Single Shift 2).
    • El segundo byte (0xA1–0xB0) indica el plano, cuyo número se obtiene restando 0xA0 de ese byte.
    • El tercer y cuarto bytes están en GR (0xA1–0xFE).

Tenga en cuenta que el plano 1 de CNS 11643 se codifica dos veces como conjunto de códigos 1 y una parte del conjunto de códigos 2.

Ver también [ editar ]

  • CJK
  • Lengua japonesa y computadoras
  • Idioma coreano y computadoras
  • Codificación de caracteres chinos

Notas [ editar ]

  1. ^ Las versiones de código ISO 2022 de 7 bits que admiten GB 2312 incluyen ISO-2022-CN (con códigos de turno) e ISO-2022-JP-2 (sin códigos de turno), los cuales también admiten otros conjuntos que no son ASCII.
  2. ^ Estas secuencias coinciden con las formas hexadecimales mostradas por DEC [22] y las formas decimales (10 65y10 66) enumeradas por Lunde. [20] Lunde enumera las formas hexadecimales de ambos como0xA0 0x42aparentemente erróneas.

Referencias [ editar ]

  1. ^ a b c d IBM . "Arquitectura de representación de datos de caracteres (CDRA)" . págs. 157-162.
  2. ↑ a b c Lunde, Ken (2008). Procesamiento de información CJKV: Computación china, japonesa, coreana y vietnamita . O'Reilly. págs. 242–244. ISBN 9780596800925.
  3. ^ "Juegos de caracteres" . IANA.
  4. ^ "4.2. Nombres y etiquetas" . Estándar de codificación . WHATWG.
  5. ^ a b c d "Mapa (versión externa) de la codificación de chino simplificado de Mac OS a Unicode 3.0 y posterior" . Apple, Inc .
  6. ^ a b "Propiedad Encoding.WindowsCodePage - .NET Framework (versión actual)" . MSDN . Microsoft.
  7. ^ Lunde, Ken (1998). Apéndice F: GB / T 12345 (PDF) . Procesamiento de información CJKV . O'Reilly Media . ISBN  9781565922242.
  8. ^ Administración de estandarización de China (SAC) (18 de noviembre de 2005). GB 18030-2005: Tecnología de la información: conjunto de caracteres codificados en chino .
  9. ^ a b "Tendencias históricas en el uso de codificaciones de caracteres para sitios web" . W3Techs.
  10. ^ "Documento de información CCSID 954" . Archivado desde el original el 27 de marzo de 2016.
  11. ^ Componentes internacionales para Unicode (ICU), ibm-954_P101-2007.ucm , 2002-12-03
  12. ^ a b c d "Tablas de asignación de código JIS X 0213" . x0213.org.
  13. ^ "Ambigüedades en la conversión de EUC japonés a Unicode (no normativo)" . Perfil japonés XML . W3C.
  14. ^ "Decodificador EUC-JP" . Estándar de codificación . WHATWG. "Si byte es un byte ASCII, devuelve un punto de código cuyo valor es byte".
  15. ^ "3.1.1 Detalles de problemas" . Problemas y soluciones para Unicode y caracteres definidos por el usuario / proveedor . El Grupo Abierto de Japón. Archivado desde el original el 3 de febrero de 1999 . Consultado el 14 de agosto de 2019 .
  16. Kaplan, Michael S. (17 de septiembre de 2005). "¿Cuándo una barra invertida no es una barra invertida?" .
  17. ^ a b "4.2 Proceso de revisión de reglas para la conversión de conjuntos de códigos entre eucJP-open y UCS" . Problemas y soluciones para Unicode y caracteres definidos por el usuario / proveedor . El Grupo Abierto de Japón. Archivado desde el original el 3 de febrero de 1999 . Consultado el 14 de agosto de 2019 .
  18. ↑ a b Lunde, Ken (13 de enero de 2009). "Apéndice J: Juegos de caracteres japoneses" (PDF) . Procesamiento de información CJKV (2ª ed.). ISBN  978-0-596-51447-1.
  19. ^ a b Chang, Hyeshik. "Léame para CJKCodecs" . cPython . Fundación de software Python.
  20. ↑ a b c d e f g h i Lunde, Ken (13 de enero de 2009). "Apéndice F: métodos de codificación del proveedor" (PDF) . Procesamiento de información CJKV (2ª ed.). ISBN  978-0-596-51447-1.
  21. ↑ a b c d e f g h i j Lunde, Ken (2009). "Apéndice E: Estándares del juego de caracteres del proveedor" (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.
  22. ^ a b "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 . Corporación de equipos digitales , Compaq .
  23. ^ "KS X 1001: 1992" (PDF) .
  24. ^ "KS C 5601: 1987" (PDF) . 1988-10-01.
  25. ^ Lunde, Ken (2009). "Capítulo 3: Estándares de juego de caracteres" . Procesamiento de información CJKV . pag. 146. ISBN 978-0596514471.
  26. ^ "CCSID 970" . Globalización de IBM . IBM. Archivado desde el original el 1 de diciembre de 2014.
  27. ^ "ibm-970_P110_P110-2006_U2 (alias euc-kr)" . Converter Explorer - Demostración de la UCI . Componentes internacionales para Unicode.
  28. ^ Componentes internacionales para Unicode (ICU), ibm-970_P110_P110-2006_U2.ucm , 2002-12-03
  29. ^ a b "Identificadores de página de códigos" . Centro de desarrollo de Windows . Microsoft.
  30. ^ Julliard, Alexandre. "dump_krwansung_codepage: crear una tabla Wansung coreana desde el archivo KSX1001" . make_unicode: Genera archivos .c de página de códigos a partir de descripciones de ftp.unicode.org . Proyecto Vino .
  31. ^ "Distribución de codificaciones de caracteres entre sitios web que usan .kr" . w3techs.com . Consultado el 15 de marzo de 2021 .
  32. ^ "Distribución de codificaciones de caracteres entre sitios web que usan coreano" . w3techs.com . Consultado el 3 de julio de 2020 .
  33. ^ "한글 코드 에 대하여" (en coreano). W3C. Archivado desde el original el 24 de mayo de 2013 . Consultado el 7 de enero de 2019 .
  34. ^ En ucnv_lmb.cpp , un archivo que se origina en IBM e incluido en elárbol fuente de Componentes internacionales para Unicode , el byte principal 0x11 se comenta como una referencia a "Coreano: ibm-1261" después de la definición deULMBCS_GRP_KOy se asigna al"windows-949"códec ICU en laOptGroupByteToCPNamematriz más adelante en el archivo.
  35. ^ "Identificadores de juego de caracteres codificados - CCSID 1363" , IBM Globalization , IBM, archivado desde el original en 2014-11-29
  36. ^ "5. Índices (§ índice EUC-KR)" , Estándar de codificación , WHATWG
  37. ^ Gil, Hojin. "HangulTalk: entorno Hangul estándar de facto para Mac" . Guía para usar Hangul en Macintosh .
  38. ↑ a b Apple (5 de abril de 2005). "Mapa (versión externa) de la codificación coreana de Mac OS a Unicode 3.2 y posterior" . Consorcio Unicode .

Enlaces externos [ editar ]

  • Tabla de conjunto de códigos EUC-JP (menos las partes ASCII y de ancho medio)
  • Identificadores de página de códigos
  • GB18030-2000: el nuevo estándar nacional chino
  • La nueva generación de software de preimpresión en China  : menciona el código 748
  • Descripción del código EUC-TW (en chino)
  • Página del manual de EUC-JISX0213 en el módulo Perl Encode
  • Registro internacional de juegos de caracteres codificados que se utilizarán con la secuencia de escape  - sección 2.4 (p.14f.) Con los juegos de caracteres codificados de China, Japón, Corea del Sur, Corea del Norte y Taiwán (ISO / IEC)
  • Estándares y sistemas de codificación de conjuntos de caracteres chinos, japoneses y coreanos