UTF-EBCDIC

UTF-EBCDIC est un codage de caractères utilisé pour représenter les caractères Unicode. Il est conçu pour être compatible avec l’EBCDIC, de sorte que les applications EBCDIC existantes sur les mainframes puissent accepter et traiter les caractères sans grosse difficulté. Ses avantages pour les systèmes existants basés sur l’EBCDIC sont similaires à ceux de l’UTF-8 pour les systèmes basés sur l’ASCII. Les détails sur la transformation UTF-EBCDIC sont définis dans le Rapport technique Unicode n°16 (UTR #16).

Transformation d'un point de code Unicode en séquence UTF-EBCDIC

Transformation intermédiaire UTF-8-Mod

Pour produire la version encodée en UTF-EBCDIC d'une suite de points de code Unicode, une première transformation intermédiaire, similaire à l’UTF-8 (désignée dans les spécifications comme UTF-8-Mod), est d'abord appliquée ; la principale différence entre cette transformation intermédiaire et l’UTF-8 est qu’elle permet de représenter les points de code 0+0080 à U+009F (les caractères de contrôle C1) sur un seul octet, et de continuer à les utiliser en tant que codes de contrôle EBCDIC.

Pour y parvenir, le motif binaire 101xxxxx a été utilisé au lieu de 10xxxxxx pour représenter les octets finals d’une séquence multi-octet représentant un seul point de code. Puisque cela ne laisse que 5 bits significatifs au lieu de 6 pour les octets finals, l’UTF-EBCDIC produira souvent un résultat un peu plus long que celui obtenu avec l’UTF-8, pour les mêmes données d’entrée.

Le rapport technique n°16 stipule que le résultat de la première transformation UTF-8-Mod ne doit pas être utilisé pour les communications entre systèmes.

Permutation finale, compatible ISO-8859 vers EBCDIC

La transformation intermédiaire précédente laisse les données dans un format basé sur l’ISO 8859 (donc aussi compatible avec ISO 646 dont l’ASCII, et avec MIME), aussi une transformation réversible de permutation d’octets est opérée sur les séquences d’octets intermédiaires, afin de les rendre aussi proche que possible de l’EBCDIC au moyen d’une table de correspondance.

Toutefois cela n’est possible que pour les positions invariantes de l’EBCDIC, la table de permutation étant basée directement sur la transformation réversible de la version américaine de l’ISO 646 (communément appelée ASCII) en la version américaine de l’EBCDIC : l’UTF-EBCDIC ne définit ni n’utilise aucune autre table de transformation pour les autres versions nationales de l’ISO 646 et de l’EBCDIC.

Transformation inverse de l’UTF-8 vers un point de code Unicode

Ces deux étapes précédentes peuvent être facilement inversées pour retrouver les points de code Unicode.

• La seconde étape sera d’abord inversée par l'utilisation d’une seconde table de permutation inverse (ci-dessous), pour produire des séquences d’octets transformées en UTF-8-Mod : cette table est en fait une table de permutation des 256 valeurs possibles d’octets, et est l’exacte inverse de la table de la section précédente.
• Puis la première étape sera inversée algorithmiquement.

Détection des octets de tête dans les textes contenant des séquences UTF-EBCDIC

Un défaut de l’UTF-EBCDIC est qu’il n’est pas simple de détecter, dans un texte codé en UTF-EBCDIC, quels octets délimitent chaque séquence.

En effet, ils sont dispersés parmi les 256 valeurs possibles, et la technique courante nécessite une table de correspondance permettant de savoir si un octet isolé représente un caractère (sauf pour les codes de contrôle C0 et C1 groupés entre 0x00 et 0x3F ou le caractère d’oblitération (DEL) codé 0xfF dans toutes les versions de l’EBCDIC), ou si c'est un octet de queue ou un octet de tête indiquant la longueur effective de la séquence.

Cette table de correspondance est décrite dans le Rapport technique n°16 et contient des drapeaux (shadow flags) pour chaque valeur d’octet possible. Son coût algorithmique et en termes de performance est non négligeable, et finalement similaire à celui de la table de permutation utilisée dans la deuxième étape de transformation depuis l’UTF-EBCDIC. Son intérêt reste très limité en termes de performance, puisqu’il faut encore traiter spécialement les octets finals (tous identifiés par le même drapeau car on ne peut connaître leur position relative dans la séquence uniquement depuis leur seule valeur d’octet) et procéder à des boucles supplémentaires de lecture et de test pour trouver le premier octet de la séquence.

Aussi, de nombreuses implémentations de l’UTF-EBCDIC se contentent uniquement de la table de permutation inverse des octets UTF-EBCDIC vers UTF-8-Mod, et se passent de la table de drapeaux. Ils effectuent alors un simple test de valeur, sachant que dans UTF-8-Mod, les octets de queue obéissent tous à la condition très simple à tester (écrite ici en syntaxe des langages C, C++, Java ou C#) :

(octet & 0xE0) == 0xA0

Utilisation de l’UTF-EBCDIC

Généralement, cet encodage est rarement utilisé, même sur les mainframes basé sur l’EBCDIC et pour lesquels cet encodage a été conçu. Les systèmes de mainframes IBM basés sur l’EBCDIC, comme z/OS ou MVS, utilisent aujourd’hui généralement l’UTF-16 pour un support complet d’Unicode : par exemple, DB2 UDB, COBOL, PL/I, Java et la boîte d’outils IBM pour XML supportent tous l’UTF-16 sur les systèmes IBM.

Extension sur 32 bits à usage interne

La transformation UTF-EBCDIC peut être parfois étendue pour faciliter les traitements internes, en considérant que les séquences UTF-EBCDIC limitées à 4 octets peuvent coder tout point de code jusqu’à la fin du plan supplémentaire n°3 (c'est àdire jusqu’à U+3FFFF). Ainsi, il est possible de représenter (de façon interne uniquement) tous les points de code du plan multilingue de base sous une forme comparable à l’UTF-16, en représentant aussi les codes de demi-zone (surrogates) de l’UTF-16. On obtient alors facilement un codet sur 32 bits, qui reste compatible avec l’EBCDIC pour chaque point de code du BMP, et deux codets de 32 bits chacun pour représenter les points de code des plans supplémentaires.

Cette représentation alternative ne doit pas être utilisée dans les échanges entre systèmes, mais uniquement pour faciliter et optimiser les interfaces de programmation interne où les caractères EBCDIC sont échangés dans des codets (en mémoire) de 32 bits, ce qui limite alors le nombre de tests de valeurs et évite le recours systématique aux tables de permutation pour tester les étendues de caractères lors de traitements complexes ou volumineux de textes (l’utilisation systématique des tables de permutation est une opération coûteuse en termes de performance, si on la compare à un simple test basé sur les intervalles de valeurs des codets de 32 bits).

Actuellement cette représentation interne n’a aucune dénomimation officielle bien définie, même si certains l’appellent UTF-16-Mod ou UTF-16-EBCDIC (dénominations impropres car cette transformation crée des codets de 32 bits représentant chacun un codet de 16 bits de l’UCS-2).

Son intérêt par rapport à la représentation intermédiaire UTF-8-Mod est qu’il devient possible d’éviter l’utilisation de toute table pour savoir si un codet est le premier d’une séquence ou l’un des codets finals. En effet, les codets des demi-zones de l’UTF-16 (qui permettent de savoir si un codet est le premier ou le second d’une séquence) sont représentés aussi dans des intervalles contigus de codets sur 32 bits dans cette représentation, ce qui facilite leur détection par un test arithmétique uniquement et qui permet de savoir si un codet 32-bit est le premier ou le second représentant un point de code supplémentaire, ou si le codet de 32 bits est isolé et représente un point de code du BMP. D’autre part, cette représentation interne préserve aussi les valeurs de tous les caractères EBCDIC invariants.

Toutefois la transformation d’une séquence UTF-EBCDIC dans cette représentation interne sur 32 bits nécessite de savoir quels octets délimitent une séquence UTF-EBCDIC, ce qui nécessite une table de drapeaux (appelée show flags) pour interpréter correctement l’UTF-EBCDIC. Mais l’inverse est immédiat et ne nécessite aucune table (la transformation inverse sefaisant par simple décalages binaires et tests desvaleurs nulles poursavoir si un ou plusieurs octets doivent être émis dans l’UTF-EBCDIC.

Si le stockage n’est pas important et ne concerne que des quantités limitées de caractères, cette représentation sera plus rapide (par exemple comme étape intermédiaire pour transformer un texte UTF-EBCDIC en majuscules quand on dispose de tables ou d'algorithmes basées sur l’EBCDIC, ou comme étape intermédiaire du calcul de clés de collation basées sur l’EBCDIC ou l’UTF-EBCDIC, ou en interne dans des analyseurs lexicaux traitant des textes codés en EBCDIC ou UTF-EBCDIC).

Par contre, son principal défaut est évidemment sa taille, double de l’UTF-16 (c’est pourquoi les bases de données préfèrent indexer ou stocker les textes et clés de recherche en utilisant l’UTF-16 plus compact).

Voir aussi

Liens internes

• Unicode
• UTF-8, UTF-16
• MVS, z/OS

Liens externes

• (en) Unicode Technical Report #16: the definition of UTF-EBCDIC

v · Unicode
Jeux de caractères	UCS (ISO/CEI 10646) · ISO 646, ASCII · ISO 8859-1 · WGL4 · UniHan
Équivalences normalisées	NFC (précomposée) · NFD (décomposée) · NFKC (compatibilité) · NFKD (compatibilité)
Propriétés et algorithmes	ISO 15924 · Casse · Ordonnancement UCA · Texte bidirectionnel · BOM
Codage	UTF-7 · UTF-8 · CESU-8 · UTF-EBCDIC · BOCU-1 · SCSU · UTF-16 · UTF-32
Autres transformations	Punycode · GB 18030
Applications d’échanges de données	Courriel et Unicode · Unicode et HTML

v · Unicode			ISO/CEI 10646, Table des caractères Unicode, UTF-8, UTF-16, UTF-32, UTF-EBCDIC, CESU-8, BOCU-1
Autres	ISO/CEI 2022, Big5, ISCII, GB 18030, GBK, Shift-JIS, Codage des caractères chinois

Codés sur 8 bits

ISO/CEI 8859	ISO/CEI 8859-1 (latin-1), ISO/CEI 8859-3 (latin-3), ISO/CEI 8859-15 (latin-9)
Pages de code Windows	Windows-1252 (latin-1), Windows-1258 (vietnamien)
Pages de code MacOS	MacRoman
Pages de code DOS	CP437 (latin-US), CP850 (latin-1), CP852 (latin-2)
Pages de code diverses	DEC-MCS, KOI8-R (russe), KOI8-U (ukrainien), StandardEncoding (PostScript)
Non basés sur ISO 646	VISCII, EBCDIC, EBCDIC 297, EBCDIC 8859

Autres

Codés sur 7 bits	ASCII, ISO 646
Moins de 7 bits	Code morse, Code wabun, Code Baudot, RADIX-50, Sixbit

Articles connexes Codage des caractères, Clavier d’ordinateur, Police numérique, Glyphe, Portail:Écriture

• Portail de l’informatique
• Portail de l’écriture