Encoder en hexadécimal

Tout dump hexadécimal est en réalité une question sur l’encodage, et la question reste invisible tant que le texte est de l’ASCII. En UTF-8, une lettre accentuée prend deux octets, un caractère CJK trois et un emoji quatre ; en UTF-16 la même lettre prend deux octets et l’emoji quatre, disposés autrement ; en latin1 la lettre prend un octet et l’emoji ne peut pas être représenté du tout.

Cette page émet de l’UTF-8, parce que c’est ce que contiennent massivement un fichier sur disque, un corps de requête et une colonne de base aujourd’hui. L’implémentation classiquement fausse lit l’unité de code à chaque index, ce qui donne un octet par caractère pour tout ce qui tient dans la plage Latin-1 — donc `é` sort en `e9` là où le fichier contient `c3 a9`, et tous les tests écrits sur du texte anglais passent.

Un octet `c3` dans un dump est presque toujours le début d’un caractère accentué. `c3 a9` est `é`, `c3 a8` est `è`, `c3 a0` est `à`, `c3 a7` est `ç` et `c3 b4` est `ô`. Un texte français produit donc une trame reconnaissable : des `c3` régulièrement espacés, chacun suivi d’un octet de la plage `a0`–`bf`.

C’est un diagnostic rapide et fiable. Si vous voyez des `e9` ou des `e0` isolés là où vous attendiez des accents, le texte est en Latin-1 et non en UTF-8 ; si vous voyez `c3 83` suivi d’autre chose, le texte a été encodé deux fois en UTF-8, ce qui est exactement ce que produit un `é` affiché à l’écran puis réenregistré.

Parce que c’est la destination qui décide, et que les destinations ne sont pas d’accord. Un éditeur hexadécimal et la plupart des documentations veulent des octets séparés par une espace. Un champ de protocole, une valeur de couleur ou un identifiant veulent une suite ininterrompue. Une empreinte de certificat ou une adresse MAC veulent des deux-points. Un littéral de tableau en C ou en Java veut des virgules.

Aucune de ces formes n’est plus correcte que les autres, et convertir de l’une à l’autre à la main sur un long dump est exactement le genre de tâche qui introduit la faute de frappe que vous passerez une heure à trouver. Le décodeur de la page voisine accepte les quatre sans qu’on lui dise laquelle, donc un aller-retour est sans perte quelle que soit votre préférence.

Tout analyseur hexadécimal digne de ce nom accepte les deux, donc le choix concerne le regard et non la machine. Les minuscules sont la convention dans l’outillage Unix, dans les identifiants d’objets Git et dans la documentation moderne. Les majuscules sont ce qu’impriment les éditeurs hexadécimaux, les RFC et beaucoup de travaux sur l’embarqué, et elles se parcourent plus facilement quand chiffres et lettres se mêlent sur une longue ligne.

Le seul endroit où ce n’est pas cosmétique est une comparaison faite sur des chaînes. Une somme de contrôle comparée avec `===` à une valeur écrite dans l’autre casse échoue tout en étant correcte, et ce défaut traverse la relecture parce que les deux valeurs sont visiblement le même nombre. Comparez sans tenir compte de la casse, ou normalisez avant.

À trouver ce qui n’est pas visible. Un saut de ligne final, une espace insécable insérée par un traitement de texte, une marque d’ordre des octets au début d’un CSV qui empêche le premier en-tête de colonne de correspondre, une double espace dans une clé — rien de tout cela ne se voit dans un champ de texte et tout se voit dans un dump.

La marque d’ordre des octets mérite d’être nommée. `ef bb bf` au début d’un fichier est une marque UTF-8, et c’est pourquoi une colonne appelée `id` refuse de correspondre à la chaîne `id` dans un script par ailleurs correct. Collez la première ligne d’un fichier récalcitrant ici : elle y est ou elle n’y est pas, ce qui prend une minute au lieu d’un après-midi.

La typographie française l’exige avant `?`, `!`, `;` et `:` et autour des guillemets, et les traitements de texte l’insèrent automatiquement. En UTF-8 elle s’écrit `c2 a0`, tandis qu’une espace ordinaire s’écrit `20`.

C’est la cause la plus fréquente de deux chaînes visiblement identiques qui refusent de correspondre : un titre copié depuis un document contient des `c2 a0` là où la saisie manuelle a mis des `20`. Le dump le montre immédiatement, et c’est souvent la seule façon de le voir sans écrire de code.

Unicode permet d’écrire `é` de deux manières : un point de code unique, `c3 a9`, ou un `e` suivi d’un accent aigu combinant, `65 cc 81`. Les deux s’affichent à l’identique dans toutes les polices, et ils ne sont pas égaux.

macOS produit couramment la seconde forme dans les noms de fichiers, Windows et Linux la première. Un dump est la seule façon simple de savoir laquelle vous tenez, et cela explique une classe entière de problèmes : un nom de fichier qui existe pour l’explorateur et pas pour un script, une recherche qui ne trouve rien, une comparaison qui échoue sur un mot parfaitement écrit.

Le dump donne aussi une réponse à une question qu’on ne pense pas toujours à poser : combien d’octets pèse ce texte. Chaque paire de chiffres est un octet, donc compter les paires suffit, et le résultat diffère du compte de caractères dès qu’il y a un accent.

C’est la mesure qui compte pour une colonne de base déclarée en octets, pour une limite de taille de message, pour un champ de protocole à longueur fixe. Un libellé français de 200 caractères peut peser 230 octets, et la différence est exactement le nombre d’accents qu’il contient.

Elle ne prend pas de fichier. Le champ attend du texte, parce que le cas d’usage est une valeur qu’on recopie ou qu’on inspecte — une clé, un en-tête, une ligne suspecte. Pour parcourir un fichier binaire entier, l’outil approprié est un éditeur hexadécimal, qui affiche aussi les décalages et permet de naviguer.

Coller la première ligne d’un fichier reste néanmoins l’un des usages les plus utiles de cette page, précisément parce que c’est là que se cachent la marque d’ordre des octets et les surprises d’encodage. Le reste du fichier, en général, ne pose pas de question.