Convertisseur décimal-hex-binaire-octal

Si tu travailles dans le réseau, Linux, Windows, les microcontrôleurs, le SDR ou le debug bas niveau, tu croises en permanence des nombres écrits dans différentes bases : décimal dans les logs, hexadécimal dans les dumps mémoire, binaire dans les bitmasks, et octal dans les permissions Unix classiques. Ce convertisseur rapide te permet de coller une valeur dans la plupart des formats courants (y compris 0x, 0b et 0o) et d’obtenir instantanément les représentations équivalentes, des bits/bytes regroupés, et en option une interprétation signée (complément à deux). C’est un outil pratique pour les développeurs, sysadmins et passionnés d’électronique qui veulent des résultats rapides et prêts à copier lorsqu’ils décodent des registres, des flags, des champs de paquets ou qu’ils traquent des valeurs « bizarres » dans un firmware ou une sortie système.

Comprendre les bases numériques dans le travail technique réel

Quand tu conçois, débogues ou optimises quelque chose de technique — logiciel, firmware, équipement réseau, récepteur SDR, serveur Linux, voire interface audio — tu finis par rencontrer la même friction : les nombres n’apparaissent pas toujours dans la base « naturelle » pour toi. Les logs préfèrent souvent le décimal, les dumps mémoire adorent l’hexadécimal, les bitmasks sont naturellement binaires, et les droits Unix restent très souvent en octal. Un convertisseur de bases transforme cette traduction mentale permanente en opération d’une seconde, et c’est précisément pour ça que ces outils sont utilisés tous les jours.

Ce guide explique ce que représentent réellement le décimal, l’hexadécimal, le binaire et l’octal, comment les reconnaître sur le terrain, et comment éviter les erreurs les plus fréquentes — surtout autour des valeurs signées, du complément à deux, de la largeur de mot (bit width) et de l’endianness.

Décimal vs binaire vs hexadécimal vs octal

Décimal

Le décimal (base 10) est le système du quotidien. Les chiffres vont de 0 à 9, et chaque position correspond à une puissance de 10.

Exemple :

255 signifie : 2×10² + 5×10¹ + 5×10⁰

En pratique, le décimal est courant dans les interfaces utilisateur, les métriques, les valeurs de timing, les limites de configuration, et les chiffres « humains » comme « 1000 Mbps » ou « 5 ms ».

Binaire

Le binaire (base 2) n’utilise que 0 et 1, et chaque position correspond à une puissance de 2.

Exemple :

11111111₂ = 1×2⁷ + 1×2⁶ + … + 1×2⁰ = 255

Le binaire est le langage natif :

• des flags et bitmasks

• des registres et périphériques de microcontrôleurs

• des permissions, feature toggles, mots d’état

• des représentations DSP/SDR (profondeur de bits, formats d’échantillons)

Il est explicite, mais devient vite long.

Hexadécimal

L’hexadécimal (base 16) utilise 0–9 et A–F (ou a–f) pour représenter 10–15. Chaque position est une puissance de 16.

Exemple :

FF₁₆ = 15×16¹ + 15×16⁰ = 240 + 15 = 255

L’hex est populaire car il correspond parfaitement au binaire :

• 1 chiffre hex = 4 bits (un nibble)

• 2 chiffres hex = 1 octet (8 bits)

C’est pour ça que les dumps mémoire, adresses MAC, hextets IPv6, CRC, hashes et registres apparaissent souvent en hex.

Octal

L’octal (base 8) utilise 0–7. Moins courant aujourd’hui, mais encore très important dans les systèmes Unix-like.

Usage classique :

• permissions de fichiers comme 755, 644, 600

Chaque chiffre octal correspond à 3 bits (puisque 8 = 2³), ce qui rend cette écriture très pratique.

Reconnaître rapidement les formats

Dans les systèmes réels, les préfixes aident beaucoup :

• 0xFF → hexadécimal

• 0b1010 → binaire

• 0o377 → octal (Python et certains outils modernes)

• 077 → octal dans des conventions historiques (notamment style C ancien)

Tout n’a pas forcément de préfixe. Certains dumps montrent du hex « nu » :

DEADBEEF
FFEE12

D’où l’intérêt éventuel de reconnaître du binaire « nu » (10101100 sans 0b). Mais c’est ambigu : 10101100 pourrait aussi être un nombre décimal. Il vaut mieux que ce soit une option, pas un comportement par défaut.

Pourquoi regrouper bits et octets

Les longues chaînes binaires sont difficiles à lire. Le regroupement améliore énormément la lisibilité :

• regroupement par nibbles (4 bits) :
  10101100 → 1010 1100

• regroupement par octets en hex (2 caractères) :
  DEADBEEF → DE AD BE EF

C’est particulièrement utile pour :

• headers de protocoles (champs alignés sur octets/nibbles)

• registres de microcontrôleurs (bit fields)

• structures packées et formats binaires

Un bon convertisseur affiche ça automatiquement, parce que ça réduit les erreurs de lecture visuelle.

Largeur de mot : la pièce manquante

Beaucoup d’erreurs viennent du fait qu’un entier n’est pas « infini » : il vit dans un nombre de bits précis (8, 16, 32, 64…).

Exemple avec 0xFF :

• unsigned 8 bits : 0xFF = 255

• signed 8 bits : 0xFF = -1 (complément à deux)

• unsigned 16 bits : 0x00FF = 255

• signed 16 bits : toujours 255 (bit de signe = 0)

