Hispanopedia Wiki
Articulo de referencia

ISO/IEC 2022

ISO/IEC 2022 Information technology—Character code structure and extension techniques , is an ISO / IEC standard in the field of character encoding . It is equivalent to the ECM...

Hispanopedia WikiContenido en espanolLectura gratuita

ISO/IEC 2022Information technology—Character code structure and extension techniques, is an ISO/IEC standard in the field of character encoding. It is equivalent to the ECMA standard ECMA-35,[1][2] the ANSI standard ANSI X3.41[3] and the Japanese Industrial StandardJIS X 0202. Originating in 1971, it was most recently revised in 1994.[4]

ISO 2022 specifies a general structure which character encodings can conform to, dedicating particular ranges of bytes (0x00–1F and 0x7F–9F) to be used for non-printing control codes[5] for formatting and in-band instructions (such as line breaks or formatting instructions for text terminals), rather than graphical characters. It also specifies a syntax for escape sequences, multiple-byte sequences beginning with the ESC control code, which can likewise be used for in-band instructions.[6] Specific sets of control codes and escape sequences designed to be used with ISO 2022 include ISO/IEC 6429, portions of which are implemented by ANSI.SYS and terminal emulators.

La norma ISO 2022 define códigos de control y secuencias de escape específicos que permiten alternar entre diferentes conjuntos de caracteres codificados (por ejemplo, entre ASCII y el japonés JIS X 0208 ) para utilizar varios en un mismo documento, [ 7 ] combinándolos efectivamente 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 admite el alfabeto latino básico ISO (equivalente al alfabeto inglés ) y no ofrece 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 ordenadores personales con diferentes codificaciones ASCII extendidas de 8 bits y un solo byte , que siguen a 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). Algunos de estos, como la serie ISO 8859 , cumplen con la norma ISO 2022, [ 9 ] [ 10 ] mientras que otros, como la página de códigos DOS 437, no lo hacen, generalmente debido a que no reservan los bytes 0x80–9F para códigos de control.

Ciertos idiomas de Asia Oriental , específicamente el chino , el japonés y el coreano (denominados colectivamente " CJK "), se escriben utilizando muchos más caracteres que el máximo de 256 que se pueden representar en un solo byte, y se representaron inicialmente en computadoras con codificaciones de doble byte o de ancho variable específicas para cada idioma ; algunas de estas (como la codificación GB 2312 del chino simplificado ) cumplen con la norma ISO 2022 , mientras que otras (como la codificación Big5 del chino tradicional ) no. Los códigos de control en ISO 2022 siempre se representan con un solo byte, independientemente del número de bytes utilizados para los 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-", sobre todo ISO-2022-JP , aunque otras codificaciones CJK como EUC-JP también utilizan mecanismos ISO 2022. [ 11 ] [ 12 ]

Dado que los primeros 256 puntos de código de Unicode se tomaron de ISO 8859-1 , Unicode hereda el concepto de códigos de control C0 y C1 de ISO 2022, aunque añade otros caracteres no imprimibles además de los códigos de control de ISO 2022. Sin embargo, los formatos de transformación de Unicode, como UTF-8, generalmente se desvían de la estructura de 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 las UTF, con la excepción de la obsoleta UTF-1 ).
  • Representación de todos los caracteres, incluidos los códigos de control, con múltiples bytes (por ejemplo, UTF-16 , UTF-32 ).
  • Mezclar bytes con el bit más significativo activado y desactivado 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 al 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 , incluyendo múltiples conjuntos de caracteres gráficos y múltiples conjuntos de códigos de control primarios (C0) y secundarios (C1) , [ 15 ]
  • Un formato para codificar estos conjuntos, suponiendo 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 caracteres 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 de código

Una implementación específica no tiene que implementar todo el estándar; el nivel de conformidad y los conjuntos de caracteres admitidos son 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 cumple con ISO/IEC 8859 , [ 9 ] [ 10 ] y Extended Unix Code , que se utiliza para idiomas de Asia Oriental . [ 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 conjuntos de caracteres o codificaciones específicas están registradas en el registro ISO-IR (excepto aquellas reservadas para uso privado, cuyo significado las definen los proveedores o las 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 sentido directo, ya que la interpretación correcta de los datos depende de las 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 usar 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 del espacio y 33 caracteres de control); si solo se excluyen los códigos de control C0 (definidos de forma estricta), esto se puede ampliar a 96 caracteres. Usando dos bytes, es posible representar hasta 8836 (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 utiliza tres bytes (aunque el G2 no registrado de EUC-TW sí lo hace, al igual que el CCCII, también no registrado ).

Para los conjuntos de caracteres de dos bytes, el punto de código de cada carácter se especifica normalmente en la forma denominada fila-celda 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. Para 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 códigos de caracteres y caracteres mostrados. Las secuencias de escape permiten que cualquiera de un amplio registro de conjuntos de caracteres gráficos sea "designado" [ 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 el flujo.

Los valores de byte de codificación ("combinaciones de bits") se suelen dar en notación de columna-línea , donde dos números decimales en el rango 00–15 (cada uno correspondiente a un dígito hexadecimal) [ 23 ] están separados por una barra. [ 24 ] 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 la propia norma ISO/IEC 2022 / ECMA-35. [ 25 ] Pueden describirse en otros lugares utilizando hexadecimal , como se usa a menudo en este artículo, o utilizando los caracteres ASCII correspondientes, [ 26 ] aunque las secuencias de escape se definen en términos de valores de byte, y el gráfico asignado a ese valor de byte puede alterarse sin afectar la secuencia de control.

Los valores de byte 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 izquierdos"), 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 derechos") . [ 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" [ 27 ] y siempre están disponibles cuando se invoca G0 sobre GL, independientemente de los conjuntos de caracteres designados. Es posible que no se incluyan en los conjuntos de caracteres gráficos, aunque sí pueden incluirse otros tamaños o tipos de caracteres de espacio en blanco . [ 28 ]

Sintaxis general de las secuencias de escape

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

El primer byte I , o su ausencia, determina el tipo de secuencia de escape; por ejemplo, puede designar un conjunto de trabajo o indicar 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. [ 32 ]

Las funciones de control de algunos conjuntos pueden utilizar bytes adicionales después de la secuencia de escape propiamente dicha. Por ejemplo, la función de control ISO 6429 " Control Sequence Introducer ", que puede representarse 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, y finalmente un solo byte en el rango 0x40–0x7E; toda la secuencia se denomina "secuencia de control". [ 33 ]

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 94n caracteres . Además, G1 a G3 pueden ser un conjunto de 96 o 96n caracteres .

En un conjunto de caracteres de 96 o 96n , 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 este. En un conjunto de caracteres de 94 o 94n , los bytes 0x20 y 0x7F no se utilizan. [ 34 ] Cuando se invoca un conjunto de caracteres de 96 o 96n en la región GL, los caracteres de espacio y borrado (códigos 0x20 y 0x7F) no están disponibles hasta que se invoca un conjunto de caracteres de 94 o 94n ( como el conjunto G0) en GL. [ 5 ] Los conjuntos de 96 caracteres no pueden ser designados a G0.

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

Combinando personajes

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. [ 38 ] 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) [ 38 ] ( CSI 0x20 (SP) 0x5F (_)). [ 39 ]

El uso de la tecla de retroceso y el retorno de carro de esta manera está permitido por ISO/IEC 646 , pero prohibido por ISO/IEC 4873 / ECMA-43 [ 40 ] y por ISO/IEC 8859 , [ 41 ] [ 42 ] debido a que deja el repertorio de caracteres gráficos sin definir. Sin embargo, 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. [ 43 ]

Conjuntos de caracteres de control

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

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

Si aparecen códigos del conjunto C0 de ISO 6429 / ECMA-48, es decir, los códigos de control ASCII , en el conjunto C0, deben aparecer en sus ubicaciones de ISO 6429 / ECMA-48. [ 46 ] 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), [ 48 ] 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. [ 46 ] [ 34 ]

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

En este último caso, las funciones de control individuales del conjunto de códigos de control C1 se invocan utilizando secuencias de escape de "tipo Fe", [ 34 ] 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 (_)). [ 52 ]

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. [ 52 ] [ 53 ] El registro de funciones de control a secuencias de tipo "Fs" debe ser aprobado por ISO/IEC JTC 1/SC 2. [ 53 ] Se pueden registrar otras funciones de control individuales a secuencias de escape de tipo "3Ft" (en el rango hasta ), [ 54 ] aunque actualmente no hay secuencias "3Ft" asignadas (a partir de 2019). [ 55 ] Algunas de estas se especifican en ECMA-35 (ISO 2022 / ANSI X3.41), otras en ECMA-48 (ISO 6429 / ANSI X3.64). [ 56 ] ECMA-48 se refiere a estas como "funciones de control independientes". [ 57 ]ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

