Aller au contenu principal
ToolsByUs

Hexadécimal vers Base64

Ce convertit ré-encode une chaîne hexadécimale en Base64 standard dans votre navigateur. L’entrée est insensible à la casse, les préfixes 0x et les espaces superflus sont supprimés, et la sortie suit RFC 4648 avec un bourrage. Les entrées de longueur impaire sont rejetées sans appel : un quartet manquant n’est jamais deviné. Aucun fichier n’est envoyé.

100 % local

Hexadécimal vers Base64 en clair

L’hex est la manière dont les programmeurs épellent les octets ; la Base64 est celle du transport. Ce convertit lit une chaîne hexadécimale par paires d’octets et ré-encode ces mêmes octets avec l’alphabet standard RFC 4648, y compris le bourrage — la chaîne exacte qu’un encodeur produirait pour les données sous-jacentes, prête pour un en-tête, un fichier de configuration ou un champ de jeton.

L’hex du monde réel est désordonné, et le convertit fait un compromis : les chiffres majuscules et minuscules sont traités de la même manière, les préfixes 0x sont supprimés où qu’ils apparaissent, et les espaces superflus — vidanges de colonnes, paires espacées, sauts de ligne — sont nettoyés avant l’analyse. Ce qu’il ne fait pas, c’est deviner. Un nombre impair de chiffres hexadécimaux signifie qu’un quartet est manquant quelque part, et le convertit refuse plutôt que d’inventer où.

La conversion est entièrement locale, comme partout sur ce site : votre chaîne est analysée et encodée dans cet onglet de navigateur, aucune requête n’est envoyée, et la politique de sécurité du contenu (Content-Security-Policy) de la page interdit les connexions sortantes. Le fait que le panneau Réseau reste vide pendant que vous convertissez est la preuve, vérifiable en quelques secondes.

Vérifier le résultat à la main est facile dans l’autre sens : envoyez le résultat au convertisseur Convertisseur Base64 en Hex et vous devriez retrouver votre chaîne hexadécimale originale, octet par octet.

Le choix entre les deux encodings dès le départ est le sujet du site Comparaison Base64 contre hex qui compare la taille, la lisibilité et l’adéquation au protocole sans le folklore des tribus.

Comment la conversion fonctionne réellement

La règle de groupement de la Base64 fait tout le vrai travail, et il vaut la peine de la voir une fois, car elle explique à la fois la longueur et le bourrage de tout ce que cet outil émet :

  • Nettoyage : les préfixes 0x et 0X sont supprimés, tout espace est retiré, et les caractères restants doivent être 0–9, a–f ou A–F ; tout autre chose est une erreur nommée avec sa position.
  • Paire : chaque deux chiffres hexadécimaux deviennent un octet — 48 est l’octet 0x48, la lettre H.
  • Groupe : les octets sont pris par groupes de trois ; les 24 bits de chaque triplet sont divisés en quatre valeurs de 6 bits, et chaque valeur est mappée à un caractère de l’alphabet standard RFC 4648 A–Z a–z 0–9 + /.
  • Bourrage : un dernier groupe de 1 ou 2 octets est complété avec des caractères = pour que la longueur de sortie soit toujours un multiple de 4.

L’entrée est nettoyée, pas jugée

L’hex dans la nature arrive décoré. Les résumés de hash viennent avec un préfixe 0x de certaines bibliothèques ; les vidages de paquets arrivent comme des colonnes de paires espacées ; la documentation écrit 48 65 6L avec des majuscules alors qu’un journal a imprimé 48656c en minuscules. Tout cela représente les mêmes octets, donc le convertit les traite de la même manière : les préfixes et les espaces disparaissent, la casse n’a plus d’importance, et seulement après nettoyage l’analyseur exige des chiffres hexadécimaux. Un mélange de casse dans une même chaîne — 6C à côté de 6c — est acceptable, car les deux orthographes désignent une même valeur de quartet.

Entrée de longueur impaire : la politique explicite

