Le Base64 n'est pas le seul encodage binaire-vers-texte — chacune de ces trois variantes a été conçue pour un contexte précis où Base64 pose problème.
Tous ces formats résolvent le même problème : représenter des données binaires arbitraires (qui peuvent contenir n'importe quel octet, y compris des caractères de contrôle invisibles) sous une forme entièrement composée de caractères imprimables, sûrs à transporter dans un email, une URL, ou un fichier texte. La différence entre eux est un compromis entre densité (combien de caractères texte pour représenter N octets) et compatibilité (quels systèmes peuvent manipuler le résultat sans erreur).
Base32 n'utilise que des majuscules et les chiffres 2-7 (32 symboles, RFC 4648) — un choix délibéré pour rester lisible et correct même dans des systèmes qui ignorent la casse (certains systèmes de fichiers, lecture à voix haute, certains anciens protocoles DNS). Il est notamment utilisé pour encoder les clés secrètes TOTP (codes d'authentification à deux facteurs Google Authenticator et équivalents) — la clé partagée scannée via QR code est en réalité du Base32.
Base58, popularisé par Bitcoin pour encoder les adresses de portefeuille, retire délibérément les caractères visuellement ambigus de Base64 : pas de 0 (zéro) ni O (lettre O), pas de I (i majuscule) ni l (L minuscule), et pas de symboles + / qui posent problème dans une URL ou un nom de fichier. L'objectif : qu'une adresse recopiée à la main ou lue à l'oral ne soit jamais ambiguë.
Contrairement à Base32/Base64 qui traitent les données par blocs de bits fixes, Base58 traite l'ensemble de la donnée comme un seul grand nombre converti en base 58 — c'est plus coûteux à calculer mais permet l'alphabet réduit à exactement 58 symboles.
Base85 (sous sa variante Ascii85, popularisée par Adobe pour PostScript/PDF) atteint la meilleure densité de tous ces encodages : 4 octets bruts deviennent 5 caractères texte (overhead de seulement 25%, contre 33% pour Base64 et 60% pour Base32). Le prix : il utilise un alphabet plus large incluant des symboles de ponctuation, ce qui le rend moins sûr à coller directement dans certains contextes (URL, JSON) sans échappement supplémentaire.
Encoder ou décoder maintenant →= en Base32 lors d'un copier-coller partiel — certains décodeurs stricts le refusent sans cette information sur la longueur exacte des données d'origine./ ou % potentiellement), contrairement au Base64 "URL-safe".Parce que la densité n'est pas le seul critère : Base64 reste plus universellement supporté nativement par les langages et protocoles, et son alphabet plus restreint pose moins de problèmes de compatibilité — Base85 reste un choix de niche pour des contextes spécifiques (PostScript, certains formats binaires).
Non, cette implémentation encode toujours sur 5 caractères pleins même pour un groupe de quatre octets nuls — le résultat reste valide et se décode correctement, juste légèrement moins compact que l'implémentation Adobe complète.
Oui, mais le calcul devient plus lent sur de très gros volumes car il repose sur de l'arithmétique en grands nombres (BigInt) plutôt que sur un traitement par blocs fixes comme Base32/64 — pour quelques kilooctets typiques d'un usage CTF, aucun souci de performance.
Outils similaires