ISO/CEI 2022 - ISO/IEC 2022

ISO / IEC 2022 Structure de code technologie caractères Informations et techniques d' extension , est une ISO standard (équivalent à l' ECMA norme ECMA-35 , l' ANSI norme ANSI X3.41 et la norme industrielle japonaise JIS X 0202 ) spécifiant:

• Infrastructure de plusieurs jeux de caractères avec des structures particulières qui peuvent être incluses dans un système de codage de caractères unique, comprenant plusieurs jeux de caractères graphiques et plusieurs jeux de codes de contrôle à la fois primaires (C0) et secondaires (C1) ,
• Un format d'encodage de ces ensembles, en supposant que 8 bits sont disponibles par octet,
• Un format pour coder ces ensembles dans le même système de codage lorsque seulement 7 bits sont disponibles par octet, et une méthode pour transformer toute donnée de caractère conforme pour passer par un tel environnement 7 bits,
• La structure générale des codes d'échappement ANSI , et
• Formats de code d'échappement spécifiques pour identifier des jeux de caractères individuels, pour annoncer l'utilisation de caractéristiques ou de sous-ensembles de codage particuliers, et pour interagir avec ou basculer vers d'autres systèmes de codage.

La plupart des jeux de caractères inclus en tant que codages ISO/IEC 2022 sont des codages à « double octet », où deux octets correspondent à un seul caractère. Cela fait de l'ISO-2022 un codage à largeur variable. Mais une implémentation spécifique n'a pas à implémenter toute la norme ; le niveau de conformité et les jeux de caractères pris en charge sont définis par la mise en œuvre.

Bien que de nombreux mécanismes définis par la norme ISO/IEC 2022 soient rarement utilisés, plusieurs codages établis sont basés sur un sous-ensemble du système ISO/IEC 2022. En particulier, les systèmes de codage 7 bits utilisant les mécanismes ISO/IEC 2022 incluent ISO-2022-JP (ou codage JIS ), qui a été principalement utilisé dans les e-mails en japonais . Les systèmes de codage 8 bits conformes à ISO/IEC 2022 incluent ISO/IEC 4873 (ECMA-43), qui est à son tour conforme à ISO/IEC 8859 , et Extended Unix Code , qui est utilisé pour les langues d' Asie de l'Est . Des applications plus spécialisées d'ISO 2022 incluent le système de codage MARC-8 utilisé dans les notices de bibliothèque MARC 21 .

introduction

De nombreuses langues ou familles de langues non basées sur l' alphabet latin, telles que le grec , le cyrillique , l' arabe ou l' hébreu, ont historiquement été représentées sur des ordinateurs avec différents codages ASCII étendus sur 8 bits . Les langues écrites d'Asie de l'Est , en particulier le chinois , le japonais et le coréen , utilisent beaucoup plus de caractères que ce qui peut être représenté dans un octet d' ordinateur de 8 bits et ont d'abord été représentés sur des ordinateurs avec des codages à double octet spécifiques à la langue .

ISO/IEC 2022 a été développé comme une technique pour s'attaquer à ces deux problèmes : pour représenter des caractères dans plusieurs jeux de caractères dans un seul codage de caractères et pour représenter de grands jeux de caractères.

Une deuxième exigence de la norme ISO-2022 était qu'elle devait être compatible avec les canaux de communication 7 bits. Ainsi, même si ISO-2022 est un jeu de caractères de 8 bits, toute séquence de 8 bits peut être réencodée pour n'utiliser que 7 bits sans perte et normalement seulement une petite augmentation de taille.

Pour représenter plusieurs jeux de caractères, les codages de caractères ISO/IEC 2022 incluent des séquences d'échappement qui indiquent le jeu de caractères pour les caractères qui suivent. Les séquences d'échappement sont enregistrées auprès de l'ISO et suivent les modèles définis dans la norme. Ces codages de caractères nécessitent que les données soient traitées séquentiellement dans le sens direct car l'interprétation correcte des données dépend des séquences d'échappement rencontrées précédemment. Notez, cependant, que d'autres normes telles que ISO-2022-JP peuvent imposer des conditions supplémentaires telles que le jeu de caractères actuel est réinitialisé à US-ASCII avant la fin d'une ligne.

Pour représenter de grands jeux de caractères, ISO/IEC 2022 s'appuie sur la propriété ISO/IEC 646 selon laquelle un caractère à sept bits définira normalement 94 caractères graphiques (imprimables) (en plus de l'espace et des 33 caractères de contrôle). En utilisant deux octets, il est ainsi possible de représenter jusqu'à 8 836 (94x94) caractères ; et, en utilisant trois octets, jusqu'à 830 584 (94 × 94 × 94) caractères. Bien que la norme le définisse, aucun jeu de caractères enregistré n'utilise trois octets (bien que le G2 non enregistré d' EUC-TW le fasse). Pour les jeux de caractères à deux octets, le point de code de chaque caractère est normalement spécifié sous la forme dite kuten (japonais :区点) (parfois appelée qūwèi (chinois :区位), en particulier lorsqu'il s'agit de GB2312 et des normes connexes), qui spécifie une zone (区, japonais : ku , chinois : qū ), et le point (japonais:点 ten ) ou la position (chinois:位 wèi ) de ce caractère dans la zone.

Les séquences d'échappement ne déclarent donc pas seulement quel jeu de caractères est utilisé, mais aussi, en connaissant les propriétés de ces jeux de caractères, savent si un codage de 94, 96, 8 836 ou 830 584 caractères (ou une autre taille) est en cours de traitement.

En pratique, les séquences d'échappement déclarant les jeux de caractères nationaux peuvent être absentes si le contexte ou la convention dicte qu'un certain jeu de caractères nationaux doit être utilisé. Par exemple, ISO-8859-1 stipule qu'aucune séquence d'échappement de définition n'est nécessaire et RFC 1922, qui définit ISO-2022-CN, autorise l'utilisation des caractères SHIFT ISO-2022 sans utilisation explicite de séquences d'échappement.

Les définitions ISO-2022 des jeux de caractères ISO-8859-X sont des combinaisons fixes spécifiques des composants qui forment ISO-2022. Spécifiquement, les caractères de contrôle inférieurs (C0), le jeu de caractères US-ASCII (en GL) et les caractères de contrôle supérieurs (C1) sont standard et les caractères élevés (GR) sont définis pour chacune des variantes ISO-8859-X ; par exemple, ISO-8859-1 est défini par la combinaison de ISO-IR-1, ISO-IR-6, ISO-IR-77 et ISO-IR-100 sans décalage ni changement de caractère autorisé.

Bien que les jeux de caractères ISO/IEC 2022 utilisant des séquences de contrôle soient encore couramment utilisés, en particulier ISO-2022-JP, la plupart des applications de messagerie modernes se convertissent pour utiliser les transformations Unicode plus simples telles que UTF-8 . Les encodages qui n'utilisent pas de séquences de contrôle, tels que les ensembles ISO-8859 sont encore très courants.

Structure du code

Notation et nomenclature

Le codage ISO/IEC 2022 spécifie un mappage à deux couches entre les codes de caractères et les caractères affichés. Les séquences d'échappement permettent à n'importe lequel d'un grand registre de jeux de caractères graphiques d'être "désigné" dans l'un des quatre jeux de travail, nommés G0 à G3, et des séquences de contrôle plus courtes spécifient le jeu de travail qui est "invoqué" pour interpréter les octets dans le flux.

