При отправке содержимого электронной почты требуется установить заголовок "Копирование содержимого". Я заметил много заголовков писем, которые я получил. Некоторые электронные письма, использующие "7bit", а некоторые используют "8 бит".
В чем разница между этими двумя? Что рекомендуется? Существует ли специальная кодировка, необходимая для тела электронной почты, чтобы установить эти заголовки?
Он может быть немного плотным для чтения, но раздел "Content-Transfer-Encoding" RFC 1341 содержит все детали:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
Ситуация вроде бы идет от плохого к худшему. Здесь мое резюме:
SMTP, по определению (RFC 821), ограничивает почту линиями длиной 1000 символов по 7 бит. Это означает, что ни один из байтов, которые вы отправляете по каналу, может иметь самый значительный ( "самый высокий" ) бит, установленный в "1" .
Содержимое, которое мы хотим отправить, часто не подчиняется этому ограничению по своей сути. Подумайте о файле изображения или текстовом файле, который содержит символы Unicode: байты этих файлов часто будут иметь свой 8-й бит, установленный в "1" . SMTP не позволяет этого, поэтому вам нужно использовать "кодирование передачи", чтобы описать, как вы работали вокруг несоответствия.
Значения заголовка Content-Transfer-Encoding описывают правило, которое вы выбрали для решения этой проблемы.
7bit просто означает: "Мои данные состоят только из символов US-ASCII, которые используют только более низкие 7 бит для каждого символа". Вы в основном гарантируете, что все байты вашего контента уже соответствуют ограничениям SMTP и поэтому не требуют специального лечения. Вы можете просто прочитать его как есть.
Обратите внимание, что при выборе 7bit вы соглашаетесь с тем, что все строки в вашем контенте имеют длину менее 1000 символов.
Пока ваше содержание придерживается этого правила, 7bit - лучшая кодировка передачи, поскольку нет необходимости в дополнительной работе; вы просто читаете/записываете байты, когда они выходят из трубы. Это также легко освещает контент и понимает его. Идея здесь в том, что, если вы просто пишете в "простом английском тексте", все будет в порядке. Но что не было правдой в 2005 году, и сегодня это не так.
8bit означает: "Мои данные могут содержать расширенные символы ASCII, они могут использовать 8-й (старший) бит, чтобы указать специальные символы за пределами стандартных 7-битных символов US-ASCII". Как и в случае с 7bit, существует лимит на 1000 символов.
8bit, точно так же, как 7bit, фактически не делает никакого преобразования байтов, поскольку они записаны или прочитаны из провода. Это просто означает, что вы не гарантируете, что ни один из байтов не будет иметь старший бит, установленный в "1" .
Это похоже на шаг от 7bit, поскольку он дает вам больше свободы в вашем контенте. Однако RFC 1341 содержит этот лакомый кусочек:
Начиная с публикации этого документа, нет стандартизированных интернет-трансферов, для которых законно включать некодированные 8-битные или двоичные данные в почтовые службы. Таким образом, нет никаких условий, при которых "8-битное" или "двоичное" кодирование контента-передачи фактически является законным в Интернете.
RFC 1341 вышел более 20 лет назад. С тех пор мы получили 8bit MIME Extensions в RFC 6152, Но даже тогда лимитные лимиты все еще могут применяться:
Обратите внимание, что это расширение НЕ исключает возможности ограничения длины линии SMTP-сервера; серверы могут реализовать это расширение, но тем не менее установить ограничение длины строки не менее 1000 октетов.
binary совпадает с 8bit, за исключением того, что ограничение длины строки отсутствует. Вы все равно можете включать любые символы, которые вы хотите, и нет никакой дополнительной кодировки. Подобно 8bit, RFC 1341 заявляет, что это действительно не законная кодировка передачи кодировки. RFC 3030 расширил это с помощью BINARYMIME.
До расширения 8BITMIME должен быть способ отправить контент, который не может быть 7bit поверх SMTP. Хорошими примерами являются HTML файлы (которые могут содержать более 1000 символов) и файлы с международными символами. Кодирование quoted-printable (определено в разделе 5.1 RFC 1341) предназначено для обработки этого. Он выполняет две функции:
Quoted Printable, из-за экранирующих и коротких строк, гораздо труднее читать человеком, чем 7bit или 8bit, но он поддерживает гораздо более широкий диапазон возможного контента.
Если ваши данные в основном нетекстовые (например: файл изображения), у вас нет многих опций. 7bit находится вне таблицы. 8bit и binary не поддерживались до RFC-расширений MIME. quoted-printable будет работать, но действительно неэффективен (каждый байт будет представлен 3 символами).
base64 является хорошим решением для данных такого типа. Он кодирует 3 необработанных байта в виде 4 символов US-ASCII, что относительно эффективно. RFC 1341 дополнительно ограничивает длину строки base64 -кодированных данных до 76 символов для соответствия в SMTP-сообщении, но это относительно простое управление, когда вы просто разбиваете или конкатенируете произвольные символы с фиксированными длинами.
Большой недостаток заключается в том, что base64 -кодированные данные почти полностью не читаются людьми, даже если это просто "простой" текст внизу.