Convertisseur de bases

Ce que fait cet outil

Un même nombre peut s’écrire dans de nombreuses bases, et les programmeurs passent sans cesse de l’une à l’autre parmi quatre d’entre elles : le binaire parce que c’est ce que contient le matériel, l’hexadécimal parce qu’il en est une abréviation lisible, le décimal parce que c’est ainsi que les humains pensent, et l’octal parce que les permissions de fichiers et quelques systèmes anciens l’utilisent encore. Saisissez une valeur dans l’un des champs et les autres suivent, avec un champ supplémentaire réglable sur n’importe quelle base de 2 à 36.

Ce qui le distingue d’une calculatrice scolaire, c’est le sélecteur de largeur et la grille de bits. Choisissez 8, 16, 32 ou 64 bits et les nombres négatifs prennent leur vraie représentation machine au lieu d’un signe moins, et chaque bit devient cliquable.

Ce qu’est vraiment une base

Une base, c’est le nombre de chiffres dont vous disposez avant d’en manquer et de devoir retenir. Le décimal en a dix, donc après 9 vient 10. Le binaire en a deux, donc après 1 vient 10. La position de chaque chiffre est une puissance de la base, et c’est tout :

1011           # le nombre, en base 2
1 x 8 = 8      # bit 3
0 x 4 = 0      # bit 2
1 x 2 = 2      # bit 1
1 x 1 = 1      # bit 0
8+0+2+1 = 11   # le total, en décimal

Les bases au-delà de dix ont besoin de plus de dix symboles, elles empruntent donc des lettres : l’hexadécimal va de 0-9 puis a-f, où a vaut 10 et f vaut 15. Cela se poursuit jusqu’à la base 36, qui utilise chaque chiffre et chaque lettre — la plus grande base que l’on puisse écrire avec l’alphabet simple, et la raison pour laquelle cet outil s’arrête là.

Pourquoi l’hexadécimal, et pas autre chose

L’hexadécimal est répandu pour une raison précise : 16 vaut 2 puissance 4, donc un chiffre hex couvre exactement quatre bits. La conversion entre hex et binaire devient une simple lecture de table, sans arithmétique — chaque chiffre hex se développe en ses quatre bits, indépendamment de ses voisins.

d    e    a    d
1101 1110 1010 1101   # chaque chiffre hex est son propre quartet

L’octal fonctionne pareillement avec trois bits par chiffre, puisque 8 vaut 2 puissance 3 — d’où les permissions Unix en octal : trois bits de permission par groupe d’utilisateurs tiennent exactement dans un chiffre. Le décimal n’entretient aucune relation de ce genre avec le binaire, et c’est pourquoi passer de l’un à l’autre demande une vraie division plutôt qu’une lecture de table.

C’est aussi pourquoi le champ binaire est ici groupé par quatre et le champ hex par deux : les groupes coïncident avec les frontières qui comptent, si bien que vous lisez un quartet ou un octet à l’écran sans compter.

Nombres négatifs et complément à deux

Un nombre négatif n’a pas de forme binaire en soi. Il n’y a pas de signe moins dans un registre — seulement des bits — le signe doit donc être encodé dans les bits eux-mêmes, ce qui oblige à décider combien il y en a. C’est la raison d’être du sélecteur de largeur, et pourquoi la réponse change quand vous en changez.

Le schéma qu’emploie toute machine moderne est le complément à deux : pour représenter un nombre négatif, on prend sa forme positive, on inverse chaque bit et on ajoute un. Résultat : le bit de poids fort finit par signifier « négatif », et l’addition ordinaire continue de fonctionner sans cas particulier pour les signes.

0000 0101   # 5
1111 1010   # chaque bit inversé
1111 1011   # plus un : -5 en un octet, ou fb en hex

Élargissez le registre et le même nombre reçoit un autre motif : -5 s’écrit fb sur 8 bits, fffb sur 16 et fffffffb sur 32. La valeur n’a pas changé ; le nombre de bits qui la portent, si. Changer de largeur dans cet outil montre exactement cela.

Pourquoi 0xFF vaut à la fois 255 et -1

Les bits ff ne disent pas s’ils sont signés. Un octet contenant 1111 1111 se lit 255 si le code qui le charge a déclaré un type non signé, et -1 s’il en a déclaré un signé. Rien dans l’octet lui-même ne distingue les deux — le type est une affirmation du programme sur des bits qui ne portent pas cette information.

C’est la source de toute une famille de bogues réels : une somme de contrôle qui ressort négative, un octet lu dans un fichier qui se compare comme inférieur à zéro, un char C qui se comporte autrement sur ARM que sur x86 parce que sa signature dépend de l’implémentation. Chaque fois que les lectures signée et non signée diffèrent, cet outil affiche les deux, car l’écart est en général précisément ce que vous cherchiez.

