Hispanopedia Wiki
Articulo de referencia

ISO/IEC 2022

La norma ISO/IEC 2022 Tecnología de la información: estructura de códigos de caracteres y técnicas de extensión es una norma ISO / IEC en el campo de la codificación de caracter...

Hispanopedia WikiContenido en espanolLectura gratuita

La norma ISO/IEC 2022 Tecnología de la información: estructura de códigos de caracteres y técnicas de extensión es una norma ISO / IEC en el campo de la codificación de caracteres . Es equivalente a la norma ECMA-35 de la ECMA , [1] [2] a la norma ANSI X3.41 [3] y a la norma industrial japonesa JIS X 0202. Se originó en 1971 y fue revisada por última vez en 1994. [4]

La norma ISO 2022 especifica una estructura general a la que pueden ajustarse las codificaciones de caracteres, dedicando rangos particulares de bytes ( 0x 00–1F y 0x7F–9F) que se utilizarán para códigos de control no imprimibles [5] para formateo e instrucciones en banda (como saltos de línea o instrucciones de formato para terminales de texto ), en lugar de caracteres gráficos . También especifica una sintaxis para secuencias de escape, secuencias de múltiples bytes que comienzan con el código de control ESC , que también se pueden utilizar para instrucciones en banda. [6] Los conjuntos específicos de códigos de control y secuencias de escape diseñados para usarse con la norma ISO 2022 incluyen la norma ISO/IEC 6429 , partes de la cual se implementan mediante ANSI.SYS y emuladores de terminal .

La propia ISO 2022 también define códigos de control particulares y secuencias de escape que se pueden utilizar para cambiar entre diferentes conjuntos de caracteres codificados (por ejemplo, entre ASCII y el japonés JIS X 0208 ) de modo de utilizar varios en un solo documento, [7] combinándolos de manera efectiva en una única codificación con estado (una característica menos importante desde la llegada de Unicode ). Está diseñada para ser utilizable tanto en entornos de 8 bits como de 7 bits (aquellos en los que solo se pueden utilizar siete bits en un byte, como el correo electrónico sin 8BITMIME ). [8]

Codificaciones y conformidad

El conjunto de caracteres ASCII es compatible con el alfabeto latino básico ISO (equivalente al alfabeto inglés ) y no proporciona un buen soporte para idiomas que utilizan letras adicionales o que utilizan un sistema de escritura completamente diferente. Otros sistemas de escritura con relativamente pocos caracteres, como el griego , el cirílico , el árabe o el hebreo , así como formas de la escritura latina que utilizan diacríticos o letras ausentes del alfabeto latino básico ISO, se han representado históricamente en computadoras personales con diferentes codificaciones ASCII extendidas de 8 bits y un solo byte , que siguen al ASCII cuando el bit más significativo es 0 (es decir, bytes 0x00–7F, cuando se representan en hexadecimal ), e incluyen caracteres adicionales para un bit más significativo de 1 (es decir, bytes 0x80–FF). Algunas de ellas, como la serie ISO 8859 , cumplen con la norma ISO 2022, [9] [10] mientras que otras, como la página de códigos DOS 437 , no lo hacen, generalmente debido a que no reservan los bytes 0x80–9F para los códigos de control.

Ciertos idiomas del este de Asia , específicamente el chino , japonés y coreano (colectivamente " CJK "), se escriben utilizando muchos más caracteres que el máximo de 256 que se puede representar en un solo byte, y se representaron por primera vez en computadoras con codificaciones de doble byte específicas del idioma o codificaciones de ancho variable ; algunas de estas (como la codificación de chino simplificado GB 2312 ) cumplen con ISO 2022 , mientras que otras (como la codificación de chino tradicional Big5 ) no. Los códigos de control en ISO 2022 siempre se representan con un solo byte, independientemente del número de bytes utilizados para caracteres gráficos. Las codificaciones CJK utilizadas en entornos de 7 bits que utilizan mecanismos ISO 2022 para cambiar entre conjuntos de caracteres a menudo reciben nombres que comienzan con "ISO-2022-", más notablemente ISO-2022-JP, aunque algunas otras codificaciones CJK como EUC-JP también hacen uso de mecanismos ISO 2022. [11] [12]

Dado que los primeros 256 puntos de código de Unicode se tomaron de la norma ISO 8859-1 , Unicode hereda el concepto de códigos de control C0 y C1 de la norma ISO 2022, aunque agrega otros caracteres no imprimibles además de los códigos de control de la norma ISO 2022. Sin embargo, los formatos de transformación Unicode, como UTF-8, generalmente se desvían de la estructura de la norma ISO 2022 de varias maneras, entre ellas:

  • Utilizando bytes de 8 bits, pero sin representar los códigos C1 en sus formas de un solo byte especificadas en ISO 2022 (la mayoría de los UTF, con la excepción del obsoleto UTF-1 )
  • Representar todos los caracteres, incluidos los códigos de control, con varios bytes (por ejemplo, UTF-16 , UTF-32 )
  • Mezcla de bytes con el bit más significativo establecido y no establecido dentro de la representación codificada para un único punto de código (por ejemplo, UTF-1, GB 18030 )

Sin embargo, existen secuencias de escape ISO 2022 para cambiar hacia y desde UTF-8 como un "sistema de codificación diferente del de ISO 2022", [13] que son compatibles con ciertos emuladores de terminal como xterm . [14]

Descripción general

Elementos

La norma ISO/IEC 2022 especifica lo siguiente:

  • Una infraestructura de múltiples conjuntos de caracteres con estructuras particulares que pueden incluirse en un único sistema de codificación de caracteres , incluidos múltiples conjuntos de caracteres gráficos y múltiples conjuntos de códigos de control tanto primarios (C0) como secundarios (C1) , [15]
  • Un formato para codificar estos conjuntos, asumiendo que hay 8 bits disponibles por byte, [16]
  • Un formato para codificar estos conjuntos en el mismo sistema de codificación cuando solo hay 7 bits disponibles por byte, [17] y un método para transformar cualquier dato de carácter conforme para que pase a través de dicho entorno de 7 bits, [8]
  • La estructura general de los códigos de escape ANSI , [6] y
  • Formatos de código de escape específicos para identificar conjuntos de caracteres individuales, [7] para anunciar el uso de características o subconjuntos de codificación particulares, [18] y para interactuar con otros sistemas de codificación o cambiar a ellos. [18]

Versiones del código

Una implementación específica no tiene por qué implementar todo el estándar; el nivel de conformidad y los conjuntos de caracteres admitidos están definidos por la implementación. Aunque muchos de los mecanismos definidos por el estándar ISO/IEC 2022 se utilizan con poca frecuencia, varias codificaciones establecidas se basan en un subconjunto del sistema ISO/IEC 2022. [19] En particular, los sistemas de codificación de 7 bits que utilizan mecanismos ISO/IEC 2022 incluyen ISO-2022-JP (o codificación JIS ), que se ha utilizado principalmente en el correo electrónico en idioma japonés . Los sistemas de codificación de 8 bits que cumplen con ISO/IEC 2022 incluyen ISO/IEC 4873 (ECMA-43), que a su vez se ajusta a ISO/IEC 8859 , [9] [10] y el Código Unix extendido , que se utiliza para idiomas del este asiático . [11] Las aplicaciones más especializadas de ISO 2022 incluyen el sistema de codificación MARC-8 utilizado en los registros de biblioteca MARC 21. [3]

Secuencias de escape de designación

Las secuencias de escape para cambiar a determinados conjuntos de caracteres o codificaciones se registran en el registro ISO-IR (excepto las reservadas para uso privado, cuyos significados están definidos por los proveedores o por especificaciones de protocolo como ARIB STD-B24 ) y siguen los patrones definidos en el estándar. Las codificaciones de caracteres que utilizan estas secuencias de escape requieren que los datos se procesen secuencialmente en una dirección hacia adelante, ya que la interpretación correcta de los datos depende de secuencias de escape encontradas previamente.

Los perfiles específicos, como ISO-2022-JP, pueden imponer condiciones adicionales, como que el conjunto de caracteres actual se restablezca a US-ASCII antes del final de una línea. Además, las secuencias de escape que declaran los conjuntos de caracteres nacionales pueden estar ausentes si una codificación específica basada en ISO-2022 lo permite o lo requiere, y dicta que se deben utilizar conjuntos de caracteres nacionales particulares. Por ejemplo, ISO-8859-1 establece que no se necesita ninguna secuencia de escape definitoria.

Caracteres multibyte

Para representar conjuntos de caracteres grandes, ISO/IEC 2022 se basa en la propiedad de ISO/IEC 646 de que una representación de caracteres de siete bits normalmente podrá representar 94 caracteres gráficos (imprimibles) (además de espacio y 33 caracteres de control); si solo se excluyen los códigos de control C0 (definidos de forma restringida), esto se puede ampliar a 96 caracteres. Usando dos bytes, es posible representar hasta 8.836 (94×94) caracteres; y, usando tres bytes, hasta 830.584 (94×94×94) caracteres. Aunque el estándar lo define, ningún conjunto de caracteres registrado usa tres bytes (aunque el G2 no registrado de EUC-TW lo hace, al igual que el CCCII no registrado de manera similar ).

En el caso de los conjuntos de caracteres de dos bytes, el punto de código de cada carácter se especifica normalmente en la denominada forma de celda de fila o kuten [a] , que comprende dos números entre 1 y 94 inclusive, que especifican una fila [b] y una celda [c] de ese carácter dentro de la zona. En el caso de un conjunto de tres bytes, se incluye un número de plano [d] adicional al principio. [20] Las secuencias de escape no solo declaran qué conjunto de caracteres se está utilizando, sino también si el conjunto es de un solo byte o de varios bytes (aunque no cuántos bytes utiliza si es de varios bytes), y también si cada byte tiene 94 o 96 valores permitidos.

Estructura del código

Notación y nomenclatura

La codificación ISO/IEC 2022 especifica una asignación de dos capas entre los códigos de caracteres y los caracteres mostrados. Las secuencias de escape permiten que cualquiera de un amplio registro de conjuntos de caracteres gráficos se "designe" [21] en uno de los cuatro conjuntos de trabajo, denominados G0 a G3, y las secuencias de control más cortas especifican el conjunto de trabajo que se "invoca" [22] para interpretar los bytes en la secuencia.

