Encodage Base64 : comment ça fonctionne

De nombreux systèmes, notamment le courrier électronique, les en-têtes HTTP et XML, ont été conçus pour traiter du texte, mais pas des données binaires arbitraires. Une valeur d’octet de 0x00 (nulle) ou de 0x1A (caractère de contrôle) peut provoquer des échecs d’analyse syntaxique ou une corruption des données.

Le codage en base 64 convertit des données binaires arbitraires en un sous-ensemble de caractères ASCII sûr pour les systèmes qui traitent uniquement du texte, ce qui permet d’intégrer du contenu binaire comme des images et des certificats dans des protocoles textuels.

Le codage en base 64 consiste à prendre trois octets de 8 bits (24 bits au total) et à les diviser en quatre groupes de 6 bits. Chaque groupe de 6 bits représente une valeur de 0 à 63, qui correspond à un caractère de l’alphabet de la base 64.

Ce rapport de 3 pour 4 signifie que tous les 3 octets d’entrée produisent 4 caractères de sortie, soit une augmentation de taille de 33 %. Le calcul tombe juste, car 3 octets = 24 bits = 4 groupes de 6 bits.

L’alphabet de la base 64 comporte 64 caractères : les majuscules A-Z (indices 0-25), les minuscules a-z (indices 26-51), les chiffres 0-9 (indices 52-61), le signe plus + (indice 62) et la barre oblique / (indice 63).

Cet alphabet évite tous les caractères de contrôle et la plupart des signes de ponctuation susceptibles de provoquer des problèmes dans les systèmes textuels. Chaque caractère de la sortie en base 64 est un caractère ASCII imprimable, utilisable en toute sécurité dans pratiquement tous les protocoles textuels.

Lorsque la longueur de l’entrée n’est pas un multiple de 3 octets, un remplissage est nécessaire. S’il reste un octet, il est complété pour former un groupe de 12 bits, ce qui produit 2 caractères de la base 64 suivis de "==". S’il reste deux octets, ils produisent 3 caractères de la base 64 suivis de "=".

Les signes de remplissage = ne sont pas des données encodées ; ils indiquent au décodeur que le dernier bloc est plus court que 3 octets. Ils garantissent que la longueur de sortie est toujours un multiple de 4 caractères.

Les valeurs ASCII de "Man" sont M=77 (01001101), a=97 (01100001), n=110 (01101110). Une fois concaténées : 010011010110000101101110.

Division en groupes de 6 bits : 010011 | 010110 | 000101 | 101110 = 19 | 22 | 5 | 46. En consultant l’alphabet de la base 64 : 19=T, 22=W, 5=F, 46=u. "Man" s’encode en "TWFu".

La base 64 standard utilise + et /, qui ont des significations particulières dans les URL et les noms de fichiers. La base 64 pour URL est une variante qui remplace + par - et / par _, ce qui la rend sûre pour les URL, les noms de fichiers et les valeurs de témoins de connexion.

Les JWT (jetons web JSON) utilisent le codage en base 64 pour URL pour leurs sections d’en-tête et de charge utile. Les normes JOSE (signature et chiffrement d’objets JSON) reposent entièrement sur la base 64 pour URL.

La base 64 est utilisée pour les pièces jointes MIME des courriers électroniques (encodage de fichiers binaires pour des courriers électroniques textuels), les jetons JWT (encodage de l’en-tête et de la charge utile JSON), les URI de données en HTML (intégration directe d’images dans CSS/HTML) et le format PEM des certificats X.509.

Le format PEM (courrier amélioré pour la confidentialité) encapsule des certificats binaires encodés en DER dans de la base 64, entre les en-têtes "-----BEGIN CERTIFICATE-----" et "-----END CERTIFICATE-----".

La base 64 n’est pas un chiffrement. C’est un encodage réversible sans clé. Toute personne qui voit des données encodées en base 64 peut les décoder immédiatement à l’aide d’outils disponibles gratuitement ou d’une seule ligne dans n’importe quel langage de programmation.

Une erreur courante consiste à penser que les mots de passe ou les jetons encodés en base 64 sont "cachés". Ils ne le sont pas. Si vous pouvez les décoder, un attaquant le peut aussi. La sécurité exige un chiffrement, pas un encodage.

Décoder la base 64 est tout aussi simple que l’encoder. Chaque groupe de 4 caractères de la base 64 est reconverti en valeurs sur 6 bits, concaténé, puis divisé en octets. Le remplissage = indique combien d’octets sont représentés par le dernier groupe.

En Python : import base64; base64.b64decode("TWFu") renvoie b"Man". Le processus est déterministe, sans perte et ne nécessite ni clé ni secret.

La surcharge de taille de 33 % de la base 64 (4 octets en sortie pour 3 octets en entrée), ainsi que les sauts de ligne tous les 76 caractères (comme l’exige MIME), rendent la base 64 peu efficace pour les transferts binaires volumineux.

Les protocoles binaires modernes, comme HTTP/2 avec son cadrage binaire et WebSockets avec ses trames binaires, peuvent gérer directement les octets bruts, ce qui élimine le besoin de recourir à la base 64 dans les contextes exigeant de hautes performances.

La base 32 utilise un alphabet de 32 caractères (A-Z et 2-7), produisant une sortie plus longue que celle de la base 64, mais insensible à la casse et adaptée aux contextes où la casse peut être perdue. Les secrets partagés TOTP sont souvent encodés en base 32.

La base 58, utilisée par Bitcoin pour les adresses de portefeuille, supprime les caractères visuellement ambigus comme 0, O, I et l. Cela réduit les erreurs de transcription lors de la copie d’adresses. Le compromis est que la base 58 n’est pas une puissance de 2, ce qui rend l’encodage légèrement plus complexe.

La base 64 convertit les données binaires en texte en regroupant les bits par blocs de 6 et en les associant à un alphabet de 64 caractères. Elle produit une surcharge de taille de 33 % et utilise un remplissage avec = pour les longueurs qui ne sont pas des multiples de 3 octets.

La base 64 n’offre aucune sécurité. Elle est utilisée pour assurer la compatibilité des transmissions, et non la confidentialité. La base 64 pour URL (-/_) est la variante sûre pour les URL, utilisée dans les JWT. Le décodage ne nécessite aucune clé et s’effectue en quelques millisecondes.