stringtranslate.com

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 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:

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:

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 puede alterarse 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.

En ciertos conjuntos de códigos de control se encuentran disponibles codificaciones alternativas de los cambios simples como códigos de control C0. 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, como 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 en GL y 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:

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]

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:

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]

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

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]

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]

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

Desventajas

Véase también

Notas al pie

  1. ^ Japonés :区点, romanizadokuten ; Chino :区位; pinyin : qūwèi ; Coreano행렬 ; Hanja行列; RR :  haeng-nyeol
  2. ^ Japonés :, romanizadoku , iluminado. 'zona'; Chino :; pinyin : ; Coreano ; Hanja; RR :  haeng
  3. ^ Japonés :, romanizadoten , lit.  'punto'; Chino :; pinyin : wèi ; lit. 'posición'; Coreano ; Hanja; RR :  yeol
  4. ^ Japonés :, romanizadohombres , lit.  'cara'
  5. ^ ab Especificado solo para los bytes F 0x40 ( @), 0x41 ( A) y 0x42 ( B), por razones históricas. [89] Algunas implementaciones, como la codificación de emojis SoftBank 2G , usan escapes adicionales de esta forma para fines que no cumplen con la norma ISO-2022. [96]
  6. ^ Listado por MARC-8 . [3] Consulte la nota a pie de página a continuación para obtener más información.ESC , F
  7. ^ F , ajustado al rango 1-63, indica qué revisión (compatible con versiones anteriores) del registro inmediatamente siguiente se necesita, para que los sistemas antiguos sepan que son antiguos. [97]
  8. ^ En ediciones anteriores, no existían conjuntos de 96 caracteres, y los códigos de escape que ahora se utilizan para conjuntos de 96 caracteres se reservaban como espacio para conjuntos adicionales de 94 caracteres. En consecuencia, la ESC 0x1B 0x2Csecuencia se definió en las primeras ediciones del estándar como la designación de conjuntos de 94 caracteres adicionales para G0. [98] Dado que los conjuntos de 96 caracteres no se pueden designar para G0, este primer byte I no se utiliza en la edición actual del estándar. Sin embargo, todavía aparece en la lista de MARC-8 . [3]
  9. ^ Véase también, por ejemplo, Printronix (2012), OKI® Programmer's Reference Manual (PDF) , pág. 26para un sistema más reciente que suele ESC ( Hcambiar a ASCII desde un DBCS.

