Convertir des bases numériques
Le convertisseur de base numérique convertit entre binaire, octal, décimal, hexadécimal et toute base de 2 à 36, dans votre navigateur. Les entiers passent par BigInt de bout en bout plutôt que par un double, car parseInt renvoie silencieusement 9007199254740992 pour 9007199254740993 — et les valeurs que les gens convertissent sont des identifiants, des masques de bits et des hash, exactement le matériel qui dépasse cette limite.
Saisissez un nombre ci-dessus ou essayez un exemple pour le convertir en binaire, décimal, hexadécimal et autres bases.
Comment fonctionne Convertir des bases numériques ?
La conversion de base ressemble à une ligne de code et cesse de l’être à deux endroits : les grands entiers et les fractions.
parseInt perd des chiffres, silencieusement
parseInt("9007199254740993", 10) renvoie 9007199254740992. Rien ne lève d’exception, rien ne prévient, et le dernier chiffre a simplement disparu — car un nombre JavaScript est un double et 2 53 est l’endroit où les entiers consécutifs cessent d’être représentables. Ce que les gens convertissent entre bases, ce sont des identifiants snowflake, des masques de bits de permissions, des hash et des adresses mémoire, et chacun dépasse régulièrement cette limite. Le chemin des entiers passe donc ici par BigInt, de l’analyse au formatage, et ne repasse jamais par un double.
Les fractions se convertissent par multiplications répétées
BigInt n’a pas de partie fractionnaire, donc la fraction est traitée à part : multipliez les chiffres fractionnaires par la base cible, prenez la retenue comme chiffre de sortie suivant, répétez. Toute l’arithmétique reste sur des entiers dans la base source, donc rien ne passe par un flottant — c’est pourquoi 0.1 en base 3 sort ici exactement 0.1 plutôt que 0.3333333333333333.
Certaines fractions ne se terminent pas dans la base cible : 0.1 décimal fait 0.0001100110011… en binaire, à l’infini, ce qui est le même fait que derrière 0.1 + 0.2 !== 0.3. Rien ne peut corriger cela, donc le développement est borné à quarante chiffres et s’arrête.
Un 0x en tête qui contredit la base est une erreur
Coller 0x1f alors que la base 10 est sélectionnée signifie presque certainement que vous pensiez à la base 16. Traiter 0 et x comme des chiffres échouerait de manière déroutante ou produirait une réponse fausse, donc la discordance est nommée. Les séparateurs de chiffres — tirets bas et espaces — sont acceptés, car 1010_1010, c’est ainsi que les gens écrivent réellement un octet.
Le complément à deux, c’est pourquoi -1 se lit ffffffff
Un entier négatif en mémoire est stocké comme son complément à deux : inverser les bits et ajouter un. Ainsi, -1 sur 32 bits est ffffffff, et -2147483648 est 80000000. Quand un débogueur vous montre une énorme valeur hexadécimale positive là où vous attendiez une petite valeur négative, c’est ce qui s’est passé. Le panneau affiche l’encodage à la largeur la plus étroite qui contient la valeur.
Bits à 1, pour une valeur utilisée comme masque
Un entier de permissions est un ensemble d’indicateurs, et la question utile est de savoir lesquels sont actifs. Les positions de bits sont listées en comptant à partir de zéro au bit de poids faible, la convention qu’utilise chaque opération de décalage de bits.
Entrée
255 (base 10)
Converti
binary 1111 1111 octal 377 hexadecimal ff set bits 0, 1, 2, 3, 4, 5, 6, 7
Quelles options et quels cas limites Convertir des bases numériques prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| Plage de bases | 2 à 36 | — | Les chiffres sont 0–9 puis a–z, insensibles à la casse, ce qui donne 36 symboles. La base 36 est le codage le plus dense qui n’utilise que des caractères alphanumériques. |
| Précision | arbitraire | BigInt | Les entiers de toute longueur se convertissent exactement. parseInt perd les chiffres au-delà de 2^53 sans avertissement, ce qui constitue le bug le plus courant dans les convertisseurs de base. |
| Fractions | multiplication répétée | 40 chiffres max | Exacte lorsque la fraction se termine dans la base cible. Lorsqu’elle ne se termine pas — 0.1 décimal en binaire — le développement est borné plutôt qu’infini. |
| Séparateurs | _ et espace | acceptés | 1010_1010 et 1010 1010 se lisent tous les deux. Les rejeter serait pédant ; c’est ainsi que les gens écrivent un octet. |
| Préfixes | 0b 0o 0x | vérifiés | Acceptés lorsqu’ils correspondent à la base sélectionnée, et signalés comme erreur lorsqu’ils ne correspondent pas — coller 0x1f avec la base 10 sélectionnée est une erreur à nommer. |
| Regroupement | booléen | activé | Tous les 4 chiffres en binaire, 3 en octal et décimal, 2 en hexadécimal — les groupements qui correspondent à la façon dont chaque base se lit. |
| Complément à deux | 8/16/32/64 bits | ajustement le plus étroit | La façon dont une valeur négative est réellement stockée, c’est pourquoi -1 apparaît comme ffffffff dans un débogueur. |
| Largeur en bits | signé et non signé | signalée | Parmi int8 jusqu’à uint64, celui qui peut contenir la valeur. Savoir si une valeur tient en int32 mais pas en int16 est le genre de détail utile à connaître avant de choisir un type de colonne. |
Questions fréquentes
Pourquoi les autres convertisseurs me donnent-ils une réponse différente pour un grand nombre ?
Parce qu’ils ont utilisé parseInt ou Number, qui passent par un double et perdent en précision au-delà de 2^53 — environ 9 millions de milliards. parseInt("9007199254740993") renvoie 9007199254740992, sans erreur. Cet outil utilise BigInt partout, donc chaque chiffre survit. Si vous convertissez un identifiant snowflake, un hash ou un grand masque de bits, c’est la différence qui compte.
Pourquoi 0.1 ne se convertit-il pas proprement en binaire ?
Parce qu’il ne le peut. Un dixième fait 0.0001100110011… en base 2, à l’infini, pour la même raison qu’un tiers fait 0.333… en base 10 : le dénominateur a un facteur premier que la base n’a pas. C’est toute l’explication de 0.1 + 0.2 !== 0.3 dans tous les langages à virgule flottante binaire. Le développement s’arrête ici à quarante chiffres parce qu’il doit bien s’arrêter quelque part.
Pourquoi -1 est-il affiché ffffffff ?
C’est le complément à deux, la façon dont pratiquement tout ordinateur stocke un entier négatif : inverser les bits de la magnitude et ajouter un. Il a la belle propriété que l’addition fonctionne de manière identique pour les valeurs signées et non signées, et c’est pourquoi il a triomphé des alternatives. Quand un débogueur montre une valeur hexadécimale positive suspectement grande là où vous attendiez un petit nombre négatif, c’est ce que vous regardez.
À quoi sert la base 36 ?
Des identifiants compacts. La base 36 utilise 0-9 et a-z, le plus grand alphabet qui survit à une normalisation de casse, à la saisie par un humain et au placement dans une URL sans encodage. Un horodatage en base 36 fait environ la moitié de sa longueur en décimal. La base 62 est plus dense mais sensible à la casse, ce qui la rend fragile partout où l’on met en minuscules.
Puis-je convertir le motif de bits d’un nombre à virgule flottante ?
Pas directement — cet outil convertit la valeur mathématique, pas l’encodage IEEE 754. Ce sont deux questions différentes : 0.5 comme valeur est 0.1 en binaire, tandis que 0.5 comme double est 3FE0000000000000 en hexadécimal. Si vous voulez le motif de bits, convertissez l’hexadécimal de la forme encodée comme un entier.
Mon nombre est-il envoyé ?
Non. C’est de l’arithmétique, qui s’exécute dans votre navigateur. Rien dans la conversion de 255 en hexadécimal n’exige un serveur, et les nombres que les gens convertissent sont souvent des identifiants internes qu’ils préféreraient ne pas mettre dans le journal de quelqu’un d’autre.