Outils de développement · Encodeur et décodeur Base64
Une brève histoire de Base64 : de uuencode et PEM à l'alphabet d'aujourd'hui
· Contexte
base64 codage
L'alphabet de Base64 est un fossile des problèmes de transport des années 1980. Cet article suit la lignée de uuencode via Privacy-Enhanced Mail jusqu'à MIME et RFC 4648, et explique chaque choix de conception.
Pourquoi l'alphabet n'est pas simplement 0–63 dans un ordre évident - la question qui nous ramène quatre décennies en arrière
Base64 ne semblait pas entièrement formé en tant que standard. L'alphabet (A-Z, a-z, 0-9, +, /) est un fossile de décennies d'expériences de codage, chacune essayant de résoudre le même problème : comment représenter les données binaires sous forme de texte qui survit au courrier électronique des années 1970 et 1980, à USENET et aux outils Unix. L'histoire s'étend sur uuencode sur Unix, Privacy-Enhanced Mail (RFC 1421) dans 1993, MIME (RFC 2045) dans 1996, et enfin RFC 4648 dans 2006 consolidant toutes les variantes.
Comprendre cet historique explique pourquoi certains caractères sont dans l'alphabet et pourquoi la RFC a laissé certains choix aux implémenteurs. uuencode, abréviation de Unix-to-Unix encode, a été le premier outil à résoudre le problème de transport 7-bit sous Unix. Créé en 1980, il a codé chaque 3 octets (24 bits) en 4 caractères à partir d'un alphabet 64 caractères. L'alphabet uuencode était ASCII 32 (espace) à ASCII 95 (trait de soulignement et autres signes de ponctuation), choisi parce que ces caractères sont imprimables sur n'importe quel terminal. Le référentiel montre l'alphabet actuellement mis en œuvre, mais il ne contient aucune preuve d'archives sur qui a sélectionné cet ordre ou pourquoi chaque personnage a gagné. Le titre est donc restreint : la présentation actuelle peut être inspectée avec précision, tandis que les motifs et les dates nécessitent des documents historiques primaires non inclus ici.
Pourquoi l'alphabet semble historique – une limite que ce référentiel ne documente pas
Cependant, l'espace en tant que caractère de codage pose problème : les éditeurs de texte et les systèmes de messagerie suppriment les espaces de fin, corrompant ainsi le résultat. L'alphabet n'était pas idéal, mais il fonctionnait assez bien pour le transfert de fichiers Unix vers Unix. Le courrier à confidentialité améliorée (RFC 1421, 1992) était l'une des premières tentatives de normalisation du courrier électronique crypté. Il incluait son propre codage Base64 (RFC 1341, pour MIME, dont la RFC 1421 était antérieure dans la spécification mais en retard dans l'adoption).
RFC 1421 Base64 utilisait l'alphabet A-Z, a-z, 0-9, +, / (l'alphabet base64 moderne) et enroulait les lignes à 64 caractères. Cet alphabet évitait les espaces et autres caractères problématiques ; chaque caractère est imprimable sans ambiguïté et ne peut pas être confondu avec les codes de contrôle ou les variations des jeux de caractères nationaux. La longueur de ligne de 64 caractères correspondait à la largeur des terminaux papier des années 1980 et constituait un compromis pratique en matière de lisibilité. Uuencode appartient à l’histoire environnante, pourtant l’outil ne lit ni n’écrit son alphabet. Le traiter comme Base64 interchangeable serait une erreur de format. La comparaison utile ici se limite au problème commun de la représentation des octets avec des caractères imprimables.
Codages antérieurs comme contexte, et non comme preuve de mise en œuvre
RFC 1421 n'a pas été largement adopté pour le courrier électronique chiffré, mais son alphabet Base64 a survécu. MIME (MultiPurpose Internet Mail Extensions, RFC 2045, 1996) a adopté l'alphabet RFC 1421 Base64 mais a modifié le retour à la ligne de 64 à 76 caractères. La raison n'était pas technique mais historique : les blocs PEM (Privacy-Enhanced Mail) étaient composés de 64 caractères, et MIME a choisi une limite légèrement différente pour éviter toute confusion avec PEM dans l'analyse automatisée.
MIME Base64 est devenu la norme pour les pièces jointes aux e-mails et constitue aujourd'hui la variante Base64 la plus largement utilisée. La RFC 2045 a également défini d'autres valeurs de Content-Transfer-Encoding (7 bits, 8 bits, quoted-printable), offrant aux systèmes de messagerie des options basées sur le type de contenu. Le choix de l'alphabet évite les caractères qui diffèrent entre ASCII et EBCDIC (le codage de caractères du mainframe IBM). Les caractères A-Z, a-z, 0-9, + et / sont les mêmes dans les deux encodages. Les blocs de style PEM sont reconnaissables car les étiquettes entourent le matériel codé enveloppé. ToolAcre peut traiter le corps Base64 extrait une fois ces étiquettes supprimées. Il ne peut pas établir quelle spécification archivistique a utilisé en premier une convention donnée, et cet article ne prétend pas que l’arbre source répond à cette question.
Armure de style PEM comme format observable moderne, sans revendiquer une histoire d'origine
Les caractères tels que les parenthèses ouvrantes et les parenthèses fermantes diffèrent entre ASCII et EBCDIC, ils ont donc été exclus. Cela était important dans les années 1980 et au début des années 1990, lorsque le transfert de données entre mainframe et Unix était courant. L'alphabet évite également les barres obliques inverses, les guillemets simples et les guillemets doubles, qui ont une signification particulière dans les chaînes C et la syntaxe du shell. Une chaîne Base64 peut être intégrée dans un programme C ou un script shell sans échapper à presque tous les caractères.
RFC 3548 (2006) encodages consolidés Base64, base32 et base16. Il a noté que MIME, PEM et d'autres applications utilisaient toutes des concepts similaires mais avec des règles de remplissage et des alphabets différents. RFC 4648 (2006, publié avec RFC 3548) est la norme actuelle et définit cinq familles de codage avec des vecteurs de test pour chacune. La RFC note également l'historique : quels documents définissent quels codages, ce qui a changé entre les versions et pourquoi les choix ont été faits. L'option d'habillage des caractères 76 de l'encodeur et la suppression des espaces du décodeur rendent les échantillons de forme MIME testables. Ces faits de mise en œuvre ne prouvent pas un historique complet des normes de courrier. Ils montrent le comportement de compatibilité moderne que les lecteurs peuvent reproduire directement dans le panel et les tests.
Wrapping de style MIME comme option d'encodeur, sans reconstruire l'historique des normes
La plupart des développeurs ne rencontrent que base64 et base64url dans la RFC 4648 ; l'historique est documenté pour ceux qui doivent implémenter les anciennes variantes. Base64url (section RFC 4648 5) remplace le plus par un tiret et la barre oblique par un trait de soulignement pour éviter les caractères réservés à l'URL. Une chaîne base64 contenant + et / doit être codée en pourcentage dans une URL (%2B et %2F) ; base64url évite cela.
JWT (JSON Web Token) utilise l'url base64 sans remplissage. Certaines applications utilisent base64url avec un remplissage. La RFC définit les deux variantes ; c'est à l'application de choisir. Cette variance explique pourquoi un décodeur JWT et un décodeur de courrier électronique Base64 peuvent produire une sortie différente pour la même chaîne d'entrée (l'un attend une URL base64, l'autre attend une base64). L'alphabet, les règles de remplissage et le retour à la ligne sont tous issus des contraintes pratiques des systèmes réels. La portabilité est mieux traitée comme une contrainte sur les alphabets de transport plutôt que comme une biographie vérifiée de chaque symbole. Les lettres et les chiffres restent visuellement familiers dans les systèmes de texte courants, tandis que la ponctuation finale diffère en mode URL sécurisé. La justification historique exacte de la sélection est omise sans preuve primaire.
La portabilité comme contrainte de conception, et non comme compte rendu vérifié des choix de personnages individuels
Le jeu de caractères 64 a été choisi pour sa représentabilité à travers les encodages ; l'alphabet a été corrigé par RFC 1341 et 1421 et MIME ; la règle de remplissage provenait de l'alignement de 3 octets ; et le retour à la ligne provenait des limites de transport des e-mails. Une implémentation qui ignore cet historique peut inventer un nouveau codage ou oublier un cas limite. Les vecteurs de test RFC 4648 (foobar produit Zm9vYmFy) sont le moyen de vérifier qu'une implémentation respecte la norme.
Des alternatives modernes comme la base85 (utilisée dans certains contextes) existent, mais la base64 reste dominante en raison de la dynamique historique et parce qu'elle est suffisamment bonne. Base64 n'est pas l'encodage le plus compact (base85 et base91 sont plus denses), mais il est simple, universel et éprouvé. Ce qui peut être énoncé avec fermeté, c'est la paire d'alphabets actuelle : le standard se termine par un plus et une barre oblique ; Les URL sécurisées remplacent le trait d'union et le trait de soulignement. Le rembourrage et l'emballage sont des options distinctes. Les tests couvrent à la fois les modes et le remplissage manquant, fournissant des preuves reproductibles du comportement actuel plutôt qu'une chronologie déduite.
Ce que le référentiel prouve sur les alphabets standards et sécurisés pour les URL actuels
La taille supplémentaire de 33 pour cent est acceptable pour la plupart des utilisations. L'alphabet est stable dans toutes les implémentations. La RFC est suffisamment claire pour que les écarts soient généralement délibérés (comme l'omission de remplissage ou la gestion des espaces) plutôt qu'un malentendu accidentel.
Comprendre l'historique Base64 explique pourquoi il ressemble à cela. Les caractères plus et barre oblique étaient un choix délibéré pour éviter toute ambiguïté dans les différents codages de caractères. La règle de remplissage provenait du regroupement 3-byte. Base85 et Ascii85 utilisent des tailles de groupe et des alphabets différents et sont en dehors de l'implémentation. Les mentionner ne fait pas de cette page un convertisseur pour eux. Comparer leur densité ou leur historique nécessiterait des sources et des vecteurs de test au-delà des fichiers Base64 examinés pour ce module.
À retenir : chaque caractère a été choisi pour une raison : comment l'encodeur et le décodeur Base64 implémentent l'alphabet standard qui en résulte
Le retour à la ligne provient d'un e-mail. Chaque décision a été prise pour résoudre un problème réel avec des systèmes réels. Aujourd'hui, Base64 est principalement utilisé dans des contextes (JWT, API, URI de données) où l'historique n'a pas d'importance, mais l'alphabet et les règles de remplissage sont hérités de MIME et PEM via RFC 4648.
La lecture unique de la RFC et l'encodage d'une chaîne de test dans l'outil d'encodage et de décodage Base64 connectent la norme actuelle à ses racines historiques. L'alphabet standard résultant est visible chaque fois que l'entrée atteint les indices soixante-deux ou soixante-trois. Utilisez un exemple qui produit ces positions, activez le mode sécurisé pour les URL et comparez uniquement la ponctuation modifiée. Cette expérience démontre le format actuel sans s’appuyer sur une histoire non étayée sur son invention.