Comment ça marche
Chaque base courante est une manière de représenter le même entier avec un nombre différent de chiffres. Le décimal (base 10) utilise 0 – 9. Le binaire (base 2) n'utilise que 0 et 1, en doublant la valeur de position à chaque déplacement vers la gauche : 1011 binaire = 1×8 + 0×4 + 1×2 + 1×1 = 11 décimal. L'hexadécimal (base 16) utilise 0 – 9 puis A – F pour 10 – 15, chaque position valant 16 fois la suivante ; 0xFF = 15×16 + 15 = 255. L'octal (base 8) est le cas intermédiaire peu utilisé — autrefois standard sur les mini-ordinateurs de type PDP, on le voit aujourd'hui surtout dans les permissions Unix (chmod 755).
Pourquoi quatre bases ? Parce que chacune répond à un besoin réel. Le binaire est ce que le CPU exécute. L'hex est du binaire sous forme plus lisible — chaque chiffre hex correspond à exactement quatre chiffres binaires (nibble), donc 0xDEADBEEF se lit mieux que 11011110101011011011111011101111. L'octal regroupe trois bits par chiffre (utile à l'époque des octets de neuf bits). Le décimal est notre comptage. La calculatrice analyse l'une et produit les trois autres pour tout vérifier d'un coup.
Les valeurs au-dessus de 2³¹ − 1 (2 147 483 647) sont rejetées parce que c'est là que le comportement de l'entier signé 32 bits se brise et que les opérations bitwise commencent à renvoyer des résultats inattendus.
La formule
Le widget délègue à parseInt(str, base) et Number.prototype.toString(base) intégrés de JavaScript ; la bibliothèque standard fait le gros du travail. La validation impose le jeu de chiffres correct par base avant l'analyse, donc des caractères non binaires dans une saisie binaire donnent une erreur propre plutôt qu'un NaN silencieusement tronqué.
Exemple de calcul
- Tapez 255 avec le bouton Décimal sélectionné.
- La ligne de résultats affiche Binaire 11111111 · Octal 377 · Décimal 255 · Hex FF.
- Cliquez sur Hex et tapez DEADBEEF → Décimal 3 735 928 559. (Juste en dessous du plafond 2³¹.)
Questions fréquentes
Pourquoi la limite haute est-elle 2³¹ − 1 et non 2⁶³ ?
JavaScript représente les nombres en flottants 64 bits et gère sans souci les entiers jusqu'à 2⁵³ − 1 pour l'arithmétique courante. Mais dès qu'on touche aux opérations bitwise (& | ^ << >> ~), le runtime convertit les opérandes en entiers signés 32 bits, donc tout ce qui dépasse 2³¹ − 1 change de signe ou s'enroule silencieusement. On plafonne ici à 2³¹ − 1 pour que les bases affichées correspondent à ce que vous verriez en mettant la valeur dans une expression bitwise en code de production.
Et les préfixes comme 0x et 0b ?
Le widget les rejette — saisissez uniquement les chiffres et utilisez le bouton de base pour fixer le contexte. C'est volontaire : un préfixe est une convention de langage de programmation (C, Python, JavaScript), pas une propriété du nombre lui-même, et accepter les préfixes de manière incohérente entre les quatre bases rend le validateur bruyant. Si vous collez 0xFF, supprimez le 0x et sélectionnez Hex.
Pourquoi le hex est-il insensible à la casse mais affiché en majuscules ?
Hex minuscule (ff, deadbeef) et majuscule (FF, DEADBEEF) parsent vers le même entier ; les deux sont valides. L'affichage normalise en majuscules parce que c'est la convention dominante en finance, en matériel et dans la plupart de la documentation (manuels Intel, RFC, syntaxe couleur RGB). Les minuscules dominent dans certains contextes de développement web — CSS, sortie de debug Node — mais c'est un choix de style, pas de justesse. Collez l'une ou l'autre forme dans la saisie et ça fonctionne.