Convertisseur texte vers hexadécimal

Une chaîne vue comme les octets qui la stockent

Toute chaîne qu’un programme manipule est, en dessous, une suite d’octets, et cette page les écrit en hexadécimal, deux chiffres chacun. Tapez Hello et vous obtenez 48 65 6C 6C 6F, un octet par lettre, avec une espace après chacun sauf le dernier. Réglez plutôt le sens sur « Hexadécimal vers texte » et collez de l’hexadécimal tiré d’un journal, d’une base de données ou d’un débogueur : vous récupérez le texte que contiennent ces octets.

Un même texte donne des octets différents selon l’encodage, et c’est l’unité qui décide de ce que sont les chiffres de cette page. L’unité démarre sur UTF-8, l’encodage du web, où H est l’octet 48 et א les octets D7 90. UTF-16 LE et UTF-16 BE consacrent deux octets à chacun d’eux, dans des ordres opposés — 48 00 ou 00 48 pour H —, tandis que « Points de code » laisse les octets de côté et écrit le numéro qu’attribue Unicode, U+05D0 pour א. L’unité réglée vaut pour l’hexadécimal que vous lisez comme pour le texte que vous écrivez, et elle reste réglée : si l’hexadécimal collé ressemble à celui d’une autre unité, la page peut proposer celle-là, mais seul votre clic fait changer d’unité.

Deux chiffres hexadécimaux par octet

Un octet contient l’une de 256 valeurs, de 0 à 255. L’hexadécimal compte par seize, avec les chiffres 0 à 9 puis A à F pour dix à quinze, et seize fois seize font 256, si bien que deux chiffres hexadécimaux nomment chaque octet et qu’un troisième n’est jamais nécessaire : 00 vaut 0, 7F vaut 127 et FF vaut 255. H vaut 72, soit quatre fois seize plus huit, donc son octet est 48.

Chaque chiffre hexadécimal représente exactement quatre bits, la moitié d’un octet : le 4 de 48 s’écrit 0100 et le 8, 1000, et, côte à côte, ils forment les huit bits de H, 01001000. La page garde les deux chiffres de chaque octet, si bien qu’un saut de ligne s’écrit 0A et une espace 20, et, comme chaque octet occupe la même largeur, l’hexadécimal peut se relire sans rien entre les octets : 4869 donne Hi.

En hexadécimal, les lettres veulent dire la même chose dans l’une ou l’autre casse. La page écrit en majuscules sauf si vous choisissez « minuscules », si bien qu’un é s’écrit C3 A9 ou c3 a9, et elle lit les deux, même mélangées dans un même collage.

Cinq styles, chacun taillé pour l’endroit où il sera collé

En hexadécimal, le réglage « Style » dispose les mêmes octets de cinq façons, chacune pour un endroit où l’hexadécimal va ensuite. Pour Hi, soit les deux octets 48 et 69 :

• « Espacé » donne 48 69, une espace entre les octets : le plus facile à lire et à compter, et le style sur lequel la page s’ouvre.
• « Compact » donne 4869, les chiffres accolés, pour un champ ou un paramètre qui prend une valeur sous la forme d’une seule chaîne hexadécimale.
• « Tableau » donne 0x48, 0x69, chaque octet étant un nombre précédé de 0x, une virgule entre eux, le tout prêt à coller dans un tableau d’octets en C, C#, JavaScript, Python ou Go.
• « Échappé » donne \x48\x69, chaque octet sous la forme \x suivi de ses deux chiffres, comme on écrit un octet dans une chaîne C ou dans un littéral d’octets Python tel que b'\x48\x69'.
• « Vidage hexadécimal » dispose les octets en lignes, avec l’endroit où commence chaque ligne et, à côté, les mêmes octets sous forme de texte : la section suivante en lit un.

La lecture reprend les cinq, ainsi que d’autres mises en forme qui laissent les octets intacts : des deux-points comme dans 48:69, les traits d’union qu’écrit le BitConverter.ToString de .NET, comme dans 48-69, 0x ou 0X devant chaque octet, et le collage entier entouré une fois de parenthèses, de crochets, d’accolades ou de guillemets. Le style et la casse ne comptent que pour l’écriture, si bien que les deux réglages disparaissent quand le sens est « Hexadécimal vers texte ».