Referencias

  1. ^ ECMA-35 (1994), Breve historia
  2. ^ ECMA-35 (1994), pág. 51, anexo D
  3. ^ abcde "Técnica 2: Uso de conjuntos de caracteres gráficos alternativos estándar". Especificaciones MARC 21 para estructura de registros, conjuntos de caracteres y medios de intercambio . Biblioteca del Congreso . 2007-12-05. Archivado desde el original el 2020-07-22 . Consultado el 2020-07-19 .
  4. ^ "ECMA-35: Estructura del código de caracteres y técnicas de extensión (página web)". Ecma International . Archivado desde el original el 2022-04-25 . Consultado el 2022-04-27 .
  5. ^ abcd ECMA-35 (1994), págs. 15-16, capítulo 8.1
  6. ^ ab ECMA-35 (1994), capítulo 13
  7. ^ ab ECMA-35 (1994), capítulos 12, 14
  8. ^ ab ECMA-35 (1994), capítulo 11
  9. ^ abcde ISO/IEC FDIS 8859-10 (1998), pág. 1, capítulo 1 ("Alcance")
  10. ^ abcde ECMA-144 (2000), pág. 1, capítulo 1 ("Alcance")
  11. ^ abcdef Lunde (2008), págs. 242–245, Capítulo 4 ("Métodos de codificación"), sección "Codificación EUC"
  12. ^ abcd Lunde (2008), págs. 253–255, Capítulo 4 ("Métodos de codificación"), sección "Codificaciones EUC versus ISO-2022".
  13. ^ Según la norma ISO-IR-196 (1996)
  14. ^ abc Moy, Edward; Gildea, Stephen; Dickey, Thomas. "Controles que comienzan con ESC". Secuencias de control de XTerm . Archivado desde el original el 2019-10-10 . Consultado el 2019-10-04 .
  15. ^ ECMA-35 (1994), capítulos 6, 7
  16. ^ ECMA-35 (1994), capítulo 8
  17. ^ ECMA-35 (1994), capítulo 9
  18. ^ ab 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 celdas de fila y celdas de fila de plano?"
  21. ^ ECMA-35 (1994), pág. 4, definición 4.11
  22. ^ ECMA-35 (1994), pág. 5, definición 4.18
  23. ^ Véase, por ejemplo, ISO-IR-14 (1975), que define la designación G0 del conjunto romano JIS X 0201 como ESC 2/8 4/10.
  24. ^ ECMA-35 (1994), pág. 5, capítulo 5.1
  25. ^ Véase, por ejemplo, RFC 1468 (1993), que define la designación G0 del conjunto romano JIS X 0201 como ESC ( J.
  26. ^ ECMA-35 (1994), pág. 7, capítulo 6.2
  27. ^ ECMA-35 (1994), pág. 10, capítulo 6.3.2
  28. ^ ECMA-35 (1994), pág. 4, definición 4.17
  29. ^ ECMA-35 (1994), pág. 4, definición 4.14
  30. ^ ECMA-35 (1994), pág. 28, capítulo 13.1
  31. ^ abc ECMA-35 (1994), pág. 33, capítulo 13.3.3
  32. ^ ECMA-48 (1991), págs. 24-26, capítulo 5.4
  33. ^ abcd ECMA-35 (1994), pág. 11, capítulo 6.4.3
  34. ^ ISO-IR-208 (1999)
  35. ^ ISO-IR-155 (1990)
  36. ^ ISO-IR-164 (1992)
  37. ^ ab ECMA-35 (1994), pág. 10, capítulo 6.3.3
  38. ^ Google Inc. (2014). «ansi.go, línea 134». Biblioteca de secuencias de escape ANSI para Go . Archivado desde el original el 2022-04-30 . Consultado el 2019-09-14 .
  39. ^ ECMA-43 (1991), pág. 5, capítulo 7 ("Especificación de los caracteres del código de 8 bits")
  40. ^ ISO/IEC FDIS 8859-10 (1998), pág. 3, capítulo 6 ("Especificación del conjunto de caracteres codificados")
  41. ^ ECMA-144 (2000), pág. 3, capítulo 6 ("Especificación del conjunto de caracteres codificados")
  42. ^ ECMA-43 (1991), pág. 19, anexo C ("Caracteres gráficos compuestos")
  43. ^ ab ECMA-35 (1994), pág. 10, capítulo 6.4.1
  44. ^ ab ECMA-35 (1994), pág. 11, capítulo 6.4.4
  45. ^ abc ECMA-35 (1994), pág. 11, capítulo 6.4.2
  46. ^ ISO-IR-104 (1985)
  47. ^ ISO-IR-1 (1975)
  48. ^ ab ECMA-35 (1994), pág. 19, capítulo 8.5.1
  49. ^ ab ECMA-35 (1994), pág. 19, capítulo 8.5.2
  50. ^ ECMA-43 (1991), pág. 8, capítulo 7.6 ("Conjunto C1")
  51. ^ ab ECMA-35 (1994), pág. 29, capítulo 13.2.1
  52. ^ ab ECMA-35 (1994), pág. 12, capítulo 6.5.1
  53. ^ ECMA-35 (1994), pág. 12, capítulo 6.5.2
  54. ^ abc ISO-IR, pág. 19, capítulo 2.7 ("Funciones de control individuales")
  55. ^ ECMA-35 (1994), pág. 12, capítulo 6.5.4
  56. ^ ECMA-48 (1991), capítulo 5.5
  57. ^ ISO/TC 97/SC 2 (30 de diciembre de 1976). Restablecimiento al estado inicial (RIS) (PDF) . ITSCJ/ IPSJ . ISO-IR -35.{{citation}}: CS1 maint: numeric names: authors list (link)
  58. ^ ECMA-35 (1994), pág. 12, capítulo 6.5.3
  59. ^ ab ECMA-35 (1994), pág. 14, capítulo 7.3, tabla 2
  60. ^ ISO-IR-14 (1975)
  61. ^ de ITU-T (1995-08-11). Recomendación T.51 (1992) Enmienda 1. Archivado desde el original el 2020-08-02 . Consultado el 2019-12-25 .
  62. ^ ISO-IR-106 (1985)
  63. ^ ECMA-35 (1994), pág. 15, capítulo 7.3, nota 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ág. 8, capítulo 5.1.7
  69. ^ Según la norma ISO-IR-105 (1985)
  70. ^ abcd ECMA-35 (1994), pág. 17, capítulo 8.3.1
  71. ^ abcd ECMA-35 (1994), pág. 23, capítulo 9.3.1
  72. ^ abc ECMA-35 (1994), pág. 19, capítulo 8.4
  73. ^ abc ECMA-35 (1994), pág. 17, capítulo 8.3.2
  74. ^ ECMA-35 (1994), págs. 23-24, capítulo 9.4
  75. ^ ECMA-35 (1994), pág. 27, capítulo 11.1
  76. ^ ECMA-35 (1994), pág. 17, capítulo 8.3.3
  77. ^ ECMA-35 (1994), pág. 47, anexo B
  78. ^ ISO-IR, pág. 2, capítulo 1 ("Introducción")
  79. ^ ISO/IEC 2375 (2003)
  80. ^ ab "Manejo de la declaración SGML en SP". SP: un sistema SGML conforme a la norma internacional ISO 8879 .
  81. ^ "20: Declaración SGML de HTML 4". Especificación HTML 4.01 . W3C .
  82. ^ ISO-IR, pág. 10, capítulo 2.2 ("Conjunto de caracteres gráficos de 94 caracteres con segundo byte intermedio")
  83. ^ ARIB STD-B24 (2008), pág. 39, parte 2, Tabla 7-3
  84. ^ Mascheck, Sven; Le Breton, Stefan; Hamilton, Richard L. "Acerca del 'conjunto de caracteres de dibujo de líneas alternativo'". ~sven_mascheck/ . Archivado desde el original el 29 de diciembre de 2019 . Consultado el 8 de enero de 2020 .
  85. ^ ECMA-35 (1994), pág. 36, capítulo 14.4
  86. ^ ECMA-35 (1994), pág. 36, capítulo 14.4.2, nota 48
  87. ^ ECMA-35 (1994), pág. 36, capítulo 14.4.2, nota 47
  88. ^ ETS 300 706 (1997), pág. 103, capítulo 14 ("Caracteres redefinibles dinámicamente")
  89. ^ abcdefghijklmnopq ECMA-35 (1994), págs. 35-36, capítulo 14.3.2
  90. ^ ISO/IEC 10646 (2017), págs. 19-20, capítulo 12.4 ("Identificación del conjunto de funciones de control")
  91. ^ ECMA-35 (1994), pág. 32, tabla 5
  92. ^ abc ECMA-35 (1994), págs. 37–41, capítulo 15.2
  93. ^ ECMA-35 (1994), pág. 34, capítulo 14.2.2
  94. ^ ECMA-35 (1994), pág. 34, capítulo 14.2.3
  95. ^ Digital . "DECDWL: línea de doble ancho y altura simple". Información del programador de terminal de video VT510 . Archivado desde el original el 2020-08-02 . Consultado el 2020-01-17 .
  96. ^ Kawasaki, Yusuke (2010). "Encode::JP::Emoji::Encoding". Encode-JP-Emoji . Línea 268. Archivado desde el original el 2022-04-30 . Consultado el 2020-05-28 .
  97. ^ ECMA-35 (1994), págs. 36-37, capítulo 14.5
  98. ^ ECMA-35 (1980), págs. 14-15, capítulo 5.3.7
  99. ^ abcd ISO-IR, pág. 20, capítulo 2.8.1 ("Sistemas de codificación con retorno estándar")
  100. ^ abcd ECMA-35 (1994), págs. 41-42, capítulo 15.4
  101. ^ abcde ISO-IR, pág. 21, capítulo 2.8.2 ("Sistemas de codificación sin retorno estándar")
  102. ^ ECMA-35 (1994), pág. 41, capítulo 15.3
  103. ^ abc ISO/IEC 10646 (2017), pág. 19, capítulo 12.2 ("Identificación de un esquema de codificación UCS")
  104. ^ ISO/IEC 10646 (2017), págs. 18-19, capítulo 12.1 ("Propósito y contexto de la identificación")
  105. ^ ISO-IR-192 (1996)
  106. ^ ISO-IR-195 (1996)
  107. ^ ISO/IEC 10646 (2017), pág. 20, capítulo 12.5 ("Identificación del sistema de codificación de ISO/IEC 2022")
  108. ^ ab Scheifler (1989), § Codificaciones de conjuntos de caracteres no estándar
  109. ^ Lunde (2008), págs. 229-230, Capítulo 4 ("Métodos de codificación"), sección "Codificación ISO-2022" "Se han destacado aquellas codificaciones que se han utilizado ampliamente en el pasado, o que continúan utilizándose hoy en día para algunos propósitos".
  110. ^ ab "Información adicional necesaria relacionada con la codificación". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 7 de enero de 2015.
  111. ^ abc Norma de codificación WHATWG, sección 2 ("Contexto de seguridad")
  112. ^ abc Estándar de codificación WHATWG, capítulo 4.2 ("Nombres y etiquetas"), "reemplazo" de ancla
  113. ^ abcd Norma de codificación WHATWG, sección 14.1 ("reemplazo")
  114. ^ abcdef RFC 1468 (1993)
  115. ^ abc "Identificadores de página de códigos". Centro de desarrollo de Windows . Microsoft. Archivado desde el original el 2019-06-16 . Consultado el 2019-09-16 .
  116. ^ Norma de codificación ab WHATWG, sección 12.2 ("ISO-2022-JP")
  117. ^ Chang, Hye-Shik. «Modules/cjkcodecs/_codecs_iso2022.c, línea 1122». Árbol de código fuente de cPython . Python Software Foundation. Archivado desde el original el 2022-04-30 . Consultado el 2019-09-15 .
  118. ^ "códecs — Registro de códecs y clases base § Codificaciones estándar". Documentación de Python 3.7.4 . Python Software Foundation. Archivado desde el original el 28 de julio de 2019 . Consultado el 16 de septiembre de 2019 .
  119. ^ "2: Conjuntos de códigos y conversión de conjuntos de códigos". Referencia técnica de DIGITAL UNIX para el uso de funciones japonesas . Digital Equipment Corporation , Compaq .[ enlace muerto ]
  120. ^ ab 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"
  121. ^ RFC 1554 (1993)
  122. ^ RFC 2237 (1997)
  123. ^ "PQ02042: Nueva función para proporcionar compatibilidad con iconv() de C/370 para la norma ISO-2022-JP japonesa". IBM . 19 de enero de 2021. Archivado desde el original el 4 de enero de 2022 . Consultado el 4 de enero de 2022 .
  124. ^ ab "CCSID 9148". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  125. ^ "CCSID 956". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 2 de diciembre de 2014.
  126. ^ "CCSID 957". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 30 de noviembre de 2014.
  127. ^ "CCSID 958". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 1 de diciembre de 2014.
  128. ^ "CCSID 959". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 2 de diciembre de 2014.
  129. ^ "CCSID 5052". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  130. ^ "CCSID 5053". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  131. ^ "CCSID 5054". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  132. ^ "CCSID 5055". IBM Globalization - Identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  133. ^ desde RFC 1557 (1993)
  134. ^ "KS X 1001:1992" (PDF) . Archivado (PDF) desde el original el 26 de septiembre de 2007. Consultado el 12 de julio de 2007 .
  135. ^ ISO-IR-149 (1988)
  136. ^ abcd RFC 1922 (1996)
  137. ^ "CVE-2024-2961".
  138. ^ "Vulnerabilidad GLIBC en servidores que sirven PHP".
  139. ^ ECMA-43 (1991), págs. 9-10, capítulo 8 ("Niveles")
  140. ^ ECMA-43 (1985), págs. 7-11, capítulo 7.3 ("El conjunto G0")
  141. ^ ECMA-43 (1991), págs. 6–8, capítulo 7.4 ("Conjunto G0")
  142. ^ ECMA-43 (1991), pág. 11, capítulo 10.3 ("Identificación de una versión")
  143. ^ ab ECMA-43 (1991), pág. 23, anexo E ("Principales diferencias entre la segunda edición (1985) y la actual (tercera) edición de esta Norma ECMA")
  144. ^ IPTC (1995). Formato de mensaje recomendado por el IPTC (PDF) (5.ª ed.). IPTC TEC 7901. Archivado (PDF) desde el original el 25 de enero de 2022. Consultado el 14 de enero de 2020 .
  145. ^ ECMA-43 (1991), págs. 10, capítulo 9.2 ("Codificación única de caracteres")
  146. ^ 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 desde el original el 2020-08-01 . Consultado el 2019-10-02 .
  147. ^ ECMA-43 (1991), págs. 10-11, capítulo 10 ("Identificación de versión y nivel")
  148. ^ IBM . «Character Data Representation Architecture (CDRA)». IBM . págs. 157–162. Archivado desde el original el 23 de junio de 2019 . Consultado el 18 de junio de 2020 .
  149. ^ Scheifler (1989)
  150. ^ Scheifler (1989), § Personajes de control
  151. ^ Scheifler (1989), § Direccionalidad
  152. ^ Scheifler (1989), § Codificaciones de juegos de caracteres estándar
  153. ^ Scheifler (1989), § Codificaciones estándar aprobadas
  154. ^ "DICOM PS3.2 2016d - Conformidad; D.6.2 Conjuntos de caracteres; D.6 Compatibilidad con conjuntos de caracteres". Archivado desde el original el 16 de febrero de 2020. Consultado el 21 de mayo de 2020 .
  155. ^ "Variación DICOM ISO 2022". Archivado desde el original el 30 de abril de 2013. Consultado el 25 de julio de 2009 .
  156. ^ ab Sivonen, Henri (17 de diciembre de 2018). "(BORRADOR NO ENVIADO) No hay generación de U+FFFD para contenido de estado ASCII de longitud cero entre secuencias de escape ISO-2022-JP" (PDF) . Archivado (PDF) desde el original el 21 de febrero de 2019 . Consultado el 21 de febrero de 2019 .
  157. ^ "935453 - Recopilamos telemetría sobre HZ y otras codificaciones que podríamos intentar eliminar". Archivado desde el original el 19 de mayo de 2017. Consultado el 18 de junio de 2018 .
  158. ^ Davis, Mark; Suignard, Michel (19 de septiembre de 2014). "3.6.2 Algunos resultados para todos los datos de entrada". Informe técnico Unicode n.° 36: Consideraciones de seguridad de Unicode (revisión 15) . Consorcio Unicode. Archivado desde el original el 22 de febrero de 2019. Consultado el 21 de febrero de 2019 .


Normas e índices de registro citados

Conjuntos de códigos registrados citados

Solicitudes de comentarios en Internet citadas

Otras obras publicadas citadas

Lectura adicional

Enlaces externos