Transfert de contenu codant 7 bits ou 8 bits
Lors de l'envoi du contenu d'un courrier électronique, il est nécessaire de définir l'en-tête "Content Transfer Encoding". J'ai observé de nombreux en-têtes d'e-mails que j'ai reçus. Certains courriels utilisant "7bit" et certains utilisent "8bit".
Quelle est la différence entre ces deux? Lequel est recommandé? Un encodage spécial est-il requis pour le corps de l'e-mail afin de définir ces en-têtes?
Cela peut paraître un peu dense à lire, mais la section "Content-Transfer-Encoding" de la RFC 1341 contient tous les détails:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
La situation va un peu de pire en pire. Voici mon résumé:
Contexte
SMTP, par définition (RFC 821), limite le courrier aux lignes de 1 000 caractères de 7 bits. Cela signifie qu'aucun des octets que vous envoyez en aval ne peut avoir le bit le plus significatif ("ordre le plus élevé") défini sur "1".
Le contenu que nous voulons envoyer n'obéira souvent pas à cette restriction de manière inhérente. Pensez à un fichier image ou à un fichier texte contenant des caractères Unicode: les octets de ces fichiers auront souvent leur 8ème bit défini sur "1". SMTP ne le permet pas, vous devez donc utiliser "l'encodage de transfert" pour décrire comment vous avez corrigé l'incohérence.
Les valeurs de l'en-tête Content-Transfer-Encoding Décrivent la règle que vous avez choisie pour résoudre ce problème.
Codage 7 bits
7bit Signifie simplement "Mes données sont composées uniquement de caractères US-ASCII, qui utilisent uniquement les 7 bits les plus bas pour chaque caractère." En gros, vous garantissez que tous les octets de votre contenu respectent déjà les restrictions du protocole SMTP. Aucun traitement particulier n'est donc nécessaire. Vous pouvez simplement le lire tel quel.
Notez que lorsque vous choisissez 7bit, Vous acceptez que toutes les lignes de votre contenu contiennent moins de 1 000 caractères.
Tant que votre contenu respecte ces règles, 7bit Est le meilleur encodage de transfert, car aucun travail supplémentaire n'est nécessaire. vous venez de lire/écrire les octets lorsqu'ils sortent du tuyau. Il est également facile de regarder le contenu 7bit Et de le comprendre. L'idée ici est que si vous écrivez simplement en "texte anglais clair" tout ira bien. Mais cela ce n'était pas vrai en 2005 et ce n'est pas vrai aujourd'hui.
Encodage 8 bits
8bit Signifie "Mes données peuvent inclure des caractères étendus ASCII; ils peuvent utiliser le 8ème bit (le plus élevé) pour indiquer des caractères spéciaux en dehors des caractères standard US-ASCII à 7 bits. "Comme avec 7bit, Il y a toujours une limite de ligne de 1000 caractères.
8bit, Tout comme 7bit, Ne fait en réalité aucune transformation des octets tels qu'ils sont écrits ou lus sur le réseau. Cela signifie simplement que vous ne garantissez pas qu'aucun des octets n'aura le bit le plus élevé défini sur "1".
Cela semble être un pas en avant par rapport à 7bit, Car cela vous donne plus de liberté dans votre contenu. Cependant, la RFC 1341 contient cette friandise:
À la date de publication du présent document, il n’existait aucun transport Internet normalisé pour lequel il était légitime d’inclure des données non codées de 8 bits ou binaires dans les corps de courrier. Ainsi, il n'y a pas de circonstances dans lesquelles le codage de contenu-transfert-codage "8 bits" ou "binaire" est réellement légal sur Internet.
Le RFC 1341 est sorti il y a plus de 20 ans. Depuis lors, nous avons obtenu extensions MIME 8 bits dans RFC 6152 . Mais même dans ce cas, des limites de lignes peuvent toujours s'appliquer:
Notez que cette extension n'élimine PAS la possibilité d'un serveur SMTP limitant la longueur de ligne; les serveurs sont libres d'implémenter cette extension mais néanmoins, fixer une limite de longueur de ligne non inférieure à 1000 octets.
Codage binaire
binary est identique à 8bit, sauf qu'il n'y a pas de restriction de longueur de ligne. Vous pouvez toujours inclure les caractères de votre choix, sans codage supplémentaire. Semblable à 8bit, Le RFC 1341 indique qu'il ne s'agit pas vraiment d'un codage de transfert de codage légitime. RFC 30 étendu cela avec BINARYMIME.
Cité imprimable
Avant l'extension 8BITMIME, Il fallait un moyen d'envoyer du contenu qui ne pouvait pas être 7bit Via SMTP. Les fichiers HTML (qui peuvent comporter plus de 1000 lignes de caractères) et les fichiers contenant des caractères internationaux en sont de bons exemples. Le codage quoted-printable (Défini dans la section 5.1 de la RFC 1341) est conçu pour gérer cela. Il fait deux choses:
- Définit comment échapper des caractères non US-ASCII afin qu'ils ne puissent être représentés que par des caractères 7 bits. (Version courte: ils sont affichés sous la forme d'un signe égal plus deux caractères de 7 bits.)
- Définit que les lignes ne seront pas supérieures à 76 caractères et que les sauts de ligne seront représentés à l'aide de caractères spéciaux (qui sont ensuite échappés).
Cité Printable, en raison des lignes d'échappement et des lignes courtes, est beaucoup plus difficile à lire par un humain que 7bit Ou 8bit, Mais il prend en charge une gamme beaucoup plus large de contenu possible.
Encodage Base64
Si vos données sont en grande partie non textuelles (ex: un fichier image), vous n’avez pas beaucoup d’options. 7bit N'est pas sur la table. 8bit Et binary n'étaient pas pris en charge avant les RFC d'extension MIME. quoted-printable Fonctionnerait, mais est vraiment inefficace (chaque octet va être représenté par 3 caractères).
base64 Est une bonne solution pour ce type de données. Il code 3 octets bruts en 4 caractères US-ASCII, ce qui est relativement efficace. La RFC 1341 limite en outre la longueur de ligne de base64 - données codées à 76 caractères pour tenir dans un message SMTP, mais cela est relativement facile à gérer lorsque vous séparez ou concaténez des caractères arbitraires à des longueurs fixes.
Le gros inconvénient est que les données codées par base64 Sont à peu près illisibles pour les humains, même s'il ne s'agit que de texte "brut" en dessous.