Outils de développement · Encodeur et décodeur Base64
Pourquoi les pièces jointes des e-mails sont en Base64 : MIME, transport 7 bits et lignes de colonnes 76
· Contexte
base64 codage
L'e-mail a été conçu pour du texte ASCII 7 bits et les pièces jointes devaient y passer. Cet article retrace comment MIME a adopté Base64, pourquoi les lignes sont renvoyées à 76 caractères et ce que cela signifie pour la taille et le débogage.
La pièce jointe arrivée corrompue via un ancien relais – le problème 8-bit que MIME a été inventé pour résoudre
Le courrier électronique a été conçu dans les années 1970 et 1980 pour le texte ASCII 7 bits uniquement. SMTP, le protocole qui transporte le courrier électronique, s'attend à ce que chaque ligne contienne au plus 998 caractères de 7 bits ASCII (caractères 0-127). L'envoi d'un fichier binaire comme un PDF ou d'une image directement via SMTP échouerait : les octets 128-255 seraient corrompus ou rejetés par les anciens serveurs de messagerie et relais. Les pièces jointes doivent être codées. MIME (MultiPurpose Internet Mail Extensions, RFC 2045) a résolu ce problème en définissant les valeurs d'en-tête Content-Transfer-Encoding, y compris base64, qui représente toute séquence d'octets sous forme de texte ASCII 7 bits.
MIME propose plusieurs choix de codage de transfert de contenu : 7 bits (pas de codage, uniquement pour l'ASCII sécurisé), 8 bits (pour les serveurs prenant en charge les octets 8 bits, non universels), quoted-printable (encode uniquement les octets non sécurisés, gardant l'ASCII lisible) et base64 (encode tout, maximisant la compatibilité). Base64 a été choisi pour les pièces jointes binaires car il est simple, standardisé et garantit la sécurité sur n'importe quel système de messagerie, quel que soit son âge ou strictement 7-bit. Le compromis est la taille : Base64 est environ un tiers plus grand que les octets d'origine.
Le problème de transport résolu par Base64 : représentant des octets arbitraires avec des caractères imprimables
Un 3 KB PDF devient approximativement 4 KB de texte Base64. La limite de lignes de caractères 76 provient de la RFC 2045.
SMTP autorise les lignes jusqu'à 998 caractères, mais les anciens systèmes de messagerie et certains filtres anti-spam rejettent les lignes longues. La RFC 2045 spécifie que les lignes MIME Base64 ne doivent pas dépasser 76 caractères (plus une fin de ligne CRLF), afin qu'un serveur de messagerie n'interrompe jamais le transport. La limite n’est pas magique ; il s'agit d'un compromis historique entre la lisibilité (les caractères 76 conviennent à la plupart des terminaux des années 1980), la compatibilité avec les anciens systèmes et le fait d'éviter la détection en tant que spam ou modèle de virus.
Les choix de sortie visibles dans cet outil : remplissage canonique et habillage de caractères 76 facultatif
Les systèmes de messagerie modernes prennent généralement en charge des lignes plus longues, mais le codage en lignes de caractères 76 garantit que la pièce jointe atteint même le destinataire le plus ancien. Après que la RFC 2045 ait défini MIME Base64, la RFC 4288 (types de médias) et la RFC 2183 (Content-Disposition) ont ajouté des méthodes standardisées pour étiqueter les pièces jointes. Un message avec une pièce jointe PDF comprend un en-tête Content-Transfer-Encoding: base64, un en-tête Content-Type: application/pdf et les PDF octets codés en Base64 avec des lignes de caractères 76. Un lecteur de courrier décode les lignes en supprimant les sauts de ligne (caractères CRLF), puis décode le Base64 pour récupérer les octets d'origine.
Le décodage d'une pièce jointe MIME Base64 nécessite d'ignorer les espaces. La RFC dit : les décodeurs doivent sauter les sauts de ligne (caractères CR et LF) pendant le décodage. C'est pourquoi un décodeur Base64 qui accepte les espaces est pratique ; la plupart des vrais courriers MIME auront des sauts de ligne. Certains décodeurs sont stricts et rejettent les espaces (adaptés aux contextes comme JWT, où les sauts de ligne ne doivent pas être présents), tandis que d'autres sont indulgents et ignorent les espaces (adaptés à MIME).
L'option de caractère 76 en pratique - comment l'encodeur insère et le décodeur ignore les sauts de ligne
L'outil d'encodage et de décodage Base64 peut gérer les deux : il accepte une pièce jointe collée sur plusieurs lignes et ignore les sauts de ligne pendant le décodage. L’impact de la taille est prévisible. L'habillage base64 RFC 2045 ajoute un CRLF (2 octets) par 76 caractères de sortie. Pour un fichier 10 KB, le Base64 est d'environ 13.3 KB, plus CRLF tous les 76 caractères : environ 13.5 KB au total. La surcharge représente environ un tiers d'octets supplémentaires.
Les limites de taille des e-mails sont généralement indiquées pour la taille encodée, et non pour la taille du fichier d'origine ; un serveur de messagerie avec une limite 25 MB signifie 25 MB du message codé, et non 25 MB de pièces jointes. Le calcul de la taille du fichier d'origine nécessite de diviser par 1.33 (ou plus précisément, par 4 divisé par 3). Le codage imprimable entre guillemets est une alternative qui conserve l'ASCII imprimable inchangé et code uniquement les octets 128-255 et quelques caractères spéciaux.
Exemple concret : lecture d'une source de message brut - recherche de la partie Base64 et décodage d'une petite pièce jointe
Un fichier texte contenant principalement de l'ASCII reste lisible si vous ouvrez la source du message brut. Base64 obscurcit tout, même le texte ASCII brut. Quoted-printable est rarement utilisé pour les fichiers binaires (ce serait très inefficace pour un PDF) mais est parfois utilisé pour le texte. Un lecteur de courrier choisit le codage en fonction du type de pièce jointe ; un navigateur ne demande généralement pas à l'utilisateur quel encodage appliquer.
Le corps Base64 d'un message électronique n'est constitué que des octets eux-mêmes, et non d'un fichier séparé. Lorsque vous voyez une pièce jointe dans un lecteur de courrier, le lecteur a déjà décodé le Base64 et affiche le fichier original.
Le coût de la taille en pratique : environ un tiers d'octets supplémentaires, et pourquoi des limites de taille de courrier sont indiquées pour la taille codée
Si vous affichez la source brute du message (une option dans la plupart des clients de messagerie), vous verrez les en-têtes MIME et le corps codé en Base64. L'outil d'encodage et de décodage Base64 peut vous aider à décoder manuellement un fragment d'une source de message ; copiez la partie Base64, supprimez les sauts de ligne et collez-la dans l'outil.
Plusieurs pièces jointes dans un message MIME utilisent une limite en plusieurs parties. Chaque partie possède ses propres en-têtes (Content-Type, Content-Transfer-Encoding) et son propre corps. Une version alternative en texte brut du message apparaît comme une partie et chaque pièce jointe apparaît comme une autre partie. La chaîne de délimitation sépare les parties ; il est choisi pour n'apparaître dans le contenu d'aucune partie. Un lecteur de courrier reconstruit le message en analysant les limites et en décodant chaque partie en fonction de son en-tête Content-Transfer-Encoding.
Ce que ceci ne couvre pas : les en-têtes de mots codés, S/MIME et l'extension 8BITMIME en profondeur
RFC 2045 l'encodage base64 n'est pas universel aujourd'hui. Certains systèmes de messagerie prennent en charge le transport 8-bit et ne nécessitent plus base64. Certains systèmes utilisent des noms de codage différents ou ajoutent des en-têtes personnalisés. Mais base64 avec les lignes de caractères 76 reste le choix le plus compatible pour les pièces jointes devant atteindre n'importe quel système de messagerie, n'importe où. Lorsque vous joignez un fichier à l'aide d'un client de messagerie, le client choisit généralement automatiquement base64 pour les fichiers binaires, gère le retour à la ligne et ajoute les en-têtes MIME.
Comprendre le mécanisme vous aide à déboguer lorsqu'une pièce jointe semble corrompue ou lorsque vous travaillez manuellement avec une source de message. Créer ou analyser un message électronique sortant nécessite de comprendre la structure MIME. Une bibliothèque doit gérer l'encodage, le retour à la ligne et les en-têtes ; vous ne construisez généralement pas MIME manuellement. Mais si vous analysez une source de message brut (débogage d'un problème de livraison ou extraction de pièces jointes par programme), sachant que Content-Transfer-Encoding: base64 signifie que le corps suivant est 76-character-wrapped base64 vous permet d'appliquer le bon décodeur.
À retenir : Base64 est la couche de compatibilité de la messagerie électronique – comment l'encodeur et le décodeur Base64 vous permettent de lire localement une petite partie de texte d'un message brut
La base64 elle-même est la norme RFC 4648 ; les en-têtes d'habillage et MIME sont spécifiques au courrier électronique. Les pièces jointes des e-mails sont en base64 car les e-mails ont été conçus pour le texte brut et base64 est la couche de compatibilité la plus simple et la plus universelle pour envoyer des données binaires via un protocole texte uniquement. La limite de lignes de 76 caractères est un artefact historique des terminaux des années 1980 et des réseaux lents, mais elle persiste comme norme de compatibilité.
Comprendre cet historique explique pourquoi MIME existe, pourquoi il existe plusieurs options de codage et pourquoi base64 reste la valeur par défaut pour les pièces jointes même si les systèmes de messagerie modernes peuvent prendre en charge directement le binaire. L'encodeur et décodeur Base64 vous permet de travailler manuellement avec des corps MIME pour vérifier ou déboguer l'encodage.