Convertir EBCDIC en ASCII : sept pages de codes

Qu’est-ce qu’EBCDIC ?

EBCDIC est l’encodage de caractères conçu par IBM pour ses mainframes au début des années soixante, et c’est encore là que vivent d’énormes quantités de données bancaires, assurantielles et administratives. Si vous avez déjà ouvert un fichier venu d’un mainframe pour y trouver un charabia à l’air presque lisible, EBCDIC en est généralement la raison : les octets sont corrects, ils ne signifient simplement pas ce que votre éditeur suppose.

La première chose à savoir est qu’EBCDIC n’est pas un encodage mais une famille, et que ses membres ne s’accordent pas. Cet outil en embarque sept — ceux qu’une bibliothèque standard généraliste implémente réellement — et vous laisse convertir dans les deux sens tout en montrant lesquels de vos octets les six autres liraient autrement.

La seconde est plus étrange, et c’est la raison pour laquelle tester un intervalle de lettres est un bogue de portabilité et non une affaire de style.

Comment l’utiliser

1. Choisissez un sens et une page de codes. Le sélecteur de page reste toujours visible et ne devine jamais, car un convertisseur qui choisit seul est précisément l’erreur que cet outil met en évidence. Si vous ignorez quelle page utilise un fichier, le tableau des divergences ci-dessous est la façon de le découvrir.
2. Collez vos octets ou votre texte. L’hexadécimal accepte les espaces, les virgules et le préfixe 0x, et lit une longue suite deux chiffres à la fois. Ce qui n’est pas de l’hexadécimal est listé plutôt qu’ignoré en silence.
3. Lisez les panneaux du dessous. L’un montre chaque octet de votre saisie sur lequel les sept pages divergent. Un autre parcourt l’intervalle des lettres et compte ce qui s’y trouve sans en être une. Un dernier vous dit si cette page supporte l’aller-retour.

Les lettres ne se suivent pas

En ASCII les minuscules vont de 97 à 122 sans rien entre les deux, et c’est pourquoi tout le monde écrit un test d’intervalle pour savoir si un caractère est une lettre. En EBCDIC ce test est faux, et pas de peu.

Sur la page américaine, le a vaut 0x81 et le z 0xA9. Cela fait quarante et un octets pour vingt-six lettres : l’intervalle emporte donc quinze valeurs qui ne sont pas des lettres. La suite se rompt deux fois — entre i et j la valeur saute de huit, entre r et s de neuf. L’outil dessine l’intervalle entier de la page sélectionnée et met les intrus en évidence, pour que vous les comptiez vous-même.

La raison est la carte perforée. EBCDIC fut conçu pour que l’octet d’un caractère se lise directement sur les perforations de zone et de chiffre de la carte, et une zone n’a jamais offert plus de neuf positions avant que la suivante ne commence. Les lettres furent réparties en groupes de neuf, neuf et huit, et les trous marquent la fin de chaque zone. Une disposition parfaitement sensée pour un lecteur de cartes est devenue, soixante ans plus tard, un piège pour un test d’une ligne.

Les chiffres, soit dit en passant, se suivent bien : de 0 à 9 ils vont de 0xF0 à 0xF9 sans rupture. Seules les lettres sont interrompues, et c’est exactement pourquoi l’erreur survit — la moitié de ce que vous retenez de la disposition est exacte.

Les pages divergent sur les crochets, pas sur les lettres

Prenez les deux pages latines les plus courantes, l’américaine et l’internationale. Elles diffèrent sur exactement sept valeurs d’octet sur 256, et les sept caractères concernés sont les crochets, la barre verticale, le point d’exclamation, le circonflexe, le symbole cent et le signe de négation.

Ce n’est pas une substitution mais un battage de cartes : les mêmes sept caractères occupent les mêmes sept positions d’octet sur les deux pages, dans un ordre différent. Toutes les lettres et tous les chiffres sont identiques. Un fichier de prose passe donc d’un système à l’autre sans une égratignure, tandis qu’un fichier de code source arrive avec ses crochets changés en symboles monétaires. Voilà pourquoi le problème reste dans les mémoires comme un problème de crochets et non d’encodage : les dégâts se concentrent exactement sur les caractères dont un langage de programmation dépend, et épargnent tout le reste.

Sur les sept pages réunies ici, seules 150 des 256 valeurs d’octet signifient partout la même chose. Le panneau des divergences se limite volontairement aux octets de votre saisie plutôt qu’à la table entière, car la question qui vaut d’être posée est de savoir si votre fichier se lirait autrement ailleurs.

Limites assumées

Sept pages, ce n’est pas toutes. IBM en a défini bien davantage, et les sept retenues ici sont celles qu’implémente une bibliothèque standard généraliste — ce qui a permis de générer les tables depuis une source plutôt que de les saisir. Si votre fichier emploie une page absente de la liste, cet outil ne peut rien et essayer les autres n’y changera rien.

L’aller-retour n’est pas universel, et l’outil le dit page par page plutôt que d’en faire une promesse globale. Cinq des sept supportent un décodage puis un réencodage des 256 valeurs. La page hébraïque laisse trente-huit positions d’octet sans attribution : celles-là ne peuvent pas revenir depuis le texte, il n’y a jamais rien eu. La grecque est différente et plus subtile : elle attribue les 256, mais sept de ses valeurs d’octet partagent un même caractère de remplissage, si bien qu’une seule du groupe peut être réencodée et que les six autres se perdent. Deux défauts distincts qui, dans un résumé, se ressemblent — d’où deux mentions séparées.

Enfin, votre navigateur ne sait rien faire de tout cela nativement. La norme d’encodages du web énumère ceux qu’un navigateur doit prendre en charge et précise qu’il ne doit en prendre en charge aucun autre ; EBCDIC n’y figure pas et n’y figurera jamais. C’est pourquoi les tables voyagent avec la page au lieu d’être confiées à un décodeur intégré, et c’est la même norme dont traite la liste des encodages de caractères de ce site, vue de l’autre côté.

Pourquoi est-ce gratuit ?

Sept tables de 256 entrées font environ cinq kilo-octets une fois compressées, et votre navigateur effectue la conversion pendant que vous tapez. Aucun serveur ne voit vos données : il n’y a donc rien à facturer ni de compte à créer.

Rien n’est envoyé. Ce que vous collez reste dans cet onglet.