L'encodage Base64 expliqué : fonctionnement, usages et idées reçues

Pourquoi Base64 existe

Toutes les données informatiques sont, au fond, des octets. Pourtant, de nombreux canaux ne transportent sans risque que du texte : corps d'e-mails, en-têtes HTTP, documents JSON et URL. Si l'on y fait passer des octets d'image bruts ou un texte chiffré, des caractères de contrôle et des sauts de ligne peuvent corrompre les données, ou un système intermédiaire peut les réécrire.

Base64 résout ce problème en convertissant n'importe quelle suite d'octets dans un alphabet de 64 caractères : lettres majuscules et minuscules, chiffres, plus + et /. Ces caractères sont considérés comme sûrs presque partout, si bien que des données binaires peuvent traverser des canaux texte sans être altérées. Le format est normalisé par la RFC 4648.

Trois octets deviennent quatre caractères

L'idée de base est simple. L'entrée est lue par blocs de trois octets (24 bits), et ces 24 bits sont découpés en quatre groupes de six bits. Six bits permettent de représenter 64 valeurs, de 0 à 63 ; chaque groupe correspond donc à un caractère : 0–25 donnent A–Z, 26–51 donnent a–z, 52–61 donnent 0–9, 62 donne + et 63 donne /.

Prenons le mot Man. Ses octets valent 77, 97 et 110. En découpant ces 24 bits en groupes de six, on obtient 19, 22, 5 et 46, soit TWFu. Un texte non anglais fonctionne de la même manière une fois converti en octets : le caractère coréen 한 occupe trois octets en UTF-8 (ED 95 9C) et devient donc exactement quatre caractères, 7ZWc.

Man   → TWFu
Hi    → SGk=
한    → 7ZWc
안녕  → 7JWI64WV

Comme trois octets donnent toujours quatre caractères, la sortie Base64 est environ 33 % plus volumineuse que l'entrée. Un fichier de 1 000 octets devient 1 336 caractères. C'est pourquoi intégrer de grandes images sous forme de data URI alourdit nettement une page.

Que signifie le = final ?

Lorsque la longueur de l'entrée n'est pas un multiple de trois, le dernier bloc ne contient qu'un ou deux octets. Les bits manquants sont complétés par des zéros, et un ou deux caractères = sont ajoutés pour que la longueur de sortie reste un multiple de quatre. Un octet restant produit ==, deux octets restants produisent un seul =. Voilà pourquoi Hi (deux octets) devient SGk=.

Le remplissage n'est qu'une indication qui aide le décodeur à retrouver la longueur exacte ; il ne contient aucune donnée. Certains systèmes l'omettent, et les décodeurs stricts peuvent alors rejeter la chaîne avec une erreur de longueur invalide. Ajouter des = jusqu'à obtenir un multiple de quatre règle généralement le problème.

Base64URL pour les liens et les noms de fichiers

Les caractères + et / ont un sens particulier dans les URL : + peut être interprété comme un espace et / sépare les segments de chemin. La variante Base64URL remplace donc + par - et / par _. Les deux mêmes octets FB FF s'encodent en +/8= en Base64 standard et en -_8= en Base64URL.

Les trois parties d'un JSON Web Token sont encodées en Base64URL, généralement sans remplissage. Décoder la partie centrale d'un JWT révèle en clair des informations comme l'identifiant de l'utilisateur ou la date d'expiration, ce qui nous amène au point le plus important sur Base64.

La grande idée reçue : Base64 n'est pas du chiffrement

Une sortie Base64 semble aléatoire, c'est pourquoi on la confond souvent avec du chiffrement. Mais il n'y a aucune clé : n'importe qui peut l'inverser instantanément avec les mêmes règles publiques. Stocker ou transmettre des mots de passe ou des clés d'API en Base64 n'offre pas plus de protection que le texte en clair.

L'authentification HTTP Basic en est un bon exemple. Le nom d'utilisateur et le mot de passe sont joints par deux-points puis encodés en Base64, mais ce n'est qu'un format de transport ; la véritable protection vient de HTTPS. Pour cacher des données, utilisez un chiffrement comme AES. Pour détecter une altération, utilisez un hachage ou une signature.

Où l'on rencontre Base64 en pratique

Savoir où Base64 est utilisé aide à identifier rapidement une chaîne inconnue.

• Pièces jointes d'e-mails : MIME encode les pièces jointes binaires en Base64 dans le corps du message.
• Data URI : de petites icônes peuvent être intégrées sous la forme data:image/png;base64,... dans du CSS ou du HTML. Réservez cette méthode aux images de quelques kilo-octets.
• JWT et OAuth : les en-têtes et charges utiles des jetons utilisent Base64URL.
• Charges utiles d'API : JSON ne peut pas contenir d'octets bruts, les fichiers et signatures sont donc envoyés sous forme de chaînes Base64.
• Certificats et clés : le corps d'un fichier PEM commençant par -----BEGIN CERTIFICATE----- est en Base64.

Dépanner une chaîne qui refuse de se décoder

La plupart des erreurs de décodage ont peu de causes. D'abord, vérifiez la présence de sauts de ligne ou d'espaces ; les e-mails et fichiers PEM reviennent souvent à la ligne tous les 76 caractères. Ensuite, si vous voyez - ou _, la chaîne est en Base64URL et doit être décodée comme telle. Enfin, si la longueur n'est pas un multiple de quatre, le remplissage manque.

Si le décodage réussit mais que le texte paraît illisible, c'est l'encodage de caractères d'origine qui pose problème. Les lettres accentuées, par exemple, produisent des octets différents en UTF-8 et en ISO-8859-1 ; il faut donc interpréter le résultat avec le même jeu de caractères que celui utilisé à l'encodage. L'outil Base64 d'AIBIZAP utilise UTF-8, si bien que les accents, le japonais, le coréen et les emoji sont convertis correctement dans les deux sens.