Outils de développement · Encodeur et décodeur Base64
Base64 vs hex vs base32 : comparaison de trois façons d'écrire des octets sous forme de texte
· Contexte
base64 codage
Hex, base32 et Base64 résolvent le même problème avec des compromis différents en termes de taille, de lisibilité et de sécurité. Cet article les compare sur la densité, la sensibilité à la casse, la sécurité des URL et l'erreur humaine.
La clé API qui a été mal saisie à cause de l, 1, I et O — un problème de lisibilité concret que hex n'aurait pas eu
Trois façons courantes de représenter les octets sous forme de texte sont hex, base32 et base64. Ils résolvent tous le même problème (exprimer des octets arbitraires en ASCII imprimable) mais avec des compromis différents en termes de taille, de lisibilité et de résilience aux erreurs. Hex contient 2 caractères par octet (F3 A2 B1 ...), donc 16 octets deviennent 32 caractères. Base32 contient 1.6 caractères par octet (environ 5 caractères par 3 octets), donc 16 octets deviennent 26 caractères.
Base64 contient 1.33 caractères par octet (exactement 4 caractères par 3 octets), donc 16 octets deviennent 24 caractères ou moins. Si la taille du fichier est importante, base64 est le plus compact. Si la transcription humaine est importante, hex et base32 sont plus sûrs. La différence de lisibilité est critique lorsqu'une valeur est saisie, copiée ou prononcée. Hex utilise 0-9 et a-f (insensible à la casse dans la plupart des contextes). Un canal de transcription change la décision car une représentation optimisée pour les machines peut être gênante pour les personnes. Base64 est sensible à la casse et utilise deux symboles de ponctuation ; hex utilise un vocabulaire visuel plus petit. L'implémentation ici teste des chaînes exactes, et non un taux d'erreur humaine, donc aucune probabilité inventée n'est attachée.
Densité : 2×, 1.6× et 1.33× — combien de caractères chaque encodage a besoin par octet et pourquoi
Base32 utilise A-Z et 2-7, évitant ainsi 0, 1, O et I qui se confondent facilement sur le papier. Base64 utilise A-Z, a-z, 0-9, + et /,, y compris les majuscules et les minuscules, ce qui le rend sensible à la casse et mélange des chiffres qui se ressemblent (0 contre O, 1 contre I contre l minuscule). Une clé API en hexadécimal peut être f3a2b1e4 ; les mêmes octets en base64 peuvent être 86KrvE== (avec remplissage) ou en base32 6VEV7FI= (avec remplissage).
Si un utilisateur doit saisir la valeur à la main, hex ou base32 est plus sûr que base64. Les caractères réservés dans les URL sont importants. Hex et base32 sont sans danger pour les URL ; les deux utilisent uniquement des caractères alphanumériques (hex utilise également 0-9, base32 utilise également 2-7). Base64 utilise plus et slash qui sont réservés à l'URL (plus représente un espace dans les données codées par formulaire, slash est un séparateur de chemin). La densité Base64 découle directement de six bits utiles par symbole de sortie et du remplissage jusqu'aux blocs de quatre caractères. Hex transporte quatre bits par symbole, soit deux caractères par octet. Base32 est présenté comme contexte de comparaison uniquement parce que ce référentiel ne fournit ni son alphabet ni un encodeur pour vérifier les sorties.
Densité à partir de la largeur de bits – arithmétique exacte Base64 et hexadécimale, Base32 étant traitée comme contexte de comparaison
Une chaîne base64 dans un paramètre d'URL doit être codée en pourcentage (le plus devient %2B, la barre oblique devient %2F), en ajoutant 4 caractères supplémentaires pour chaque occurrence. Base64url (section RFC 4648 5) remplace le plus par un tiret et une barre oblique par un trait de soulignement, ce qui le rend sécurisé pour les URL sans codage en pourcentage. La plupart des API qui utilisent base64 dans les URL utilisent en fait base64url, mais la distinction n'est souvent pas explicite dans la documentation.
Les secrets TOTP (les codes utilisés par les applications d'authentification) sont généralement distribués en base32. Un écran d'inscription TOTP affiche un secret base32 car il est plus facile à saisir et à transcrire que les mêmes octets en base64 ou en hexadécimal. Les résumés de hachage SHA sont souvent affichés en hexadécimal, car il s'agit du format traditionnel et parce que l'hexadécimal n'est pas sensible à la casse, ce qui rend les fautes de frappe moins probables. La sensibilité à la casse est importante lorsque quelqu'un lit une valeur à voix haute ou la retape, car la modification de la casse d'une lettre modifie son index. ToolAcre préserve exactement la casse et décodera les différents octets résultants sans savoir qu'un humain a commis une erreur de transcription. La représentation elle-même n’a pas de somme de contrôle.
Caractères réservés et sécurité des URL : où + et / mordent, et comment base32 et hex évitent le problème
Les JWT utilisent base64url. Les sommes de contrôle des fichiers peuvent être hexadécimales ou base64 ; les deux sont communs. Le choix relève d’une convention historique et non d’une nécessité technique. La résilience aux erreurs est une différence subtile mais importante. Base32 évite les chiffres 0, 1, 8 et 9 (qui ressemblent à des lettres), réduisant ainsi les erreurs de transcription. Base64 inclut tous les chiffres, ce qui rend 1 ambigu (est-ce une lettre I, un l minuscule ou le chiffre 1 ?).
Hex est encore plus sujet aux erreurs : 0 ressemble à O, l ressemble à 1. Une somme de contrôle qui doit être saisie ou lue à partir d’une impression est plus sûre en base32. Une clé API collée directement depuis un ordinateur est sûre dans n'importe quel format ; la lisibilité n’a d’importance que lorsque les yeux humains sont impliqués. Octets identiques, mais codage différent : la séquence 16-byte [0xf3, 0xa2, 0xb1, ...] devient f3a2b1... Les plus et slash de la norme Base64 nécessitent une gestion adaptée aux canaux ; Le mode sécurisé pour les URL les remplace par un trait d’union et un trait de soulignement. Hex évite ces séparateurs en utilisant uniquement des chiffres et des lettres. Les conventions Base32 varient, cet article évite donc les propriétés de sécurité prometteuses que le référentiel n'implémente ni ne teste.
Exemple concret : les mêmes 16 octets dans les trois encodages — comparaison des longueurs et inspection visuelle
en hexadécimal, 6VEV7FI=... en base32 et 86KrvE== en base64. Aucune de ces chaînes n'est interchangeable. Une application recevant f3a2b1... attend un hexadécimal et tentera de l'analyser en hexadécimal. La réception de 86KrvE== échouera si l'application attend un hexadécimal. Le format d'encodage fait partie du contrat des données : l'expéditeur et le destinataire doivent se mettre d'accord sur l'encodage utilisé. Le rembourrage est une autre différence.
Hex n'utilise pas de remplissage (4 octets sont toujours 8 caractères hexadécimaux, sans exception). Base32 et base64 utilisent tous deux un remplissage égal pour aligner la sortie sur un multiple de caractères (8 pour base32, 4 pour base64). Le remplissage est mathématiquement nécessaire ; il garantit que chaque entrée de n octets produit un nombre de caractères déterministe. Les règles de remplissage varient : certaines applications nécessitent un remplissage, d'autres permettent de l'omettre. La comparaison travaillée utilise une séquence d'octets fixe et calcule mécaniquement Base64 et hex. Sa longueur Base32 peut être discutée à partir d'un regroupement de cinq bits, mais une valeur de texte Base32 exacte est omise car aucune implémentation révisée ne l'a générée. L’arithmétique des longueurs et la vérification des résultats restent distinctes.
Où chacun est conventionnel — hachages en hexadécimal, secrets TOTP en base32, JWT et données : URI en Base64
Lors du collage d'une valeur base32 ou base64 sans remplissage, les décodeurs peuvent l'accepter ou la rejeter en fonction de l'implémentation. Les clés et jetons cryptographiques montrent la différence de codage.
Une clé HMAC fait 32 octets, qui deviennent 64 caractères hexadécimaux, 52 caractères base32 (avec remplissage) ou 44 caractères base64 (avec remplissage). Lors de la distribution d'une clé, l'encodage doit être documenté. Si la documentation indique que la clé est composée de 44 caractères base64 mais que vous recevez 52 caractères, quelque chose ne va pas. La convention peut guider les lecteurs mais ne prouve pas son adéquation. Les résumés de hachage sont généralement affichés au format hexadécimal, tandis que les segments JWT utilisent Base64url. Le bon choix dépend toujours des règles du canal, du fait que les gens copient la valeur et qu'un autre protocole ait déjà corrigé la représentation.
Ce que cela ne couvre pas : encodages base58, base85 et somme de contrôle
L'encodage base64 plus court facilite légèrement l'intégration des jetons dans les systèmes avec des limites de caractères (comme les codes QR ou les URL). Le choix du codage d’une valeur est défini par l’écosystème dont elle provient. Les API Web utilisent souvent base64url. La documentation cryptographique utilise souvent l'hexadécimal. Les applications d'authentification utilisent base32. Lorsque vous construisez un système, choisissez un encodage, documentez-le clairement et respectez-le.
Mélanger les encodages (en disant base64 ou base32) introduit de la confusion. Lors du débogage, la première étape consiste à identifier le codage utilisé par la valeur ; l'outil d'encodeur et de décodage Base64 peut vous aider en essayant de le décoder de plusieurs manières et en voyant laquelle produit une sortie raisonnable. Aucun encodage n’est universellement meilleur. Base64 est le plus compact pour le stockage brut. Hex est le plus familier aux cryptographes et le plus lisible par l'homme pour les petites séquences. Les encodages Base58, Base85 et somme de contrôle font des compromis différents et sont absents du panneau Base64 de ToolAcre. Leurs alphabets, règles d'ambiguïté et sommes de contrôle doivent être évalués avec des sources et des implémentations dédiées plutôt qu'extrapolés à partir du comportement testé de cet outil.
À retenir : choisissez l'encodage pour le canal et le lecteur - comment l'encodeur et le décodeur Base64 couvrent le cas Base64 dans le navigateur, aux côtés du calculateur de hachage SHA dans le même produit
Base32 est le plus résistant aux erreurs de transcription. Le choix dépend du contexte : où se trouve la valeur, comment elle est partagée et quels systèmes la consommeront.
Comprendre les compromis vous aide à choisir judicieusement lors de la conception d'une API ou d'un système. L'outil d'encodage et de décodage Base64 démontre l'encodage base64 ; son utilisation avec un outil hexadécimal ou base32 vous permet de voir les mêmes octets dans les trois formats et de comprendre leurs différences de taille et de lisibilité. Pour le cas Base64, encodez un échantillon, notez le nombre exact d'octets UTF-8 et de caractères de sortie, et testez la ponctuation standard par rapport à la ponctuation sécurisée pour les URL. Pour le travail de synthèse, utilisez le panneau SHA séparé. Garder ces opérations distinctes évite qu’un choix de codage soit confondu avec un hachage ou une protection de l’intégrité.