Une chaîne hexadécimale de longueur impaire ne peut être analysée sans deviner, car un chiffre est manquant et n’importe quelle extrémité est un endroit plausible pour la perte. Prépendre un zéro et appendre un zéro produit des octets différents — 0x48 contre 0x84 — donc corriger silencieusement l’entrée choisirait une signification au hasard et vous donnerait des données qui semblent correctes. La politique de ce convertit est de refuser : une entrée de longueur impaire retourne une erreur nommée indiquant la longueur, et la réparation appartient à celui qui sait où le chiffre est réellement allé. C’est la même règle de refus plutôt que de déformer que le reste des convertisseurs de ce site appliquent.

À quoi ressemble la sortie

L’exemple traité ci-dessous est la paire exacte que le bouton Charger l’exemple produit : une chaîne hexadécimale décorée — préfixe 0x, espaces, casse mixte — arrivant comme cinq octets épelant « Hello » et partant comme la Base64 standard SGVsbG8=, avec un = car le dernier groupe porte deux octets au lieu de trois. La sortie utilise l’alphabet standard, y compris le plus et la barre oblique, pas la variante sûre pour les URL ; si votre destination déforme ces deux caractères, l’alphabet sûr pour les URL de RFC 4648 est la substitution documentée à appliquer ensuite.

Questions fréquentes

La conversion de hex en Base64 envoie mon quelque part ?

Non. L’analyse et l’encodage s’exécutent dans cet onglet de navigateur, dans du code qui est livré avec la page. La page ne définit aucun point d’envoi, et sa politique de sécurité du contenu bloque les connexions sortantes, donc l’exfiltration est structurellement impossible plutôt que simplement promise. Les DevTools rendent la vérification possible : ouvrez le panneau Réseau, convertissez une chaîne, et constatez qu’il ne enregistre rien du tout.

Pourquoi une entrée hex de longueur impaire est-elle rejetée au lieu d’être corrigée ?

Parce que chaque correction est une devinette avec des conséquences réelles. Un nombre impair de chiffres signifie qu’un quartet est manquant, et ajouter un zéro au début plutôt qu’à la fin produit des octets différents — 48 contre 84 — donc une réparation silencieuse inventerait des données qui semblent plausibles. Le convertit retourne une erreur nommée avec la longueur, et vous corrigez la source là où le chiffre a été perdu.

Les majuscules, les préfixes 0x et les espaces sont-ils vraiment acceptés ?

Oui. La casse est sans importance — 4C et 4c sont le même quartet — les préfixes 0x et 0X sont supprimés même quand ils se répètent devant chaque octet, et tout espace est retiré avant l’analyse, donc une vidange hexadécimale collée en colonne se convertit sans nettoyage préalable. Après nettoyage, seuls 0–9 et a–f ou A–F sont valides ; un g ou une virgule isolée est une erreur nommée avec sa position.

La sortie inclut-elle toujours un bourrage = ?

Le bourrage n’apparaît que lorsque le nombre d’octets n’est pas un multiple de trois — un = pour un reste de deux octets, deux pour un reste d’un octet — et la longueur de sortie est toujours un multiple de 4. Les caractères = font partie de RFC 4648, ce n’est pas du bruit : les supprimer casse les décodeurs qui s’appuient sur la longueur. Cet outil émet la forme standard bourrée, correspondant à ce que les encodeurs standards produisent.

Pourquoi la sortie Base64 est-elle plus courte que l’entrée hex ?

Arithmétique de surcharge d’encodage : l’hex utilise 2 caractères par octet, la Base64 utilise 4 pour 3. Pour les mêmes octets, l’hex tourne à 100 pour cent de surcharge et la Base64 à environ 33, donc un résumé de 64 octets passe de 128 chiffres hex à 88 caractères Base64 avec bourrage. Les données sont identiques tout au long — seule l’efficacité de compression de l’alphabet a changé.

L’encodage Base64 est-il un moyen de chiffrer des données ?

Non, et le traiter comme tel est une erreur de sécurité authentique. La Base64 est un encodage réversible sans clé : quiconque détient la chaîne peut la décoder, hors ligne, en quelques millisecondes — cette page le fait sans réseau. Elle existe pour déplacer des octets dans des canaux sûrs pour le texte, pas pour les protéger. Si la confidentialité compte, chiffrez d’abord, puis appliquez la Base64 au texte chiffré pour le transport.

Équipe ToolsByUs · Comment nous vérifions nos outils