stringtranslate.com

ISO/CEI 2022

ISO/IEC 2022 Tecnología de la información: estructura de códigos de caracteres y técnicas de extensión , es un estándar ISO / IEC en el campo de la codificación de caracteres . Es equivalente al estándar ECMA ECMA-35 , [1] [2] el estándar ANSI ANSI X3.41 [3] y el estándar industrial japonés JIS X 0202 . Originado en 1971, fue revisado por última vez en 1994. [4]

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 usarán para códigos de control no imprimibles [5] para formatear e instrucciones dentro de 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 puede utilizar para instrucciones dentro de banda. [6] Los conjuntos específicos de códigos de control y secuencias de escape diseñados para usarse con ISO 2022 incluyen ISO/IEC 6429 , partes del 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 usar para cambiar entre diferentes conjuntos de caracteres codificados (por ejemplo, entre ASCII y el JIS X 0208 japonés ) para usar múltiples en un solo documento, [7] combinando efectivamente en una única codificación con estado (una característica menos importante desde la llegada de Unicode ). Está diseñado para poder utilizarse tanto en entornos de 8 bits como en entornos de 7 bits (aquellos en los que sólo se pueden utilizar siete bits en un byte, como el correo electrónico sin 8BITMIME ). [8]

Codificaciones y conformidad