Un piège se cache dans « Échappé ». Dans une chaîne JavaScript, ou dans une chaîne Python ordinaire plutôt qu’un littéral d’octets, \x désigne un caractère et non un octet, si bien que \xD7\x90 y fait deux caractères, et non le א dont les octets UTF-8 sont D7 90. Au-delà de l’ASCII, confiez les octets à quelque chose qui prend des octets.

Lire un vidage hexadécimal, colonne par colonne

Un vidage hexadécimal dispose les octets seize par ligne, avec une colonne de chaque côté pour vous aider à les repérer. Écrits avec « Vidage hexadécimal », Hello, World! et un saut de ligne remplissent une ligne : d’abord 00000000, le décalage, c’est-à-dire la position du premier octet de la ligne comptée depuis zéro, en huit chiffres hexadécimaux ; puis les quatorze octets, huit puis six, avec un écart plus large entre les deux moitiés ; puis |Hello, World!.|, les mêmes octets sous forme de caractères, chaque octet qui n’est pas de l’ASCII imprimable étant affiché comme un point, le saut de ligne compris. Une dernière ligne ne contient que 0000000E, soit quatorze : l’endroit où se trouverait l’octet suivant, et donc la longueur. C’est la disposition qu’affiche hexdump -C.

• Avec « Hexadécimal vers texte » choisi et n’importe quelle unité sauf « Points de code », un vidage hexadécimal collé est lu pour ses seuls octets : la colonne de texte est laissée hors de la lecture, aucun décalage n’est lu comme un octet, et un avis sous le résultat dit que l’entrée a été prise pour un vidage et nomme la disposition.
• Deux dispositions sont lues ainsi : celle que produit hexdump -C, et ce qu’affiche xxd sans option, où un deux-points suit chaque décalage et où les octets se présentent en groupes de quatre chiffres. L’hexadécimal brut qu’affiche xxd -p n’a besoin d’aucune disposition et se lit comme n’importe quel autre hexadécimal.
• hexdump -C affiche une ligne réduite à * à la place des lignes qui répètent celle du dessus, et la page remplit de nouveau ces lignes à partir du décalage de la ligne suivante, si bien que les octets reviennent au complet.
• Chaque décalage après le premier doit découler des octets au-dessus de lui, y compris la longueur qu’affiche hexdump -C sur sa dernière ligne, et une ligne dont le décalage ne suit pas est refusée à cet endroit plutôt que lue de travers : c’est là qu’apparaît une ligne omise, un octet perdu ou un décalage mal tapé. Ce qu’aucun décalage ne suit ne peut pas être vérifié ; un vidage hexadécimal privé de ses premières lignes, ou la fin d’un vidage sans ligne de longueur après elle — xxd n’en écrit pas —, se lit donc comme ce qui reste.

UTF-16 LE, et pourquoi un octet sur deux vaut 00

Windows conserve le texte en UTF-16 avec l’octet de poids faible en premier, ce qui est l’UTF-16 LE ; en .NET, c’est Encoding.Unicode, et SQL Server stocke une valeur NVARCHAR de la même façon. L’UTF-16 donne deux octets à chaque caractère jusqu’à U+FFFF, et pour tout ce qui va jusqu’à U+00FF — les lettres de l’alphabet anglais, les chiffres, é et le reste du Latin-1 — l’octet de poids fort vaut 00. L’octet de poids faible venant en premier, ce zéro tombe après chaque lettre : Hi s’écrit 48 00 69 00.

SQL Server affiche une valeur VARBINARY sous la forme 0x suivi de son hexadécimal, si bien qu’un NVARCHAR contenant Hi, converti en VARBINARY, s’affiche 0x48006900. Collez cela ici alors que l’UTF-8 est choisi : le texte sort sous la forme H, un NUL, i et un NUL, et l’avis en dessous dit qu’un octet sur deux vaut 00, comme dans un texte en alphabet latin écrit en UTF-16 plutôt qu’en UTF-8, avec « Passer en UTF-16 LE » à côté. Appuyez dessus et les mêmes octets se lisent Hi.

L’UTF-16 BE place au contraire l’octet de poids fort en premier : Hi y devient 00 48 00 69, et א, D0 05 en UTF-16 LE, y devient 05 D0. Des zéros à la première place de chaque paire font que l’avis propose UTF-16 BE. Il ne dit rien dès qu’un caractère au-delà de U+00FF figure dans le texte, parce que l’octet de poids fort de ce caractère ne vaut pas 00, et il ne parle que là où un octet sur deux vaut 00.

Une marque d’ordre des octets au début

