Lors de l'envoi du contenu d'un e-mail, il est nécessaire de définir l'en-tête "Content Transfer Encoding". J'ai observé de nombreux en-têtes de courriels que j'ai reçus. Certains e-mails utilisent "7 bits" et certains utilisent "8 bits".
Quelle est la différence entre ces deux? Laquelle est recommandée? Un encodage spécial est-il nécessaire pour le corps de l'e-mail afin de définir ces en-têtes?
Réponses:
Cela peut ê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 de mal en pis. Voici mon résumé:
SMTP, par définition (RFC 821), limite le courrier à des lignes de 1000 caractères de 7 bits chacune. Cela signifie qu'aucun des octets que vous envoyez dans le tube ne peut avoir le bit le plus significatif ("d'ordre le plus élevé") mis à "1".
Le contenu que nous voulons envoyer n'obéira souvent pas à cette restriction par nature. Pensez à un fichier image ou à un fichier texte contenant des caractères Unicode: les octets de ces fichiers auront souvent leur 8ème bit mis à "1". SMTP ne le permet pas, vous devez donc utiliser le «codage de transfert» pour décrire comment vous avez contourné l'incompatibilité.
Les valeurs de l'en- Content-Transfer-Encodingtête décrivent la règle que vous avez choisie pour résoudre ce problème.
7bitsignifie simplement "Mes données se composent uniquement de caractères US-ASCII, qui n'utilisent que les 7 bits inférieurs pour chaque caractère." Vous garantissez essentiellement que tous les octets de votre contenu respectent déjà les restrictions de SMTP, et qu'il ne nécessite donc aucun traitement spécial. Vous pouvez simplement le lire tel quel.
Notez que lorsque vous choisissez 7bit, vous acceptez que toutes les lignes de votre contenu comportent moins de 1 000 caractères.
Tant que votre contenu respecte ces règles, 7bitest le meilleur encodage de transfert, car aucun travail supplémentaire n'est nécessaire; vous venez de lire / écrire les octets au fur et à mesure qu'ils sortent du tube. Il est également facile de visualiser le 7bitcontenu et de le comprendre. L'idée ici est que si vous écrivez simplement en "texte anglais brut", tout ira bien. Mais ce n'était pas vrai en 2005 et ce n'est pas vrai aujourd'hui.
8bitsignifie "Mes données peuvent inclure des caractères ASCII étendus; ils peuvent utiliser le 8ème bit (le plus élevé) pour indiquer des caractères spéciaux en dehors des caractères 7 bits US-ASCII standard." Comme avec 7bit, il y a toujours une limite de ligne de 1000 caractères.
8bit, tout comme 7bit, ne fait aucune transformation des octets lorsqu'ils sont écrits ou lus à partir du câble. Cela signifie simplement que vous ne garantissez pas qu'aucun des octets n'aura le bit le plus élevé mis à "1".
Cela semble être un pas en avant 7bit, car cela vous donne plus de liberté dans votre contenu. Cependant, la RFC 1341 contient cette friandise:
A la date de publication de ce document, il n'existe aucun transport Internet standardisé pour lequel il est légitime d'inclure des données 8 bits non codées ou binaires dans les corps de courrier. Ainsi, il n'y a pas de circonstances dans lesquelles le codage de transfert de contenu "8 bits" ou "binaire" est réellement légal sur Internet.
La RFC 1341 est sortie il y a plus de 20 ans. Depuis lors, nous avons obtenu des extensions MIME 8 bits dans la RFC 6152 . Mais même dans ce cas, les limites de ligne peuvent toujours s'appliquer:
Notez que cette extension n'élimine PAS la possibilité qu'un serveur SMTP limite la longueur de la ligne; les serveurs sont libres d'implémenter cette extension mais fixent néanmoins une limite de longueur de ligne non inférieure à 1000 octets.
binaryest 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 et il n'y a pas d'encodage supplémentaire. Similaire à 8bit, la RFC 1341 indique qu'il ne s'agit pas vraiment d'un encodage de transfert de codage légitime. La RFC 3030 a étendu cela avec BINARYMIME.
Avant l' 8BITMIMEextension, il devait y avoir un moyen d'envoyer du contenu qui ne pouvait pas être 7bitvia SMTP. Les fichiers HTML (qui peuvent avoir plus de 1000 lignes de caractères) et les fichiers avec des caractères internationaux en sont de bons exemples. Le quoted-printablecodage (défini dans la section 5.1 de la RFC 1341) est conçu pour gérer cela. Il fait deux choses:
Quoted Printable, en raison des lignes d'échappement et des lignes courtes, est beaucoup plus difficile à lire par un humain que 7bitou 8bit, mais il prend en charge une gamme beaucoup plus large de contenu possible.
Si vos données sont en grande partie non textuelles (ex: un fichier image), vous n'avez pas beaucoup d'options. 7bitest hors de la table. 8bitet binaryn'étaient pas pris en charge avant les RFC d'extension MIME. quoted-printablefonctionnerait, mais est vraiment inefficace (chaque octet sera représenté par 3 caractères).
base64est une bonne solution pour ce type de données. Il encode 3 octets bruts sous forme de 4 caractères US-ASCII, ce qui est relativement efficace. La RFC 1341 limite en outre la longueur de ligne des base64données codées à 76 caractères pour tenir dans un message SMTP, mais c'est relativement facile à gérer lorsque vous ne faites que fractionner ou concaténer des caractères arbitraires à des longueurs fixes.
Le gros inconvénient est que les base64données codées sont à peu près entièrement illisibles par les humains, même s'il ne s'agit que de texte "clair" en dessous.