El juego de caracteres ASCII admite el alfabeto latino básico ISO (equivalente al alfabeto inglés ) y no proporciona una buena compatibilidad con 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 escritura latina que utilizan signos diacríticos o letras ausentes del alfabeto latino básico ISO, se han representado históricamente en ordenadores personales con diferentes formatos de 8 bits. Codificaciones ASCII extendidas de 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 ellos, como la serie ISO 8859 , cumplen con ISO 2022, [9] [10] mientras que otros, como la página de códigos 437 de DOS , 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 chino , japonés y coreano (colectivamente " CJK "), se escriben usando 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 caracteres dobles específicos del idioma. -codificaciones de bytes o codificaciones de ancho variable ; algunos de estos (como la codificación en chino simplificado GB 2312 ) se ajustan a ISO 2022 , mientras que otros (como la codificación en 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 los caracteres gráficos. Las codificaciones CJK utilizadas en entornos de 7 bits que utilizan mecanismos ISO 2022 para cambiar entre conjuntos de caracteres suelen recibir nombres que comienzan con "ISO-2022-", sobre todo ISO-2022-JP, aunque algunas otras codificaciones CJK como EUC-JP también hacer uso de los 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 agrega otros caracteres no imprimibles además de los códigos de control ISO 2022. Sin embargo, los formatos de transformación Unicode como UTF-8 generalmente se desvían de la estructura 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 al de ISO 2022", [13] que son compatibles con ciertos emuladores de terminal como xterm . [14]

Descripción general

Elementos

ISO/IEC 2022 especifica lo siguiente:

Versiones de código

Una implementación específica no tiene que implementar todo el estándar; el nivel de conformidad y los juegos 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 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 el código Unix extendido , que se utiliza para Oriente. Lenguas asiáticas . [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 particulares se registran en el registro ISO-IR (excepto aquellas reservadas para uso privado, cuyos significados están definidos por los proveedores o por especificaciones de protocolo como ARIB STD-B24 ) y seguir los patrones definidos dentro del estándar. Las codificaciones de caracteres que utilizan estas secuencias de escape requieren que los datos se procesen secuencialmente en dirección directa, ya que la interpretación correcta de los datos depende de secuencias de escape encontradas previamente.

Perfiles específicos como ISO-2022-JP pueden imponer condiciones adicionales, como que el juego de caracteres actual se restablezca a US-ASCII antes del final de una línea. Además, las secuencias de escape que declaran los juegos 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 juegos de caracteres nacionales particulares. Por ejemplo, ISO-8859-1 establece que no es necesario definir una secuencia de escape.

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 sólo se excluyen los códigos de control C0 (definidos estrictamente), esto se puede ampliar a 96 caracteres. Así, utilizando dos bytes, es posible representar hasta 8.836 (94×94) caracteres; y, utilizando tres bytes, hasta 830.584 (94×94×94) caracteres. Aunque el estándar lo define, ningún juego de caracteres registrado utiliza tres bytes (aunque el G2 no registrado de EUC-TW sí lo hace, al igual que el CCCII no registrado de manera similar ).

Para los juegos de caracteres de dos bytes, el punto de código de cada carácter normalmente se especifica en la denominada forma de celda de fila o kuten [a] , que comprende dos números entre 1 y 94 inclusive, especificando una fila [b] y una celda [ c] de ese personaje 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 sólo declaran qué juego de caracteres se está utilizando, sino también si el juego es de un solo byte o multibyte (aunque no cuántos bytes usa si es multibyte), 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 gran registro de conjuntos de caracteres gráficos sea "designado" [21] en uno de los cuatro conjuntos de trabajo, denominados G0 a G3, y secuencias de control más cortas especifican el conjunto de trabajo que se "invoca" [22] para interpretar. bytes en la secuencia.

Los valores de bytes de codificación ("combinaciones de bits") a menudo se dan en notación de líneas de columnas , 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] Pueden describirse en otros lugares usando hexadecimal , como se usa a menudo en este artículo, o usando los caracteres ASCII correspondientes, [25] aunque las secuencias de escape en realidad se definen en términos de valores de bytes y el gráfico asignado a ese valor de bytes. puede ser alterado 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á disponible (es decir, en un entorno de 8 bits), se denominan códigos "GR" ("derecho de gráficos") . [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 primarios (C0). controles secundarios (C1) o no se utiliza. [5]

Caracteres codificados fijos

El carácter de eliminación 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 a través de GL, independientemente de qué conjuntos de caracteres sean. designada. Es posible que no se incluyan en conjuntos de caracteres gráficos, aunque es posible que se incluyan otros tamaños o tipos de caracteres de espacios 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 va seguido de 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 la ausencia del mismo, determina el tipo de secuencia de escape; podría, por ejemplo, designar un conjunto de trabajo o denotar una función de control única. 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 utilizar más bytes siguiendo 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 por un solo byte en el rango 0x40–0x7E, denominándose la secuencia completa "secuencia de control". [32]

Juegos 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, de 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 el conjunto. En un conjunto de 94 o 94 n caracteres, los bytes 0x20 y 0x7F no se utilizan. [33] Cuando se invoca un conjunto de caracteres de 96 o 96 n 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 caracteres de 94 o 94 n (como el conjunto G0 ) se invoca 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 el conjunto realmente asigne los bytes 0x20/A0 y 0x7F/FF; 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 dibujos 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 personajes

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

El uso de retroceso y retorno de carro de esta manera está permitido por ISO/IEC 646 pero prohibido por ISO/IEC 4873 / ECMA-43 [39] y por ISO/IEC 8859 , [40] [41] sobre la base de que sale el repertorio gráfico de personajes indefinido. ISO/IEC 4873 / ECMA-43, sin embargo, 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 sobreestamparse para formar un carácter con un significado diferente. . [42]

Controlar conjuntos de caracteres

Los juegos de caracteres de control se clasifican como juegos de códigos de control "primarios" o "secundarios", [43] también llamados respectivamente juegos 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 no puede contener ningún control de escape. . [33] Por lo tanto, son registros completamente separados, siendo un conjunto C0 solo un conjunto C0 y un conjunto C1 siendo 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, deben aparecer en sus ubicaciones ISO 6429/ECMA-48. [45] 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 de 0x00 a 0x1F, [48] mientras que una función de control C1 se puede invocar en el rango CR de 0x80 a 0x9F (en un entorno de 8 bits) o mediante el uso de secuencias de escape (en un entorno de 7 bits). entorno de 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, la invocación que se utiliza puede comunicarse utilizando secuencias de locutores.

En el último caso, las funciones de control únicas del conjunto de códigos de control C1 se invocan utilizando secuencias de escape "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 (@)a través de ESC 0x5F (_)). [51]

Otras funciones de control

Se asignan funciones de control adicionales a las secuencias de escape "tipo Fs" (en el rango ESC 0x60 (`)hasta ESC 0x7E (~)); estos tienen significados asignados permanentemente en lugar de depender de las designaciones C0 o C1. [51] [52] El registro de funciones de control para secuencias tipo "Fs" debe ser aprobado por ISO/IEC JTC 1/SC 2 . [52] Se pueden registrar otras funciones de control único para escribir secuencias de escape "3Ft" (en el rango hasta ), [53] aunque actualmente no hay secuencias "3Ft" asignadas (a partir de 2019). [54] Algunos de estos se especifican en ECMA-35 (ISO 2022 / ANSI X3.41), otros en ECMA-48 (ISO 6429 / ANSI X3.64). [55] ECMA-48 se refiere a éstas como "funciones de control independientes". [56]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, previo acuerdo 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

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

Un código de 8 bits puede tener códigos GR que especifican caracteres G1, es decir, con su correspondiente código de 7 bits que utiliza 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 G2. caracteres, con el código de 7 bits correspondiente utilizando un código de turno único para acceder al segundo conjunto (por ejemplo, T.51 ). [61]

Los códigos que se muestran en la siguiente tabla son las codificaciones más comunes de estos códigos de control, conforme a ISO/IEC 6429 . Los cambios LS2, LS3, LS1R, LS2R y LS3R se registran como funciones de control únicas y siempre se codifican como las secuencias de escape que se enumeran a continuación, [54] mientras que los demás son 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 dependiendo de qué conjuntos de controles se designen: deben estar presentes en los conjuntos de controles designados si se utiliza su funcionalidad. . [48] ​​[49] Los propios controles C1, como se mencionó anteriormente, pueden representarse mediante secuencias de escape o bytes de 8 bits, pero no ambos.

En determinados conjuntos de códigos de control están disponibles codificaciones alternativas de los turnos únicos 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] 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, [63] y también se puede usar solo para SS2, [64] aunque el código más antiguo También existen conjuntos con SS2 en 0x1C, [65] [66] [67] y se mencionaron como tales en una edición anterior del estándar. [68] La codificación 0x8E y 0x8F de los turnos únicos como se muestra a continuación es obligatoria para ISO/IEC 4873 niveles 2 y 3. [69]

Aunque oficialmente se consideran códigos de turno y se denominan en consecuencia, los códigos de turno único no siempre se consideran turnos [12] y pueden verse simplemente como bytes de prefijo (es decir, los primeros bytes en una secuencia de varios bytes), [11] ya que no requiere 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 utilizar GL o GR, pero no ambos, como área de turno único. Esto debe especificarse 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 se utiliza GL como área de turno único. [74] [75] Si es necesario, se puede comunicar qué área de turno único se utiliza mediante secuencias de locutores.

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

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

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

El registro internacional ISO de juegos de caracteres codificados para usar con secuencias de escape (ISO-IR) enumera juegos de caracteres gráficos, juegos de códigos de control, códigos de control únicos, etc. que se han registrado para su uso con ISO/IEC 2022. El procedimiento para registrar Los códigos y conjuntos con el registro ISO-IR están especificados en 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 juego de caracteres CCITT para chino simplificado se conoce como ISO-IR-165 .

El registro de juegos de caracteres codificados en el registro ISO-IR identifica los documentos que especifican el juego de caracteres o la función de control asociada con una secuencia de escape de uso no privado ISO/IEC 2022. Este puede ser un documento estándar; sin embargo, el registro no crea un nuevo estándar ISO, no compromete a ISO o IEC a adoptarlo como estándar internacional, y no compromete a ISO o IEC a agregar cualquiera 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 SGML para los conjuntos de caracteres admitidos. [80]

Designaciones de juegos de caracteres

Las secuencias de escape para designar conjuntos de caracteres toman 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 juego de caracteres y el conjunto de trabajo al que se designará, mientras que el byte F (y cualquier byte I adicional ) identifica el juego de caracteres. sí mismo, tal como está asignado en el registro ISO-IR (o, para las secuencias de fuga de uso privado, mediante acuerdo previo).ESC I [I...] F

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

Al igual que con otros tipos de secuencias de escape, el rango 0x30–0x3F está reservado para F bytes 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 gráfica de designación de conjuntos, 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 indicado es un " conjunto de caracteres dinámicamente redefinible " (DRCS) definido mediante acuerdo previo, [85] que también se considera de uso privado. [31] Un conjunto gráfico que se considera DRCS implica que representa una fuente de glifos exactos, en lugar de un conjunto de caracteres abstractos. [86] La forma en que se transmiten, asignan y gestionan los conjuntos DRCS y las fuentes asociadas no está estipulada por la propia ISO/IEC 2022/ECMA-35, aunque recomienda asignarlos secuencialmente comenzando con el byte F 0x40 ( @); [87] sin embargo, dentro de algunos protocolos de telecomunicaciones, como World System Teletext , se define una forma de transmitir fuentes DRCS. [88]

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

Hay características adicionales (rara vez utilizadas) para cambiar conjuntos de caracteres de control, pero esta es una búsqueda de un solo nivel, en el sentido de que (como se indicó anteriormente) el conjunto C0 siempre se invoca a través de CL, y el conjunto C1 siempre se invoca a través de CR o mediante utilizando códigos de escape. Como se señaló anteriormente, es necesario que cualquier conjunto de caracteres C0 incluya el carácter ESC en la posición 0x1B, para que sean posibles más cambios. Las secuencias de designación de conjuntos de control (a diferencia de las secuencias de conjuntos gráficos) también se pueden usar desde ISO/IEC 10646 (UCS/Unicode), en contextos donde el procesamiento de códigos de escape ANSI es apropiado, siempre que cada byte en la secuencia se complete para el tamaño de la unidad de código de la codificación. [90]

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

Tenga en cuenta que el registro de F bytes 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 $ + Ay 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 juegos de caracteres de control C0 y C1 son independientes; el juego de caracteres de control C0 designado por ESC ! A(que resulta ser el juego de control NATS para la transmisión de texto de periódicos) no es el mismo que el juego de caracteres de control C1 designado por ESC " A(el juego de control de atributos CCITT para videotex ).

Interacción con otros sistemas de codificación.

El estándar 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 codificada en ISO/IEC 2022 comprenden (a partir de 2019) varios formatos 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 regresar a ISO 2022; Es posible que tengan sus propios medios para regresar 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. Estos 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 usan 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 enumera como obsoleto. [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 % Ges la que admite, 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, el 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 X Consortium define cinco secuencias DOCS de uso privado. [108]

Anuncios de estructura de código

La secuencia "anunciar estructura de código" ( ) se utiliza para anunciar una estructura de código específica o un grupo específico de instalaciones ISO 2022 que se utilizan en una versión de código particular. Aunque los anuncios se pueden combinar, el estándar prohíbe ciertas combinaciones contradictorias (específicamente, el uso de anuncios de cambio de bloqueo 16 a 23 con los anuncios 1, 3 y 4), al igual que el uso de anuncios adicionales además de los anuncios de nivel ISO/IEC 4873 12 a 14. [92] (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

(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 son compatibles con Mozilla Firefox a partir de 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 definidos por los RFC del IETF , de los cuales ISO-2022-JP e ISO-2022-KR se han utilizado ampliamente en el pasado. [109] Los proveedores, incluido IBM , definen otras variantes . [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 siga siendo compatible, [111] a diferencia del mapeo 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 Código Unix extendido . [11] [12] Las codificaciones ISO/IEC 8859 también siguen la norma ISO 2022, en un subconjunto estipulado en ISO/IEC 4873. [9] [10]

Versiones de correo electrónico japonés

ISO-2022-JP

ISO-2022-JP es una codificación muy utilizada para el japonés, en particular enel correo electrónico. Fue introducido para su uso en la red JUNET y posteriormente codificado enIETF RFC1468, de 1993.[114]Tiene la ventaja sobre otrascodificaciones para japonésde que no requierelimpia de 8 bits. Microsoft la llamaPá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 que fuera posible designar conjuntos de varios bytes, excepto G0, los escapes para JIS X 0208 no incluyen el segundo I -byte (. [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 deben cambiarse mediante sistemas que simplemente transmitan mensajes como correos electrónicos. [114] El estándar de codificación WHATWG al que hace referencia HTML5 maneja ESC ( By ESC ( Jdiferencia, pero trata ESC $ @de la misma manera que ESC $ Bal decodificar y usa solo ESC $ BJIS 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 alejarse de JIS X 0208, que en realidad está registrado para ISO-IR-11 (una variante sueca de ISO 646 y Teletexto del sistema mundial ). [114] [yo]

Versiones con katakana de medio ancho

El uso de ESC ( Ipara cambiar al conjunto Kana JIS X 0201-1976 (1 byte por carácter) no forma parte del perfil ISO-2022-JP, [114] pero a veces también se utiliza. 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 ); [117] [118] esto se acerca tanto en nombre como en estructura a una codificación denominada ISO-2022-JPext por DEC , que además agrega una región de dos bytes definida por el usuario a la que se accede 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 permitido adicionalmente es la 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, usando 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 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 . [115]

ISO-2022-JP-2

ISO-2022-JP-2 es una extensión multilingüe de ISO-2022-JP, definida en RFC 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 pueden designarse como G0 y se accede a ellas desde G2 utilizando la forma de secuencia de escape de 7 bits del código de turno único SS2:[121]

ISO-2022-JP con la representación ISO-2022-JP-2 de JIS X 0212, pero no las otras extensiones, fue posteriormente denominado 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 en conjunto se denominan "juegos de caracteres codificados en japonés TCP/IP". [123] CCSID 9148 es la norma (RFC 1468) ISO-2022-JP. [124]

JIS X 0213

El estándar JIS X 0213 , publicado 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 el estándar básico JIS X 0208 dieron como resultado un nuevo registro para el plano JIS 1 extendido, mientras que el nuevo plano 2 recibió su propio registro. Las nuevas adiciones al plano 1 en la edición de 2004 de la norma dieron como resultado la adición de un registro adicional a una revisión adicional 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

ISO-2022-KR se define en RFC 1557, de 1993.[133]Codifica ASCII y el doble byte coreanoKS X 1001-1992,[134][135]anteriormente denominado KS C 5601-1987. A diferencia de 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 eISO-2022-CN-EXTestán definidas en 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 de las formas de código de escape de 7 bits de las funciones de turno único SS2 y SS3 (para acceder a G2 y G3).[136]Admiten los juegos de caracteresGB 2312(parachino simplificado) yCNS 11643(parachino tradicional).

El perfil básico ISO-2022-CN utiliza ASCII como su conjunto G0 (cambio 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) . al cual el RFC proporciona 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 adicionales como permitidos, pero condicionados a que se les asignen secuencias de escape ISO 2022 registradas: [136]

El carácter después de ESC(para juegos de caracteres de un solo byte) o ESC $(para juegos de caracteres de varios bytes) especifica el tipo de juego de caracteres y el juego de trabajo al que está designado. 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, en ocasiones, 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 todas las entradas al carácter de reemplazo (�), para evitar ciertas secuencias de comandos entre sitios y 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 usan con mucha más frecuencia en el contenido implementado. [111]

ISO/CEI 4873

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

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

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

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 otras posiciones se asignaran a caracteres espaciados (no combinados), que 0x23 se asignara a £ o #. , y ese 0x24 fue asignado a $ o ¤ . [138] Por ejemplo, la codificación de 8 bits de JIS X 0201 es compatible con ediciones anteriores. Esto se cambió posteriormente para especificar completamente el conjunto ISO/IEC 646:1991 IRV / ISO-IR No. 6 (ASCII). [139] [140] [141]

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

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

ISO/IEC 8859 define codificaciones completas en el nivel 1 de ISO/IEC 4873 y no permite el uso de varias partes de ISO/IEC 8859 juntas. Estipula que ISO/IEC 10367 debe usarse en su lugar 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, las que existían en 1991, cuando se publicó) y algunos conjuntos complementarios. [144]

Las secuencias de escape de designación de juegos 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 locutor ISO/IEC 2022 que especifique el nivel ISO/IEC 4873, seguida de un conjunto completo. de escapes que especifican las designaciones del juego 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 indica un conjunto vacío. Cada nivel ISO/IEC 4873 tiene su propia secuencia de locutor ISO/IEC 2022, que es la siguiente: [145]

Código Unix extendido

El código Unix extendido (EUC) es un sistema de codificación de caracteres de ancho variable de 8 bits que se utiliza principalmente en japonés , coreano y chino simplificado . Se basa en ISO 2022 y solo los juegos de caracteres que se ajusten a la estructura ISO 2022 pueden tener formularios EUC. Se pueden representar hasta cuatro juegos de caracteres codificados (en G0, G1, G2 y G3). El conjunto G0 se invoca a través de GL, el conjunto G1 se invoca a través de GR y los conjuntos G2 y G3 (si están presentes) se invocan utilizando los desplazamientos únicos SS2 y SS3, que se utilizan como bytes CR (es decir, 0x8E y 0x8F respectivamente) y invocar sobre GR (no GL). [11] No se utilizan códigos de cambio 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 juego de caracteres codificados de 94x94 representados en dos bytes. La forma EUC-CN de GB 2312 y EUC-KR son ejemplos de códigos EUC de dos bytes. EUC-JP incluye caracteres representados por hasta tres bytes (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 el locutor ni las secuencias de designación de ISO 2022; sin embargo, corresponde a la siguiente secuencia de cuatro secuencias de locutores, cuyos significados se desglosan de la siguiente manera. [146]

Texto compuesto (X11)

El Consorcio X definió un perfil ISO 2022 llamado Texto compuesto como formato de intercambio en 1989. [147] 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 ), [148] con la secuencia SDS ( ) CSI utilizada para el control de texto bidireccional. [149] 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. [150] Se utilizan los siguientes bytes F:0x090x0A 0x1B0x9BCSI … ]

Para especificar codificaciones mediante 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 usando 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

Ver también

Notas a pie de página

  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 :, romanizadodiez , iluminado. 'punto'; Chino :; pinyin : wei ; iluminado. 'posición'; Coreano ; Hanja; RR : 
  4. ^ Japonés :, romanizadohombres , iluminado. 'rostro'
  5. ^ ab Especificado para F bytes 0x40 ( @), 0x41 ( A) y 0x42 ( B) únicamente, por razones históricas. [89] Algunas implementaciones, como la codificación de emoji SoftBank 2G , utilizan escapes adicionales de este formulario para fines que no cumplen con ISO-2022. [96]
  6. ^ Listado por MARC-8 . [3] Consulte la nota a pie de página a continuación para conocer los antecedentes.ESC , F
  7. ^ F , ajustado al rango 1-63, indica qué revisión (compatible hacia arriba) 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 para designar conjuntos adicionales de 94 caracteres para G0. [98] Dado que los conjuntos de 96 caracteres no pueden designarse para G0, este primer byte no se utiliza en la edición actual del estándar. Sin embargo, todavía figura en MARC-8 . [3]
  9. ^ Véase también, por ejemplo, Printronix (2012), Manual de referencia del programador de OKI® (PDF) , p. 26para un sistema más reciente que utiliza ESC ( Hpara cambiar 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 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 Internacional . Archivado desde el original el 25 de abril de 2022 . Consultado el 27 de abril de 2022 .
  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. ^ abcdeISO/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. ^ ab ISO-IR-196 (1996)
  14. ^ abc Moy, Eduardo; Gildea, Esteban; Dickey, Thomas. "Controles que comienzan con ESC". Secuencias de control XTerm . Archivado desde el original el 10 de octubre de 2019 . Consultado el 4 de octubre de 2019 .
  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 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. ^ 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. ^ a b C 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 30 de abril de 2022 . Consultado el 14 de septiembre de 2019 .
  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 juego de caracteres codificados")
  41. ^ ECMA-144 (2000), pág. 3, capítulo 6 ("Especificación del juego 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. ^ a b C 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, pag. 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). Restablecer al estado inicial (RIS) (PDF) . ITSCJ/ IPSJ . ISO-IR -35.{{citation}}: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace )
  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. ^ ab UIT-T (11 de agosto de 1995). Recomendación T.51 (1992) Enmienda 1. Archivado desde el original el 2020-08-02 . Consultado el 25 de diciembre de 2019 .
  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. ^ ab 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. ^ a b C ECMA-35 (1994), pág. 19, capítulo 8.4
  73. ^ a b C 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, pag. 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, pag. 10, capítulo 2.2 ("Juego 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 Bretón, Stefan; Hamilton, Richard L. "Acerca del 'conjunto de caracteres de dibujo lineal 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 300706 (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. ^ Digitales . "DECDWL: línea de doble ancho y altura única". Información del programador del terminal de vídeo VT510 . Archivado desde el original el 2020-08-02 . Consultado el 17 de enero de 2020 .
  96. ^ Kawasaki, Yusuke (2010). "Codificar::JP::Emoji::Codificación". Codificar-JP-Emoji . Línea 268. Archivado desde el original el 30 de abril de 2022 . Consultado el 28 de mayo de 2020 .
  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, pag. 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. ^ abcdeISO -IR, pag. 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. ^ a b C 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" "Aquellas codificaciones que se han utilizado ampliamente en el pasado o que se siguen utilizando hoy en día para algunos fines, han sido destacados."
  110. ^ ab "Información requerida adicional relacionada con la codificación". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 7 de enero de 2015.
  111. ^ abc Estándar de codificación WHATWG, sección 2 ("Antecedentes de seguridad")
  112. ^ abc WHATWG Encoding Standard, capítulo 4.2 ("Nombres y etiquetas"), ancla "reemplazo"
  113. ^ abcd Estándar 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 16 de junio de 2019 . Consultado el 16 de septiembre de 2019 .
  116. ^ ab Estándar de codificación WHATWG, sección 12.2 ("ISO-2022-JP")
  117. ^ Chang, Hye-Shik. "Módulos/cjkcodecs/_codecs_iso2022.c, línea 1122". Árbol fuente de cPython . Fundación de software Python. Archivado desde el original el 30 de abril de 2022 . Consultado el 15 de septiembre de 2019 .
  118. ^ "códecs: registro de códecs y clases base § Codificaciones estándar". Documentación de Python 3.7.4 . Fundación de software Python. 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 . Corporación de Equipos Digitales , 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: codificación JIS"
  121. ^ RFC 1554 (1993)
  122. ^ RFC 2237 (1997)
  123. ^ "PQ02042: Nueva función para proporcionar compatibilidad con C/370 iconv() para ISO-2022-JP japonés". IBM . 2021-01-19. Archivado desde el original el 4 de enero de 2022 . Consultado el 4 de enero de 2022 .
  124. ^ ab "CCSID 9148". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  125. ^ "CCSID 956". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 2 de diciembre de 2014.
  126. ^ "CCSID 957". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 30 de noviembre de 2014.
  127. ^ "CCSID 958". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 1 de diciembre de 2014.
  128. ^ "CCSID 959". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 2 de diciembre de 2014.
  129. ^ "CCSID 5052". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  130. ^ "CCSID 5053". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  131. ^ "CCSID 5054". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  132. ^ "CCSID 5055". Globalización de IBM: identificadores de conjuntos de caracteres codificados . IBM . Archivado desde el original el 29 de noviembre de 2014.
  133. ^ ab 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. ^ ECMA-43 (1991), págs. 9-10, capítulo 8 ("Niveles")
  138. ^ ECMA-43 (1985), págs. 7-11, capítulo 7.3 ("El conjunto G0")
  139. ^ ECMA-43 (1991), págs. 6 a 8, capítulo 7.4 ("conjunto G0")
  140. ^ ECMA-43 (1991), pág. 11, capítulo 10.3 ("Identificación de una versión")
  141. ^ ab 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")
  142. ^ IPTC (1995). El formato de mensaje recomendado por 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 .
  143. ^ ECMA-43 (1991), págs. 10, capítulo 9.2 ("Codificación única de caracteres")
  144. ^ van Wingen, Johan W (1999). "8. Extensión de Código, ISO 2022 y 2375, ISO 4873 y 10367". Conjuntos de caracteres. Letras, fichas y códigos . Terena. Archivado desde el original el 1 de agosto de 2020 . Consultado el 2 de octubre de 2019 .
  145. ^ ECMA-43 (1991), págs. 10-11, capítulo 10 ("Identificación de versión y nivel")
  146. ^ IBM . "Arquitectura de representación de datos de caracteres (CDRA)". IBM . págs. 157-162. Archivado desde el original el 23 de junio de 2019 . Consultado el 18 de junio de 2020 .
  147. ^ Scheifler (1989)
  148. ^ Scheifler (1989), § Personajes de control
  149. ^ Scheifler (1989), § Direccionalidad
  150. ^ Scheifler (1989), § Codificaciones de juegos de caracteres estándar
  151. ^ Scheifler (1989), § Codificaciones estándar aprobadas
  152. ^ "DICOM PS3.2 2016d - Conformidad; conjuntos de caracteres D.6.2; compatibilidad con conjuntos de caracteres D.6". Archivado desde el original el 16 de febrero de 2020 . Consultado el 21 de mayo de 2020 .
  153. ^ "Variación DICOM ISO 2022". Archivado desde el original el 30 de abril de 2013 . Consultado el 25 de julio de 2009 .
  154. ^ ab Sivonen, Henri (17 de diciembre de 2018). "(BORRADOR NO PRESENTADO) Sin generación 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 .
  155. ^ "935453: recopile 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 .
  156. ^ Davis, marca; Suignard, Michel (19 de septiembre de 2014). "3.6.2 Algunas salidas para todas las entradas". Informe técnico de 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 .


Estándares e índices de registro citados

Conjuntos de códigos registrados citados

Solicitudes de comentarios en Internet citadas

Otros trabajos publicados citados

Otras lecturas

enlaces externos