Encoder en Base64

Base64 ne chiffre ni ne compresse : il réécrit des octets avec seulement 64 caractères qui survivent à presque n’importe quel transport. Il prend trois octets, les regarde comme vingt-quatre bits et les redécoupe en quatre groupes de six, et chaque groupe désigne un caractère de la table. Six bits indexent exactement soixante-quatre valeurs, d’où le nom et la taille de l’alphabet.

De là vient son coût : le résultat occupe toujours un tiers de plus que l’original, remplissage compris. C’est le prix à payer pour traverser un canal qui ne comprend que du texte, et c’est pourquoi une pièce jointe pèse plus lourd que le fichier qu’elle contient — le courrier électronique reste un protocole de texte à l’intérieur.

L’alphabet standard utilise `+` et `/` pour ses deux derniers caractères. Les deux ont un sens dans une URL : la barre oblique sépare des segments de chemin et le plus se lit comme une espace dans un query string. Une valeur en Base64 standard glissée dans une adresse arrive donc modifiée, ou casse.

La variante compatible URL, définie au §5 du RFC 4648, remplace ces deux caractères par `-` et `_`, qui ne signifient rien nulle part dans une adresse. C’est ce qu’emploient les JWT, et c’est pourquoi un token copié depuis un en-tête ne contient ni barre oblique ni signe plus. Si la valeur doit voyager dans une URL, c’est cette option ; sinon, le standard est ce que tout le reste attend.

Base64 travaille trois octets à la fois. Quand l’entrée n’est pas un multiple de trois, il en reste un ou deux, et le remplissage est marqué par un ou deux signes égal en fin de chaîne. C’est pourquoi un résultat se termine par `=`, par `==` ou par rien, et pourquoi sa longueur est toujours un multiple de quatre.

Ce remplissage est optionnel dans certaines spécifications et obligatoire dans d’autres, ce qui provoque un désaccord récurrent : les JWT l’omettent volontairement, tandis que beaucoup de bibliothèques refusent de décoder sans lui. Quand quelque chose rejette une valeur qui paraît correcte, le nombre de caractères est la première chose à regarder.

Base64 encode des octets, pas des caractères, et il faut donc d’abord décider comment le texte devient des octets. Ici c’est toujours l’UTF-8, où un `é` fait deux octets, un `ç` aussi, et un emoji quatre. La chaîne Base64 est d’autant plus longue que le texte s’éloigne de l’ASCII.

C’est là que se niche l’écart le plus fréquent avec un autre outil : si l’autre partie a travaillé en Latin-1, le `é` valait un octet au lieu de deux et les résultats ne coïncident pas. Aucun des deux encodeurs n’a tort — ils encodaient des textes différents, et le malentendu est une couche plus bas.

L’en-tête `Authorization: Basic` contient exactement `utilisateur:motdepasse` en Base64, et rien d’autre. Quiconque voit l’en-tête peut le défaire en une seconde, puisqu’il n’y a aucune clé : c’est un encodage, pas un chiffrement.

Ce qui protège ces identifiants, c’est HTTPS et uniquement HTTPS. Basic Auth sur du HTTP simple revient donc à envoyer le mot de passe en clair, et un en-tête de ce type dans une capture d’écran, un ticket ou un journal est un identifiant exposé. Qu’il paraisse illisible ne change rien.

Une image en Base64 dans un `src` économise une requête, ce qui est raisonnable pour une petite icône ou un SVG de quelques kilooctets. Au-delà, le compte n’y est plus : le fichier grossit d’un tiers, il est incrusté dans le HTML et n’est donc plus mis en cache séparément, et le navigateur doit l’analyser avant de peindre quoi que ce soit.

Le point de bascule dépend de la page, mais la règle empirique tient : en dessous de quelques kilooctets la data URI gagne presque toujours, au-dessus de quelques dizaines elle perd presque toujours. Une grande image incrustée transforme chaque visite en téléchargement complet d’un HTML gonflé.

On le rencontre régulièrement comme moyen de « masquer » une clé dans le code d’une application, dans un fichier de configuration ou dans un script. Cela ne masque rien : le retour tient en un bouton, et les outils qui traquent les secrets divulgués reconnaissent les chaînes Base64 précisément parce que le motif est facile à détecter.

Ce que cela fait, en revanche, c’est retirer l’alerte à celui qui relit en diagonale, et c’est bien le problème : un secret en clair se voit et se corrige, un secret en Base64 passe la revue. S’il faut vraiment qu’une valeur soit cachée, il faut du chiffrement avec une clé qui vit ailleurs, ou ne pas la mettre là du tout.

Le MIME d’origine coupait le Base64 tous les soixante-seize caractères, et les blocs PEM le coupent tous les soixante-quatre. Ces retours à la ligne font partie du format d’enveloppe, pas de la valeur : un décodeur strict qui les rencontre au milieu d’une chaîne peut refuser, et beaucoup refusent.

Cet encodeur produit une seule ligne continue, ce qui est ce qu’attendent un en-tête HTTP, un champ JSON et une variable d’environnement. Si votre destination veut des lignes coupées — un fichier PEM que vous reconstituez à la main — la coupe se fait après, et elle se refait à l’identique tant que rien n’a été ajouté au milieu d’un groupe de quatre.

Les data URI, pour qu’une petite icône vive dans une feuille de style au lieu de coûter une requête. Le MIME, pour qu’une pièce jointe survive à un serveur de courrier antérieur au transport huit bits. Les en-têtes d’authentification Basic. Les segments de JWT. Les fichiers PEM, qui sont des octets DER en Base64 entre deux lignes de tirets. Les secrets Kubernetes, qui sont du Base64 dans du YAML et la raison pour laquelle beaucoup de gens cherchent cette page une première fois.

Leur point commun est un canal spécifié pour du texte à qui on demande de transporter autre chose. Base64 est l’adaptateur. Là où le canal accepte des octets — un envoi de fichier, un corps de requête — il ajoute un tiers de volume et n’achète rien.