Encodeur et décodeur Base64

Le Base64 existe car une grande partie de l'infrastructure construite autour du texte — email, JSON, XML, URL — ne peut pas transporter de façon fiable des octets binaires arbitraires, qui pourraient contenir des caractères de contrôle, des octets nuls, ou des séquences d'octets terminant une chaîne prématurément ou cassant directement un analyseur. Le Base64 associe chaque groupe de trois octets de données binaires arbitraires à quatre caractères tirés d'un ensemble fixe de 64 que tout système basé sur le texte gère en sécurité — lettres, chiffres et deux symboles — donc le résultat encodé peut être intégré dans du JSON, envoyé comme pièce jointe email, ou inclus dans un document sans que rien en aval ne le méprenne pour autre chose que du texte brut.

Le surcoût de cette sécurité est fixe et inévitable : quatre caractères de sortie pour trois octets d'entrée, une expansion d'environ 33 %, quelles que soient les données sous-jacentes. C'est le prix payé pour un passage sûr garanti à travers des canaux texte seul, pas un défaut propre à une implémentation particulière.

La fonction `btoa` intégrée du navigateur, à laquelle recourent directement de nombreuses implémentations Base64 rapides, génère une erreur dès qu'elle rencontre un caractère au-delà du point de code U+00FF — ce qui inclut essentiellement tous les emojis, le chinois, japonais, coréen, cyrillique, grec et arabe, plus pas mal de caractères latins accentués utilisés en français, allemand, espagnol et d'autres langues. Ce n'est pas un cas limite obscur touchant des entrées rares ; cela affecte une très grande fraction du texte réel, et c'est pourquoi tant d'outils Base64 faits maison fonctionnent parfaitement en test avec une entrée en anglais brut puis échouent la première fois qu'un utilisateur colle quelque chose avec un emoji ou un nom non latin.

La solution est d'encoder le texte en octets UTF-8 d'abord, puis d'encoder ces octets en Base64 — ce que font les encodeurs correctement construits et ce que fait cet outil — plutôt que d'essayer d'introduire directement des points de code Unicode dans un encodage conçu pour des séquences d'octets inférieures à 256.

Le jeu de caractères du Base64 standard inclut `+` et `/`, tous deux ayant une signification dans une URL — `+` est parfois interprété comme un espace, et `/` est un séparateur de chemin — donc une chaîne Base64 standard collée directement dans une chaîne de requête ou un nom de fichier peut être corrompue ou tronquée silencieusement par ce qui analyse cette URL. Base64URL remplace ces deux caractères par `-` et `_`, aucun n'ayant de signification spéciale dans une URL, et supprime généralement aussi les caractères de remplissage `=` finaux, qui existent purement pour signaler la longueur et sont inutiles une fois que le décodeur sait déjà s'y attendre.

Les JSON Web Tokens utilisent Base64URL précisément pour cette raison : un JWT est conçu pour voyager dans un en-tête HTTP Authorization et parfois une URL, et les caractères réservés du Base64 standard rendraient cela peu fiable.

Cela vaut la peine de le dire clairement car cette supposition apparaît souvent : le Base64 n'offre aucune confidentialité. Aucune clé secrète n'intervient à aucun moment du processus, donc quiconque obtient une chaîne Base64 peut la décoder instantanément vers les données d'origine en utilisant rien de plus qu'un appel de bibliothèque standard ou un outil exactement comme celui-ci. Encoder un mot de passe ou une clé API en Base64 avant de le stocker ou de le transmettre n'offre aucune protection — cela cache seulement la valeur d'un coup d'œil occasionnel, ce qui est une propriété très différente de la sécurité réelle.