Choisir la bonne largeur est essentiel quand tu interprètes des valeurs issues de :

• registres matériels (8/16/32 bits typiques)

• paquets réseau (tailles de champs fixes)

• mesures de capteurs signées

• structs firmware et messages packés

Avec une largeur N, le comportement « machine » correspond à un wrap modulo 2^N. C’est aussi la raison des effets de débordement en C sur les entiers non signés.

Signed vs unsigned et complément à deux

Idée principale

Un motif de bits n’est que… des bits. Signed/unsigned est une question d’interprétation.

• unsigned : 0 à 2^N − 1

• signed (complément à deux) : −2^(N−1) à 2^(N−1) − 1

Le complément à deux est utilisé presque partout, car l’arithmétique y est efficace et cohérente.

Règle mentale rapide

Pour un entier signé sur N bits :

• MSB (bit le plus significatif) = 0 → valeur positive

• MSB = 1 → valeur négative

Exemple sur 8 bits :

• 0b01111111 = 127

• 0b10000000 = -128

• 0b11111111 = -1

Conversion à la main

Pour interpréter un motif N bits en signed :

• si MSB = 0 : identique à unsigned

• si MSB = 1 : soustraire 2^N à la valeur unsigned

Exemple :

0xFF (8 bits) = 255 unsigned
signed : 255 − 256 = −1

Un toggle « signed interpretation » dans le convertisseur te permet de vérifier instantanément ce point.

Exemples pratiques

Exemple 1 : flags dans un registre d’état

Registre = 0x2D, datasheet :

• Bit 0 : READY

• Bit 2 : ERROR

• Bit 3 : TX_ACTIVE

• Bit 5 : LOW_BAT

0x2D → binaire : 0010 1101

Tu lis alors :

• bit 0 = 1 (READY)

• bit 2 = 1 (ERROR)

• bit 3 = 1 (TX_ACTIVE)

• bit 5 = 1 (LOW_BAT)

Exemple 2 : permissions Unix en octal

755 :

• owner 7 → rwx

• group 5 → r-x

• others 5 → r-x

Chaque chiffre octal = 3 bits :

• 7 → 111

• 5 → 101

• 4 → 100

Donc 644 devient évident :

• 6 = 110 → rw-

• 4 = 100 → r–

• 4 = 100 → r–

Exemple 3 : valeurs négatives de capteurs

Valeur 16 bits : 0xFF9C

unsigned : 65436 (n’a pas de sens comme température)
signed : 65436 − 65536 = −100

Avec une unité 0,01 °C, −100 correspondrait à −1,00 °C. D’où l’intérêt d’une vue « 16-bit signed ».

Pourquoi AND/OR/XOR/NOT et les shifts sont utiles

Ces opérations apparaissent partout :

AND

Tester/effacer des bits :

• value & mask
  Exemple : lire les 8 bits de poids faible : x & 0xFF

OR

Mettre des bits à 1 :

• value | mask

XOR

Basculer des bits, comparer des motifs :

• value ^ mask

NOT

Inverse chaque bit, mais seulement avec une largeur définie.

• sur 8 bits : NOT 0x00 → 0xFF

• sur 8 bits : NOT 0x0F → 0xF0

Sans largeur, NOT devient ambigu en complément à deux, donc un bon outil impose 8/16/32/64 bits.

Shifts

Utilisés pour :

• multiplier/diviser par 2^n

• packer/unpacker des champs

• construire des masques

Extraction de champ typique :

• (value >> 12) & 0xF

Endianness : quand l’ordre des octets change tout

Endianness = ordre des octets pour les valeurs multi-octets.

• big-endian : octet de poids fort d’abord

• little-endian : octet de poids faible d’abord

Pour 0x12345678 :

• big-endian : 12 34 56 78

• little-endian : 78 56 34 12

Important car :

• beaucoup de CPU stockent en little-endian (x86)

• beaucoup de protocoles réseau sont big-endian (network byte order)

Afficher les deux vues et permettre le swap d’endianness aide énormément en debug de captures, dumps mémoire, formats binaires et bugs de sérialisation.

Erreurs fréquentes à éviter

• croire que hex = unsigned : c’est juste une représentation

• oublier la largeur avec NOT/shift : comportement dépend du nombre de bits

• mélanger ASCII, octets et nombres : ASCII est un encodage, pas une « vérité »

• supposer qu’un zéro en tête signifie octal : vrai dans certains legacy, pas partout

• traiter « 101010 » comme forcément binaire : ça peut être décimal

Où la conversion de bases sert au quotidien

Tu l’utilises constamment si tu :

• lis des logs kernel/Windows où des flags sont en hex

• décodes des champs de paquets (Wireshark / raw)

• travailles sur des registres MCU (GPIO/UART/SPI)

• reverse-engineers firmware et formats binaires

• crées des bitmasks et feature flags

• règles des pipelines SDR/DSP (bit depth, formats)

• interprètes des bytes MIDI / mots d’état audio

• vérifies des CRC, hashes et checksums

Conseils pour tirer le maximum du convertisseur

• utilise des préfixes (0x/0b/0o) pour éviter toute ambiguïté

• choisis une largeur (8/16/32/64) pour coller au matériel/protocole

• active le regroupement (nibbles/bytes) pour lire plus vite et plus sûr

• teste tes masques et extractions avec AND/shift/XOR

• si l’outil synchronise l’URL, partage un lien pour un debug reproductible

Les images utilisées dans cet article sont générées par IA...

Cet article peut contenir des liens d’affiliation...