La grille de bits

Chaque bit de la valeur courante est affiché avec son numéro de position, et un clic l’inverse. Les bases se mettent à jour aussitôt, ce qui rend certaines questions bien plus faciles qu’à la main :

• Quel bit est activé dans cette valeur de drapeaux — cliquez-les et lisez les positions.
• Quel est le masque pour les bits 4 et 7 — activez ces deux-là et lisez l’hex.
• Que fait l’activation du bit de poids fort sur une valeur signée — elle la rend négative, visiblement.
• Cette valeur est-elle une puissance de deux — une puissance de deux a exactement un bit activé.

Le bit 0 est le bit de poids faible et se trouve à droite, convention universelle et raison pour laquelle la grille reste de gauche à droite même sur une page qui se lit à l’envers. Les rangées font huit bits pour que les frontières d’octets se voient d’un coup d’œil.

Les grands nombres restent exacts

Les nombres JavaScript sont des doubles, qui ne contiennent exactement les entiers que jusqu’à 2^53 — environ 9 millions de milliards. Une valeur 64 bits peut dépasser cela, et un convertisseur bâti sur des nombres ordinaires l’arrondira en silence, produisant une chaîne hex plausible et fausse dans ses derniers chiffres.

Ici tout repose sur des entiers de précision arbitraire, si bien qu’une valeur 64 bits complète se convertit exactement. Le mode précision arbitraire va plus loin et supprime la limite entièrement — utile pour les valeurs cryptographiques et les grands identifiants — mais notez que sans largeur fixe il n’y a pas de complément à deux : un nombre négatif y porte simplement un signe moins dans chaque base.

Du binaire au décimal, et du décimal au binaire

Le binaire et le décimal forment ici la seule paire qui ne partage rien : deux n’est pas une puissance de dix et dix n’est pas une puissance de deux, donc aucun des deux sens n’est une lecture de table et tous deux exigent un vrai calcul. Ce n’est pas non plus le même calcul, et c’est la part qu’on énonce rarement : la méthode rapide à la main dans un sens n’est pas l’inverse de la méthode rapide à la main au retour.

• Du binaire au décimal, en doublant : partez du bit le plus à gauche avec zéro, puis, pour chaque bit, doublez ce que vous avez et ajoutez ce bit. Pour 1011 cela donne 1, 2, 5, 11 — un seul passage, aucun poids de position à retenir, et c’est exactement ce que fait cet outil quand il lit ce que vous saisissez.
• Du binaire au décimal, par les positions : additionnez le poids de chaque bit activé, ce qui est l’exemple détaillé plus haut. Plus rapide quand seuls deux ou trois bits sont activés, plus lent quand la plupart le sont.
• Du décimal au binaire, en divisant : divisez par deux et notez le reste, encore et encore, jusqu’à ce qu’il ne reste rien, puis lisez les restes de bas en haut. La réponse arrive par le bit de poids faible d’abord, et c’est pourquoi elle paraît à l’envers pendant tout le temps où vous l’écrivez.
• Du décimal au binaire, en soustrayant : retirez la plus grande puissance de deux qui tient, et recommencez. 200 perd 128 et il reste 72 ; 72 perd 64 et il reste 8 ; 8 perd 8 et il ne reste rien — donc les bits aux positions 7, 6 et 3 sont activés et l’octet vaut 1100 1000. Plus rapide que la division dès que peu de bits sont activés.

Une chose qu’aucune méthode à la main ne couvre ici : un nombre décimal négatif n’a aucune forme binaire tant qu’une largeur n’a pas été choisie. Demandez moins cinq en binaire et la réponse honnête est une question — combien de bits ? — que tranche justement le sélecteur de largeur, et dont traite la section sur le complément à deux plus haut. En mode précision arbitraire il n’y a pas de largeur, donc le signe moins accompagne simplement le nombre dans chaque base.

Du décimal à l’hexadécimal, et de l’hexadécimal au décimal

Presque personne qui le fait souvent ne divise par seize. Le raccourci, c’est la relation de l’hexadécimal avec le binaire : convertissez le nombre décimal en binaire une fois, découpez les bits par groupes de quatre depuis la droite et lisez chaque groupe comme un seul chiffre hex. Le retour est le même chemin à l’envers : dépliez chaque chiffre hex en ses quatre bits, puis additionnez le poids des bits activés. Pour tout ce qui tient dans un octet il existe encore plus court : le premier chiffre hex vaut seize fois le second, il suffit donc de multiplier et d’ajouter.