Las secuencias de escape de tipo "Fp" ( ESC 0x30 (0)hasta ESC 0x3F (?)) o de tipo "3Fp" ( hasta ) están reservadas para códigos de control de uso privado único, mediante acuerdo previo entre las partes. [ 59 ] Varias de estas secuencias de ambos tipos son utilizadas por terminales DEC como el VT100 y, por lo tanto, son compatibles con emuladores de terminales . [ 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 acuerdo previo. El conjunto invocado sobre cada área también puede modificarse con códigos de control denominados desplazamientos, como se muestra en la tabla siguiente. [ 60 ]

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

Los códigos mostrados en la tabla siguiente son las codificaciones más comunes de estos códigos de control, conformes a ISO/IEC 6429. Los desplazamientos 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, [ 55 ] 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 designados: deben estar presentes en los conjuntos de control designados si se utiliza su funcionalidad. [ 49 ] [ 50 ] Los controles C1 en sí mismos, como se mencionó anteriormente, pueden representarse utilizando secuencias de escape o bytes de 8 bits, pero no ambos.

Existen codificaciones alternativas de los desplazamientos 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 [ 62 ] y T.61 . [ 63 ] Esta codificación es actualmente recomendada por ISO/IEC 2022 / ECMA-35 para aplicaciones que requieren representaciones de un solo byte de 7 bits de SS2 y SS3, [ 64 ] y también puede usarse solo para SS2, [ 65 ] aunque también existen conjuntos de códigos más antiguos con SS2 en 0x1C, [ 66 ] [ 67 ] [ 68 ] y se mencionaron como tales en una edición anterior del estándar. [ 69 ] La codificación 0x8E y 0x8F de los desplazamientos simples como se muestra a continuación es obligatoria para los niveles 2 y 3 de ISO/IEC 4873. [ 70 ]

Aunque oficialmente se consideran códigos de cambio y se nombran como tales, los códigos de cambio único no siempre se ven como cambios, [ 12 ] y pueden simplemente verse como bytes de prefijo (es decir, los primeros bytes en una secuencia de varios bytes), [ 11 ] ya que no requieren que el codificador mantenga el conjunto activo actual 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 área de cambio único. Esto debe especificarse en la definición de la versión del código. [ 73 ] Por ejemplo, ISO/IEC 4873 especifica GL, mientras que EUC empaquetado especifica GR. En entornos de 7 bits, solo se usa GL como área de cambio único. [ 75 ] [ 76 ] Si es necesario, se puede comunicar qué área de cambio único se usa usando secuencias de anunciador .

Los nombres "bloqueo de desplazamiento cero" (LS0) y "bloqueo de desplazamiento uno" (LS1) se refieren al mismo par de caracteres de control C0 (0x0F y 0x0E) que los nombres "desplazamiento de entrada" (SI) y "desplazamiento de salida" (SO). Sin embargo, el estándar los denomina LS0 y LS1 cuando se utilizan en entornos de 8 bits y SI y SO cuando se utilizan en entornos de 7 bits. [ 60 ]

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

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

El registro internacional ISO de conjuntos de caracteres codificados para ser utilizados 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 han sido registrados para su uso con ISO/IEC 2022. El procedimiento para registrar códigos y conjuntos en 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. [ 78 ] [ 79 ] 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 a una secuencia de escape de uso no privado ISO/IEC 2022. Puede tratarse de un documento estándar; sin embargo, el registro no crea una nueva norma ISO, no compromete a la ISO ni a la IEC a adoptarla como norma internacional, ni a añadir ninguno de sus caracteres al Conjunto Universal de Caracteres Codificados . [ 80 ]

Las secuencias de escape registradas en ISO-IR también se utilizan encapsuladas en un Identificador Público Formal para identificar conjuntos de caracteres utilizados para referencias numéricas de caracteres en SGML (ISO 8879). Por ejemplo, la cadena ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0se puede usar para identificar la Versión de Referencia Internacional de ISO 646-1983 , [ 81 ] y la especificación HTML 4.01 la utiliza ISO Registration Number 177//CHARSET ISO/IEC 10646-1:1993 UCS-4 with implementation level 3//ESC 2/5 2/15 4/6para identificar Unicode. [ 82 ] 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 compatibles. [ 81 ]

designaciones de conjuntos de caracteres

Las secuencias de escape para designar conjuntos de caracteres tienen la forma . Como se mencionó anteriormente, los bytes intermedios ( I ) están en el rango 0x20–0x2F, y el byte final ( F ) está en el rango 0x30–0x7E. El primer byte I (o, para un conjunto de varios bytes, los dos primeros) identifica el tipo de conjunto de caracteres y el conjunto de trabajo al que se le asignará, mientras que el byte F (y cualquier byte I adicional ) identifica el conjunto de caracteres en sí, como se asignó 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 extender el rango del byte F. Actualmente, esto solo se usa con conjuntos de 94 caracteres, donde se han asignado códigos de la forma. [ 83 ] En el otro extremo, no se han registrado conjuntos de 96 bytes de varios bytes, 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 , [ 32 ] en este caso para definiciones de conjuntos de caracteres de uso privado (que podrían incluir conjuntos no registrados definidos por protocolos como ARIB STD-B24 [ 84 ] o MARC-8 , [ 3 ] o conjuntos específicos del proveedor como DEC Special Graphics ). [ 85 ] 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, [ 86 ] que también se considera de uso privado. [ 32 ] Que un conjunto gráfico se considere un DRCS implica que representa una fuente de glifos exactos, en lugar de un conjunto de caracteres abstractos. [ 87 ] La forma 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 ( @); [ 88 ] sin embargo, en algunos protocolos de telecomunicaciones, como el Teletexto del Sistema Mundial , se define una forma de transmitir las fuentes DRCS . [ 89 ]

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

Existen funciones adicionales (poco 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 códigos de escape. Como se indicó anteriormente, es necesario que cualquier conjunto de caracteres C0 incluya el carácter ESC en la posición 0x1B, para que sean posibles cambios posteriores. Las secuencias de designación del conjunto de control (a diferencia de las del conjunto gráfico) también pueden utilizarse dentro de ISO/IEC 10646 (UCS/Unicode), en contextos donde el procesamiento de códigos de escape ANSI sea apropiado, siempre que cada byte de la secuencia se rellene hasta alcanzar el tamaño de la unidad de código de la codificación. [ 91 ]

A continuación se muestra una tabla de bytes de secuencia de escape I y la designación u otra función que desempeñan. [ 92 ]

Nótese que el registro de bytes F es independiente para los distintos tipos. El conjunto gráfico de 94 caracteres designado por ESC ( Ahasta ESC + Ano guarda relación alguna con el conjunto de 96 caracteres designado por ESC - Ahasta ESC / A. Y ninguno de estos guarda relación con el conjunto de 94 n caracteres designado por ESC $ ( Ahasta ESC $ + A, y así sucesivamente; los bytes finales deben interpretarse en contexto. (De hecho, sin bytes intermedios, 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 (que resulta ser el conjunto de control NATS para la transmisión de texto de periódicos) no es el mismo que el conjunto de caracteres de control C1 designado por (el conjunto de control de atributos CCITT para Videotex ).ESC ! AESC " A

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 regresar 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 Videotex , UTF-8 y UTF-1 . [ 100 ] Se incluye un segundo byte I de 0x2F ( /) en las secuencias de designación de los códigos que no utilizan esa secuencia de bytes para regresar a ISO 2022; pueden tener sus propios medios para regresar a ISO 2022 (como una secuencia diferente o rellena) o ninguno en absoluto. [ 101 ] 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. [ 102 ]

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). [ 100 ] [ 102 ]

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 . [ 102 ] 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, mientras que el resto figura como obsoleto. [ 104 ] ISO/IEC 10646 estipula que los formatos big-endian de UTF-16 y UTF-32 se designan mediante sus secuencias de escape. [ 105 ]

De las secuencias que cambian a UTF-8, está la que admite, por ejemplo, xterm . [ 14 ]ESC % G

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 alcanzar el tamaño de la unidad de código de la codificación (es decir, 001B 0025 0040para UTF-16), lo que significa que la codificación de la secuencia de retorno estándar no se ajusta exactamente a la norma ISO/IEC 2022. Por este motivo, las designaciones para UTF-16 y UTF-32 utilizan una sintaxis sin retorno estándar. [ 108 ]

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

Anuncios sobre la estructura del código

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

Versiones del código ISO/IEC 2022

(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).
Mozilla Firefox admitía diversas codificaciones ISO 2022 y otras codificaciones CJK desde 2004. (Esta compatibilidad se ha reducido en versiones posteriores para evitar ciertos ataques de secuencias de comandos entre sitios ).

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) están definidas por los RFC de la IETF , de las cuales ISO-2022-JP e ISO-2022-KR se han utilizado ampliamente en el pasado. [ 110 ] Varias otras variantes están definidas por proveedores, incluido IBM . [ 111 ] Aunque UTF-8 es la codificación preferida en HTML5 , el contenido heredado en ISO-2022-JP sigue estando suficientemente extendido como para que el estándar de codificación WHATWG mantenga el soporte para él, [ 112 ] en contraste con la asignación de ISO-2022-KR, ISO-2022-CN e ISO-2022-CN-EXT [ 113 ] completamente al carácter de reemplazo , [ 114 ] debido a preocupaciones sobre ataques de inyección de código como el cross-site scripting . [ 112 ] [ 114 ]

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 norma ISO 2022, en un subconjunto estipulado en la norma ISO/IEC 4873. [ 9 ] [ 10 ]

versiones japonesas de correo electrónico

ISO-2022-JP

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

  • ESC ( Bpara cambiar a ASCII (1 byte por carácter)
  • ESC ( Jpara cambiar a JIS X 0201-1976 (ISO/IEC 646:JP) Conjunto romano (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. [ 115 ] Además, debido a que se registraron antes de que fuera posible designar conjuntos multibyte excepto para G0, los escapes para JIS X 0208 no incluyen el segundo byte I. [ 90( ]

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 deben ser modificadas por sistemas que simplemente retransmiten mensajes como correos electrónicos. [ 115 ] El estándar de codificación WHATWG al que hace referencia HTML5 maneja ESC ( By ESC ( Jde forma distinta, pero trata ESC $ @igual que ESC $ Bal decodificar, y usa solo ESC $ Bpara JIS X 0208 al codificar. [ 117 ] 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 ). [ 115 ] [ i ]

Versiones con katakana de ancho reducido

El uso de ESC ( Ipara cambiar al conjunto Kana JIS X 0201-1976 (1 byte por carácter) no es parte del perfil ISO-2022-JP, [ 115 ] pero también se usa a veces. Python lo permite en una variante que denomina ISO-2022-JP-EXT (que también incorpora JIS X 0212 como se describe a continuación, completando la cobertura de EUC-JP ); [ 118 ] [ 119 ] esto es cercano tanto en nombre como en estructura a una codificación denominada 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 . [ 120 ] La variante WHATWG/HTML5 permite decodificar katakana JIS X 0201 en entrada ISO-2022-JP, pero convierte los caracteres a sus equivalentes JIS X 0208 al codificar. [ 117 ] La página de códigos de Microsoft para ISO-2022-JP con kana JIS X 0201 permitido adicionalmente es la página de códigos 50221. [ 116 ]

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 desde G1 sin secuencias de escape, utilizando Shift Out y Shift In o estableciendo el octavo bit (invocado por GR), respectivamente. [ 121 ] No se utilizan ampliamente; [ 121 ] La compatibilidad con JIS X 0208 en JIS X 0201 extendido de 8 bits se logra más comúnmente a través de Shift JIS . La página de códigos de Microsoft para ISO 2022 basado 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. [ 116 ]

ISO-2022-JP-2

ISO-2022-JP-2 es una extensión multilingüe de ISO-2022-JP, definida enRFC 1554(de 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 se acceden desde G2 utilizando la forma de secuencia de escape de 7 bits del código de desplazamiento simple SS2: [ 122 ]

  • 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 ISO/IEC 8859-1 , conjunto de latín extendido 1 (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 sin las demás extensiones, fue posteriormente denominada ISO-2022-JP-1 por el RFC 2237 , de fecha 1997. [ 123 ]

IBM TCP japonés

IBM implementa nueve codificaciones de 7 bits basadas en ISO 2022 para japonés, cada una utilizando 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 TCP/IP para japonés". [ 124 ] CCSID 9148 es el estándar (RFC 1468) ISO-2022-JP. [ 125 ]

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 de 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 un nuevo registro para el plano 1 extendido de JIS, 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 un registro adicional en una revisión posterior del perfil, denominada ISO-2022-JP-2004 . Además de los códigos de designación básicos de ISO-2022-JP, se reconocen las siguientes designaciones:

  • ESC ( Ipara cambiar al conjunto de caracteres Kana JIS X 0201-1976 (1 byte por carácter)
  • ESC $ ( Opara cambiar a JIS X 0213-2000 Plano 1 (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

ISO-2022-KR se define enRFC 1557, de 1993. [ 134 ] Codifica ASCII y el doble byte coreanoKS X 1001-1992, [ 135 ] [ 136 ] anteriormente llamado KS C 5601-1987. A diferencia de ISO-2022-JP-2, utiliza loscaracteres Shift Out y Shift Inpara alternar entre ellos, después de incluirlosESC $ ) Cuna vez al inicio de una línea para designar KS X 1001 a G1. [ 134 ]

ISO-2022-CN yLas funciones ISO-2022-CN-EXT están definidas enel RFC 1922, de 1996. Son codificaciones de 7 bits que utilizan las funciones Shift Out y Shift In (para cambiar entre G0 y G1), y las formas de código de escape de 7 bits de las funciones de cambio único SS2 y SS3 (para acceder a G2 y G3). [ 137 ] 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 de entrada) 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 , para el cual el RFC proporciona una correspondencia en un apéndice): [ 137 ]

  • ESC $ ) Acambiar 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 a CNS 11643-1992 Plano 2 (2 bytes por carácter) [designado a G2]

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

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

El perfil ISO-2022-CN-EXT enumera además conjuntos gráficos estándar Guobiao adicionales como permitidos, pero condicionados a que se les asignen secuencias de escape ISO 2022 registradas: [ 137 ]

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

El carácter que sigue a ESC(para conjuntos de caracteres de un 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 asigna. En los ejemplos anteriores, el carácter ((0x28) asigna un conjunto de 94 caracteres al conjunto de caracteres G0, mientras que ), *o +(0x29–0x2B) lo asigna a 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 por motivos de seguridad. Cabe destacar que 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" [ 113 ] , que asigna toda la entrada al carácter de reemplazo ( �) , para prevenir ciertos ataques de secuencias de comandos entre sitios y ataques relacionados, que utilizan una diferencia en la compatibilidad de codificación entre el cliente y el servidor [ 114 ] . Aunque la misma preocupación de seguridad (permitir que las secuencias de bytes ASCII se interpreten de forma 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 [ 112 ] .

En abril de 2024, se encontró una vulnerabilidad de seguridad [ 138 ] 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. [ 139 ]

ISO/IEC 4873

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

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

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

  • 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 a través de GL y G1 a través de 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 simple SS2 y SS3 (es decir, los desplazamientos de bloqueo están prohibidos), y se invocan sobre la región GL (incluyendo 0x20 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. [ 70 ]
  • El nivel 3 permite las funciones de cambio con bloqueo GR LS1R, LS2R y LS3R, además de los cambios simples, pero por lo demás tiene las mismas restricciones que el nivel 2.

Las ediciones anteriores del estándar permitían asignaciones no ASCII en el conjunto G0, siempre que se conservaran las posiciones invariantes ISO/IEC 646 , que las demás posiciones se asignaran a caracteres de espaciado (no de combinación), que 0x23 se asignara a £ o # , y que 0x24 se asignara a $ o ¤ . [ 141 ] Por ejemplo, la codificación de 8 bits de JIS X 0201 cumple con las ediciones anteriores. Posteriormente, esto se modificó para especificar completamente el conjunto ISO/IEC 646:1991 IRV / ISO-IR No. 6 (ASCII). [ 142 ] [ 143 ] [ 144 ]

El uso de la IRV ISO/IEC 646 (sincronizada con ASCII desde 1991) en el nivel 1 de ISO/IEC 4873 sin C1 ni G1 establecidos, es decir, usar la IRV en un entorno de 8 bits en el que no se utilizan códigos de desplazamiento y el bit más significativo siempre es cero, se conoce como ISO 4873 DV , donde DV significa "Versión predeterminada". [ 145 ]

En los casos en que haya caracteres duplicados disponibles en diferentes conjuntos, la edición actual de ISO/IEC 4873 / ECMA-43 solo permite el uso de estos caracteres en el conjunto de trabajo de menor numeración en el que aparezcan. [ 146 ] Por ejemplo, si un carácter aparece tanto en el conjunto G1 como en el conjunto G3, debe utilizarse del conjunto G1. Sin embargo, se señala que en ediciones anteriores se permitía el uso de caracteres de otros conjuntos. [ 144 ]

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

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 el estándar requiere una secuencia de anunciador 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 de anunciador ISO/IEC 2022, que son las siguientes: [ 148 ]

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 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 sobre GR, y los conjuntos G2 y G3 (si están presentes) se invocan 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 símbolo de yen en algunas versiones de EUC-JP y un símbolo de won en algunas versiones de EUC-KR.

G1 se utiliza para un conjunto de caracteres codificados de 94x94 representados en dos bytes. Las formas 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 utiliza las secuencias de anunciador o designación de ISO 2022; sin embargo, corresponde a la siguiente secuencia de cuatro secuencias de anunciador, cuyos significados se desglosan a continuación. [ 149 ]

Texto compuesto (X11)

El Consorcio X definió un perfil ISO 2022 llamado Texto Compuesto como formato de intercambio en 1989. [ 150 ] Este utiliza solo cuatro códigos de control: HT ( ), NL (salto de línea, codificado como LF , ) , ESC ( ) y CSI (en su representación de 8 bits ), [ 151 ] con la secuencia CSI SDS ( ) utilizada para el control de texto bidireccional. [ 152 ] 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. [ 153 ] Se utilizan los siguientes bytes F:0x090x0A0x1B0x9BCSI … ]

Para especificar codificaciones mediante etiquetas, X11 Compound Text define cinco secuencias DOCS de uso privado: ( ) para codificaciones de longitud variable, y hasta para codificaciones de longitud fija, utilizando 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 . La etiqueta de codificación se incluye en ISO 8859-1 antes del texto codificado y termina con STX ( ). [ 109 ]ESC % / 01B 25 2F 30ESC % / 1ESC % / 40x80–FF0x02

Comparación con otras codificaciones

Ventajas

  • Dado que la gama completa de codificaciones de caracteres gráficos de ISO/IEC 2022 se puede utilizar con GL, los glifos disponibles no se ven significativamente limitados por la incapacidad de representar GR y C1, como ocurre en un sistema limitado a codificaciones de 7 bits. Por consiguiente, permite la representación de un amplio conjunto de caracteres en dicho sistema. En general, esta compatibilidad con 7 bits no supone una ventaja real, salvo para la retrocompatibilidad con sistemas más antiguos. La gran mayoría de los ordenadores modernos utilizan 8 bits por byte.
  • En comparación con Unicode, ISO/IEC 2022 evita la unificación de los caracteres chinos (Han) mediante el uso de códigos de secuencia para alternar entre codificaciones discretas para diferentes idiomas de Asia Oriental. Esto evita los problemas asociados con la unificación, como la dificultad de admitir varios idiomas CJK con sus variantes de caracteres correspondientes en un mismo documento y fuente.

Desventajas

  • Dado que ISO/IEC 2022 es una codificación con estado, un programa no puede saltar a mitad 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 a mitad 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 dicha secuencia.
  • Debido a la naturaleza con estado de la norma ISO/IEC 2022, un carácter idéntico y equivalente puede codificarse en diferentes conjuntos de caracteres, que pueden asignarse a cualquiera de los conjuntos G0 a G3, los cuales pueden invocarse mediante desplazamientos simples o mediante desplazamientos de bloqueo a GL o GR. En consecuencia, los caracteres pueden representarse de múltiples maneras, lo que significa que dos cadenas visualmente idénticas y equivalentes no pueden compararse de forma fiable 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" [ 155 ] ), además de admitir otras codificaciones. [ 156 ] Este tipo de variación dificulta la transferencia de texto de forma portátil 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 el cambio a o desde otros conjuntos de caracteres, como admite ISO/IEC 2022, suele ser innecesario en 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 sanitización. [ 157 ] El uso de esta codificación es tratado como sospechoso por los conjuntos de protección de malware, [ 158 ] 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 prevenir ataques. [ 113 ] [ 114 ] Las versiones restringidas del código ISO 2022 de 8 bits que no utilizan escapes de designación ni códigos de desplazamiento de bloqueo, como Extended Unix Code , no comparten este problema.
  • La concatenación puede plantear problemas. Perfiles como ISO-2022-JP especifican que la secuencia comienza en el estado ASCII y debe terminar en el estado ASCII. [ 115 ] Esto es necesario para asegurar que los caracteres en secuencias concatenadas ISO-2022-JP y/o ASCII se interpretarán en el conjunto correcto. Esto tiene como consecuencia que si una secuencia que termina en un carácter multibyte se concatena con una que comienza con un carácter multibyte, se genera un par de códigos de escape que cambian a ASCII e inmediatamente se alejan de él. Sin embargo, como se estipula en el Informe Técnico Unicode n.° 36 ("Consideraciones de seguridad de Unicode"), los pares de secuencias de escape ISO 2022 sin caracteres entre ellas deben generar un carácter de reemplazo ( "�" ) para evitar que se utilicen para enmascarar secuencias maliciosas como el cross-site scripting . [ 159 ] La implementación de esta medida, por ejemplo en Mozilla Thunderbird , ha dado lugar a problemas de interoperabilidad, con la generación de caracteres "�" inesperados cuando se han concatenado dos secuencias ISO-2022-JP. [ 157 ]

Véase también

Notas a pie de página

  1. ↑ Japonés :区点, romanizado :  kuten ; chino simplificado :区位; chino tradicional :區位; pinyin : qūwèi ; Coreano : 행렬 ; Hanja :行列; RR : haeng-nyeol   
  2. ↑ chino tradicional :區; chino simplificado :区; pinyin : qū ; Pronunciación japonesa : ku ; iluminado. 'zona'; Coreano : 행 ; Hanja :行; RR : haeng   
  3. ↑ Japonés :点, romanizado :  diez , iluminado. ' punto ' ; Chino :位; pinyin : wei ; iluminado. ' posición ' ; Coreano : 열 ; Hanja :列; RR : sí   
  4. ↑ Japonés :面, romanizado :  men , lit. ' cara '
  5. 1 2 Especificado para los bytes F 0x40 (@), 0x41 (A) y 0x42 (B) solamente, por razones históricas. [ 90 ] Algunas implementaciones, como la codificación de emojis SoftBank 2G, utilizan escapes adicionales de esta forma para propósitos que no cumplen con ISO-2022. [ 97 ]
  6. ↑ Listado por MARC-8 . [ 3 ] Véase la nota al piea continuación para obtener información adicional.ESC , F
  7. ↑ F , ajustado al rango 1-63, indica qué revisión (compatible con versiones posteriores) del registro inmediatamente siguiente se necesita, para que los sistemas antiguos sepan que son antiguos. [ 98 ]
  8. ↑ En ediciones anteriores, no existían conjuntos de 96 caracteres, y los códigos de escape que ahora se usan para los conjuntos de 96 caracteres estaban reservados como espacio para conjuntos adicionales de 94 caracteres. En consecuencia, laESC 0x1B 0x2Csecuencia se definió en ediciones anteriores del estándar para designar conjuntos adicionales de 94 caracteres a G0. [ 99 ] Dado que los conjuntos de 96 caracteres no se pueden designar a G0, este primer byte I no se usa en la edición actual del estándar. Sin embargo, todavía aparece en MARC-8 . [ 3 ]
  9. ↑ Véase también, por ejemplo, Printronix (2012), Manual de referencia del programador de OKI® (PDF) , pág.  26, archivado del original (PDF) el 25/09/2019 , consultado el 25/09/2019.para un sistema más reciente que utiliza ESC ( Hpara cambiar de DBCS a ASCII.

Referencias

  1. ↑ ECMA-35 (1994) , Breve historia
  2. ↑ ECMA-35 (1994) , pág. 51, anexo D 
  3. 1 2 3 4 5 "Técnica 2: Uso de conjuntos de caracteres gráficos alternativos estándar" . Especificaciones MARC 21 para la estructura de registros, conjuntos de caracteres y medios de intercambio . Biblioteca del Congreso . 5 de diciembre de 2007. Archivado del original el 22 de julio de 2020. Consultado el 19 de julio de 2020 .
  4. ↑ "ECMA-35: Estructura del código de caracteres y técnicas de extensión (página web)" . Ecma International . Archivado del original el 25 de abril de 2022. Consultado el 27 de abril de 2022 .
  5. 1 2 3 4 ECMA-35 (1994) , págs. 15-16, capítulo 8.1 
  6. 1 2 ECMA-35 (1994) , capítulo 13
  7. 1 2 ECMA-35 (1994) , capítulos 12, 14
  8. 1 2 ECMA-35 (1994) , capítulo 11
  9. 1 2 3 4 5 ISO/IEC FDIS 8859-10 (1998) , pág. 1, capítulo 1 ("Alcance") 
  10. 1 2 3 4 5 ECMA-144 (2000) , pág. 1, capítulo 1 ("Ámbito de aplicación") 
  11. ^ Lunde (2008) , págs. 242-245 , capítulo 4 ("Métodos de codificación"), sección "Codificación EUC " 
  12. 1 2 3 4 Lunde (2008) , págs. 253–255, Capítulo 4 ("Métodos de codificación"), sección "Codificaciones EUC frente a ISO-2022" . 
  13. 1 2 ISO-IR-196 (1996)
  14. 1 2 3 Moy, Edward; Gildea, Stephen; Dickey, Thomas. "Controles que comienzan con ESC" . Secuencias de control de XTerm . Archivado del original el 10-10-2019 . Recuperado el 04-10-2019 .
  15. ↑ ECMA-35 (1994) , capítulos 6, 7
  16. ↑ ECMA-35 (1994) , capítulo 8
  17. ↑ ECMA-35 (1994) , capítulo 9
  18. 1 2 ECMA-35 (1994) , capítulo 15
  19. ↑ Lunde (2008) , págs. 228–234, Capítulo 4 ("Métodos de codificación"), sección "Codificación ISO-2022" 
  20. ↑ Lunde (2008) , págs. 19–20, Capítulo 1 ("Descripción general del procesamiento de información CJKV"), sección "¿Qué son Row-Cell y Plane-Row-Cell?" 
  21. ↑ ECMA-35 (1994) , pág. 4, definición 4.11 
  22. ↑ ECMA-35 (1994) , pág. 5, definición 4.18 
  23. ↑ ISO/IEC JTC1/SC2/WG2 (2025). "Anexo K (informativo): Notaciones de representaciones de valores de octeto". Tecnología de la información – Conjunto de caracteres codificados universales (UCS) (Borrador del comité). pág. 3463. ISO/IEC CD.3 10646:2025, JTC1/SC2 /WG2 N5347. Por lo tanto, la notación de valor de octeto de ISO/IEC 2022 (y otros estándares de codificación de caracteres) se puede convertir a la notación de valor de octeto utilizada por este documento convirtiendo el valor de x e y a notación hexadecimal. Por ejemplo; 04/15 es equivalente a 4F. {{citation}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  24. ↑ Véase, por ejemplo, ISO-IR-14 (1975) , que define la designación G0 del conjunto romano JIS X 0201 comoESC 2/8 4/10.
  25. ↑ ECMA-35 (1994) , pág. 5, capítulo 5.1 
  26. ↑ Véase, por ejemplo, RFC 1468 (1993) , que define la designación G0 del conjunto romano JIS X 0201 comoESC ( J.
  27. ↑ ECMA-35 (1994) , pág. 7, capítulo 6.2 
  28. ↑ ECMA-35 (1994) , pág. 10, capítulo 6.3.2 
  29. ↑ ECMA-35 (1994) , pág. 4, definición 4.17 
  30. ↑ ECMA-35 (1994) , pág. 4, definición 4.14 
  31. ↑ ECMA-35 (1994) , pág. 28, capítulo 13.1 
  32. 1 2 3 ECMA-35 (1994) , pág. 33, capítulo 13.3.3 
  33. ↑ ECMA-48 (1991) , págs. 24-26, capítulo 5.4 
  34. 1 2 3 4 ECMA-35 (1994) , pág. 11, capítulo 6.4.3 
  35. ↑ ISO-IR-208 (1999)
  36. ↑ ISO-IR-155 (1990)
  37. ↑ ISO-IR-164 (1992)
  38. 1 2 ECMA-35 (1994) , pág. 10, capítulo 6.3.3 
  39. ↑ Google Inc. (2014). "ansi.go, línea 134" . Biblioteca de secuencias de escape ANSI para Go . Archivado del original el 30 de abril de 2022. Consultado el 14 de septiembre de 2019 .
  40. ↑ ECMA-43 (1991) , pág. 5, capítulo 7 ("Especificación de los caracteres del código de 8 bits") 
  41. ↑ ISO/IEC FDIS 8859-10 (1998) , pág. 3, capítulo 6 ("Especificación del conjunto de caracteres codificados") 
  42. ↑ ECMA-144 (2000) , pág. 3, capítulo 6 ("Especificación del conjunto de caracteres codificados") 
  43. ↑ ECMA-43 (1991) , pág. 19, anexo C ("Caracteres gráficos compuestos") 
  44. 1 2 ECMA-35 (1994) , pág. 10, capítulo 6.4.1 
  45. 1 2 ECMA-35 (1994) , pág. 11, capítulo 6.4.4 
  46. 1 2 3 ECMA-35 (1994) , pág. 11, capítulo 6.4.2 
  47. ↑ ISO-IR-104 (1985)
  48. ↑ ISO-IR-1 (1975)
  49. 1 2 ECMA-35 (1994) , pág. 19, capítulo 8.5.1 
  50. 1 2 ECMA-35 (1994) , pág. 19, capítulo 8.5.2 
  51. ↑ ECMA-43 (1991) , pág. 8, capítulo 7.6 ("Conjunto C1") 
  52. 1 2 ECMA-35 (1994) , pág. 29, capítulo 13.2.1 
  53. 1 2 ECMA-35 (1994) , pág. 12, capítulo 6.5.1 
  54. ↑ ECMA-35 (1994) , pág. 12, capítulo 6.5.2 
  55. 1 2 3 ISO-IR , pág. 19, capítulo 2.7 ("Funciones de control únicas") 
  56. ↑ ECMA-35 (1994) , pág. 12, capítulo 6.5.4 
  57. ↑ ECMA-48 (1991) , capítulo 5.5
  58. ↑ ISO/TC 97/SC 2 (1976-12-30). Restablecer al estado inicial (RIS) (PDF) . ITSCJ/ IPSJ . ISO-IR -35.{{citation}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  59. ↑ ECMA-35 (1994) , pág. 12, capítulo 6.5.3 
  60. 1 2 ECMA-35 (1994) , pág. 14, capítulo 7.3, tabla 2 
  61. ↑ ISO-IR-14 (1975)
  62. 1 2 UIT-T (1995-08-11). Recomendación T.51 (1992) Enmienda 1. Archivado del original el 2 de agosto de 2020. Recuperado el 25 de diciembre de 2019 .
  63. ↑ ISO-IR-106 (1985)
  64. ↑ ECMA-35 (1994) , pág. 15, capítulo 7.3, nota 23 
  65. ↑ ISO-IR-140 (1987)
  66. ↑ ISO-IR-7 (1975)
  67. ↑ ISO-IR-26 (1976)
  68. ↑ ISO-IR-36 (1977)
  69. ↑ ECMA-35 (1980) , pág. 8, capítulo 5.1.7 
  70. 1 2 ISO-IR-105 (1985)
  71. 1 2 3 4 ECMA-35 (1994) , pág. 17, capítulo 8.3.1 
  72. 1 2 3 4 ECMA-35 (1994) , pág. 23, capítulo 9.3.1 
  73. 1 2 3 ECMA-35 (1994) , pág. 19, capítulo 8.4 
  74. 1 2 3 ECMA-35 (1994) , pág. 17, capítulo 8.3.2 
  75. ↑ ECMA-35 (1994) , págs. 23-24, capítulo 9.4 
  76. ↑ ECMA-35 (1994) , pág. 27, capítulo 11.1 
  77. ↑ ECMA-35 (1994) , pág. 17, capítulo 8.3.3 
  78. ↑ ECMA-35 (1994) , pág. 47, anexo B 
  79. ↑ ISO-IR , pág. 2, capítulo 1 ("Introducción") 
  80. ↑ ISO/IEC 2375 (2003)
  81. 1 2 "Gestión de la declaración SGML en SP" . SP: un sistema SGML conforme a la norma internacional ISO 8879 .
  82. ↑ "20: Declaración SGML de HTML 4" . Especificación HTML 4.01 . W3C .
  83. ↑ ISO-IR , pág. 10, capítulo 2.2 ("Conjunto de caracteres gráficos de 94 caracteres con segundo byte intermedio") 
  84. ↑ ARIB STD-B24 (2008) , pág. 39, parte 2, tabla 7-3 
  85. ↑ Mascheck, Sven; Le Breton, Stefan; Hamilton, Richard L. "Acerca del 'conjunto de caracteres de dibujo lineal alternativo'"" . ~sven_mascheck/ . Archivado del original el 29-12-2019 . Recuperado el 08-01-2020 .
  86. ↑ ECMA-35 (1994) , pág. 36, capítulo 14.4 
  87. ↑ ECMA-35 (1994) , pág. 36, capítulo 14.4.2, nota 48 
  88. ↑ ECMA-35 (1994) , pág. 36, capítulo 14.4.2, nota 47 
  89. ↑ ETS 300 706 (1997) , pág. 103, capítulo 14 ("Personajes dinámicamente redefinibles") 
  90. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ECMA-35 (1994) , págs. 35–36, capítulo 14.3.2 
  91. ↑ ISO/IEC 10646 (2017) , págs. 19-20, capítulo 12.4 ("Identificación del conjunto de funciones de control") 
  92. ↑ ECMA-35 (1994) , pág. 32, tabla 5 
  93. 1 2 3 ECMA-35 (1994) , págs. 37–41, capítulo 15.2 
  94. ↑ ECMA-35 (1994) , pág. 34, capítulo 14.2.2 
  95. ↑ ECMA-35 (1994) , pág. 34, capítulo 14.2.3 
  96. ↑ Digital . "DECDWL: Línea de doble ancho y altura simple" . Información del programador del terminal de vídeo VT510 . Archivado del original el 2 de agosto de 2020. Consultado el 17 de enero de 2020 .
  97. ↑ Kawasaki, Yusuke (2010). "Encode::JP::Emoji::Encoding" . Encode-JP-Emoji . Línea 268. Archivado del original el 30 de abril de 2022. Consultado el 28 de mayo de 2020 .
  98. ↑ ECMA-35 (1994) , págs. 36–37, capítulo 14.5
  99. ↑ ECMA-35 (1980) , págs. 14-15, capítulo 5.3.7
  100. 1 2 3 4 ISO-IR , pág. 20, capítulo 2.8.1 ("Sistemas de codificación con retorno estándar") 
  101. 1 2 3 4 ECMA-35 (1994) , págs. 41–42, capítulo 15.4 
  102. 1 2 3 4 5 ISO-IR , pág. 21, capítulo 2.8.2 ("Sistemas de codificación sin retorno estándar") 
  103. ↑ ECMA-35 (1994) , pág. 41, capítulo 15.3 
  104. 1 2 3 ISO/IEC 10646 (2017) , pág. 19, capítulo 12.2 ("Identificación de un esquema de codificación UCS") 
  105. ↑ ISO/IEC 10646 (2017) , págs. 18-19, capítulo 12.1 ("Propósito y contexto de la identificación") 
  106. ↑ ISO-IR-192 (1996)
  107. ↑ ISO-IR-195 (1996)
  108. ↑ ISO/IEC 10646 (2017) , pág. 20, capítulo 12.5 ("Identificación del sistema de codificación de ISO/IEC 2022") 
  109. ^ Scheifler (1989) , § Codificaciones de juegos de caracteres no estándar
  110. ↑ Lunde (2008) , págs. 229–230, Capítulo 4 ("Métodos de codificación"), sección "Codificación ISO-2022": "Se han resaltado aquellas codificaciones que se han utilizado ampliamente en el pasado o que se siguen utilizando hoy en día para algunos fines." 
  111. 1 2 "Información adicional requerida relacionada con la codificación" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 7 de enero de 2015.
  112. 1 2 3 Estándar de codificación WHATWG , sección 2 ("Antecedentes de seguridad")
  113. 1 2 3 Estándar de codificación WHATWG , capítulo 4.2 ("Nombres y etiquetas"), anclaje "reemplazo"
  114. 1 2 3 4 Estándar de codificación WHATWG , sección 14.1 ("reemplazo")
  115. 1 2 3 4 5 6 RFC 1468 (1993)
  116. 1 2 3 "Identificadores de página de códigos" . Centro de desarrollo de Windows . Microsoft. Archivado del original el 16 de junio de 2019. Recuperado el 16 de septiembre de 2019 .
  117. 1 2 Estándar de codificación WHATWG , sección 12.2 ("ISO-2022-JP")
  118. ↑ Chang, Hye-Shik. "Modules/cjkcodecs/_codecs_iso2022.c, línea 1122" . Árbol de código fuente de cPython . Python Software Foundation. Archivado del original el 30 de abril de 2022. Consultado el 15 de septiembre de 2019 .
  119. ↑ "códecs — Registro de códecs y clases base § Codificaciones estándar" . Documentación de Python 3.7.4 . Python Software Foundation. Archivado del original el 28 de julio de 2019. Consultado el 16 de septiembre de 2019 .
  120. ↑ "2: Conjuntos de códigos y conversión de conjuntos de códigos" . Referencia técnica DIGITAL UNIX para el uso de funciones japonesas . Digital Equipment Corporation , Compaq .
  121. 1 2 Lunde (2008) , págs. 236–238, Capítulo 4 ("Métodos de codificación"), sección "El predecesor de la codificación ISO-2022-JP: la codificación JIS" 
  122. ↑ RFC 1554 (1993)
  123. ↑ RFC 2237 (1997)
  124. ↑ "PQ02042: Nueva función para proporcionar soporte para iconv() de C/370 para ISO-2022-JP japonés" . IBM . 19 de enero de 2021. Archivado del original el 4 de enero de 2022. Consultado el 4 de enero de 2022 .
  125. 1 2 "CCSID 9148" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 29/11/2014.
  126. ↑ "CCSID 956" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 2 de diciembre de 2014.
  127. ↑ "CCSID 957" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 30/11/2014.
  128. ↑ "CCSID 958" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 1 de diciembre de 2014.
  129. ↑ "CCSID 959" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 2 de diciembre de 2014.
  130. ↑ "CCSID 5052" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 29/11/2014.
  131. ↑ "CCSID 5053" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 29/11/2014.
  132. ↑ "CCSID 5054" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 29/11/2014.
  133. ↑ "CCSID 5055" . Globalización de IBM - Identificadores de conjuntos de caracteres codificados . IBM . Archivado del original el 29/11/2014.
  134. 1 2 RFC 1557 (1993)
  135. ↑ "KS X 1001:1992" (PDF) . Archivado (PDF) del original el 26-09-2007 . Consultado el 12-07-2007 .
  136. ↑ ISO-IR-149 (1988)
  137. 1 2 3 4 RFC 1922 (1996)
  138. ↑ "CVE-2024-2961" .
  139. ↑ "Vulnerabilidad de GLIBC en servidores que ejecutan PHP" .
  140. ↑ ECMA-43 (1991) , págs. 9-10, capítulo 8 ("Niveles") 
  141. ↑ ECMA-43 (1985) , págs. 7–11, capítulo 7.3 ("El conjunto G0") 
  142. ↑ ECMA-43 (1991) , págs. 6–8, capítulo 7.4 ("G0 set") 
  143. ↑ ECMA-43 (1991) , pág. 11, capítulo 10.3 ("Identificación de una versión") 
  144. 1 2 ECMA-43 (1991) , pág. 23, anexo E ("Principales diferencias entre la segunda edición (1985) y la presente (tercera) edición de esta norma ECMA") 
  145. ↑ IPTC (1995). Formato de mensaje recomendado por la IPTC (PDF) (5.ª ed.). IPTC TEC 7901. Archivado (PDF) del original el 25/01/2022 . Consultado el 14/01/2020 . 
  146. ↑ ECMA-43 (1991) , pág. 10, capítulo 9.2 ("Codificación única de caracteres") 
  147. ↑ van Wingen, Johan W (1999). "8. Extensión de código, ISO 2022 y 2375, ISO 4873 y 10367" . Conjuntos de caracteres. Letras, tokens y códigos . Terena. Archivado del original el 1 de agosto de 2020. Recuperado el 2 de octubre de 2019 .
  148. ↑ ECMA-43 (1991) , págs. 10-11, capítulo 10 ("Identificación de la versión y el nivel") 
  149. ↑ IBM . "Arquitectura de representación de datos de caracteres (CDRA)" . IBM . págs. 157–162 . Archivado del original el 23 de junio de 2019. Consultado el 18 de junio de 2020 . 
  150. ↑ Scheifler (1989)
  151. ↑ Scheifler (1989) , § Personajes de control
  152. ↑ Scheifler (1989) , § Direccionalidad
  153. ^ Scheifler (1989) , § Codificaciones de juegos de caracteres estándar
  154. ↑ Scheifler (1989) , § Codificaciones estándar aprobadas
  155. ↑ "DICOM PS3.2 2016d - Conformidad; D.6.2 Conjuntos de caracteres; D.6 Compatibilidad con conjuntos de caracteres" . Archivado del original el 16 de febrero de 2020. Consultado el 21 de mayo de 2020 .
  156. ↑ "Variación DICOM ISO 2022" . Archivado del original el 30 de abril de 2013. Consultado el 25 de julio de 2009 .
  157. 1 2 Sivonen, Henri (17-12-2018). "(BORRADOR NO ENVIADO) No se genera U+FFFD para contenido de estado ASCII de longitud cero entre secuencias de escape ISO-2022-JP" (PDF) . Archivado (PDF) del original el 21-02-2019 . Recuperado el 21-02-2019 .
  158. ↑ "935453 - Recopilar telemetría sobre HZ y otras codificaciones que podríamos intentar eliminar" . Archivado del original el 19 de mayo de 2017. Consultado el 18 de junio de 2018 .
  159. ↑ Davis, Mark; Suignard, Michel (19 de septiembre de 2014). "3.6.2 Alguna salida para toda entrada" . Informe técnico Unicode n.º 36: Consideraciones de seguridad de Unicode (revisión 15) . Consorcio Unicode. Archivado del original el 22 de febrero de 2019. Recuperado el 21 de febrero de 2019 .

Normas e índices de registro citados

  • ARIB (2008). ARIB STD-B24: Especificación de codificación y transmisión de datos para radiodifusión digital (PDF) (Estándar ARIB). 5.2-E1. Vol.  1. Archivado (PDF) del original el 10 de julio de 2017. Recuperado el 10 de julio de 2017 .
  • ECMA (1980). ECMA-35: Extensión del conjunto de caracteres codificados de 7 bits (PDF) (Estándar ECMA) (2.ª  ed.).
  • ECMA (1994). ECMA-35: Estructura del código de caracteres y técnicas de extensión (PDF) (Estándar ECMA) (6.ª  ed.).
  • ECMA (1985). ECMA-43: Estructura y reglas del conjunto de caracteres codificados de 8 bits (PDF) (Estándar ECMA) (2.ª  ed.).
  • ECMA (1991). ECMA-43: Estructura y reglas del conjunto de caracteres codificados de 8 bits (PDF) (Estándar ECMA) (3.ª  ed.).
  • ECMA (1991). ECMA-48: Funciones de control para conjuntos de caracteres codificados (PDF) (Estándar ECMA) (5.ª  ed.).
  • ECMA (2000). ECMA-144: Conjuntos de caracteres gráficos codificados de un solo byte de 8 bits: Alfabeto latino n.° 6 (PDF) (Estándar ECMA) (3.ª  ed.).
  • Unión Europea de Radiodifusión (1997). ETS 300 706: Especificación de teletexto mejorado (PDF) (Normas europeas de telecomunicaciones). ETSI .
  • ISO/IEC JTC 1/SC 2 (2003). ISO/IEC 2375:2003: Tecnología de la información — Procedimiento para el registro de secuencias de escape y conjuntos de caracteres codificados . ISO .{{cite book}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • ISO/IEC JTC 1/SC 2 (1998-02-12). ISO/IEC FDIS 8859-10: Tecnología de la información — Conjuntos de caracteres gráficos codificados de un solo byte de 8 bits — Parte 10: Alfabeto latino n.º 6 (PDF) (Borrador final de la norma internacional).{{cite book}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • ISO/IEC JTC 1/SC 2 (2017). ISO/IEC 10646: Tecnología de la información — Conjunto de caracteres codificados universales (UCS) (Norma ISO) (5.ª  ed.). ISO .{{cite book}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • ISO-IR: Registro internacional ISO/IEC de conjuntos de caracteres codificados para usar con secuencias de escape (PDF) (Índice del registro). ITSCJ/ IPSJ . Archivado del original (PDF) el 12 de mayo de 2023. Consultado el 12 de mayo de 2023 .
  • Scheifler, Robert W. (1989). Codificación de texto compuesto (estándar del consorcio X). X Consorcio .
  • van Kesteren, Anne . Estándar de codificación WHATWG (estándar de vida WHATWG). QUÉ WG .

Conjuntos de códigos registrados citados

  • ISO/TC 97/SC 2 (1975-12-01). ISO-IR-1: El conjunto de caracteres de control de la ISO 646 (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • Comisión de Normalización de Suecia (1 de diciembre de 1975). ISO-IR-7: Conjunto de control NATS para transmisión de texto de periódicos (PDF) . ITSCJ/ IPSJ .
  • Comité de Normas Industriales Japonesas (1975-12-01). ISO-IR-14: Conjunto de caracteres gráficos romanos japoneses (PDF) . ITSCJ/ IPSJ .
  • IPTC (25 de marzo de 1976). ISO-IR-26: Conjunto de control para transmisión de texto de periódico (PDF) . ITSCJ/ IPSJ .
  • ISO/TC 97/SC 2 (15-10-1977). ISO-IR-36: El conjunto de caracteres de control de ISO 646, con IS4 reemplazado por Single Shift para G2 (SS2) (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • ISO/TC97/SC2/WG-7 ; ECMA (1 de agosto de 1985). ISO-IR-104: C0 mínimo establecido para ISO 4873 (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • ISO/TC97/SC2/WG-7 ; ECMA (1 de agosto de 1985). ISO-IR-105: Conjunto mínimo de C1 para ISO 4873 (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • UIT (1985-08-01). ISO-IR-106: Conjunto primario de funciones de control de Teletex (PDF) . ITSCJ/ IPSJ .
  • Úřad pro normalizaci a měřeni (31 de julio de 1987). ISO-IR-140: el conjunto C0 de caracteres de control de ISO 646, con EM reemplazado por SS2 (PDF) . ITSCJ/ IPSJ .
  • Oficina de Normas de Corea (1988-10-01). ISO-IR-149: Conjunto de caracteres gráficos coreanos para el intercambio de información (KS C 5601:1987) (PDF) . ITSCJ/ IPSJ .
  • ISO/IEC/JTC1/SC2/WG3 (16-04-1990). ISO-IR-155: Conjunto básico de dibujos de cajas (PDF) . ITSCJ/ IPSJ .{{citation}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  • CCITT (13-07-1992). ISO-IR-164: Conjunto suplementario de caracteres gráficos hebreos (PDF) . ITSCJ/ IPSJ .
  • ECMA (22-04-1996). ISO-IR-192: Formato de transformación UCS (UTF-8), nivel de implementación 3, sin retorno estándar (PDF) . ITSCJ/ IPSJ .
  • ECMA (22-04-1996). ISO-IR-195: Formato de transformación UCS (UTF-16), nivel de implementación 3, sin retorno estándar (PDF) . ITSCJ/ IPSJ .
  • ECMA (22-04-1996). ISO-IR-196: Formato de transformación UCS (UTF-8), con retorno estándar (PDF) . ITSCJ/ IPSJ .
  • Autoridad Nacional de Normas de Irlanda (07-12-1999). ISO-IR-208: Conjunto de caracteres codificados Ogham para el intercambio de información (PDF) . ITSCJ/ IPSJ .

Se citan las solicitudes de comentarios de Internet.

  • Murai, J.; Crispin, M.; van der Poel, E. (1993). "RFC 1468: Codificación de caracteres japoneses para mensajes de Internet" . Solicitudes de comentarios . IETF . doi : 10.17487/rfc1468 .
  • Ohta, M.; Handa, K. (1993). "RFC 1554: ISO-2022-JP-2: Extensión multilingüe de ISO-2022-JP" . Solicitudes de comentarios . IETF . doi : 10.17487/rfc1554 .
  • Choi, U.; Chon, K.; Park, H. (1993). "RFC 1557: Codificación de caracteres coreanos para mensajes de Internet" . Solicitudes de comentarios . IETF . doi : 10.17487/rfc1557 .
  • Zhu, HF.; Hu, DY.; Wang, ZG.; Kao, TC.; Chang, WCH.; Crispin, M. (1996). "RFC 1922: Codificación de caracteres chinos para mensajes de Internet" . Solicitudes de comentarios . IETF . doi : 10.17487/rfc1922 .
  • Tamaru, K. (1997). "RFC 2237: Codificación de caracteres japoneses para mensajes de Internet" . Solicitudes de comentarios . IETF . doi : 10.17487/rfc2237 .

Otras obras publicadas citadas

Lecturas adicionales

  • ISO/IEC 2022:1994
  • ISO/IEC 2022:1994/Cor 1:1999
  • ECMA-35 , equivalente a ISO/IEC 2022 y de descarga gratuita.
  • Registro Internacional de Conjuntos de Caracteres Codificados para su Uso con Secuencias de Escape : una lista completa de los conjuntos de caracteres asignados y sus secuencias de escape.
  • Historia de los códigos de caracteres en Norteamérica, Europa y Asia Oriental desde 1999, rev. 2004
  • El documento CJK.INF de Ken Lunde , archivado el 15 de mayo de 2021 en Wayback Machine , trata sobre la codificación de los idiomas chino, japonés y coreano (CJK), e incluye un análisis de las distintas variantes de la norma ISO/IEC 2022.
Obtenido de " https://en.wikipedia.org/w/index.php?title=ISO/IEC_2022&oldid=1362291230#IBM_Japanese_TCP "
Lecturas relacionadas
6 articulos
Organización Internacional de NormalizaciónOrganización Internacional de NormalizaciónLa Organización Internacional de Normalización ( ISO / ˈaɪs oʊ / [ 3] ) es una organización internacional de normalización independiente y no guber...Comisión Electrotécnica InternacionalComisión Electrotécnica InternacionalLa Comisión Electrotécnica Internacional ( IEC ; en francés : Commission électrotechnique internationale ) es una organización internacional de nor...Codificación de caracteresCodificación de caracteresLa codificación de caracteres es el proceso de asignar números a caracteres gráficos , especialmente a los caracteres escritos del lenguaje humano ...Ecma InternacionalEcma InternacionalEcma International ( / ˈɛkmə / ) es una organización de normalización sin fines de lucro para sistemas de información y comunicación. [ 1 ] Adquiri...Instituto Nacional de Normas EstadounidensesEl Instituto Nacional Estadounidense de Estándares ( ANSI / ˈænsi / AN -see ) es una organización privada sin fines de lucro que supervisa el desar...Normas industriales japonesasNormas industriales japonesasLas Normas Industriales Japonesas ( JIS ) (日本産業規格, Nihon Sangyō Kikaku , anteriormente 日本工業規格Nihon Kōgyō Kikaku hasta el 30 de junio de 2019) son l...