Décoder de l’hexadécimal

Les espaces, les deux-points, les virgules et un `0x` devant chaque octet sont tous retirés avant que quoi que ce soit ne soit lu. Cela couvre une fenêtre de surveillance de débogueur, une capture réseau, une empreinte de certificat, un littéral de tableau en C et la sortie de `xxd`, c’est-à-dire les cinq endroits d’où une suite hexadécimale provient réellement.

L’alternative est un outil qui exige une chaîne propre et ininterrompue, ce qui impose de retaper ou de faire un remplacement avant de pouvoir poser sa question. Chacune de ces étapes est une occasion de perdre un chiffre, et perdre un chiffre décale tous les octets suivants — produisant un texte confiant et faux plutôt que visiblement cassé.

Chaque octet fait exactement deux chiffres, donc un compte impair signifie qu’il manque quelque chose et il n’existe aucun moyen de savoir de quel côté. Compléter au début et compléter à la fin donnent des réponses différentes, et les deux paraissent plausibles.

L’outil s’arrête donc et le dit. Cela vaut mieux qu’une réponse : un nombre impair de chiffres signifie presque toujours que la copie a été tronquée ou qu’un caractère a été perdu, et le savoir immédiatement est plus rapide que de lire une chaîne décodée en se demandant pourquoi elle commence au milieu d’un mot.

Beaucoup d’hexadécimal n’est pas une chaîne. Une instruction compilée, un bloc compressé, une clé, un en-tête d’image — tous se décodent en octets qui ne forment aucun UTF-8 valide, et la plupart des décodeurs vous rendent quand même un écran de caractères de remplacement.

Celui-ci indique le nombre d’octets à la place. Cela distingue deux situations autrement identiques : votre entrée était fausse, ou votre entrée était bonne et le contenu n’est simplement pas du texte. La seconde n’est pas un échec, et la traiter comme tel envoie les gens chercher une erreur qu’ils n’ont pas commise.

La plupart des formats binaires s’annoncent. `89 50 4e 47` est un PNG, `ff d8 ff` un JPEG, `25 50 44 46` un PDF — celui-là épelle `%PDF` en ASCII, ce qui explique pourquoi les quatre premiers octets d’un PDF sont lisibles ici alors que le reste ne l’est pas. `50 4b 03 04` est un ZIP, et donc aussi un document Office moderne ou un JAR.

`ef bb bf` n’est pas un format du tout : c’est une marque d’ordre des octets UTF-8, et la trouver au début d’une suite explique toute une classe de défauts où le premier champ d’un fichier refuse de correspondre à une chaîne qu’il égale visiblement.

Un `c3` suivi d’un octet entre `a0` et `bf` est un caractère accentué : `c3 a9` donne `é`, `c3 a8` donne `è`, `c3 a7` donne `ç`. Si votre dump en contient, le texte derrière est en UTF-8 et cette page le rendra correctement.

Si à la place vous voyez des `e9`, `e8` ou `e0` isolés au milieu de texte lisible, les octets sont en Latin-1. Ils ne forment pas d’UTF-8 valide, donc cette page les signalera plutôt que d’en faire un mot approximatif — et ce signalement est la réponse : le problème est l’encodage de la source, pas le décodage.

Un texte en UTF-16 décodé comme de l’UTF-8 donne un résultat caractéristique : chaque lettre suivie d’un octet nul, ou précédée, selon l’ordre des octets. Vous voyez donc `41 00 42 00` là où l’UTF-8 aurait donné `41 42`.

C’est courant sur des données venues de Windows, où plusieurs API travaillent nativement en UTF-16. Reconnaître le motif vous évite de conclure que le décodeur est cassé : il ne l’est pas, vous tenez simplement un autre encodage, et la conversion doit se faire avant plutôt qu’ici.

Un dump peut contenir `00`, `07`, `1b` ou `7f` — respectivement un octet nul, une sonnerie, un début de séquence d’échappement de terminal et une suppression. Ils font partie de l’UTF-8 valide et n’ont aucune apparence à l’écran.

Le résultat peut donc sembler plus court qu’il ne l’est, ou contenir des choses qui n’apparaissent nulle part. C’est notamment ce qui se passe avec les séquences de couleur d’un terminal, qui commencent par `1b 5b` : un journal copié depuis une console coloriée en est rempli, et elles expliquent pourquoi une comparaison de chaînes échoue sur deux lignes identiques à l’œil.

Une valeur copiée depuis un débogueur arrive souvent avec un nom de variable, une adresse ou un nombre d’octets accolés. Ces caractères ne sont pas hexadécimaux et provoquent un refus, ce qui est le comportement voulu : deviner lesquels retirer reviendrait à deviner où commence la donnée.

La règle pratique est de ne copier que ce qui est fait de chiffres et de séparateurs. Si le refus persiste sur une chaîne qui semble propre, cherchez un `l` minuscule pris pour un `1`, un `O` majuscule pris pour un `0`, ou un tiret cadratin substitué à un tiret par une correction automatique.

Il ne restitue pas la structure. Un dump d’un enregistrement binaire redevient une suite d’octets, et savoir que les quatre premiers étaient une longueur et les deux suivants un type demande de connaître le format. Cette page lit des octets comme du texte ; elle ne sait rien d’un protocole.

C’est pourquoi le message qui indique le nombre d’octets est souvent plus utile que le texte lui-même. Il vous dit que l’entrée était cohérente et vous rend à la question suivante, qui est celle du format — et cette question-là se résout avec la documentation du protocole, pas avec un convertisseur.