Base64 : origine, fonctionnement et cas d’usage
Comprenez ce qu’est Base64, son origine, la règle des 3 octets vers 4 caractères et les situations où l’utiliser.
Base64 en une phrase
Base64 est un encodage binaire-vers-texte : toute suite d’octets devient une chaîne composée d’un petit alphabet largement compatible. Il ignore si ces octets forment une image, un PDF ou un mot ; il leur fournit simplement un emballage adapté aux systèmes textuels.
La transformation est réversible et sans perte, mais ce n’est ni du chiffrement, ni un hachage, ni de la compression.
D’où vient Base64
Les premiers réseaux et systèmes de courrier ne transportaient pas toujours correctement les octets 8 bits. Certaines passerelles attendaient du texte imprimable sur 7 bits et pouvaient altérer le binaire. Des méthodes plus anciennes, comme uuencode, traitaient déjà ce problème ; l’encodage imprimable à 64 caractères de Privacy-Enhanced Mail, défini par la RFC 1421, est un ancêtre direct de Base64.
MIME a ensuite nommé Base64 comme encodage de transfert pour les corps et pièces jointes des messages. Publiée en 2006, la RFC 4648 est aujourd’hui la référence générale pour les alphabets standard et compatible URL. Base64 est donc le fruit d’une évolution collective des standards.
Pourquoi 64 caractères et la règle 3 vers 4
Six bits représentent exactement 64 valeurs, de 0 à 63. Base64 standard les associe à A–Z, a–z, 0–9, + et /. L’encodeur lit trois octets, soit 24 bits, puis redécoupe ce bloc en quatre groupes de 6 bits. Chaque valeur devient un indice dans l’alphabet et produit un caractère.
Pour “Man”, les octets ASCII/UTF-8 donnent les indices 19, 22, 5 et 46 : T, W, F et u. Le résultat est TWFu, et le décodage suit le chemin inverse.
- Entrée
Man- Octets d’entrée
01001101 01100001 01101110- Groupes de 6 bits
010011 010110 000101 101110- Indices de l’alphabet
19 · 22 · 5 · 46- Sortie Base64
TWFu
Remplissage, Unicode et Base64url
Un dernier bloc d’un seul octet produit deux caractères utiles puis == ; deux octets produisent trois caractères puis =. Ce remplissage ne cache rien : il indique la quantité réelle de données dans le dernier bloc de 24 bits. Certains protocoles l’omettent quand la longueur est connue autrement.
Base64 traite des octets. Le texte accentué, 中文 ou les emoji doivent d’abord être convertis, généralement en UTF-8. Base64url remplace + et / par - et _ pour les URL et noms de fichiers ; cet alphabet proche ne doit pas être mélangé sans vérifier le protocole.
Les bons cas d’usage
Base64 apparaît dans les pièces jointes MIME, les blocs PEM de certificats ou de clés et les URL data: pour de petites images ou polices. JSON et XML peuvent ainsi porter de petites données binaires. HTTP Basic utilise Base64 et les segments JWT utilisent base64url, sans que cela rende leur contenu secret.
Le critère est simple : le conteneur exige du texte alors que la charge utile est binaire. Si un envoi de fichier, un stockage objet ou un BLOB accepte déjà le binaire, Base64 est souvent superflu.
Le coût en taille et en performances
Trois octets complets deviennent quatre caractères. La longueur exacte vaut 4 × ceil(n / 3) : le surcoût approche donc 33,3% pour les gros contenus et peut être plus élevé pour les très petits. Les retours à la ligne ou le préfixe d’une URL data: ajoutent encore quelques octets.
Une autre couche peut compresser le transfert, mais l’encodage consomme toujours mémoire et processeur. Pour les gros fichiers, un transport binaire direct est généralement préférable.
Ce que Base64 ne fait pas
Base64 ne garantit ni confidentialité ni authenticité. Chacun peut décoder ou modifier la chaîne sans clé. Il ne protège donc ni mot de passe, ni jeton d’API, ni donnée personnelle. Utilisez chiffrement et TLS pour le secret, un hachage cryptographique pour une empreinte, et une signature ou un MAC contre l’altération.
La règle à retenir : Base64 franchit une frontière de texte, pas une frontière de sécurité.