Un texte peut commencer par U+FEFF, un caractère qui n’affiche rien et qui est là pour servir de marque d’ordre des octets. En UTF-16, ses deux octets donnent l’ordre de chaque paire qui suit, FF FE pour l’UTF-16 LE et FE FF pour l’UTF-16 BE, et en UTF-8 ce sont les trois octets EF BB BF, une signature indiquant que le texte est en UTF-8 — un encodage qui n’a qu’un seul ordre.

La page conserve une marque plutôt que de la supprimer. L’hexadécimal qui commence par la marque propre à l’unité choisie se lit comme un texte commençant par U+FEFF, et un avis dit que la marque a été conservée, si bien que réécrire ce texte redonne les mêmes octets, marque comprise. L’hexadécimal qui commence par la marque de l’autre ordre UTF-16, ou par une marque UTF-16 alors que l’UTF-8 est choisi, reçoit un avis indiquant que les octets commencent par la marque d’une autre unité, à côté d’un bouton qui passe à l’ordre que nomme la marque. Partout ailleurs qu’au début, U+FEFF est un caractère ordinaire et ne déclenche aucun avis.

Des octets qui ne sont pas du texte, affichés comme U+FFFD

Les séquences d’octets ne sont pas toutes du texte dans l’unité choisie : un caractère privé de son dernier octet, un octet égaré comme E9, que d’anciennes pages de codes écrivent pour é, et un octet en trop resté à la fin de l’UTF-16 ne forment rien. Une mauvaise séquence ne fait pas échouer tout le collage pour autant : chacune est remplacée par U+FFFD, le caractère de remplacement, et tout le reste se lit normalement.

Un avis donne alors leur nombre et désigne la première par sa place parmi les octets, par les chiffres que vous avez écrits pour elle et par sa ligne et sa colonne. Café enregistré en Windows-1252, la page de codes Windows du texte d’Europe occidentale, s’écrit 43 61 66 E9, é y tenant en un seul octet, E9 ; lu en UTF-8, il revient sous la forme Caf et U+FFFD, et l’avis désigne l’octet 4, écrit E9, à la ligne 1, colonne 10. En UTF-8, le mot s’écrit 43 61 66 C3 A9.

L’avis compte des séquences, pas des octets : F0 9F 98, trois des quatre octets de 😀, forment un seul U+FFFD. Et un U+FFFD qui se trouve réellement dans le texte, les octets EF BF BD, est lu comme du texte et n’est pas compté du tout, si bien que l’avis ne porte jamais que sur des octets qui ne se sont pas lus.

Refaire un fichier à partir de l’hexadécimal

La lecture vous remet les octets en plus du texte. Avec le sens sur « Hexadécimal vers texte » et UTF-8, UTF-16 LE ou UTF-16 BE choisi, « Télécharger » enregistre, dans un fichier nommé bytes.bin, exactement les octets qui ont été lus, y compris ceux qui n’étaient pas du texte, et avant tout remplacement : le travail que fait xxd -r avec un vidage hexadécimal. « Télécharger » n’existe pas pour les points de code, qui ne sont pas des octets, ni pendant l’écriture, quand ce que vous emportez, ce sont des chiffres.

Ainsi, l’hexadécimal de quelque chose qui n’a jamais été du texte revient quand même en entier. Toute image PNG commence par les huit octets 89 50 4E 47 0D 0A 1A 0A ; lus en UTF-8, ils s’affichent comme U+FFFD, les lettres PNG et quatre caractères de contrôle, avec un avis sur l’unique séquence qui n’est pas du texte, et « Télécharger » enregistre les huit à l’identique. Le fichier s’appelle toujours bytes.bin, puisque des octets ne portent pas de nom : donnez-lui donc le sien, comme image.png, une fois qu’il est enregistré.

Où aller pour un caractère, ses bits ou un nombre

Pour savoir ce qu’est un caractère — son nom, sa catégorie, et s’il fait partie des caractères invisibles —, l’Inspecteur de caractères Unicode décompose un texte point de code par point de code et montre aussi les octets UTF-8 de chacun.

Le Convertisseur texte vers binaire est cette même page, ouverte sur le binaire, où le motif que suit l’UTF-8 se lit dans les premiers bits de chaque octet. Et un nombre n’est pas un texte : 255 saisi ici, ce sont les chiffres 2, 5 et 5, donc les octets 32 35 35, tandis que le Convertisseur de bases prend 255 comme une quantité et l’écrit ff en hexadécimal.