Les valeurs d'octet de codage ("combinaisons de bits") sont souvent données en notation colonne-ligne , où deux nombres décimaux compris entre 00 et 15 (chacun correspondant à un seul chiffre hexadécimal) sont séparés par une barre oblique. Ainsi, par exemple, les codes 2/0 (0x20) à 2/15 (0x2F) inclus peuvent être appelés "colonne 02". C'est la notation utilisée dans la norme ISO/IEC 2022 / ECMA-35 elle-même. Ils peuvent être décrits ailleurs en utilisant hexadécimal , comme c'est souvent utilisé dans cet article, ou en utilisant les caractères ASCII correspondants, bien que les séquences d'échappement soient en fait définies en termes de valeurs d'octet, et le graphique attribué à cette valeur d'octet peut être modifié sans affecter le séquence de contrôle.

Les valeurs d'octets de la plage graphique ASCII 7 bits (hexadécimal 0x20-0x7F), se trouvant sur le côté gauche d'une table de codes de caractères, sont appelées codes « GL » (avec « GL » signifiant « graphiques à gauche ») tandis que les octets de la plage « ASCII élevée » (0xA0–0xFF), si disponible (c'est-à-dire dans un environnement 8 bits), sont appelés codes « GR » (« droits graphiques ») . Les termes "CL" (0x00-0x1F) et "CR" (0x80-0x9F) sont définis pour les plages de contrôle, mais la plage CL appelle toujours les commandes primaires (C0), tandis que la plage CR appelle toujours soit les commandes secondaires (C1 ) contrôle ou n'est pas utilisé.

Caractères codés fixes

Le caractère de suppression DEL (0x7F), le caractère d'échappement ESC (0x1B) et le caractère d'espacement SP (0x20) sont des caractères codés "fixes" et sont toujours disponibles lorsque G0 est invoqué sur GL, quels que soient les jeux de caractères désignés. Ils peuvent ne pas être inclus dans les jeux de caractères graphiques, bien que d'autres tailles ou types de caractères d'espacement puissent l'être.

Syntaxe générale des séquences d'échappement

Les séquences utilisant le caractère ESC (échappement) prennent la forme , où le caractère ESC est suivi de zéro ou plusieurs octets intermédiaires ( I ) de la plage 0x20-0x2F, et un octet final ( F ) de la plage 0x30-0x7E. ESC [I...] F

Le premier octet I , ou son absence, détermine le type de séquence d'échappement ; il pourrait, par exemple, désigner un ensemble de travail, ou désigner une fonction de contrôle unique. Dans tous les types de séquences d'échappement, les octets F compris entre 0x30 et 0x3F sont réservés à des usages privés non enregistrés définis par accord préalable entre les parties.

Jeux de caractères graphiques

Chacun des quatre ensembles de travail G0 à G3 peut être un ensemble de 94 caractères ou un ensemble multi-octets de 94 ⁿ caractères . De plus, G1 à G3 peut être un jeu de 96 ou 96 ⁿ caractères.

Dans un ensemble de 96 ou 96 ⁿ caractères, les octets 0x20 à 0x7F lorsque GL-invoqué, ou 0xA0 à 0xFF lorsque GR-invoqué, sont alloués et peuvent être utilisés par l'ensemble. Dans un ensemble de 94 ou 94 ⁿ caractères, les octets 0x20 et 0x7F ne sont pas utilisés. Lorsqu'un jeu de caractères ⁿ 96 ou 96 est invoqué dans la région GL, les caractères d'espacement et de suppression (codes 0x20 et 0x7F) ne sont pas disponibles tant qu'un jeu de caractères ⁿ 94 ou 94 (tel que le jeu G0) est invoqué. en GL. Les jeux de 96 caractères ne peuvent pas être affectés à G0.

L'enregistrement d'un ensemble comme un ensemble de 96 caractères ne signifie pas nécessairement que les octets 0x20/A0 et 0x7F/FF sont réellement affectés par l'ensemble ; quelques exemples de jeux de caractères graphiques qui sont enregistrés en tant que jeux de 96 mais n'utilisent pas ces octets incluent le jeu G1 de IS 434 , le jeu de dessins de boîte de ISO/IEC 10367 et ISO-IR-164 (un sous-ensemble du jeu G1 de la norme ISO-8859-8 avec uniquement les lettres, utilisées par le CCITT ).

Combiner des personnages

Les caractères sont censés être des caractères d'espacement, et non des caractères de combinaison, sauf indication contraire de l'ensemble graphique en question. ISO 2022 / ECMA-35 reconnaît également l'utilisation des caractères de contrôle de retour arrière et de chariot comme moyen de combiner des caractères d'espacement, ainsi que la séquence CSI « Combinaison de caractères graphiques » (GCC) ( CSI 0x20 (SP) 0x5F (_)).

L'utilisation du retour arrière et du retour chariot de cette manière est autorisée par ISO/IEC 646 mais interdite par ISO/IEC 4873 / ECMA-43 et par ISO/IEC 8859 , au motif qu'elle laisse le répertoire de caractères graphiques indéfini. L'ISO/CEI 4873 / ECMA-43 autorise cependant l'utilisation de la fonction GCC sur la base que la séquence de caractères est conservée la même et simplement affichée dans un espace, plutôt que d'être surestampée pour former un caractère avec un sens différent.

Jeux de caractères de contrôle

Les jeux de caractères de contrôle sont classés en jeux de caractères de contrôle "principaux" ou "secondaires", respectivement également appelés jeux de caractères de contrôle "C0" et "C1".

Un jeu de contrôle C0 doit contenir le caractère de contrôle ESC (échappement) à 0x1B (un jeu C0 contenant uniquement ESC est enregistré comme ISO-IR-104), alors qu'un jeu de contrôle C1 peut ne pas contenir le contrôle d'échappement du tout. Par conséquent, ce sont des enregistrements entièrement séparés, un ensemble C0 n'étant qu'un ensemble C0 et un ensemble C1 n'étant qu'un ensemble C1.

Si des codes de l'ensemble C0 de la norme ISO 6429 / ECMA-48, c'est-à-dire les codes de contrôle ASCII , apparaissent dans l'ensemble C0, ils doivent apparaître à leurs emplacements ISO 6429 / ECMA-48. Inclusion de caractères de contrôle de transmission dans l'ensemble C0, en plus des dix inclus par ISO 6429 / ECMA-48 (à savoir SOH, STX, ETX, EOT, ENQ, ACK, DLE, NAK, SYN et ETB), ou inclusion de l'un de ceux-ci dix dans l'ensemble C1, est également interdit par la norme ISO/IEC 2022 / ECMA-35.

Un jeu de contrôle C0 est invoqué sur la plage CL 0x00 à 0x1F, tandis qu'un caractère de contrôle C1 peut être invoqué sur la plage CR 0x80 à 0x9F (dans un environnement 8 bits) ou en utilisant des séquences d'échappement (dans un -bit), mais pas les deux. Le style d'invocation C1 utilisé doit être spécifié dans la définition de la version du code. Par exemple, ISO/IEC 4873 spécifie les octets CR pour les contrôles C1 (SS2 et SS3) qu'il utilise. Si nécessaire, l'invocation utilisée peut être communiquée à l'aide de séquences d'annonceurs .

Dans ce dernier cas, les caractères de contrôle uniques du jeu de caractères de contrôle C1 sont invoqués à l'aide de séquences d'échappement "type Fe", c'est-à-dire celles où le caractère de contrôle ESC est suivi d'un octet des colonnes 04 ou 05 (c'est-à-dire ESC 0x40 (@)jusqu'à ESC 0x5F (_)).

Autres fonctions de contrôle

Des fonctions de contrôle supplémentaires sont affectées aux séquences d'échappement de "type Fs" (dans la plage ESC 0x60 (`)jusqu'à ESC 0x7E (~)); ceux-ci ont des significations attribuées de façon permanente plutôt que de dépendre des désignations C0 ou C1. L'enregistrement des fonctions de commande sur des séquences de type "Fs" doit être approuvé par l' ISO/CEI JTC 1/SC 2 . D'autres fonctions de contrôle simples peuvent être enregistrées pour taper des séquences d'échappement "3Ft" (dans la plage jusqu'à ), bien qu'aucune séquence "3Ft" ne soit actuellement attribuée (à partir de 2019). ESC 0x23 (#) [I...] 0x40 (@)ESC 0x23 (#) [I...] 0x7E (~)

Les séquences d'échappement suivantes sont attribuées pour les fonctions de commande simples :

Les séquences d'échappement de type « Fp » ( ESC 0x30 (0)à ESC 0x3F (?)) ou de type « 3Fp » ( à ) sont réservées à des codes de contrôle à usage privé unique, après accord préalable entre les parties. Plusieurs de ces séquences des deux types sont utilisées par les terminaux DEC tels que le VT100 , et sont donc supportées par les émulateurs de terminaux . ESC 0x23 (#) [I...] 0x30 (0)ESC 0x23 (#) [I...] 0x3F (?)

Fonctions de décalage

Par défaut, les codes GL spécifient les caractères G0 et les codes GR (le cas échéant) spécifient les caractères G1 ; cela peut être spécifié autrement par accord préalable. L'ensemble invoqué sur chaque zone peut également être modifié avec des codes de contrôle appelés décalages, comme indiqué dans le tableau ci-dessous.

Un code à 8 bits peut avoir des codes GR spécifiant les caractères G1, c'est-à-dire avec son code à 7 bits correspondant en utilisant Shift In et Shift Out pour basculer entre les ensembles (par exemple JIS X 0201 ), bien que certains aient à la place des codes GR spécifiant les caractères G2, avec le code à 7 bits correspondant en utilisant un code à décalage unique pour accéder au deuxième ensemble (par exemple T.51 ).

Les codes indiqués dans le tableau ci-dessous sont les codages les plus courants de ces codes de contrôle, conformément à la norme ISO/IEC 6429 . Les décalages LS2, LS3, LS1R, LS2R et LS3R sont enregistrés en tant que fonctions de contrôle uniques et sont toujours codés comme les séquences d'échappement répertoriées ci-dessous, tandis que les autres font partie d'un ensemble de codes de contrôle C0 ou C1 (comme indiqué ci-dessous, SI (LS0) et SO (LS1) sont des commandes C0 et SS2 et SS3 sont des commandes C1), ce qui signifie que leur codage et leur disponibilité peuvent varier en fonction des ensembles de commandes désignés : ils doivent être présents dans les ensembles de commandes désignés si leur fonctionnalité est utilisée. Les contrôles C1 eux-mêmes, comme mentionné ci-dessus, peuvent être représentés en utilisant des séquences d'échappement ou des octets de 8 bits, mais pas les deux.

Des codages alternatifs des décalages simples en tant que codes de contrôle CO sont disponibles dans certains ensembles de codes de contrôle. Par exemple, SS2 et SS3 sont généralement disponibles en 0x19 et 0x1D respectivement en T.51 et T.61 . Ce codage est actuellement recommandé par ISO/IEC 2022 / ECMA-35 pour les applications nécessitant des représentations sur un seul octet 7 bits de SS2 et SS3, et peut également être utilisé pour SS2 uniquement, bien que des jeux de codes plus anciens avec SS2 à 0x1C existent également, et ont été mentionnés comme tels dans une édition antérieure de la norme. Le codage 0x8E et 0x8F des décalages simples comme indiqué ci-dessous est obligatoire pour ISO/IEC 4873 niveaux 2 et 3.

Dans les environnements 8 bits, GL ou GR, mais pas les deux, peuvent être utilisés comme zone à décalage unique. Ceci doit être spécifié dans la définition de la version du code. Par exemple, ISO/IEC 4873 spécifie GL, tandis que l' EUC emballé spécifie GR. Dans les environnements 7 bits, seul GL est utilisé comme zone à décalage unique. Si nécessaire, la zone à quart unique utilisée peut être communiquée à l'aide de séquences d'annonceurs .

Les noms "locking shift zero" (LS0) et "locking shift one" (LS1) font référence à la même paire de caractères de contrôle C0 (0x0F et 0x0E) que les noms "shift in" (SI) et "shift out" (SO ). Cependant, la norme les appelle LS0 et LS1 lorsqu'ils sont utilisés dans des environnements 8 bits et SI et SO lorsqu'ils sont utilisés dans des environnements 7 bits.

La norme ISO/IEC 2022 / ECMA-35 autorise, mais décourage, l'invocation simultanée de G1, G2 ou G3 dans les deux GL et GR.

Enregistrement des jeux de codes graphiques et de contrôle

Le registre international ISO des jeux de caractères codés à utiliser avec des séquences d'échappement (ISO-IR) répertorie les jeux de caractères graphiques, les jeux de codes de contrôle, les codes de contrôle uniques, etc., qui ont été enregistrés pour être utilisés avec ISO/IEC 2022. La procédure d'enregistrement codes et ensembles avec le registre ISO-IR est spécifié par ISO/IEC 2375 . Chaque enregistrement reçoit une séquence d'échappement unique et un numéro d'entrée de registre unique pour l'identifier. Par exemple, le jeu de caractères CCITT pour le chinois simplifié est appelé ISO-IR-165 .

L'enregistrement des jeux de caractères codés auprès du registre ISO-IR identifie les documents spécifiant le jeu de caractères ou la fonction de contrôle associé à une séquence d'échappement ISO/CEI 2022 à usage non privé. Il peut s'agir d'un document standard ; cependant, l'enregistrement ne crée pas une nouvelle norme ISO, n'engage pas l'ISO ou la CEI à l'adopter en tant que norme internationale et n'engage pas l'ISO ou la CEI à ajouter l'un de ses caractères au jeu de caractères codés universel .

Désignations des jeux de caractères

Les séquences d'échappement pour désigner les jeux de caractères prennent la forme . Comme mentionné ci-dessus, les octets intermédiaires ( I ) sont de la plage 0x20-0x2F, et l' octet final ( F ) est de la plage 0x30-0x7E. Le premier octet I (ou, pour un jeu multi-octets, les deux premiers) identifie le type de jeu de caractères et le jeu de travail auquel il doit être désigné, tandis que l' octet F (et tout octet I supplémentaire ) identifie le jeu de caractères lui-même, tel qu'attribué dans le registre ISO-IR (ou, pour les séquences d'échappement à usage privé, par accord préalable). ESC I [I...] F

Des octets I supplémentaires peuvent être ajoutés avant l' octet F pour étendre la plage d'octets F. Ceci n'est actuellement utilisé qu'avec les ensembles de 94 caractères, où les codes du formulaire ont été attribués. A l'autre extrême, aucun ensemble de 96 multi-octets n'a été enregistré, les séquences ci-dessous sont donc strictement théoriques. ESC ( ! F

Comme pour les autres types de séquences d'échappement, la plage 0x30–0x3F est réservée aux octets F à usage privé , dans ce cas pour les définitions de jeux de caractères à usage privé (qui peuvent inclure des jeux non enregistrés définis par des protocoles tels que ARIB STD-B24 ou MARC-8 , ou des ensembles spécifiques au fournisseur tels que DEC Special Graphics ). Cependant, dans une séquence de désignation d'ensemble graphique, si le deuxième octet I (pour un ensemble à un octet) ou le troisième octet I (pour un ensemble à deux octets) est 0x20 (espace), l'ensemble noté est un " caractère dynamiquement redéfinissable ensemble " (DRCS) défini par accord préalable, qui est également considéré comme un usage privé. Un ensemble graphique considéré comme un DRCS implique qu'il représente une police de glyphes exacts, plutôt qu'un ensemble de caractères abstraits. La manière dont les ensembles DRCS et les polices associées sont transmis, alloués et gérés n'est pas stipulée par l'ISO/IEC 2022 / ECMA-35 elle-même, bien qu'elle recommande de les allouer séquentiellement en commençant par l' octet F 0x40 ( @); cependant, une manière de transmettre les polices DRCS est définie dans certains protocoles de télécommunication tels que World System Teletext .

Il existe également trois cas particuliers pour les codes multi-octets. Les séquences de code ESC $ @, ESC $ Aet ESC $ Bont tous été enregistrés lorsque la version contemporaine de la norme a permis ensembles multi-octets seulement dans G0, doit donc être accepté à la place des séquences ESC $ ( @par ESC $ ( Bdésigner au jeu de caractères G0.

Il existe des fonctionnalités supplémentaires (rarement utilisées) pour changer les jeux de caractères de contrôle, mais il s'agit d'une recherche à un seul niveau, dans la mesure où (comme indiqué ci-dessus) l'ensemble C0 est toujours appelé sur CL, et l'ensemble C1 est toujours appelé sur CR ou par en utilisant des codes d'échappement. Comme indiqué ci-dessus, il est nécessaire que tout jeu de caractères C0 comprenne le caractère ESC à la position 0x1B, de sorte que d'autres modifications soient possibles. Les séquences de désignation des ensembles de contrôle (par opposition aux ensembles graphiques) peuvent également être utilisées à partir de l' ISO/CEI 10646 (UCS/Unicode), dans des contextes où le traitement des codes d'échappement ANSI est approprié, à condition que chaque octet de la séquence soit complété par la taille de l'unité de code de l'encodage.

Un tableau des octets de séquence d'échappement I et la désignation ou autre fonction qu'ils remplissent est ci-dessous.

Notez que le registre des octets F est indépendant pour les différents types. L'ensemble graphique de 94 caractères désigné par ESC ( Aà ESC + An'a aucun rapport avec l'ensemble de 96 caractères désigné par ESC - Aà ESC / A. Et aucun de ceux-ci n'est lié à l'ensemble de 94 ⁿ caractères désigné par ESC $ ( Aà ESC $ + A, et ainsi de suite ; les derniers octets doivent être interprétés dans leur contexte. (En effet, sans aucun octet intermédiaire, ESC Aest un moyen de spécifier le code de contrôle C1 0x81.)

Notez également que les jeux de caractères de contrôle C0 et C1 sont indépendants ; le jeu de caractères de contrôle C0 désigné par ESC ! A(qui se trouve être le jeu de contrôle NATS pour la transmission de textes de journaux) n'est pas le même que le jeu de caractères de contrôle C1 désigné par ESC " A(le jeu de contrôle d'attribut du CCITT pour le vidéotex ).

Interaction avec d'autres systèmes de codage

La norme définit également un moyen de spécifier des systèmes de codage qui ne suivent pas sa propre structure.

Une séquence est également définie pour le retour à l'ISO/IEC 2022 ; les enregistrements qui prennent en charge cette séquence telle qu'encodée dans ISO/IEC 2022 comprennent (à partir de 2019) divers formats vidéotex , UTF-8 et UTF-1 . Un deuxième octet I de 0x2F ( /) est inclus dans les séquences de désignation des codes qui n'utilisent pas cette séquence d'octets pour revenir à ISO 2022 ; ils peuvent avoir leurs propres moyens de revenir à ISO 2022 (comme une séquence différente ou rembourrée) ou aucun. Tous les enregistrements existants de ce dernier type (à partir de 2019) sont soit des données brutes transparentes, soit des formats Unicode/UCS , soit des sous-ensembles de ceux-ci.

Les séquences qui basculent vers les formats ISO/IEC 10646 ( Unicode ) qui ne suivent pas la structure ISO/IEC 2022 sont particulièrement intéressantes . Ceux-ci incluent UTF-8 (qui ne réserve pas la plage 0x80–0x9F pour les caractères de contrôle), son prédécesseur UTF-1 (qui mélange les octets GR et GL dans des codes multi-octets), et UTF-16 et UTF-32 (qui utilisent unités de codage plus larges).

Plusieurs codes ont également été enregistrés pour des sous-ensembles (niveaux 1 et 2) d'UTF-8, UTF-16 et UTF-32, ainsi que pour trois niveaux d' UCS-2 . Cependant, les seuls codes actuellement spécifiés par ISO/IEC 10646 sont les codes de niveau 3 pour UTF-8, UTF-16 et UTF-32 et le code de niveau non spécifié pour UTF-8, le reste étant répertorié comme obsolète. L'ISO/CEI 10646 stipule que les formats big-endian de UTF-16 et UTF-32 sont désignés par leurs séquences d'échappement.

Parmi les séquences passant à UTF-8, ESC % Gest celle prise en charge par, par exemple, xterm .

Bien que l'utilisation d'une variante de la séquence de retour standard de l'UTF-16 et de l'UTF-32 soit autorisée, les octets de la séquence d'échappement doivent être remplis à la taille de l'unité de code du codage (c'est- 001B 0025 0040à- dire pour UTF-16), c'est-à-dire le le codage de la séquence de retour standard n'est pas exactement conforme à ISO/IEC 2022. Pour cette raison, les désignations pour UTF-16 et UTF-32 utilisent une syntaxe sans retour standard.

Annonces de structure de code

La séquence « annoncer la structure du code » ( ) est utilisée pour annoncer une structure de code spécifique ou un groupe spécifique d'installations ISO 2022 qui sont utilisées dans une version de code particulière. Bien que les annonces puissent être combinées, certaines combinaisons contradictoires (en particulier, l'utilisation des annonces d'équipe de verrouillage 16-23 avec les annonces 1, 3 et 4) sont interdites par la norme, tout comme l'utilisation d'annonces supplémentaires en plus des annonces de niveau ISO/IEC 4873 12-14 (qui spécifient pleinement les caractéristiques structurelles admissibles). Les séquences d'annonces sont les suivantes : ESC SP (0x20) F

Versions des codes ISO/CEI 2022

Divers encodages ISO 2022 et autres CJK pris en charge par Mozilla Firefox à partir de 2004. (Cette prise en charge a été réduite dans les versions ultérieures pour éviter certaines attaques de scripts intersites.)

Versions de courrier électronique en japonais

ISO-2022-JP est un codage largement utilisé pour le japonais, en particulier dans lese-mails. Il a été introduit pour être utilisé sur le réseau JUNET et codifié plus tard dans l'IETF RFC1468, daté de 1993. Il présente un avantage par rapport aux autrescodages pour le japonaisen ce sens qu'il ne nécessite pas detransmissionpropre sur 8 bits. Microsoft l'appellepage de code 50220. Il commence en ASCII et comprend les séquences d'échappement suivantes :

• ESC ( B pour passer en ASCII (1 octet par caractère)
• ESC ( Jpour passer à JIS X 0201-1976 (ISO/IEC 646:JP) Ensemble romain (1 octet par caractère)
• ESC $ @pour passer à JIS X 0208-1978 (2 octets par caractère)
• ESC $ Bpour passer à JIS X 0208-1983 (2 octets par caractère)

L'utilisation des deux caractères ajoutés dans JIS X 0208-1990 est autorisée, mais sans inclure la séquence IRR, c'est-à-dire en utilisant la même séquence d'échappement que JIS X 0208-1983. De plus, en raison de l'enregistrement possible avant la désignation des ensembles multi-octets sauf pour G0, les échappements pour JIS X 0208 n'incluent pas le deuxième I -byte (.

La RFC note que certains systèmes existants ne distinguent pas ESC ( Bde ESC ( J, ou ne distinguent pas ESC $ @de ESC $ B, mais stipule que les séquences d'échappement ne doivent pas être modifiées par des systèmes relayant simplement des messages tels que des e-mails. La norme d'encodage WHATWG référencée par HTML5 gère ESC ( Bet ESC ( Jdistinctement, mais traite de ESC $ @la même manière que ESC $ Blors du décodage et n'utilise que ESC $ Bpour JIS X 0208 lors de l'encodage. La RFC note également que certains systèmes antérieurs avaient fait un usage erroné de la séquence ESC ( Hpour s'éloigner de JIS X 0208, qui est en fait enregistré pour ISO-IR-11 (une variante suédoise d' ISO 646 et du World System Teletext ).

L'utilisation de ESC ( Ipour passer à l' ensemble Kana JIS X 0201-1976 (1 octet par caractère) ne fait pas partie du profil ISO-2022-JP, mais est aussi parfois utilisée. Python l' autorise dans une variante qu'il étiquette ISO-2022-JP-EXT (qui incorpore également JIS X 0212 comme décrit ci-dessous, complétant la couverture d' EUC-JP ); ceci est proche à la fois du nom et de la structure d'un codage noté ISO-2022-JPext par DEC , qui ajoute en outre une région définie par l'utilisateur de deux octets accessible avec ESC $ ( 0pour compléter la couverture de Super DEC Kanji . La variante WHATWG/HTML5 permet de décoder le katakana JIS X 0201 en entrée ISO-2022-JP, mais convertit les caractères en leurs équivalents JIS X 0208 lors de l'encodage. La page de code de Microsoft pour ISO-2022-JP avec JIS X 0201 kana également autorisée est la page de code 50221 .

D'autres variantes plus anciennes connues sous le nom de JIS7 et JIS8 s'appuient directement sur les codages 7 bits et 8 bits définis par JIS X 0201 et permettent l'utilisation de JIS X 0201 kana de G1 sans séquences d'échappement, en utilisant Shift Out et Shift In ou en définissant le huitième bit (GR-invoqué), respectivement. Ils ne sont pas largement utilisés ; La prise en charge de JIS X 0208 dans JIS X 0201 8 bits étendu est plus généralement réalisée via Shift JIS . La page de code de Microsoft pour ISO 2022 basée sur JIS X 0201 avec katakana à un octet via Shift Out et Shift In est la page de code 50222 .

ISO-2022-JP-2 est une extension multilingue de l'ISO-2022-JP, définie dans la RFC 1554 (datée de 1993), qui permet les séquences d'échappement suivantes en plus de celles de l'ISO-2022-JP. LespartiesISO/IEC 8859sont des ensembles de 96 caractères qui ne peuvent pas être désignés par G0, et sont accessibles à partir de G2 en utilisant la forme de séquence d'échappement à 7 bits du code à décalage unique SS2 :

• ESC $ Apour passer à GB 2312-1980 (2 octets par caractère)
• ESC $ ( Cpour passer à KS X 1001-1992 (2 octets par caractère)
• ESC $ ( Dpour passer à JIS X 0212-1990 (2 octets par caractère)
• ESC . Apour passer à la partie haute ISO/IEC 8859-1 , ensemble Latin étendu 1 (1 octet par caractère) [désigné comme G2]
• ESC . Fpour passer à la partie haute ISO/IEC 8859-7 , ensemble grec de base (1 octet par caractère) [désigné comme G2]

ISO-2022-JP avec la représentation ISO-2022-JP-2 de JIS X 0212, mais pas les autres extensions, a ensuite été surnommé ISO-2022-JP-1 par RFC 2237, daté de 1997.

La norme JIS X 0213 , publiée pour la première fois en 2000, définit une version mise à jour d'ISO-2022-JP, sans les extensions ISO-2022-JP-2, nommée ISO-2022-JP-3 . Les ajouts apportés par JIS X 0213 par rapport à la norme de base JIS X 0208 ont entraîné un nouvel enregistrement pour l'avion JIS étendu 1, tandis que le nouvel avion 2 a reçu son propre enregistrement. Les ajouts supplémentaires au plan 1 dans l'édition 2004 de la norme ont entraîné l'ajout d'un enregistrement supplémentaire à une nouvelle révision du profil, baptisée ISO-2022-JP-2004 . En plus des codes de désignation de base ISO-2022-JP, les désignations suivantes sont reconnues :

• ESC ( Ipour passer à JIS X 0201-1976 Kana set (1 octet par caractère)
• ESC $ ( Opour passer à JIS X 0213-2000 Plan 1 (2 octets par caractère)
• ESC $ ( Ppour passer à JIS X 0213-2000 Plane 2 (2 octets par caractère)
• ESC $ ( Qpour passer à JIS X 0213-2004 Plan 1 (2 octets par caractère, ISO-2022-JP-2004 uniquement)

Autres versions 7 bits

ISO-2022-KR est défini dans la RFC 1557, datée de 1993. Il code l'ASCIIet le coréen à double octetKS X 1001-1992, précédemment nommé KS C 5601-1987. Contrairement à ISO-2022-JP-2, il utilise les caractèresShift Out et Shift Inpour basculer entre eux, après avoir inclusESC $ ) Cune fois en début de ligne pour désigner KS X 1001 à G1.

ISO-2022-CN etISO-2022-CN-EXTsont définis dans la RFC 1922, datée de 1996. Ce sont des codages 7 bits utilisant à la fois les fonctions Shift Out et Shift In (pour passer de G0 à G1), et de les formes de code d'échappement à 7 bits des fonctions à décalage unique SS2 et SS3 (pour accéder à G2 et G3). Ils prennent en charge les jeux de caractèresGB 2312(pour lechinois simplifié) etCNS 11643(pourle chinois traditionnel).

Le profil de base ISO-2022-CN utilise ASCII comme jeu G0 (décalage), et comprend également GB 2312 et les deux premiers plans de CNS 11643 (car ces deux plans sont suffisants pour représenter tous les caractères chinois traditionnels de Big5 commun , auquel le RFC fournit une correspondance en annexe) :

• ESC $ ) Apour passer à GB 2312-1980 (2 octets par caractère) [désigné à G1]
• ESC $ ) Gpour passer au plan CNS 11643-1992 1 (2 octets par caractère) [désigné par G1]
• ESC $ * Hpour passer au plan CNS 11643-1992 2 (2 octets par caractère) [désigné par G2]

Le profil ISO-2022-CN-EXT permet les ensembles et plans supplémentaires suivants.

• ESC $ ) Epour passer à ISO-IR-165 (2 octets par caractère) [désigné à G1]
• ESC $ + Ipour passer à CNS 11643-1992 Plane 3 (2 octets par caractère) [désigné à G3]
• ESC $ + Jpour passer à CNS 11643-1992 Plane 4 (2 octets par caractère) [désigné à G3]
• ESC $ + Kpour passer à CNS 11643-1992 Plane 5 (2 octets par caractère) [désigné à G3]
• ESC $ + Lpour passer à CNS 11643-1992 Plane 6 (2 octets par caractère) [désigné à G3]
• ESC $ + Mpour passer à CNS 11643-1992 Plane 7 (2 octets par caractère) [désigné à G3]

Le profil ISO-2022-CN-EXT répertorie en outre des ensembles graphiques standard Guobiao supplémentaires comme étant autorisés, mais à condition qu'ils se voient attribuer des séquences d'échappement ISO 2022 enregistrées :

• GB 12345 en G1
• Go 7589 ou Go 13131 en G2
• Go 7590 ou Go 13132 en G3

Le caractère après ESC(pour les jeux de caractères codés sur un octet) ou ESC $(pour les jeux de caractères codés sur plusieurs octets) spécifie le type de jeu de caractères et de jeu de travail auquel il est destiné. Dans les exemples ci-dessus, le caractère ((0x28) désigne un jeu de 94 caractères pour le jeu de caractères G0, tandis que ), *ou +(0x29-0x2B) désigne les jeux de caractères G1-G3.

ISO-2022-KR et ISO-2022-CN sont utilisés moins fréquemment que ISO-2022-JP et sont parfois délibérément non pris en charge en raison de problèmes de sécurité. Notamment, la norme d'encodage WHATWG utilisée par HTML5 mappe ISO-2022-KR, ISO-2022-CN et ISO-2022-CN-EXT (ainsi que HZ-GB-2312 ) au décodeur "de remplacement", qui mappe toutes les entrées au caractère de remplacement ( ), afin d'empêcher certains scripts intersites et attaques associées, qui utilisent une différence de prise en charge de l'encodage entre le client et le serveur. Bien que le même problème de sécurité (permettant d'interpréter différemment les séquences d'octets ASCII) s'applique également à ISO-2022-JP et UTF-16 , ils n'ont pas pu bénéficier de ce traitement car ils sont beaucoup plus fréquemment utilisés dans le contenu déployé.

ISO/CEI 4873

Relation entre les éditions et niveaux ECMA-43 (ISO/IEC 4873) et EUC .

Un sous-ensemble d'ISO 2022 appliqué aux codages à un octet 8 bits est défini par ISO/IEC 4873 , également publié par Ecma International sous le nom ECMA-43. ISO/IEC 8859 définit des codes à 8 bits pour ISO/IEC 4873 (ou ECMA-43) niveau 1.

ISO/IEC 4873 / ECMA-43 définit trois niveaux de codage :

• Niveau 1, qui comprend un ensemble C0, l'ensemble ASCII G0, un ensemble C1 en option et un ensemble G1 à un octet (94 ou 96 caractères) en option. G0 est invoqué sur GL et G1 est invoqué sur GR. L'utilisation des fonctions de décalage n'est pas autorisée.
• Niveau 2, qui comprend un ensemble G2 et/ou G3 à un octet (94 ou 96 caractères) en plus d'un ensemble G1 obligatoire. Seules les fonctions à décalage unique SS2 et SS3 sont autorisées (c'est-à-dire que les décalages de verrouillage sont interdits), et elles invoquent sur la région GL (y compris 0x 20 et 0x7F dans le cas d'un ensemble 96). SS2 et SS3 doivent être disponibles en C1 à 0x8E et 0x8F respectivement. Cet ensemble C1 minimal requis pour ISO 4873 est enregistré comme ISO-IR-105.
• Le niveau 3, qui permet les fonctions de verrouillage de changement de vitesse GR LS1R, LS2R et LS3R en plus des changements de vitesse simples, mais a par ailleurs les mêmes restrictions que le niveau 2.

Les éditions antérieures de la norme autorisaient les affectations non ASCII dans l'ensemble G0, à condition que les positions invariantes ISO 646 soient conservées, que les autres positions soient affectées à des caractères d'espacement (non combinés), que 0x23 soit affecté à £ ou # , et que 0x24 a été attribué à $ ou ¤ . Par exemple, l'encodage 8 bits de JIS X 0201 est compatible avec les éditions précédentes. Cela a été modifié par la suite pour spécifier entièrement l'ensemble ISO 646:1991 IRV / ISO-IR No. 6 ( ASCII ).

L'utilisation de l' IRV ISO 646 (synchronisé avec l'ASCII depuis 1991) à ISO/IEC 4873 Niveau 1 sans réglage C1 ou G1, c'est-à-dire l'utilisation de l'IRV dans un environnement 8 bits dans lequel les codes de décalage ne sont pas utilisés et le bit haut est toujours zéro, est connu sous le nom d' ISO 4873 DV , dans lequel DV signifie "Version par défaut".

Dans les cas où des caractères en double sont disponibles dans différents ensembles, l'édition actuelle de l'ISO/IEC 4873 / ECMA-43 ne permet d'utiliser ces caractères que dans l'ensemble de travail numéroté le plus bas dans lequel ils apparaissent. Par exemple, si un caractère apparaît à la fois dans le G1 et l'ensemble G3, il doit être utilisé à partir de l'ensemble G1. Cependant, l'utilisation d'autres ensembles est notée comme ayant été autorisée dans les éditions précédentes.

ISO/IEC 8859 définit des codages complets au niveau 1 de l'ISO/IEC 4873, et ne permet pas l'utilisation de plusieurs parties ISO/IEC 8859 ensemble. Il stipule que l' ISO/CEI 10367 doit être utilisé à la place pour les niveaux 2 et 3 de l'ISO/CEI 4873. L'ISO/CEI 10367:1991 comprend les ensembles G0 et G1 correspondant à ceux utilisés par les 9 premières parties de l'ISO/CEI 8859 (c'est-à-dire ceux qui existait à partir de 1991, date de sa publication), et quelques jeux supplémentaires.

Les séquences d'échappement de désignation de jeu de caractères sont utilisées pour identifier ou basculer entre les versions pendant l'échange d'informations uniquement si cela est requis par un autre protocole, auquel cas la norme requiert une séquence d'annonceur ISO/IEC 2022 spécifiant le niveau ISO/IEC 4873, suivie d'un ensemble complet d'échappements spécifiant les désignations de jeu de caractères pour C0, C1, G0, G1, G2 et G3 respectivement (mais en omettant les désignations G2 et G3 pour le niveau 1), avec un octet F de 0x7E désignant un jeu vide. Chaque niveau ISO/IEC 4873 a sa propre séquence d'annonceur ISO/IEC 2022, qui est la suivante :

Code Unix étendu

Le code Unix étendu (EUC) est un système de codage de caractères à largeur variable sur 8 bits utilisé principalement pour le japonais , le coréen et le chinois simplifié . Il est basé sur ISO 2022, et seuls les jeux de caractères conformes à la structure ISO 2022 peuvent avoir des formes EUC. Jusqu'à quatre jeux de caractères codés peuvent être représentés (en G0, G1, G2 et G3). L'ensemble G0 est invoqué sur GL, l'ensemble G1 est invoqué sur GR, et les ensembles G2 et G3 sont (s'ils sont présents) invoqués en utilisant les décalages simples SS2 et SS3, qui sont utilisés sur GR (pas GL), c'est-à-dire à 0x8E et 0x8F respectivement. Les codes d'équipe de verrouillage ne sont pas utilisés.

Le code attribué au jeu G0 est ASCII , ou le jeu de caractères ISO 646 national du pays tel que KS-Roman (KS X 1003) ou JIS-Roman (la moitié inférieure de JIS X 0201 ). Par conséquent, 0x5C ( barre oblique inverse en US-ASCII) est utilisé pour représenter un signe Yen dans certaines versions d'EUC-JP et un signe Won dans certaines versions d'EUC-KR.

G1 est utilisé pour un jeu de caractères codés 94x94 représenté sur deux octets. La forme EUC-CN de GB2312 et EUC-KR sont des exemples de tels codes EUC à deux octets. EUC-JP comprend des caractères représentés par jusqu'à trois octets (c'est-à-dire SS3 plus deux octets) alors qu'un seul caractère dans EUC-TW peut prendre jusqu'à quatre octets (c'est-à-dire SS2 plus trois octets).

Le code EUC lui-même n'utilise pas les séquences d'annonceur ou de désignation de l'ISO 2022 ; cependant, il correspond à la séquence suivante de quatre séquences d'annonceurs, dont les significations se décomposent comme suit.

Comparaison avec d'autres encodages

Avantages

• Comme toute la gamme de codages de caractères graphiques d'ISO/IEC 2022 peut être invoquée sur GL, les glyphes disponibles ne sont pas significativement limités par une incapacité à représenter GR et C1, comme dans un système limité aux codages 7 bits. Il permet donc la représentation d'un grand ensemble de caractères dans un tel système. Généralement, cette compatibilité 7 bits n'est pas vraiment un avantage, sauf pour la rétrocompatibilité avec les systèmes plus anciens. La grande majorité des ordinateurs modernes utilisent 8 bits pour chaque octet.
• Par rapport à Unicode, ISO/IEC 2022 contourne l' unification Han en utilisant des codes de séquence pour basculer entre des codages discrets pour différentes langues d'Asie de l'Est. Cela évite les problèmes associés à l'unification, tels que la difficulté à prendre en charge plusieurs langues CJK avec leurs variantes de caractères associées dans un seul document et une seule police.

Désavantages

• Étant donné que ISO/IEC 2022 est un codage avec état, un programme ne peut pas sauter au milieu d'un bloc de texte pour rechercher, insérer ou supprimer des caractères. Cela rend la manipulation du texte très lourde et lente par rapport aux encodages sans état. Tout saut au milieu du texte peut nécessiter une sauvegarde de la séquence d'échappement précédente avant que les octets suivant la séquence d'échappement puissent être interprétés.
• En raison de la nature avec état de la norme ISO/IEC 2022, un caractère identique et équivalent peut être codé dans différents jeux de caractères, qui peuvent être désignés par l'un des G0 à G3, qui peuvent être invoqués à l'aide de décalages uniques ou en utilisant des décalages de verrouillage vers GL ou GR. Par conséquent, les caractères peuvent être représentés de plusieurs manières, ce qui signifie que deux chaînes visuellement identiques et équivalentes ne peuvent pas être comparées de manière fiable pour l'égalité.
• Certains systèmes, comme DICOM et plusieurs clients de messagerie, utilisent une variante d'ISO-2022 (par exemple "ISO 2022 IR 100") en plus de prendre en charge plusieurs autres encodages. Ce type de variation rend difficile le transfert portable de texte entre les systèmes informatiques.
• UTF-1 , le format de transformation Unicode multi-octets compatible avec la représentation ISO/IEC 2022 des caractères de contrôle 8 bits, présente divers inconvénients par rapport à UTF-8 , et le passage de ou vers d'autres jeux de caractères, tel que pris en charge par ISO/IEC 2022 , est généralement inutile dans les documents Unicode.
• En raison de ses séquences d'échappement, il est possible de construire des séquences d'octets d'attaque dans lesquelles une chaîne malveillante (telle que le cross-site scripting ) est masquée jusqu'à ce qu'elle soit décodée en Unicode, ce qui peut lui permettre de contourner la désinfection. L'utilisation de cet encodage est donc considérée comme suspecte par les suites de protection contre les logiciels malveillants, et les données ISO 2022 7 bits (sauf ISO-2022-JP) sont mappées dans leur intégralité au caractère de remplacement dans HTML5 pour empêcher les attaques. Les versions de code ISO 2022 restreintes à 8 bits qui n'utilisent pas d'échappement de désignation ou de codes de décalage de verrouillage, telles que le code Unix étendu , ne partagent pas ce problème.
• La concaténation peut poser des problèmes. Des profils tels que ISO-2022-JP spécifient que le flux commence dans l'état ASCII et doit se terminer dans l'état ASCII. Cela est nécessaire pour garantir que les caractères des flux ISO-2022-JP et/ou ASCII concaténés seront interprétés dans le bon ensemble. Cela a pour conséquence que si un flux qui se termine par un caractère multi-octets est concaténé avec un qui commence par un caractère multi-octets, une paire de codes d'échappement est générée en basculant vers l'ASCII et s'en éloignant immédiatement. Cependant, comme stipulé dans le rapport technique Unicode n°36 ("Considérations relatives à la sécurité Unicode"), les paires de séquences d'échappement ISO 2022 sans caractères entre elles doivent générer un caractère de remplacement (" ") pour éviter qu'elles ne soient utilisées pour masquer des séquences malveillantes telles que comme script inter-sites . La mise en œuvre de cette mesure, par exemple dans Mozilla Thunderbird , a conduit à des problèmes d'interopérabilité, avec des caractères " " inattendus générés lorsque deux flux ISO-2022-JP ont été concaténés.

Voir également

• ISO 2709
• ISO/CEI 646
• ISO-IR-102
• Codes de contrôle C0 et C1
• CJC
• Normes MARC
• Mojibake
• luit
• ISO/CEI JTC 1/SC 2

Notes de bas de page

Les références

Normes et indices de registre cités

• ARIB (2008). ARIB STD-B24 : Spécifications de codage et de transmission de données pour la diffusion numérique (PDF) (Norme ARIB). 5.2-E1. 1 . Archivé (PDF) de l'original le 2017-07-10 . Récupéré le 2017-07-10 .
• ECMA (1980). ECMA-35 : Extension du jeu de caractères codés à 7 bits (PDF) (norme ECMA) (2e éd.).
• ECMA (1994). ECMA-35 : Structure de code de caractères et techniques d'extension (PDF) (norme ECMA) (6e éd.).
• ECMA (1985). ECMA-43 : Structure et règles de jeu de caractères codés sur 8 bits (PDF) (norme ECMA) (2e éd.).
• ECMA (1991). ECMA-43 : Structure et règles de jeu de caractères codés sur 8 bits (PDF) (norme ECMA) (3e éd.).
• ECMA (2000). ECMA-144 : Jeux de caractères graphiques codés à un octet sur 8 bits : alphabet latin n 6 (PDF) (norme ECMA) (3e éd.).
• Union européenne de radiodiffusion (1997). ETS 300 706 : Spécification Télétexte Améliorée (PDF) (Normes Européennes de Télécommunications). ETSI .
• ISO/CEI JTC 1/SC 2 (2003). ISO/CEI 2375:2003: Technologies de l'information — Procédure d'enregistrement des séquences d'échappement et des jeux de caractères codés . ISO .
• ISO/CEI JTC 1/SC 2 (1998-02-12). ISO/CEI FDIS 8859-10 : Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet — Partie 10 : Alphabet latin n° 6 (PDF) (Final Draft International Standard).
• ISO/CEI JTC 1/SC 2 (2017). ISO/IEC 10646 : Technologies de l'information — Jeu de caractères codés universels (UCS) (norme ISO) (5e éd.). ISO .
• ISO-IR : Registre international ISO/IEC des jeux de caractères codés à utiliser avec les séquences d'échappement (PDF) (Index du registre). ITSCJ/ IPSJ .
• van Kesteren, Anne . Norme de codage WHATWG (norme de vie WHATWG). WHATWG .

Jeux de codes enregistrés cités

• ISO/TC 97/SC 2 (1975-12-01). ISO-IR-1 : L'ensemble des caractères de contrôle de l'ISO 646 (PDF) . ITSCJ/ IPSJ .
• Sveriges Standardiseringskommission (1975-12-01). ISO-IR-7 : Ensemble de contrôle NATS pour la transmission de texte dans les journaux (PDF) . ITSCJ/ IPSJ .
• Comité japonais des normes industrielles (1975-12-01). ISO-IR-14 : Le jeu de caractères graphiques romains japonais (PDF) . ITSCJ/ IPSJ .
• IPTC (1976-03-25). ISO-IR-26 : Jeu de commandes pour la transmission de textes de journaux (PDF) . ITSCJ/ IPSJ .
• ISO/TC 97/SC 2 (1977-10-15). ISO-IR-36 : l'ensemble des caractères de contrôle de l'ISO 646, avec IS4 remplacé par Single Shift pour G2 (SS2) (PDF) . ITSCJ/ IPSJ .
• ISO/TC97/SC2/WG-7 ; ECMA (1985-08-01). ISO-IR-104 : C0 minimum défini pour ISO 4873 (PDF) . ITSCJ/ IPSJ .
• ISO/TC97/SC2/WG-7 ; ECMA (1985-08-01). ISO-IR-105 : C1 minimum défini pour ISO 4873 (PDF) . ITSCJ/ IPSJ .
• UIT (1985-08-01). ISO-IR-106 : Ensemble principal de fonctions de contrôle du télétex (PDF) . ITSCJ/ IPSJ .
• ad pro normalizaci a měřeni (1987-07-31). ISO-IR-140 : l'ensemble de caractères de contrôle C0 de l'ISO 646, avec EM remplacé par SS2 (PDF) . ITSCJ/ IPSJ .
• Bureau coréen des normes (1988-10-01). ISO-IR-149 : jeu de caractères graphiques coréens pour l'échange d'informations (KS C 5601:1987) (PDF) . ITSCJ/ IPSJ .
• ISO/IEC/JTC1/SC2/WG3 (1990-04-16). ISO-IR-155 : Ensemble de dessins de boîte de base (PDF) . ITSCJ/ IPSJ .
• CCITT (1992-07-13). ISO-IR-164 : Ensemble supplémentaire de caractères graphiques en hébreu (PDF) . ITSCJ/ IPSJ .
• ECMA (1996-04-22). ISO-IR-192 : UCS Transformation Format (UTF-8), niveau de mise en œuvre 3, sans retour standard (PDF) . ITSCJ/ IPSJ .
• ECMA (1996-04-22). ISO-IR-195 : UCS Transformation Format (UTF-16), niveau de mise en œuvre 3, sans retour standard (PDF) . ITSCJ/ IPSJ .
• ECMA (1996-04-22). ISO-IR-196 : UCS Transformation Format (UTF-8), avec retour standard (PDF) . ITSCJ/ IPSJ .
• Autorité nationale des normes d'Irlande (1999-12-07). ISO-IR-208 : Jeu de caractères codés Ogham pour l'échange d'informations (PDF) . ITSCJ/ IPSJ .

Demandes de commentaires sur Internet citées

• Murai, J.; Crispin, M.; van der Poel, E. (1993). "RFC 1468 : Encodage de caractères japonais pour les messages Internet" . Demandes de commentaires . IETF . doi : 10.17487/rfc1468 .
• Ohta, M. ; Handa, K. (1993). "RFC 1554 : ISO-2022-JP-2 : Extension multilingue de l'ISO-2022-JP" . Demandes de commentaires . IETF . doi : 10.17487/rfc1554 .
• Choi, U. ; Chon, K.; Park, H. (1993). "RFC 1557 : Encodage de caractères coréens pour les messages Internet" . Demandes de commentaires . IETF . doi : 10.17487/rfc1557 .
• Zhu, HF.; Hu, DY.; Wang, ZG.; Kao, Californie ; Chang, WCH.; Crispin, M. (1996). "RFC 1922 : Encodage de caractères chinois pour les messages Internet" . Demandes de commentaires . IETF . doi : 10.17487/rfc1922 .
• Tamaru, K. (1997). "RFC 2237 : Encodage de caractères japonais pour les messages Internet" . Demandes de commentaires . IETF . doi : 10.17487/rfc2237 .

Autres ouvrages publiés cités

• Lunde, Ken (2008). Traitement de l'information CJKV (2e éd.). O'Reilly Media . ISBN 9780596514471.

Lectures complémentaires

• Lunde, Ken (1998). Traitement des informations CJKV . Cambridge, Massachusetts : O'Reilly & Associates . ISBN 1-56592-224-7.

Liens externes

• ISO/CEI 2022:1994
• ISO/CEI 2022:1994/Cor 1:1999
• ECMA-35 , équivalent à ISO/IEC 2022 et téléchargeable gratuitement.
• Registre international des jeux de caractères codés à utiliser avec des séquences d'échappement , une liste complète des jeux de caractères attribués et leurs séquences d'échappement
• Histoire des codes de caractères en Amérique du Nord, en Europe et en Asie de l'Est à partir de 1999, rév. 2004
• Ken Lunde de CJK.INF : un document sur le codage des langues chinois, japonais et coréen (CJK), y compris une discussion sur les différentes variantes de la norme ISO / CEI 2022.