Los valores de byte de codificación ("combinaciones de bits") a menudo se dan en notación de línea de columna , donde dos números decimales en el rango 00-15 (cada uno correspondiente a un solo dígito hexadecimal) están separados por una barra. [23] Por lo tanto, por ejemplo, los códigos 2/0 (0x20) a 2/15 (0x2F) inclusive pueden denominarse "columna 02". Esta es la notación utilizada en el propio estándar ISO/IEC 2022 / ECMA-35. [24] Se pueden describir en otro lugar utilizando hexadecimal , como se utiliza a menudo en este artículo, o utilizando los caracteres ASCII correspondientes, [25] aunque las secuencias de escape se definen en realidad en términos de valores de byte, y el gráfico asignado a ese valor de byte se puede alterar sin afectar la secuencia de control.

Los valores de bytes del rango gráfico ASCII de 7 bits (hexadecimal 0x20–0x7F), que se encuentran en el lado izquierdo de una tabla de códigos de caracteres, se denominan códigos "GL" (donde "GL" significa "gráficos a la izquierda"), mientras que los bytes del rango "ASCII alto" (0xA0–0xFF), si están disponibles (es decir, en un entorno de 8 bits), se denominan códigos "GR" ("gráficos a la derecha") . [5] Los términos "CL" (0x00–0x1F) y "CR" (0x80–0x9F) se definen para los rangos de control, pero el rango CL siempre invoca los controles primarios (C0), mientras que el rango CR siempre invoca los controles secundarios (C1) o no se utiliza. [5]

Caracteres codificados fijos

El carácter de borrado DEL (0x7F), el carácter de escape ESC (0x1B) y el carácter de espacio SP (0x20) se designan como caracteres codificados "fijos" [26] y siempre están disponibles cuando se invoca G0 sobre GL, independientemente de qué conjuntos de caracteres se designen. Es posible que no se incluyan en conjuntos de caracteres gráficos, aunque sí pueden incluirse otros tamaños o tipos de caracteres de espacio en blanco . [27]

Sintaxis general de secuencias de escape

Las secuencias que utilizan el carácter ESC (escape) toman la forma , donde el carácter ESC es seguido por cero o más bytes intermedios [28] ( I ) del rango 0x20–0x2F, y un byte final [29] ( F ) del rango 0x30–0x7E. [30]ESC [I...] F

El primer byte I , o su ausencia, determina el tipo de secuencia de escape; podría, por ejemplo, designar un conjunto de trabajo o denotar una única función de control. En todos los tipos de secuencias de escape, los bytes F en el rango 0x30–0x3F están reservados para usos privados no registrados definidos por acuerdo previo entre las partes. [31]

Las funciones de control de algunos conjuntos pueden hacer uso de bytes adicionales después de la secuencia de escape propiamente dicha. Por ejemplo, la función de control ISO 6429 " Introductor de secuencia de control ", que se puede representar mediante una secuencia de escape, va seguida de cero o más bytes en el rango 0x30–0x3F, luego cero o más bytes en el rango 0x20–0x2F, luego un solo byte en el rango 0x40–0x7E, denominándose a toda la secuencia "secuencia de control". [32]

Conjuntos de caracteres gráficos

Cada uno de los cuatro conjuntos de trabajo G0 a G3 puede ser un conjunto de 94 caracteres o un conjunto multibyte de 94 n caracteres . Además, G1 a G3 puede ser un conjunto de 96 o 96 n caracteres.

En un conjunto de 96 o 96 n caracteres, los bytes 0x20 a 0x7F cuando se invoca GL, o 0xA0 a 0xFF cuando se invoca GR, se asignan al conjunto y pueden ser utilizados por él. En un conjunto de 94 o 94 n caracteres, los bytes 0x20 y 0x7F no se utilizan. [33] Cuando se invoca un conjunto de 96 o 96 n caracteres en la región GL, los caracteres de espacio y eliminación (códigos 0x20 y 0x7F) no están disponibles hasta que se invoca un conjunto de 94 o 94 n caracteres (como el conjunto G0) en GL. [5] Los conjuntos de 96 caracteres no se pueden designar a G0.

El registro de un conjunto como un conjunto de 96 caracteres no significa necesariamente que los bytes 0x20/A0 y 0x7F/FF estén realmente asignados por el conjunto; algunos ejemplos de conjuntos de caracteres gráficos que están registrados como conjuntos de 96 pero que no utilizan esos bytes incluyen el conjunto G1 de IS 434 , [34] el conjunto de dibujo de cajas de ISO/IEC 10367 , [35] e ISO-IR-164 (un subconjunto del conjunto G1 de ISO-8859-8 con solo las letras, utilizado por CCITT ). [36]

Combinando caracteres

Se espera que los caracteres sean caracteres de espaciado, no caracteres de combinación, a menos que el conjunto gráfico en cuestión especifique lo contrario. [37] La ​​norma ISO 2022 / ECMA-35 también reconoce el uso de los caracteres de control de retroceso y retorno de carro como medios para combinar caracteres que de otro modo serían de espaciado, así como la secuencia CSI "Combinación de caracteres gráficos" (GCC) [37] ( CSI 0x20 (SP) 0x5F (_)). [38]

El uso de la tecla de retroceso y del retorno de carro de esta manera está permitido por la norma ISO/IEC 646, pero prohibido por la norma ISO/IEC 4873 / ECMA-43 [39] y por la norma ISO/IEC 8859 [ 40] [41], sobre la base de que deja indefinido el repertorio de caracteres gráficos. Sin embargo, la norma ISO/IEC 4873 / ECMA-43 permite el uso de la función GCC siempre que la secuencia de caracteres se mantenga igual y simplemente se muestre en un espacio, en lugar de superponerse para formar un carácter con un significado diferente. [42]

Conjuntos de caracteres de control

Los conjuntos de caracteres de control se clasifican como conjuntos de códigos de control "primarios" o "secundarios", [43] también llamados respectivamente conjuntos de códigos de control "C0" y "C1". [44]

Un conjunto de control C0 debe contener el carácter de control ESC (escape) en 0x1B [45] (un conjunto C0 que contiene solo ESC se registra como ISO-IR-104), [46] mientras que un conjunto de control C1 puede no contener el control de escape en absoluto. [33] Por lo tanto, son registros completamente separados, siendo un conjunto C0 solo un conjunto C0 y un conjunto C1 solo un conjunto C1. [44]

Si los códigos del conjunto C0 de ISO 6429 / ECMA-48, es decir, los códigos de control ASCII , aparecen en el conjunto C0, se requiere que aparezcan en sus ubicaciones ISO 6429 / ECMA-48. [45] La inclusión de caracteres de control de transmisión en el conjunto C0, además de los diez incluidos por ISO 6429 / ECMA-48 (a saber, SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN y ETB), [47] o la inclusión de cualquiera de esos diez en el conjunto C1, también está prohibida por la norma ISO/IEC 2022 / ECMA-35. [45] [33]

Un conjunto de control C0 se invoca en el rango CL 0x00 a 0x1F, [48] mientras que una función de control C1 se puede invocar en el rango CR 0x80 a 0x9F (en un entorno de 8 bits) o mediante secuencias de escape (en un entorno de 7 bits u 8 bits), [43] pero no ambos. El estilo de invocación C1 que se utiliza debe especificarse en la definición de la versión del código. [49] Por ejemplo, ISO/IEC 4873 especifica bytes CR para los controles C1 que utiliza (SS2 y SS3). [50] Si es necesario, se puede comunicar qué invocación se utiliza mediante secuencias de anunciador.

En el último caso, se invocan funciones de control individuales del conjunto de códigos de control C1 utilizando secuencias de escape de "tipo Fe", [33] es decir, aquellas en las que el carácter de control ESC va seguido de un byte de las columnas 04 o 05 (es decir, ESC 0x40 (@)hasta ESC 0x5F (_)). [51]

Otras funciones de control