• 255 vaut ff — un octet dont chaque bit est activé. C’est celui qu’il vaut la peine de savoir par cœur, car c’est là que l’octet s’arrête.
• 256 vaut 100. Un pas au-delà d’un octet plein, les chiffres basculent exactement comme 99 bascule en 100 en décimal, et le nombre hexadécimal gagne un chiffre que l’octet ne peut pas contenir.
• 65535 vaut ffff et 65536 vaut 10000 : les deux mêmes repères un octet plus haut, là où s’arrête un compteur de seize bits.
• 4096 vaut 1000, et c’est pourquoi les tailles de page, les alignements et les décalages en mémoire paraissent ronds en hex et déchiquetés en décimal. L’hexadécimal compte par groupes de quatre bits, et le matériel aussi.

La casse ne compte pas : FF et ff sont la même valeur, l’outil accepte les deux écritures à l’entrée et écrit des minuscules à la sortie. Ce qu’il ne fera pas, c’est deviner. Le préfixe 0x appartient au champ hexadécimal et il est refusé dans le champ décimal plutôt qu’écarté en silence, car une valeur lue dans la mauvaise base est la seule erreur qu’un convertisseur ne doit jamais rendre plausible.

De l’octal au décimal, et le zéro initial qui change la réponse

L’octal survit à un endroit plus qu’à tout autre : les permissions de fichiers, où trois bits de permission par groupe d’utilisateurs tiennent exactement dans un chiffre octal. Le convertir en décimal relève de l’arithmétique positionnelle ordinaire avec des puissances de huit — 755 en octal fait sept soixante-quatre plus cinq huit plus cinq, soit 493 — et le sens inverse est une division par huit dont les restes se lisent de bas en haut, la même forme que du décimal au binaire et pour la même raison : huit non plus n’a aucune relation avec dix.

• 755 vaut 493 en décimal, 644 vaut 420 et 777 vaut 511. Aucun de ces nombres décimaux ne sert à personne, et c’est bien le propos : les permissions s’écrivent en octal parce que les chiffres coïncident avec les bits de permission, non parce que la valeur compte quoi que ce soit.
• Un zéro initial est une marque de base en C et en Python 2 : 0755 y est octal et vaut donc le nombre 493. Python 3 refuse cette écriture tout net et réclame 0o755 à la place, ce qui a supprimé toute une famille de bogues silencieux.
• YAML 1.1 lit lui aussi un 0755 non entre guillemets comme 493 — d’où la nécessité de mettre un mode de permissions entre guillemets dans un fichier de configuration, faute de quoi il cesse d’être le mode que vous avez écrit.
• JSON ne l’a jamais permis : sa grammaire interdit le zéro initial dans un nombre, si bien que 0755 n’y est même pas un nombre mais une erreur d’analyse — le plus bruyant des trois comportements, et le seul qu’on ne puisse pas mal lire.

Cet outil ne voit dans un zéro initial la marque de rien du tout. C’est le champ où vous saisissez qui fixe la base : 0755 vaut 755 dans le champ décimal et 493 dans le champ octal, et le préfixe 0o est accepté dans le champ octal et refusé partout ailleurs. Deviner la base d’après un préfixe reviendrait à renvoyer un nombre autre que celui qui a été saisi.

De l’octal à l’hexadécimal : la paire sans raccourci

Toutes deux sont des puissances de deux, donc toutes deux ne sont qu’un regroupement des mêmes bits — et pourtant c’est la seule paire parmi les quatre bases sans la moindre règle chiffre par chiffre. Un chiffre octal fait trois bits, un chiffre hex en fait quatre, et aucun des deux nombres ne divise l’autre, de sorte que les frontières ne coïncident jamais. Impossible d’échapper à l’écriture des bits et à leur regroupement.

• Écrivez chaque chiffre octal par ses trois bits, dans l’ordre : 755 devient 111 101 101.
• Regroupez ces bits par quatre depuis l’extrémité droite, en complétant à gauche par des zéros quand le compte ne tombe pas juste : 0001 1110 1101.
• Lisez chaque groupe de quatre comme un chiffre hex : 1ed. Compléter du mauvais côté est l’erreur classique ici, et elle n’a pas l’air d’une erreur : elle multiplie simplement la réponse, en silence.

Que deux chiffres hex fassent exactement un octet et que deux chiffres octaux n’en fassent pas est toute la raison pour laquelle l’hexadécimal a supplanté l’octal pour lire la mémoire : huit bits font deux chiffres octaux et deux tiers, la frontière d’octet tombe donc au milieu d’un chiffre. L’octal convenait aux machines dont la taille de mot était un multiple de trois bits ; l’hexadécimal convient à l’octet de huit bits. Et sur cette page, pour cette paire, la grille de bits va plus vite que l’une ou l’autre méthode à la main : activez les bits une fois et les deux champs affichent déjà la réponse.