Résumé

  • La RFC 3548 répond à une source d’incompatibilité discrète : des textes disaient « base64 » sans préciser l’alphabet, les retours à la ligne, le bourrage ni le traitement des caractères étrangers à l’alphabet.
  • Elle rappelle que le comportement de transfert MIME est un profil destiné au courrier, pas un contrat universel pour tous les décodeurs.

Un éditeur de texte ouvre une chaîne Base64 ; il est donc tentant de croire que la conversion se suffit à elle-même : des octets entrent, des caractères imprimables sortent, et tout décodeur sait revenir en arrière. La RFC 3548 décrit une histoire plus nuancée. Les implémentations avaient accumulé de petites différences, alors que des protocoles invoquaient « base64 » comme si ce nom levait chaque ambiguïté.

Le désaccord ne portait pas sur le découpage en groupes de six bits, mais sur ce qui l’entoure. Faut-il insérer des retours à la ligne ? Le bourrage final = doit-il être présent ? Un décodeur rejette-t-il un caractère inattendu ou l’ignore-t-il ? Quels sont les 64 symboles retenus ? Emprunter la réponse d’un format voisin peut fonctionner dans ce format et échouer face à un pair qui en attend un autre.

Publiée en juillet 2003 comme RFC informative, la RFC 3548 voulait réduire cette ambiguïté. Son introduction relève un raccourci fréquent : des spécifications de protocole mentionnaient « base64 » sans description ni référence précise, souvent en prenant MIME comme référence sans considérer le retour à la ligne ou les caractères hors alphabet. Le document rassemble donc les schémas Base16, Base32 et Base64 courants et rend visibles leurs paramètres.

MIME est une source de confusion parce qu’il définit un contexte particulier. La RFC 2045 décrit Base64 comme un encodage de transfert du contenu des messages. Sa limite de 76 caractères par ligne appartient à ce contexte ; PEM utilisait 64 caractères dans un autre cadre hérité du courrier. Pour un protocole qui renvoie à la RFC 3548, la règle générale est de ne pas ajouter de saut de ligne à moins que le texte appelant le demande. Une coupure n’est pas un simple ornement si l’autre analyseur risque de la compter comme une donnée ou de la rejeter.

Le bourrage et la tolérance dépendent eux aussi du profil. La RFC 3548 demande le bourrage nécessaire, sauf disposition différente dans la spécification appelante. Elle recommande de rejeter les caractères étrangers à l’alphabet, à moins qu’une règle explicite choisisse une autre conduite. MIME peut ignorer ces caractères, y compris CRLF, mais cette exception reste sienne. La transposer ailleurs modifie l’ensemble des entrées admises. La RFC évoque les canaux clandestins et les erreurs d’implémentation comme motifs de prudence ; elle ne rapporte pas un incident attribué à un logiciel précis.

L’alphabet devait également être nommé. L’alphabet Base64 courant utilise + et / pour les valeurs 62 et 63. La RFC 3548 décrit une variante adaptée aux URL et aux noms de fichiers, qui emploie et _. Elle précise que cette variante n’est pas le même encodage et ne doit pas être désignée par le seul mot « base64 ». Une chaîne insérée dans un chemin ou un identifiant rencontre des contraintes différentes de celles d’un corps de courriel.

En octobre 2006, la RFC 4648 a remplacé la RFC 3548 par un texte sur la voie des normes. Elle conserve cette approche par profils et ajoute une règle d’encodage canonique : les bits de bourrage doivent être nuls en Base64 et Base32, faute de quoi plusieurs chaînes peuvent produire les mêmes octets décodés. C’est une question distincte des retours à la ligne MIME. Ensemble, les deux RFC montrent pourquoi « le décodage a réussi » ne suffit pas : les pairs doivent encore s’accorder sur la forme, le bourrage, la tolérance et le niveau où la valeur est interprétée.

L’encodage de base n’est ni un chiffrement ni une authentification. Il offre une représentation des octets compatible avec certains transports. L’apport historique de la RFC 3548 est plus modeste et plus durable : un nom familier ne constitue pas, à lui seul, un jeu complet de règles.

Sources