Se asignan funciones de control adicionales a las secuencias de escape de "tipo Fs" (en el rango ESC 0x60 (`)hasta ESC 0x7E (~)); estas tienen significados asignados permanentemente en lugar de depender de las designaciones C0 o C1. [51] [52] El registro de funciones de control para secuencias de tipo "Fs" debe ser aprobado por ISO/IEC JTC 1/SC 2. [ 52] Se pueden registrar otras funciones de control individuales para secuencias de escape de tipo "3Ft" (en el rango hasta ), [53] aunque actualmente no se asignan secuencias "3Ft" (a partir de 2019). [54] Algunas de estas se especifican en ECMA-35 (ISO 2022 / ANSI X3.41), otras en ECMA-48 (ISO 6429 / ANSI X3.64). [55] ECMA-48 se refiere a estas como "funciones de control independientes". [56]ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

Las secuencias de escape del tipo "Fp" ( ESC 0x30 (0)hasta ESC 0x3F (?)) o del tipo "3Fp" ( hasta ) están reservadas para códigos de control de uso privado único, mediante acuerdo previo entre las partes. [58] Varias de estas secuencias de ambos tipos son utilizadas por terminales DEC como el VT100 y, por lo tanto, son compatibles con emuladores de terminal . [14]ESC 0x23 (#) [I...] 0x30 (0)ESC 0x23 (#) [I...] 0x3F (?)

Funciones de cambio

Por defecto, los códigos GL especifican caracteres G0 y los códigos GR (cuando están disponibles) especifican caracteres G1; esto puede especificarse de otra manera mediante un acuerdo previo. El conjunto invocado sobre cada área también puede modificarse con códigos de control denominados turnos, como se muestra en la tabla siguiente. [59]

Un código de 8 bits puede tener códigos GR que especifiquen caracteres G1, es decir, con su código de 7 bits correspondiente que utilice Shift In y Shift Out para cambiar entre los conjuntos (por ejemplo, JIS X 0201 ), [60] aunque algunos, en cambio, tienen códigos GR que especifican caracteres G2, con el código de 7 bits correspondiente que utiliza un código de un solo cambio para acceder al segundo conjunto (por ejemplo, T.51 ). [61]

Los códigos que se muestran en la tabla siguiente son las codificaciones más comunes de estos códigos de control, conforme a la norma ISO/IEC 6429. Los cambios LS2, LS3, LS1R, LS2R y LS3R se registran como funciones de control individuales y siempre se codifican como las secuencias de escape que se enumeran a continuación, [54] mientras que los demás forman parte de un conjunto de códigos de control C0 o C1 (como se muestra a continuación, SI (LS0) y SO (LS1) son controles C0 y SS2 y SS3 son controles C1), lo que significa que su codificación y disponibilidad pueden variar según los conjuntos de control que se designen: deben estar presentes en los conjuntos de control designados si se utiliza su funcionalidad. [48] [49] Los propios controles C1, como se mencionó anteriormente, pueden representarse utilizando secuencias de escape o bytes de 8 bits, pero no ambos.

Existen codificaciones alternativas de los cambios simples como códigos de control C0 en ciertos conjuntos de códigos de control. Por ejemplo, SS2 y SS3 suelen estar disponibles en 0x19 y 0x1D respectivamente en T.51 [61] y T.61 . [62] Actualmente, ISO/IEC 2022 / ECMA-35 recomienda esta codificación para aplicaciones que requieren representaciones de un solo byte de 7 bits de SS2 y SS3, [63] y también se puede utilizar solo para SS2, [64] aunque también existen conjuntos de códigos más antiguos con SS2 en 0x1C, [65] [66] [67] y se mencionaron como tales en una edición anterior de la norma. [68] La codificación 0x8E y 0x8F de los cambios simples que se muestra a continuación es obligatoria para los niveles 2 y 3 de ISO/IEC 4873. [69]

Aunque oficialmente se consideran códigos de cambio y se los nombra en consecuencia, los códigos de cambio simple no siempre se ven como cambios, [12] y pueden verse simplemente como bytes de prefijo (es decir, los primeros bytes en una secuencia de múltiples bytes), [11] ya que no requieren que el codificador mantenga el conjunto actualmente activo como estado , a diferencia de los códigos de cambio de bloqueo. En entornos de 8 bits, se puede usar GL o GR, pero no ambos, como el área de cambio simple. Esto se debe especificar en la definición de la versión del código. [72] Por ejemplo, ISO/IEC 4873 especifica GL, mientras que EUC empaquetado especifica GR. En entornos de 7 bits, solo GL se usa como el área de cambio simple. [74] [75] Si es necesario, se puede comunicar qué área de cambio simple se usa usando secuencias de anunciador.

Los nombres "desplazamiento cero con bloqueo" (LS0) y "desplazamiento uno con bloqueo" (LS1) hacen referencia al mismo par de caracteres de control C0 (0x0F y 0x0E) que los nombres "desplazamiento hacia dentro" (SI) y "desplazamiento hacia fuera" (SO). Sin embargo, el estándar se refiere a ellos como LS0 y LS1 cuando se utilizan en entornos de 8 bits y como SI y SO cuando se utilizan en entornos de 7 bits. [59]

La norma ISO/IEC 2022 / ECMA-35 permite, pero desaconseja, invocar G1, G2 o G3 tanto en GL como en GR simultáneamente. [76]

Registro de conjuntos de códigos gráficos y de control

El registro internacional ISO de conjuntos de caracteres codificados para su uso con secuencias de escape (ISO-IR) enumera conjuntos de caracteres gráficos, conjuntos de códigos de control, códigos de control individuales, etc., que se han registrado para su uso con ISO/IEC 2022. El procedimiento para registrar códigos y conjuntos con el registro ISO-IR está especificado por ISO/IEC 2375. Cada registro recibe una secuencia de escape única y un número de entrada de registro único para identificarlo. [77] [78] Por ejemplo, el conjunto de caracteres CCITT para chino simplificado se conoce como ISO-IR-165 .

El registro de conjuntos de caracteres codificados en el registro ISO-IR identifica los documentos que especifican el conjunto de caracteres o la función de control asociada con una secuencia de escape de uso no privado ISO/IEC 2022. Puede tratarse de un documento estándar; sin embargo, el registro no crea un nuevo estándar ISO, no compromete a la ISO o a la IEC a adoptarlo como estándar internacional y no compromete a la ISO o a la IEC a añadir ninguno de sus caracteres al Conjunto de caracteres codificados universales . [79]

Las secuencias de escape registradas ISO-IR también se utilizan encapsuladas en un Identificador Público Formal para identificar conjuntos de caracteres utilizados para referencias de caracteres numéricos en SGML (ISO 8879). Por ejemplo, la cadena ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0se puede utilizar para identificar la Versión de Referencia Internacional de ISO 646 -1983, [80] y la especificación HTMLISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6 4.01 se utiliza para identificar Unicode. [81] La representación textual de la secuencia de escape, incluida en el tercer elemento del FPI, será reconocida por las implementaciones de SGML para los conjuntos de caracteres admitidos. [80]

Designaciones de conjuntos de caracteres

Las secuencias de escape para designar conjuntos de caracteres toman la forma . Como se mencionó anteriormente, los bytes intermedios ( I ) son del rango 0x20–0x2F, y el byte final ( F ) es del rango 0x30–0x7E. El primer byte I (o, para un conjunto de varios bytes, los primeros dos) identifica el tipo de conjunto de caracteres y el conjunto de trabajo al que se va a designar, mientras que el byte F (y cualquier byte I adicional ) identifica el conjunto de caracteres en sí, tal como se asigna en el registro ISO-IR (o, para las secuencias de escape de uso privado, por acuerdo previo). ESC I [I...] F

Se pueden agregar bytes I adicionales antes del byte F para ampliar el rango del byte F. Esto actualmente solo se usa con conjuntos de 94 caracteres, donde se han asignado códigos de la forma. [82] En el otro extremo, no se han registrado conjuntos de 96 multibyte, por lo que las secuencias a continuación son estrictamente teóricas. ESC ( ! F

Al igual que con otros tipos de secuencias de escape, el rango 0x30–0x3F está reservado para bytes F de uso privado, [31] en este caso para definiciones de conjuntos de caracteres de uso privado (que pueden incluir conjuntos no registrados definidos por protocolos como ARIB STD-B24 [83] o MARC-8 , [3] o conjuntos específicos del proveedor como DEC Special Graphics ). [84] Sin embargo, en una secuencia de designación de conjunto gráfico, si el segundo byte I (para un conjunto de un solo byte) o el tercer byte I (para un conjunto de doble byte) es 0x20 (espacio), el conjunto denotado es un " conjunto de caracteres dinámicamente redefinible " (DRCS) definido por acuerdo previo, [85] que también se considera de uso privado. [31] Un conjunto gráfico que se considera un DRCS implica que representa una fuente de glifos exactos, en lugar de un conjunto de caracteres abstractos. [86] La manera en que se transmiten, asignan y gestionan los conjuntos DRCS y las fuentes asociadas no está estipulada por la propia norma ISO/IEC 2022 / ECMA-35, aunque recomienda asignarlos secuencialmente comenzando con el byte F 0x40 ( @); [87] sin embargo, una manera de transmitir fuentes DRCS está definida dentro de algunos protocolos de telecomunicaciones como World System Teletext . [88]

También hay tres casos especiales para códigos multibyte. Las secuencias de códigos ESC $ @, ESC $ A, y ESC $ Bse registraron cuando la versión contemporánea del estándar permitía conjuntos multibyte sólo en G0, por lo que deben aceptarse en lugar de las secuencias ESC $ ( @hasta ESC $ ( Bpara designar el conjunto de caracteres G0. [89]

Existen características adicionales (raramente utilizadas) para cambiar los conjuntos de caracteres de control, pero se trata de una búsqueda de un solo nivel, ya que (como se indicó anteriormente) el conjunto C0 siempre se invoca sobre CL, y el conjunto C1 siempre se invoca sobre CR o mediante el uso de códigos de escape. Como se indicó anteriormente, se requiere que cualquier conjunto de caracteres C0 incluya el carácter ESC en la posición 0x1B, de modo que sean posibles más cambios. Las secuencias de designación del conjunto de control (a diferencia de las del conjunto gráfico) también se pueden utilizar desde dentro de ISO/IEC 10646 (UCS/Unicode), en contextos donde sea apropiado procesar códigos de escape ANSI , siempre que cada byte de la secuencia se rellene hasta el tamaño de la unidad de código de la codificación. [90]

A continuación se muestra una tabla de bytes de secuencia de escape I y la designación u otra función que realizan. [91]

Tenga en cuenta que el registro de bytes F es independiente para los diferentes tipos. El conjunto gráfico de 94 caracteres designado por ESC ( Athrough ESC + Ano está relacionado de ninguna manera con el conjunto de 96 caracteres designado por ESC - Athrough ESC / A. Y ninguno de ellos está relacionado con el conjunto de 94 n caracteres designado por ESC $ ( Athrough ESC $ + A, y así sucesivamente; los bytes finales deben interpretarse en contexto. (De hecho, sin ningún byte intermedio, ESC Aes una forma de especificar el código de control C1 0x81).

Tenga en cuenta también que los conjuntos de caracteres de control C0 y C1 son independientes; el conjunto de caracteres de control C0 designado por ESC ! A(que resulta ser el conjunto de control NATS para la transmisión de texto de periódico) no es el mismo que el conjunto de caracteres de control C1 designado por ESC " A(el conjunto de control de atributos CCITT para Videotex ).

Interacción con otros sistemas de codificación

La norma también define una forma de especificar sistemas de codificación que no siguen su propia estructura.

También se define una secuencia para volver a ISO/IEC 2022; los registros que admiten esta secuencia tal como está codificada en ISO/IEC 2022 comprenden (a partir de 2019) varios formatos de Videotex , UTF-8 y UTF-1 . [99] Se incluye un segundo byte I de 0x2F ( /) en las secuencias de designación de códigos que no utilizan esa secuencia de bytes para volver a ISO 2022; pueden tener sus propios medios para volver a ISO 2022 (como una secuencia diferente o rellenada) o ninguno en absoluto. [100] Todos los registros existentes de este último tipo (a partir de 2019) son datos sin procesar transparentes, formatos Unicode/UCS o subconjuntos de los mismos. [101]

De particular interés son las secuencias que cambian a formatos ISO/IEC 10646 ( Unicode ) que no siguen la estructura ISO/IEC 2022. Estas incluyen UTF-8 (que no reserva el rango 0x80–0x9F para caracteres de control), su predecesor UTF-1 (que mezcla bytes GR y GL en códigos multibyte) y UTF-16 y UTF-32 (que utilizan unidades de codificación más amplias). [99] [101]

También se registraron varios códigos para subconjuntos (niveles 1 y 2) de UTF-8, UTF-16 y UTF-32, así como para tres niveles de UCS-2 . [101] Sin embargo, los únicos códigos especificados actualmente por ISO/IEC 10646 son los códigos de nivel 3 para UTF-8, UTF-16 y UTF-32 y el código de nivel no especificado para UTF-8, y el resto se enumeran como obsoletos. [103] ISO/IEC 10646 estipula que los formatos big-endian de UTF-16 y UTF-32 se designan por sus secuencias de escape. [104]

De las secuencias que cambian a UTF-8, ESC % Gla que soporta, por ejemplo, xterm . [14]

Aunque se permite el uso de una variante de la secuencia de retorno estándar de UTF-16 y UTF-32, los bytes de la secuencia de escape deben rellenarse hasta el tamaño de la unidad de código de la codificación (es decir, 001B 0025 0040para UTF-16), es decir, la codificación de la secuencia de retorno estándar no se ajusta exactamente a ISO/IEC 2022. Por este motivo, las designaciones para UTF-16 y UTF-32 utilizan una sintaxis sin retorno estándar. [107]

Para especificar codificaciones por etiquetas, el formato de texto compuesto del Consorcio X define cinco secuencias DOCS de uso privado. [108]

Anuncios de estructura de código

La secuencia "anuncio de estructura de código" ( ) se utiliza para anunciar una estructura de código específica o un grupo específico de funciones ISO 2022 que se utilizan en una versión de código particular. Aunque los anuncios se pueden combinar, la norma prohíbe ciertas combinaciones contradictorias (en concreto, el uso de anuncios de cambio de bloqueo 16-23 con anuncios 1, 3 y 4), así como el uso de anuncios adicionales sobre los anuncios de nivel ISO/IEC 4873 12-14 [92] (que especifican por completo las características estructurales permitidas). Las secuencias de anuncios son las siguientes: ESC SP (0x20) F

Versiones del código ISO/IEC 2022

(Una captura de pantalla de una versión antigua de Firefox que muestra Big5, GB 2312, GBK, GB 18030, HZ, ISO-2022-CN, Big5-HKSCS, EUC-TW, EUC-JP, ISO-2022-JP, Shift_JIS, EUC-KR, UHC, Johab e ISO-2022-KR como codificaciones disponibles en el submenú CJK).
Varias codificaciones ISO 2022 y otras codificaciones CJK admitidas por Mozilla Firefox a partir de 2004. (Esta compatibilidad se ha reducido en versiones posteriores para evitar ciertos ataques de secuencias de comandos entre sitios ).

Las RFC de IETF definen seis versiones de código ISO 2022 de 7 bits (ISO-2022-CN, ISO-2022-CN-EXT, ISO-2022-JP, ISO-2022-JP-1, ISO-2022-JP-2 e ISO-2022-KR) , de las cuales ISO-2022-JP e ISO-2022-KR se han utilizado ampliamente en el pasado. [109] Los proveedores definen varias otras variantes, incluido IBM . [110] Aunque UTF-8 es la codificación preferida en HTML5 , el contenido heredado en ISO-2022-JP sigue estando lo suficientemente extendido como para que el estándar de codificación WHATWG conserve el soporte para él, [111] en contraste con la asignación de ISO-2022-KR, ISO-2022-CN e ISO-2022-CN-EXT [112] completamente al carácter de reemplazo , [113] debido a preocupaciones sobre ataques de inyección de código como secuencias de comandos entre sitios . [111] [113]

Las versiones de código de 8 bits incluyen el Código Unix Extendido . [11] [12] Las codificaciones ISO/IEC 8859 también siguen la ISO 2022, en un subconjunto estipulado en ISO/IEC 4873. [9] [10]

Versiones de correo electrónico en japonés

ISO-2022-JP

ISO-2022-JP es una codificación muy utilizada para el japonés, en particular enel correo electrónico. Se introdujo para su uso en la red JUNET y posteriormente se codificó enIETF RFC1468, de 1993.[114]Tiene una ventaja sobre otrascodificaciones para el japonésen el sentido de que no requierelimpia de 8 bits.Microsoft la denominapágina de códigos 50220.[115]Comienza en ASCII e incluye las siguientes secuencias de escape:

  • ESC ( Bpara cambiar a ASCII (1 byte por carácter)
  • ESC ( Jpara cambiar al conjunto romano JIS X 0201-1976 (ISO/IEC 646:JP) (1 byte por carácter)
  • ESC $ @para cambiar a JIS X 0208-1978 (2 bytes por carácter)
  • ESC $ Bpara cambiar a JIS X 0208-1983 (2 bytes por carácter)

Se permite el uso de los dos caracteres añadidos en JIS X 0208-1990, pero sin incluir la secuencia IRR, es decir, utilizando la misma secuencia de escape que JIS X 0208-1983. [114] Además, debido a que se registraron antes de designar conjuntos de múltiples bytes excepto que era posible G0, los escapes para JIS X 0208 no incluyen el segundo byte I. [89( ]

El RFC señala que algunos sistemas existentes no distinguían ESC ( Bde ESC ( J, o no distinguían ESC $ @de ESC $ B, pero estipula que las secuencias de escape no deberían ser cambiadas por sistemas que simplemente retransmiten mensajes como correos electrónicos. [114] El estándar de codificación WHATWG al que hace referencia HTML5 maneja ESC ( By ESC ( Jde forma distinta, pero trata ESC $ @lo mismo que ESC $ Bal decodificar, y utiliza solo ESC $ Bpara JIS X 0208 al codificar. [116] El RFC también señala que algunos sistemas anteriores habían hecho un uso erróneo de la secuencia ESC ( Hpara cambiar de JIS X 0208, que en realidad está registrado para ISO-IR-11 (una variante sueca de ISO 646 y World System Teletext ). [114] [i]

Versiones con katakana de ancho medio

El uso de ESC ( Ipara cambiar al conjunto JIS X 0201-1976 Kana (1 byte por carácter) no es parte del perfil ISO-2022-JP, [114] pero también se usa a veces. Python lo permite en una variante que etiqueta ISO-2022-JP-EXT (que también incorpora JIS X 0212 como se describe a continuación, completando la cobertura de EUC-JP ); [117] [118] esto es cercano tanto en nombre como en estructura a una codificación denotada ISO-2022-JPext por DEC , que además agrega una región definida por el usuario de dos bytes a la que se accede con ESC $ ( 0para completar la cobertura de Super DEC Kanji . [119] La variante WHATWG/HTML5 permite decodificar katakana JIS X 0201 en la entrada ISO-2022-JP, pero convierte los caracteres a sus equivalentes JIS X 0208 al codificarlos. [116] La página de códigos de Microsoft para ISO-2022-JP con JIS X 0201 kana adicionalmente permitido es Página de códigos 50221. [ 115]

Otras variantes más antiguas conocidas como JIS7 ​​y JIS8 se basan directamente en las codificaciones de 7 y 8 bits definidas por JIS X 0201 y permiten el uso de kana JIS X 0201 de G1 sin secuencias de escape, utilizando Shift Out y Shift In o configurando el octavo bit (invocado por GR), respectivamente. [120] No se utilizan ampliamente; [120] La compatibilidad con JIS X 0208 en JIS X 0201 de 8 bits extendido se logra más comúnmente a través de Shift JIS . La página de códigos de Microsoft para ISO 2022 basada en JIS X 0201 con katakana de un solo byte a través de Shift Out y Shift In es la página de códigos 50222. [115 ]

ISO-2022-JP-2

ISO-2022-JP-2 es una extensión multilingüe de ISO-2022-JP, definida en RFC 1554 (fechada en 1993), que permite las siguientes secuencias de escape además de las de ISO-2022-JP. LasISO/IEC 8859son conjuntos de 96 caracteres que no se pueden asignar a G0 y a los que se accede desde G2 utilizando la forma de secuencia de escape de 7 bits del código de desplazamiento simple SS2:[121]

  • ESC $ Apara cambiar a GB 2312-1980 (2 bytes por carácter)
  • ESC $ ( Cpara cambiar a KS X 1001-1992 (2 bytes por carácter)
  • ESC $ ( Dpara cambiar a JIS X 0212-1990 (2 bytes por carácter)
  • ESC . Apara cambiar a la parte alta de ISO/IEC 8859-1 , conjunto Latin 1 extendido (1 byte por carácter) [designado a G2]
  • ESC . Fpara cambiar a la parte alta de ISO/IEC 8859-7 , conjunto griego básico (1 byte por carácter) [designado a G2]

La norma ISO-2022-JP con la representación ISO-2022-JP-2 de JIS X 0212, pero no las otras extensiones, fue posteriormente denominada ISO-2022-JP-1 por RFC 2237, de 1997. [122]

TCP japonés de IBM

IBM implementa nueve codificaciones de 7 bits basadas en ISO 2022 para japonés, cada una de las cuales utiliza un conjunto diferente de secuencias de escape: IBM-956, IBM-957, IBM-958, IBM-959, IBM-5052, IBM-5053, IBM-5054, IBM-5055 e ISO-2022-JP, que se denominan colectivamente "conjuntos de caracteres codificados japoneses TCP/IP". [123] El CCSID 9148 es el estándar (RFC 1468) ISO-2022-JP. [124]

JIS X 0213

La norma JIS X 0213 , publicada por primera vez en 2000, define una versión actualizada de ISO-2022-JP, sin las extensiones ISO-2022-JP-2, denominada ISO-2022-JP-3 . Las adiciones realizadas por JIS X 0213 en comparación con la norma base JIS X 0208 dieron como resultado que se hiciera un nuevo registro para el plano JIS 1 extendido, mientras que el nuevo plano 2 recibió su propio registro. Las adiciones posteriores al plano 1 en la edición de 2004 de la norma dieron como resultado que se añadiera un registro adicional a una revisión posterior del perfil, denominada ISO-2022-JP-2004 . Además de los códigos de designación básicos ISO-2022-JP, se reconocen las siguientes designaciones:

  • ESC ( Ipara cambiar al conjunto Kana JIS X 0201-1976 (1 byte por carácter)
  • ESC $ ( Opara cambiar al plano 1 JIS X 0213-2000 (2 bytes por carácter)
  • ESC $ ( Ppara cambiar a JIS X 0213-2000 Plano 2 (2 bytes por carácter)
  • ESC $ ( Qpara cambiar a JIS X 0213-2004 Plano 1 (2 bytes por carácter, solo ISO-2022-JP-2004)

Otras versiones de 7 bits

La norma ISO-2022-KR se define en el RFC 1557, de 1993.[133]Codifica ASCII y el código coreano de doble byteKS X 1001-1992,[134][135]anteriormente denominado KS C 5601-1987. A diferencia de la norma ISO-2022-JP-2, utiliza loscaracteres Shift Out y Shift Inpara cambiar entre ellos, después de incluirlosESC $ ) Cuna vez al comienzo de una línea para designar KS X 1001 a G1.[133]

ISO-2022-CN yLas ISO-2022-CN-EXT se definen en el RFC 1922, de 1996. Son codificaciones de 7 bits que utilizan tanto las funciones Shift Out como Shift In (para cambiar entre G0 y G1), y las formas de código de escape de 7 bits de las funciones de cambio simple SS2 y SS3 (para acceder a G2 y G3).[136]Admiten los conjuntos de caracteresGB 2312(parachino simplificado) yCNS 11643(parachino tradicional).

El perfil básico ISO-2022-CN utiliza ASCII como su conjunto G0 (desplazamiento hacia adentro), y también incluye GB 2312 y los dos primeros planos de CNS 11643 (debido a que estos dos planos son suficientes para representar todos los caracteres chinos tradicionales del Big5 común , al que el RFC proporciona una correspondencia en un apéndice): [136]

  • ESC $ ) Apara cambiar a GB 2312-1980 (2 bytes por carácter) [designado a G1]
  • ESC $ ) Gpara cambiar al plano 1 de CNS 11643-1992 (2 bytes por carácter) [designado a G1]
  • ESC $ * Hpara cambiar al plano 2 de CNS 11643-1992 (2 bytes por carácter) [designado a G2]

El perfil ISO-2022-CN-EXT permite los siguientes conjuntos y planos adicionales. [136]

  • ESC $ ) Epara cambiar a ISO-IR-165 (2 bytes por carácter) [designado a G1]
  • ESC $ + Ipara cambiar al plano 3 de CNS 11643-1992 (2 bytes por carácter) [designado a G3]
  • ESC $ + Jpara cambiar al plano 4 de CNS 11643-1992 (2 bytes por carácter) [designado a G3]
  • ESC $ + Kpara cambiar al plano 5 de CNS 11643-1992 (2 bytes por carácter) [designado a G3]
  • ESC $ + Lpara cambiar al plano 6 de CNS 11643-1992 (2 bytes por carácter) [designado a G3]
  • ESC $ + Mpara cambiar al plano 7 de CNS 11643-1992 (2 bytes por carácter) [designado a G3]

El perfil ISO-2022-CN-EXT enumera además conjuntos gráficos estándar de Guobiao que están permitidos, pero con la condición de que se les asignen secuencias de escape ISO 2022 registradas: [136]

  • GB 12345 en G1
  • GB 7589 o GB 13131 en G2
  • GB 7590 o GB 13132 en G3

El carácter después de ESC(para conjuntos de caracteres de un solo byte) o ESC $(para conjuntos de caracteres de varios bytes) especifica el tipo de conjunto de caracteres y el conjunto de trabajo al que se designa. En los ejemplos anteriores, el carácter ((0x28) designa un conjunto de 94 caracteres para el conjunto de caracteres G0, mientras que ), *o +(0x29–0x2B) designa los conjuntos de caracteres G1–G3.

ISO-2022-KR e ISO-2022-CN se utilizan con menos frecuencia que ISO-2022-JP y, a veces, no se admiten deliberadamente debido a problemas de seguridad. En particular, el estándar de codificación WHATWG utilizado por HTML5 asigna ISO-2022-KR, ISO-2022-CN e ISO-2022-CN-EXT (así como HZ-GB-2312 ) al decodificador de "reemplazo", [112] que asigna toda la entrada al carácter de reemplazo (�), para evitar ciertos ataques de secuencias de comandos entre sitios y otros ataques relacionados, que utilizan una diferencia en el soporte de codificación entre el cliente y el servidor. [113] Aunque la misma preocupación de seguridad (permitir que las secuencias de bytes ASCII se interpreten de manera diferente) también se aplica a ISO-2022-JP y UTF-16 , no se les pudo dar este tratamiento debido a que se utilizan con mucha más frecuencia en el contenido implementado. [111]

En abril de 2024, se encontró una falla de seguridad [137] en la implementación de ISO-2022-CN-EXT en glibc , lo que llevó a recomendaciones para deshabilitar la codificación por completo en los sistemas Linux. [138]

ISO/IEC 4873

Relación entre las ediciones y niveles de ECMA-43 (ISO/IEC 4873) y EUC.

Un subconjunto de la norma ISO 2022 aplicado a codificaciones de un solo byte de 8 bits se define en la norma ISO/IEC 4873 , también publicada por Ecma International como ECMA-43. La norma ISO/IEC 8859 define códigos de 8 bits para el nivel 1 de la norma ISO/IEC 4873 (o ECMA-43). [9] [10]

La norma ISO/IEC 4873 / ECMA-43 define tres niveles de codificación: [139]

  • Nivel 1, que incluye un conjunto C0, el conjunto ASCII G0, un conjunto C1 opcional y un conjunto G1 opcional de un solo byte (94 o ​​96 caracteres). G0 se invoca sobre GL y G1 sobre GR. No se permite el uso de funciones de desplazamiento.
  • Nivel 2, que incluye un conjunto G2 y/o G3 de un solo byte (de 94 o 96 caracteres) además de un conjunto G1 obligatorio. Solo se permiten las funciones de desplazamiento único SS2 y SS3 (es decir, los desplazamientos de bloqueo están prohibidos) y se invocan sobre la región GL (incluidos 0x 20 y 0x7F en el caso de un conjunto de 96). SS2 y SS3 deben estar disponibles en C1 en 0x8E y 0x8F respectivamente. Este conjunto C1 mínimo requerido para ISO 4873 está registrado como ISO-IR-105. [69]
  • Nivel 3, que permite las funciones de bloqueo de cambios GR LS1R, LS2R y LS3R además de los cambios individuales, pero por lo demás tiene las mismas restricciones que el nivel 2.

Las ediciones anteriores de la norma permitían asignaciones no ASCII en el conjunto G0, siempre que se conservaran las posiciones invariantes de ISO/IEC 646 , que las otras posiciones se asignaran a caracteres espaciadores (no combinables), que 0x23 se asignara a £ o # y que 0x24 se asignara a $ o ¤ . [140] Por ejemplo, la codificación de 8 bits de JIS X 0201 es compatible con ediciones anteriores. Esto se modificó posteriormente para especificar por completo el conjunto ISO/IEC 646:1991 IRV / ISO-IR No. 6 (ASCII). [141] [142] [143]

El uso del IRV ISO/IEC 646 (sincronizado con ASCII desde 1991) en el nivel 1 de ISO/IEC 4873 sin C1 o G1 establecido, es decir, utilizando el IRV en un entorno de 8 bits en el que no se utilizan códigos de desplazamiento y el bit alto siempre es cero, se conoce como DV ISO 4873 , donde DV significa "Versión predeterminada". [144]

En los casos en que se encuentran caracteres duplicados en diferentes conjuntos, la edición actual de la norma ISO/IEC 4873 / ECMA-43 solo permite utilizar estos caracteres en el conjunto de trabajo con el número más bajo en el que aparecen. [145] Por ejemplo, si un carácter aparece tanto en el conjunto G1 como en el conjunto G3, debe utilizarse desde el conjunto G1. Sin embargo, se indica que el uso desde otros conjuntos se ha permitido en ediciones anteriores. [143]

La norma ISO/IEC 8859 define codificaciones completas en el nivel 1 de la norma ISO/IEC 4873 y no permite el uso de varias partes de la norma ISO/IEC 8859 juntas. Estipula que la norma ISO/IEC 10367 se debe utilizar en su lugar para los niveles 2 y 3 de la norma ISO/IEC 4873. [9] [10] La norma ISO/IEC 10367:1991 incluye conjuntos G0 y G1 que coinciden con los utilizados en las primeras 9 partes de la norma ISO/IEC 8859 (es decir, los que existían en 1991, cuando se publicó), y algunos conjuntos complementarios. [146]

Las secuencias de escape de designación de conjunto de caracteres se utilizan para identificar o cambiar entre versiones durante el intercambio de información solo si lo requiere un protocolo adicional, en cuyo caso la norma requiere una secuencia anunciadora ISO/IEC 2022 que especifique el nivel ISO/IEC 4873, seguida de un conjunto completo de escapes que especifiquen las designaciones de conjunto de caracteres para C0, C1, G0, G1, G2 y G3 respectivamente (pero omitiendo las designaciones G2 y G3 para el nivel 1), con un byte F de 0x7E que denota un conjunto vacío. Cada nivel ISO/IEC 4873 tiene su propia secuencia anunciadora ISO/IEC 2022, que son las siguientes: [147]

Código Unix extendido

El Código Unix Extendido (EUC) es un sistema de codificación de caracteres de ancho variable de 8 bits utilizado principalmente para japonés , coreano y chino simplificado . Se basa en la norma ISO 2022, y solo los conjuntos de caracteres que se ajustan a la estructura ISO 2022 pueden tener formas EUC. Se pueden representar hasta cuatro conjuntos de caracteres codificados (en G0, G1, G2 y G3). El conjunto G0 se invoca sobre GL, el conjunto G1 se invoca sobre GR y los conjuntos G2 y G3 se invocan (si están presentes) utilizando los desplazamientos simples SS2 y SS3, que se utilizan como bytes CR (es decir, 0x8E y 0x8F respectivamente) y se invocan sobre GR (no GL). [11] No se utilizan códigos de desplazamiento de bloqueo. [12]

El código asignado al conjunto G0 es ASCII, o el conjunto de caracteres ISO 646 nacional del país , como KS-Roman (KS X 1003) o JIS-Roman (la mitad inferior de JIS X 0201 ). [11] Por lo tanto, 0x5C ( barra invertida en US-ASCII) se utiliza para representar un signo de yen en algunas versiones de EUC-JP y un signo de won en algunas versiones de EUC-KR.

G1 se utiliza para un conjunto de caracteres codificados de 94x94 representados 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 (es decir, SS3 más dos bytes), mientras que un solo carácter en EUC-TW puede ocupar hasta cuatro bytes (es decir, SS2 más tres bytes).

El código EUC en sí no hace uso de las secuencias de anunciantes o designaciones de ISO 2022; sin embargo, corresponde a la siguiente secuencia de cuatro secuencias de anunciantes, con significados que se desglosan de la siguiente manera. [148]

Texto compuesto (X11)

El Consorcio X definió un perfil ISO 2022 llamado Texto Compuesto como formato de intercambio en 1989. [149] Este utiliza solo cuatro códigos de control: HT ( ), NL (nueva línea, codificado como LF , ) , ESC ( ) y CSI (en su representación de 8 bits ), [150] con la secuencia CSI SDS ( ) que se utiliza para el control de texto bidireccional. [151] Es un código de 8 bits que utiliza G0 y G1 para GL y GR, y sigue ISO-8859-1 en su estado inicial. [152] Se utilizan los siguientes bytes F: 0x090x0A 0x1B0x9BCSI … ]

Para especificar codificaciones por etiquetas, X11 Compound Text define cinco secuencias DOCS de uso privado: ESC % / 0( 1B 25 2F 30) para codificaciones de longitud variable, y ESC % / 1hasta ESC % / 4para codificaciones de longitud fija que utilizan de uno a cuatro bytes respectivamente. En lugar de utilizar otra secuencia de escape para volver a ISO 2022 , los dos bytes que siguen a la secuencia de escape inicial especifican la longitud restante en bytes, codificada en base 128 utilizando bytes 0x80–FF. La etiqueta de codificación se incluye en ISO 8859-1 antes del texto codificado y termina con STX ( ). [108]0x02

Comparación con otras codificaciones

Ventajas

  • Como toda la gama de codificaciones de caracteres gráficos de ISO/IEC 2022 se puede invocar sobre GL, los glifos disponibles no están significativamente limitados por la incapacidad de representar GR y C1, como en un sistema limitado a codificaciones de 7 bits. Por lo tanto, permite la representación de un gran conjunto de caracteres en un sistema de este tipo. En general, esta compatibilidad de 7 bits no es realmente una ventaja, excepto por la compatibilidad con versiones anteriores de sistemas más antiguos. La gran mayoría de las computadoras modernas utilizan 8 bits para cada byte.
  • En comparación con Unicode, la norma ISO/IEC 2022 evita la unificación Han al utilizar códigos de secuencia para cambiar entre codificaciones discretas para diferentes idiomas del este de Asia. Esto evita los problemas [ cita requerida ] asociados con la unificación, como la dificultad de admitir varios idiomas CJK con sus variantes de caracteres asociadas en un solo documento y fuente.

Desventajas

  • Dado que ISO/IEC 2022 es una codificación con estado, un programa no puede saltar en medio de un bloque de texto para buscar, insertar o eliminar caracteres. Esto hace que la manipulación del texto sea muy engorrosa y lenta en comparación con las codificaciones sin estado. Cualquier salto en medio del texto puede requerir una copia de seguridad a la secuencia de escape anterior antes de que se puedan interpretar los bytes que siguen a la secuencia de escape.
  • Debido a la naturaleza de estado de la norma ISO/IEC 2022, un carácter idéntico y equivalente puede codificarse en diferentes conjuntos de caracteres, que pueden designarse como G0 a G3, que pueden invocarse mediante desplazamientos simples o mediante desplazamientos bloqueados a GL o GR. En consecuencia, los caracteres pueden representarse de múltiples maneras, lo que significa que no es posible comparar de manera confiable dos cadenas visualmente idénticas y equivalentes para determinar su igualdad.
  • Algunos sistemas, como DICOM y varios clientes de correo electrónico, utilizan una variante de ISO-2022 (por ejemplo, "ISO 2022 IR 100" [154] ) además de admitir varias otras codificaciones. [155] Este tipo de variación dificulta la transferencia portátil de texto entre sistemas informáticos.
  • UTF-1 , el formato de transformación Unicode multibyte compatible con la representación de caracteres de control de 8 bits de ISO/IEC 2022, tiene varias desventajas en comparación con UTF-8 , y cambiar desde o hacia otros conjuntos de caracteres, como los que admite ISO/IEC 2022, normalmente no es necesario en los documentos Unicode.
  • Debido a sus secuencias de escape, es posible construir secuencias de bytes de ataque en las que una cadena maliciosa (como cross-site scripting ) se enmascara hasta que se decodifica a Unicode, lo que puede permitirle eludir la desinfección. [156] Por lo tanto, el uso de esta codificación es tratado como sospechoso por las suites de protección contra malware, [157] [ se necesita una mejor fuente ] y los datos ISO 2022 de 7 bits (excepto ISO-2022-JP) se asignan en su totalidad al carácter de reemplazo en HTML5 para evitar ataques. [112] [113] Las versiones de código ISO 2022 de 8 bits restringidas que no usan escapes de designación o códigos de cambio de bloqueo, como Extended Unix Code , no comparten este problema.
  • Concatenation can pose issues. Profiles such as ISO-2022-JP specify that the stream starts in the ASCII state and must end in the ASCII state.[114] This is necessary to ensure that characters in concatenated ISO-2022-JP and/or ASCII streams will be interpreted in the correct set. This has the consequence that if a stream that ends in a multi-byte character is concatenated with one that starts with a multi-byte character, a pair of escape codes are generated switching to ASCII and immediately away from it. However, as stipulated in Unicode Technical Report #36 ("Unicode Security Considerations"), pairs of ISO 2022 escape sequences with no characters between them should generate a replacement character ("�") to prevent them from being used to mask malicious sequences such as cross-site scripting.[158] Implementing this measure, e.g. in Mozilla Thunderbird, has led to interoperability issues, with unexpected "�" characters being generated where two ISO-2022-JP streams have been concatenated.[156]

See also

Footnotes

  1. ^ Japanese: 区点, romanized: kuten; Chinese: 区位; pinyin: qūwèi; Korean: 행렬; Hanja: 行列; RR: haeng-nyeol
  2. ^ Japanese: 区, romanized: ku, lit. 'zone'; Chinese: 区; pinyin: qū; Korean: 행; Hanja: 行; RR: haeng
  3. ^ Japanese: 点, romanized: ten, lit. 'point'; Chinese: 位; pinyin: wèi; lit. 'position'; Korean: 열; Hanja: 列; RR: yeol
  4. ^ Japanese: 面, romanized: men, lit. 'face'
  5. ^ a b Specified for F bytes 0x40 (@), 0x41 (A) and 0x42 (B) only, for historical reasons.[89] Some implementations, such as the SoftBank 2G emoji encoding, use additional escapes of this form for non-ISO-2022-compliant purposes.[96]
  6. ^ Listed by MARC-8.[3] See footnote for ESC , F below for background.
  7. ^ F, adjusted to the range 1-63, indicates which (upwardly compatible) revision of the immediately-following registration is needed, so that old systems know that they are old.[97]
  8. ^ In earlier editions, 96-character sets did not exist, and the escape codes now used for 96-character sets were reserved as space for additional 94-character sets. Accordingly, the ESC 0x1B 0x2C sequence was defined in early editions of the standard as designating further 94-character sets to G0.[98] Since 96-character sets cannot be designated to G0, this first I byte is not used by the current edition of the standard. However, it is still listed by MARC-8.[3]
  9. ^ See also, for instance, Printronix (2012), OKI® Programmer's Reference Manual (PDF), p. 26 for a more recent system which uses ESC ( H to switch to ASCII from a DBCS.

References

  1. ^ ECMA-35 (1994), Brief History
  2. ^ ECMA-35 (1994), p. 51, annex D
  3. ^ a b c d e "Technique 2: Using standard alternate graphic character sets". MARC 21 Specifications for Record Structure, Character Sets, and Exchange Media. Library of Congress. 2007-12-05. Archived from the original on 2020-07-22. Retrieved 2020-07-19.
  4. ^ "ECMA-35: Character code structure and extension techniques (web page)". Ecma International. Archived from the original on 2022-04-25. Retrieved 2022-04-27.
  5. ^ a b c d ECMA-35 (1994), pp. 15–16, chapter 8.1
  6. ^ a b ECMA-35 (1994), chapter 13
  7. ^ a b ECMA-35 (1994), chapters 12, 14
  8. ^ a b ECMA-35 (1994), chapter 11
  9. ^ a b c d e ISO/IEC FDIS 8859-10 (1998), p. 1, chapter 1 ("Scope")
  10. ^ a b c d e ECMA-144 (2000), p. 1, chapter 1 ("Scope")
  11. ^ a b c d e f Lunde (2008), pp. 242–245, Chapter 4 ("Encoding Methods"), section "EUC encoding"
  12. ^ a b c d Lunde (2008), pp. 253–255, Chapter 4 ("Encoding Methods"), section "EUC versus ISO-2022 encodings".
  13. ^ a b ISO-IR-196 (1996)
  14. ^ a b c Moy, Edward; Gildea, Stephen; Dickey, Thomas. "Controls beginning with ESC". XTerm Control Sequences. Archived from the original on 2019-10-10. Retrieved 2019-10-04.
  15. ^ ECMA-35 (1994), chapters 6, 7
  16. ^ ECMA-35 (1994), chapter 8
  17. ^ ECMA-35 (1994), chapter 9
  18. ^ a b ECMA-35 (1994), chapter 15
  19. ^ Lunde (2008), pp. 228–234, Chapter 4 ("Encoding Methods"), section "ISO-2022 encoding"
  20. ^ Lunde (2008), pp. 19–20, Chapter 1 ("CJKV Information Processing Overview"), section "What are Row-Cell and Plane-Row-Cell?"
  21. ^ ECMA-35 (1994), p. 4, definition 4.11
  22. ^ ECMA-35 (1994), p. 5, definition 4.18
  23. ^ See, for instance, ISO-IR-14 (1975), defining the G0 designation of the JIS X 0201 Roman set as ESC 2/8 4/10.
  24. ^ ECMA-35 (1994), p. 5, chapter 5.1
  25. ^ See, for instance, RFC 1468 (1993), defining the G0 designation of the JIS X 0201 Roman set as ESC ( J.
  26. ^ ECMA-35 (1994), p. 7, chapter 6.2
  27. ^ ECMA-35 (1994), p. 10, chapter 6.3.2
  28. ^ ECMA-35 (1994), p. 4, definition 4.17
  29. ^ ECMA-35 (1994), p. 4, definition 4.14
  30. ^ ECMA-35 (1994), p. 28, chapter 13.1
  31. ^ a b c ECMA-35 (1994), p. 33, chapter 13.3.3
  32. ^ ECMA-48 (1991), pp. 24–26, chapter 5.4
  33. ^ a b c d ECMA-35 (1994), p. 11, chapter 6.4.3
  34. ^ ISO-IR-208 (1999)
  35. ^ ISO-IR-155 (1990)
  36. ^ ISO-IR-164 (1992)
  37. ^ a b ECMA-35 (1994), p. 10, chapter 6.3.3
  38. ^ Google Inc. (2014). "ansi.go, line 134". ANSI escape sequence library for Go. Archived from the original on 2022-04-30. Retrieved 2019-09-14.
  39. ^ ECMA-43 (1991), p. 5, chapter 7 ("Specification of the characters of the 8-bit code")
  40. ^ ISO/IEC FDIS 8859-10 (1998), p. 3, chapter 6 ("Specification of the coded character set")
  41. ^ ECMA-144 (2000), p. 3, chapter 6 ("Specification of the coded character set")
  42. ^ ECMA-43 (1991), p. 19, annex C ("Composite graphic characters")
  43. ^ a b ECMA-35 (1994), p. 10, chapter 6.4.1
  44. ^ a b ECMA-35 (1994), p. 11, chapter 6.4.4
  45. ^ a b c ECMA-35 (1994), p. 11, chapter 6.4.2
  46. ^ ISO-IR-104 (1985)
  47. ^ ISO-IR-1 (1975)
  48. ^ a b ECMA-35 (1994), p. 19, chapter 8.5.1
  49. ^ a b ECMA-35 (1994), p. 19, chapter 8.5.2
  50. ^ ECMA-43 (1991), p. 8, chapter 7.6 ("C1 set")
  51. ^ a b ECMA-35 (1994), p. 29, chapter 13.2.1
  52. ^ a b ECMA-35 (1994), p. 12, chapter 6.5.1
  53. ^ ECMA-35 (1994), p. 12, chapter 6.5.2
  54. ^ a b c ISO-IR, p. 19, chapter 2.7 ("Single control functions")
  55. ^ ECMA-35 (1994), p. 12, chapter 6.5.4
  56. ^ ECMA-48 (1991), chapter 5.5
  57. ^ ISO/TC 97/SC 2 (1976-12-30). Reset to Initial State (RIS) (PDF). ITSCJ/IPSJ. ISO-IR-35.{{citation}}: CS1 maint: numeric names: authors list (link)
  58. ^ ECMA-35 (1994), p. 12, chapter 6.5.3
  59. ^ a b ECMA-35 (1994), p. 14, chapter 7.3, table 2
  60. ^ ISO-IR-14 (1975)
  61. ^ a b ITU-T (1995-08-11). Recommendation T.51 (1992) Amendment 1. Archived from the original on 2020-08-02. Retrieved 2019-12-25.
  62. ^ ISO-IR-106 (1985)
  63. ^ ECMA-35 (1994), p. 15, chapter 7.3, note 23
  64. ^ ISO-IR-140 (1987)
  65. ^ ISO-IR-7 (1975)
  66. ^ ISO-IR-26 (1976)
  67. ^ ISO-IR-36 (1977)
  68. ^ ECMA-35 (1980), p. 8, chapter 5.1.7
  69. ^ a b ISO-IR-105 (1985)
  70. ^ a b c d ECMA-35 (1994), p. 17, chapter 8.3.1
  71. ^ a b c d ECMA-35 (1994), p. 23, chapter 9.3.1
  72. ^ a b c ECMA-35 (1994), p. 19, chapter 8.4
  73. ^ a b c ECMA-35 (1994), p. 17, chapter 8.3.2
  74. ^ ECMA-35 (1994), pp. 23–24, chapter 9.4
  75. ^ ECMA-35 (1994), p. 27, chapter 11.1
  76. ^ ECMA-35 (1994), p. 17, chapter 8.3.3
  77. ^ ECMA-35 (1994), p. 47, annex B
  78. ^ ISO-IR, p. 2, chapter 1 ("Introduction")
  79. ^ ISO/IEC 2375 (2003)
  80. ^ a b "Handling of the SGML declaration in SP". SP: an SGML System Conforming to International Standard ISO 8879.
  81. ^ "20: SGML Declaration of HTML 4". HTML 4.01 Specification. W3C.
  82. ^ ISO-IR, p. 10, chapter 2.2 ("94-Character graphic character set with second Intermediate byte")
  83. ^ ARIB STD-B24 (2008), p. 39, part 2, Table 7-3
  84. ^ Mascheck, Sven; Le Breton, Stefan; Hamilton, Richard L. "About the 'alternate linedrawing character set'". ~sven_mascheck/. Archived from the original on 2019-12-29. Retrieved 2020-01-08.
  85. ^ ECMA-35 (1994), p. 36, chapter 14.4
  86. ^ ECMA-35 (1994), p. 36, chapter 14.4.2, note 48
  87. ^ ECMA-35 (1994), p. 36, chapter 14.4.2, note 47
  88. ^ ETS 300 706 (1997), p. 103, chapter 14 ("Dynamically Re-definable Characters")
  89. ^ a b c d e f g h i j k l m n o p q ECMA-35 (1994), pp. 35–36, chapter 14.3.2
  90. ^ ISO/IEC 10646 (2017), pp. 19–20, chapter 12.4 ("Identification of control function set")
  91. ^ ECMA-35 (1994), p. 32, table 5
  92. ^ a b c ECMA-35 (1994), pp. 37–41, chapter 15.2
  93. ^ ECMA-35 (1994), p. 34, chapter 14.2.2
  94. ^ ECMA-35 (1994), p. 34, chapter 14.2.3
  95. ^ Digital. "DECDWL—Double-Width, Single-Height Line". VT510 Video Terminal Programmer Information. Archived from the original on 2020-08-02. Retrieved 2020-01-17.
  96. ^ Kawasaki, Yusuke (2010). "Encode::JP::Emoji::Encoding". Encode-JP-Emoji. Line 268. Archived from the original on 2022-04-30. Retrieved 2020-05-28.
  97. ^ ECMA-35 (1994), pp. 36–37, chapter 14.5
  98. ^ ECMA-35 (1980), pp. 14–15, chapter 5.3.7
  99. ^ a b c d ISO-IR, p. 20, chapter 2.8.1 ("Coding systems with Standard return")
  100. ^ a b c d ECMA-35 (1994), pp. 41–42, chapter 15.4
  101. ^ a b c d e ISO-IR, p. 21, chapter 2.8.2 ("Coding systems without Standard return")
  102. ^ ECMA-35 (1994), p. 41, chapter 15.3
  103. ^ a b c ISO/IEC 10646 (2017), p. 19, chapter 12.2 ("Identification of a UCS encoding scheme")
  104. ^ ISO/IEC 10646 (2017), pp. 18–19, chapter 12.1 ("Purpose and context of identification")
  105. ^ ISO-IR-192 (1996)
  106. ^ ISO-IR-195 (1996)
  107. ^ ISO/IEC 10646 (2017), p. 20, chapter 12.5 ("Identification of the coding system of ISO/IEC 2022")
  108. ^ a b Scheifler (1989), § Non-Standard Character Set Encodings
  109. ^ Lunde (2008), pp. 229–230, Chapter 4 ("Encoding Methods"), section "ISO-2022 encoding" "Those encodings that have been extensively used in the past, or continue to be used today for some purposes, have been highlighted."
  110. ^ a b "Additional Coding-related Required Information". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2015-01-07.
  111. ^ a b c WHATWG Encoding Standard, section 2 ("Security background")
  112. ^ a b c WHATWG Encoding Standard, chapter 4.2 ("Names and labels"), anchor "replacement"
  113. ^ a b c d WHATWG Encoding Standard, section 14.1 ("replacement")
  114. ^ a b c d e f RFC 1468 (1993)
  115. ^ a b c "Code Page Identifiers". Windows Dev Center. Microsoft. Archived from the original on 2019-06-16. Retrieved 2019-09-16.
  116. ^ a b WHATWG Encoding Standard, section 12.2 ("ISO-2022-JP")
  117. ^ Chang, Hye-Shik. "Modules/cjkcodecs/_codecs_iso2022.c, line 1122". cPython source tree. Python Software Foundation. Archived from the original on 2022-04-30. Retrieved 2019-09-15.
  118. ^ "codecs — Codec registry and base classes § Standard Encodings". Python 3.7.4 documentation. Python Software Foundation. Archived from the original on 2019-07-28. Retrieved 2019-09-16.
  119. ^ "2: Codesets and Codeset Conversion". DIGITAL UNIX Technical Reference for Using Japanese Features. Digital Equipment Corporation, Compaq.[dead link]
  120. ^ a b Lunde (2008), pp. 236–238, Chapter 4 ("Encoding Methods"), section "The predecessor of ISO-2022-JP encoding—JIS encoding"
  121. ^ RFC 1554 (1993)
  122. ^ RFC 2237 (1997)
  123. ^ "PQ02042: New Function to Provide C/370 iconv() Support for Japanese ISO-2022-JP". IBM. 2021-01-19. Archived from the original on 2022-01-04. Retrieved 2022-01-04.
  124. ^ a b "CCSID 9148". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  125. ^ "CCSID 956". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-12-02.
  126. ^ "CCSID 957". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-30.
  127. ^ "CCSID 958". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-12-01.
  128. ^ "CCSID 959". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-12-02.
  129. ^ "CCSID 5052". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  130. ^ "CCSID 5053". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  131. ^ "CCSID 5054". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  132. ^ "CCSID 5055". IBM Globalization - Coded Character Set Identifiers. IBM. Archived from the original on 2014-11-29.
  133. ^ a b RFC 1557 (1993)
  134. ^ "KS X 1001:1992" (PDF). Archived (PDF) from the original on 2007-09-26. Retrieved 2007-07-12.
  135. ^ ISO-IR-149 (1988)
  136. ^ a b c d RFC 1922 (1996)
  137. ^ "CVE-2024-2961".
  138. ^ "GLIBC Vulnerability on Servers Serving PHP".
  139. ^ ECMA-43 (1991), pp. 9–10, chapter 8 ("Levels")
  140. ^ ECMA-43 (1985), pp. 7–11, chapter 7.3 ("The G0 set")
  141. ^ ECMA-43 (1991), pp. 6–8, chapter 7.4 ("G0 set")
  142. ^ ECMA-43 (1991), p. 11, chapter 10.3 ("Identification of a version")
  143. ^ a b ECMA-43 (1991), p. 23, annex E ("Main differences between the second edition (1985) and the present (third) edition of this ECMA Standard")
  144. ^ IPTC (1995). The IPTC Recommended Message Format (PDF) (5th ed.). IPTC TEC 7901. Archived (PDF) from the original on 2022-01-25. Retrieved 2020-01-14.
  145. ^ ECMA-43 (1991), pp. 10, chapter 9.2 ("Unique coding of characters")
  146. ^ van Wingen, Johan W (1999). "8. Code Extension, ISO 2022 and 2375, ISO 4873 and 10367". Character sets. Letters, tokens and codes. Terena. Archived from the original on 2020-08-01. Retrieved 2019-10-02.
  147. ^ ECMA-43 (1991), pp. 10–11, chapter 10 ("Identification of version and level")
  148. ^ IBM. "Character Data Representation Architecture (CDRA)". IBM. pp. 157–162. Archived from the original on 2019-06-23. Retrieved 2020-06-18.
  149. ^ Scheifler (1989)
  150. ^ Scheifler (1989), § Control Characters
  151. ^ Scheifler (1989), § Directionality
  152. ^ Scheifler (1989), § Standard Character Set Encodings
  153. ^ Scheifler (1989), § Approved Standard Encodings
  154. ^ "DICOM PS3.2 2016d - Conformance; D.6.2 Character Sets; D.6 Support of Character Sets". Archived from the original on 2020-02-16. Retrieved 2020-05-21.
  155. ^ "DICOM ISO 2022 variation". Archived from the original on 2013-04-30. Retrieved 2009-07-25.
  156. ^ a b Sivonen, Henri (2018-12-17). "(UNSUBMITTED DRAFT) No U+FFFD Generation for Zero-Length ASCII-State Content between ISO-2022-JP Escape Sequences" (PDF). Archived (PDF) from the original on 2019-02-21. Retrieved 2019-02-21.
  157. ^ "935453 - Gather telemetry about HZ and other encodings we might try to remove". Archived from the original on 2017-05-19. Retrieved 2018-06-18.
  158. ^ Davis, Mark; Suignard, Michel (2014-09-19). "3.6.2 Some Output For All Input". Unicode Technical Report #36: Unicode Security Considerations (revision 15). Unicode Consortium. Archived from the original on 2019-02-22. Retrieved 2019-02-21.


Standards and registry indices cited

  • ARIB (2008). ARIB STD-B24: Data Coding and Transmission Specification for Digital Broadcasting (PDF) (ARIB Standard). 5.2-E1. Vol. 1. Archived (PDF) from the original on 2017-07-10. Retrieved 2017-07-10.
  • ECMA (1980). ECMA-35: Extension of the 7-bit Coded Character Set (PDF) (ECMA Standard) (2nd ed.).
  • ECMA (1994). ECMA-35: Character Code Structure and Extension Techniques (PDF) (ECMA Standard) (6th ed.).
  • ECMA (1985). ECMA-43: 8-Bit Coded Character Set Structure and Rules (PDF) (ECMA Standard) (2nd ed.).
  • ECMA (1991). ECMA-43: 8-Bit Coded Character Set Structure and Rules (PDF) (ECMA Standard) (3rd ed.).
  • ECMA (1991). ECMA-48: Control Functions for Coded Character Sets (PDF) (ECMA Standard) (5th ed.).
  • ECMA (2000). ECMA-144: 8-Bit Single-Byte Coded Graphic Character sets: Latin Alphabet No. 6 (PDF) (ECMA Standard) (3rd ed.).
  • European Broadcasting Union (1997). ETS 300 706: Enhanced Teletext specification (PDF) (European Telecommunications Standards). ETSI.
  • ISO/IEC JTC 1/SC 2 (2003). ISO/IEC 2375:2003: Information technology — Procedure for registration of escape sequences and coded character sets. ISO.{{cite book}}: CS1 maint: numeric names: authors list (link)
  • ISO/IEC JTC 1/SC 2 (1998-02-12). ISO/IEC FDIS 8859-10: Information Technology — 8-bit single-byte coded graphic character sets — Part 10: Latin alphabet No. 6 (PDF) (Final Draft International Standard).{{cite book}}: CS1 maint: numeric names: authors list (link)
  • ISO/IEC JTC 1/SC 2 (2017). ISO/IEC 10646: Information technology — Universal Coded Character Set (UCS) (ISO Standard) (5th ed.). ISO.{{cite book}}: CS1 maint: numeric names: authors list (link)
  • ISO-IR: ISO/IEC International Register of Coded Character Sets To Be Used With Escape Sequences (PDF) (Registry Index). ITSCJ/IPSJ.
  • Scheifler, Robert W. (1989). Compound Text Encoding (X Consortium Standard). X Consortium.
  • van Kesteren, Anne. WHATWG Encoding Standard (WHATWG Living Standard). WHATWG.

Registered code sets cited

  • ISO/TC 97/SC 2 (1975-12-01). ISO-IR-1: The set of control characters of the ISO 646 (PDF). ITSCJ/IPSJ.{{citation}}: CS1 maint: numeric names: authors list (link)
  • Sveriges Standardiseringskommission (1975-12-01). ISO-IR-7: NATS Control set for newspaper text transmission (PDF). ITSCJ/IPSJ.
  • Japanese Industrial Standards Committee (1975-12-01). ISO-IR-14: The Japanese Roman graphic set of characters (PDF). ITSCJ/IPSJ.
  • IPTC (1976-03-25). ISO-IR-26: Control set for newspaper text transmission (PDF). ITSCJ/IPSJ.
  • ISO/TC 97/SC 2 (1977-10-15). ISO-IR-36: The set of control characters of ISO 646, with IS4 replaced by Single Shift for G2 (SS2) (PDF). ITSCJ/IPSJ.{{citation}}: CS1 maint: numeric names: authors list (link)
  • ISO/TC97/SC2/WG-7; ECMA (1985-08-01). ISO-IR-104: Minimum C0 set for ISO 4873 (PDF). ITSCJ/IPSJ.{{citation}}: CS1 maint: numeric names: authors list (link)
  • ISO/TC97/SC2/WG-7; ECMA (1985-08-01). ISO-IR-105: Minimum C1 Set for ISO 4873 (PDF). ITSCJ/IPSJ.{{citation}}: CS1 maint: numeric names: authors list (link)
  • ITU (1985-08-01). ISO-IR-106: Teletex Primary Set of Control Functions (PDF). ITSCJ/IPSJ.
  • Úřad pro normalizaci a měřeni (1987-07-31). ISO-IR-140: The C0 Set of Control Characters of ISO 646, with EM replaced by SS2 (PDF). ITSCJ/IPSJ.
  • Korea Bureau of Standards (1988-10-01). ISO-IR-149: Korean Graphic Character Set for Information Interchange (KS C 5601:1987) (PDF). ITSCJ/IPSJ.
  • ISO/IEC/JTC1/SC2/WG3 (1990-04-16). ISO-IR-155: Basic Box-Drawings Set (PDF). ITSCJ/IPSJ.{{citation}}: CS1 maint: numeric names: authors list (link)
  • CCITT (1992-07-13). ISO-IR-164: Hebrew Supplementary Set of Graphic Characters (PDF). ITSCJ/IPSJ.
  • ECMA (1996-04-22). ISO-IR-192: UCS Transformation Format (UTF-8), implementation level 3, without standard return (PDF). ITSCJ/IPSJ.
  • ECMA (1996-04-22). ISO-IR-195: UCS Transformation Format (UTF-16), implementation level 3, without standard return (PDF). ITSCJ/IPSJ.
  • ECMA (1996-04-22). ISO-IR-196: UCS Transformation Format (UTF-8), with standard return (PDF). ITSCJ/IPSJ.
  • National Standards Authority of Ireland (1999-12-07). ISO-IR-208: Ogham coded character set for information interchange (PDF). ITSCJ/IPSJ.

Internet Requests For Comment cited

  • Murai, J.; Crispin, M.; van der Poel, E. (1993). "RFC 1468: Japanese Character Encoding for Internet Messages". Requests for Comments. IETF. doi:10.17487/rfc1468.
  • Ohta, M.; Handa, K. (1993). "RFC 1554: ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP". Requests for Comments. IETF. doi:10.17487/rfc1554.
  • Choi, U.; Chon, K.; Park, H. (1993). "RFC 1557: Korean Character Encoding for Internet Messages". Requests for Comments. IETF. doi:10.17487/rfc1557.
  • Zhu, HF.; Hu, DY.; Wang, ZG.; Kao, TC.; Chang, WCH.; Crispin, M. (1996). "RFC 1922: Chinese Character Encoding for Internet Messages". Requests for Comments. IETF. doi:10.17487/rfc1922.
  • Tamaru, K. (1997). "RFC 2237: Japanese Character Encoding for Internet Messages". Requests for Comments. IETF. doi:10.17487/rfc2237.

Other published works cited

Further reading

  • ISO/IEC 2022:1994
  • ISO/IEC 2022:1994/Cor 1:1999
  • ECMA-35, equivalent to ISO/IEC 2022 and freely downloadable.
  • International Register of Coded Character Sets to be Used with Escape Sequences Archived 2022-05-13 at the Wayback Machine, a full list of assigned character sets and their escape sequences
  • History of Character Codes in North America, Europe, and East Asia from 1999, rev. 2004
  • Ken Lunde's CJK.INF: a document on encoding Chinese, Japanese, and Korean (CJK) languages, including a discussion of the various variants of ISO/IEC 2022.
Retrieved from "https://en.wikipedia.org/w/index.php?title=ISO/IEC_2022&oldid=1242963950"