Base64 expliqué : comment l’encodage et le décodage fonctionnent

Ce qu’est réellement Base64

Base64 est une façon d’écrire des octets quelconques en n’utilisant que 64 caractères sûrs. Toute l’idée est là. Ce n’est pas du chiffrement, ni de la compression, ni une somme de contrôle. Cela résout un problème précis : vous avez des données binaires, et le canal par lequel vous devez les faire passer n’accepte que du texte.

Ce canal peut être le corps d’un e-mail, un champ JSON, une URL, un en-tête HTTP, un fichier YAML ou un fichier PEM. Envoyez des octets bruts et quelque chose en route les abîmera : un octet nul tronque une chaîne, un 0x0D est réécrit par une conversion de fin de ligne, un octet haut est réinterprété dans un autre jeu de caractères. Base64 contourne tout cela en n’utilisant que des lettres, des chiffres et deux signes de ponctuation, qui survivent tous au fait d’être traités comme du texte.

Le coût, c’est la taille : la sortie est environ un tiers plus grosse que l’entrée. C’est le marché, et il vaut presque toujours la peine, car l’alternative ce sont des données qui arrivent corrompues.

Comment trois octets deviennent quatre caractères

Base64 travaille par groupes de trois octets. Trois octets font 24 bits, et 24 se divise proprement en quatre groupes de six. Chaque groupe de 6 bits indexe un alphabet de 64 caractères : trois octets en entrée donnent donc quatre caractères en sortie.

Prenons les trois octets de Man :

M = 77 = 01001101, a = 97 = 01100001, n = 110 = 01101110

Concaténez les bits et redécoupez-les par six :

010011 010110 000101 101110 → 19, 22, 5, 46 → T, W, F, u

Ainsi Man s’encode en TWFu. Quatre caractères, aucun remplissage nécessaire, car trois octets se divisaient exactement. Ce « se divisaient exactement » est justement le sujet de la section suivante.

Les 64 caractères

Les indices 0–25 sont A–Z, 26–51 sont a–z, 52–61 sont 0–9, et 62 et 63 sont les deux qui causent tous les ennuis. En Base64 standard, ce sont + et /.

L’alphabet, et pourquoi il y en a deux

+ et / sont parfaitement acceptables dans le corps d’un e-mail et franchement hostiles dans une URL. / est un séparateur de chemin et + signifie une espace dans une chaîne de requête : une valeur Base64 collée dans une URL peut donc revenir avec des octets modifiés, sans la moindre erreur nulle part.

D’où base64url, une variante qui garde les 62 premiers caractères et remplace les deux derniers : - pour + et _ pour /. C’est l’encodage utilisé par les JSON Web Tokens — si vous avez déjà lu un JWT à la main, vous avez lu du base64url — et par tout ce qui voyage dans une URL ou un nom de fichier.

Les deux variantes sont identiques par ailleurs, et c’est précisément ce qui rend leur mélange dangereux. Une chaîne qui ne contient ni +, ni /, ni -, ni _ est valide dans les deux et se décode pareil. Une chaîne qui en contient se décode en octets différents selon la variante supposée par le décodeur, en général sans aucune erreur levée. Notre encodeur et décodeur Base64 indique quel alphabet il a détecté, précisément pour cette raison.

Le remplissage, et pourquoi les décodeurs ne s’accordent pas

L’entrée est rarement un multiple de trois octets. Un octet restant donne deux caractères, deux octets restants en donnent trois, et le Base64 standard complète le groupe jusqu’à quatre avec des signes = :

• 3 octets → 4 caractères, pas de remplissage
• 2 octets → 3 caractères + =
• 1 octet → 2 caractères + ==

Le remplissage ne porte aucune donnée. Il existe pour qu’un décodeur lisant un flux concaténé sache où s’arrête une valeur encodée. Si vous décodez une seule chaîne isolée, vous n’en avez pas besoin du tout — d’où le fait que base64url le supprime d’ordinaire, et que = soit de toute façon malvenu dans une URL.

Le problème pratique

Certains décodeurs exigent le remplissage et rejettent net une chaîne sans lui. D’autres acceptent les deux formes. C’est la raison la plus fréquente pour laquelle un token qui marche dans un langage échoue dans un autre avec un laconique « base64 invalide ». Le correctif consiste presque toujours à remettre le remplissage : ajoutez des = jusqu’à ce que la longueur soit un multiple de quatre. Un décodeur strict sur le remplissage n’est pas cassé, et l’encodeur qui l’a omis ne l’est pas non plus : chacun suit une moitié différente de la même spécification.

Base64 n’est pas du chiffrement

Cela mérite sa propre section, car l’erreur est aussi fréquente que coûteuse. Base64 n’a pas de clé. Il ne cache rien. L’inverser tient en un appel de fonction, disponible dans tous les langages et sur n’importe quelle page comme celle-ci.

L’exemple canonique est l’authentification HTTP Basic. Un en-tête Authorization: Basic n’est rien d’autre que identifiant:motdepasse en Base64. Il paraît opaque, et c’est précisément le danger : il se lit comme « chiffré » pour qui n’en a jamais décodé un, alors qu’en réalité quiconque voit la requête peut lire les identifiants. Voilà pourquoi Basic n’est acceptable qu’en HTTPS : c’est le transport qui apporte la confidentialité, l’encodage n’en apporte aucune.

Il en va de même pour la charge utile d’un JWT, pour un bloc Base64 dans un fichier de configuration, et pour une clé d’API que quelqu’un a « obfusquée » avant de la committer. Si la seule chose entre un attaquant et votre secret est du Base64, il n’y a rien entre un attaquant et votre secret. Notre guide pour décoder et déboguer les JSON Web Tokens approfondit ce que cela signifie pour les tokens en particulier.

Où l’on croise réellement du Base64

Une fois la forme reconnue, on le voit partout :

• Pièces jointes d’e-mails. MIME transporte du binaire ainsi depuis le début des années quatre-vingt-dix, découpé à 76 caractères par ligne.
• data: URI. Une petite image intégrée dans du CSS ou du HTML sous la forme data:image/png;base64,…, échangeant une requête HTTP contre un tiers d’octets en plus.
• Fichiers PEM. Les certificats et les clés entre les marqueurs -----BEGIN… sont du Base64 du DER sous-jacent, découpé à 64 caractères.
• JWT. L’en-tête et la charge utile sont du JSON en base64url ; la signature est du base64url d’octets bruts.
• Basic auth et certains identifiants d’API. Comme ci-dessus, avec la même réserve.
• Du binaire dans du JSON. JSON n’a pas de type octet, donc les octets voyagent sous forme de chaîne Base64.

Pourquoi certains Base64 ont des retours à la ligne

MIME découpe à 76 caractères et PEM à 64, parce que les formats dans lesquels ils vivent sont antérieurs aux longues lignes. Ces retours ne font pas partie des données et un décodeur doit les ignorer. La plupart le font ; quelques-uns non, et c’est pourquoi coller un corps PEM découpé dans un décodeur strict échoue parfois jusqu’à ce qu’on retire les retours à la ligne.

Le coût en taille, et quand il compte

Quatre caractères pour trois octets, c’est une expansion de 4/3 — environ 33 % — avant remplissage et retours à la ligne. Pour une valeur de configuration ponctuelle, c’est sans importance. Pour quoi que ce soit sur un chemin critique, non.

Une image de 10 Ko intégrée en data: URI coûte environ 13,3 Ko de HTML et, contrairement à une vraie image, elle ne peut être mise en cache séparément ni chargée en différé. Un token envoyé à chaque appel d’API traîne son surcoût à chaque requête. Et la compression ne vous sauve pas : la sortie Base64 se compresse bien moins bien que les octets d’origine, car l’encodage détruit les motifs au niveau de l’octet que recherche un compresseur. Compressez d’abord, encodez ensuite — jamais l’inverse.

Encoder du texte, c’est encoder des octets

Base64 encode des octets. Il n’a aucune notion de caractère : « encode cette chaîne en Base64 » est donc toujours un raccourci pour « transforme cette chaîne en octets, puis encode ces octets ». L’étape intermédiaire est celle qui déraille, car elle a besoin d’un encodage de caractères et la spécification n’en choisit pas un pour vous.

En pratique la réponse est UTF-8, et les API modernes l’utilisent par défaut. Mais si un côté encode le texte en UTF-16 ou en Latin-1 et que l’autre décode en UTF-8, le Base64 est parfaitement valide et le texte qui en sort est du charabia. L’indice : les caractères non ASCII survivent mal tandis que l’ASCII pur survit très bien, puisque l’ASCII est un sous-ensemble d’UTF-8.

Le test d’aller-retour

Si vous doutez qu’une chaîne de traitement gère correctement le texte, encodez une chaîne avec un accent et un caractère non latin, décodez-la, puis comparez. Tout ce qui abîme José ou un emoji perd de l’information quelque part dans la conversion en octets, pas dans le Base64 lui-même.

Quand le décodage échoue

Quatre diagnostics couvrent presque tous les cas :

• « Caractère invalide ». Quelque chose hors de l’alphabet s’est glissé dedans — le plus souvent une espace égarée, un guillemet copié avec la chaîne, ou un préfixe data:image/png;base64, resté devant.
• « Longueur invalide ». Après suppression des blancs, la longueur modulo quatre vaut 1, ce qu’aucun Base64 valide ne peut produire. Un caractère a été perdu en route.
• Ça décode, mais en charabia. Soit les alphabets sont mal appariés (du base64url décodé comme du standard, ou l’inverse), soit l’encodage de texte est mal apparié comme décrit plus haut.
• Ça décode en octets qui ne sont pas du texte. Ce n’est pas une erreur. Beaucoup de Base64 contient une image, une clé ou une structure sérialisée ; un bon décodeur vous montre une vue hexadécimale au lieu de prétendre que le résultat est une chaîne.

Parcourir ces points dans l’ordre — caractères, longueur, alphabet, encodage — résout presque tout. Et quand une valeur refuse simplement de se décoder où que ce soit, l’explication la plus probable est la plus ennuyeuse : elle était tronquée. Base64 n’a aucun contrôle d’intégrité, donc une chaîne qui a perdu sa fin ressemble exactement à une chaîne qui n’en a jamais eu.

Outils et guides associés :

• Encodeur et décodeur Base64 : Encodez du texte en Base64 ou décodez-le, avec sortie URL-safe et UTF-8 géré.
• Décodeur JWT : Décodez un JSON Web Token et lisez son en-tête, sa charge utile, ses claims et son expiration.
• JWT expliqué : décoder et déboguer les JSON Web Tokens : Ce que contient un JSON Web Token

Questions fréquentes