Кодирование передачи контента 7 бит или 8 бит

Question

При отправке содержимого электронной почты необходимо установить заголовок "Content Transfer Encoding". Я наблюдал много заголовков писем, которые я получил. Некоторые письма используют "7bit", а некоторые используют "8bit".

В чем разница между этими двумя? Что рекомендуется? Требуется ли какая-либо специальная кодировка тела письма для установки этих заголовков?

Answer 1

Это может быть немного плотным для чтения, но раздел "Content-Transfer-Encoding" RFC 1341 содержит все детали:

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

Ситуация вроде ухудшается. Вот мое резюме:

Фон

SMTP, по определению (RFC 821), ограничивает почту линиями по 1000 символов по 7 бит в каждой. Это означает, что ни один из байтов, которые вы отправляете по каналу, не может иметь бит старшего значащего ("высшего порядка"), установленный в "1".

Контент, который мы хотим отправить, часто не подчиняется этому ограничению по своей сути. Подумайте о файле изображения или текстовом файле, который содержит символы Unicode: для байтов этих файлов часто будет установлен восьмой бит, равный "1". SMTP не позволяет этого, поэтому вам нужно использовать "кодировку передачи", чтобы описать, как вы работали с несоответствием.

Значения для Content-Transfer-Encoding В заголовке опишите правило, которое вы выбрали для решения этой проблемы.

7-битное кодирование

7bit просто означает "Мои данные состоят только из символов US-ASCII, которые используют только младшие 7 битов для каждого символа". Вы в основном гарантируете, что все байты в вашем контенте уже придерживаются ограничений SMTP, и поэтому он не требует особой обработки. Вы можете просто прочитать это как есть.

Обратите внимание, что когда вы выбираете 7bit, вы соглашаетесь с тем, что все строки в вашем контенте имеют длину менее 1000 символов.

Пока ваш контент придерживается этих правил, 7bit является наилучшей кодировкой передачи, поскольку нет необходимости в дополнительной работе; Вы просто читаете / пишете байты, когда они выходят из конвейера. Это также легко для глаз 7bit содержание и смысл этого. Идея в том, что если вы просто пишете "простым английским текстом", все будет в порядке. Но это было не так в 2005 году, и это не так сегодня.

8-битное кодирование

8bit означает "Мои данные могут включать расширенные символы ASCII; они могут использовать 8-й (старший) бит для обозначения специальных символов вне стандартных 7-разрядных символов US-ASCII". Как с 7bit, до сих пор есть ограничение в 1000 символов.

8bit, как 7bit, на самом деле не выполняет никаких преобразований байтов, когда они записываются или читаются с провода. Это просто означает, что вы не гарантируете, что ни один из байтов не установит для старшего бита значение "1".

Это похоже на шаг вперед от 7bit, поскольку это дает вам больше свободы в вашем контенте. Тем не менее, RFC 1341 содержит этот кусок:

На момент публикации этого документа не было стандартизированных Интернет-транспортов, для которых было бы законно включать незашифрованные 8-битные или двоичные данные в почтовые тела. Таким образом, нет обстоятельств, при которых "8-битное" или "двоичное" Content-Transfer-Encoding действительно является законным в Интернете.

RFC 1341 вышел более 20 лет назад. С тех пор мы получили 8-битные расширения MIME в RFC 6152. Но даже тогда, ограничения линии все еще могут применяться:

Обратите внимание, что это расширение НЕ устраняет возможность ограничения длины SMTP-сервера; Серверы могут свободно реализовывать это расширение, но, тем не менее, устанавливают ограничение длины строки не менее 1000 октетов.

Двоичное кодирование

binary такой же как 8bitза исключением того, что нет ограничения по длине строки. Вы по-прежнему можете включать любые символы, которые вы хотите, и нет никакой дополнительной кодировки. Похожий на 8bit, RFC 1341 утверждает, что это не совсем допустимая кодировка передачи кодирования. RFC 3030 расширил это BINARYMIME,

Цитируется для печати

Перед 8BITMIME расширение, должен быть способ отправки контента, который не может быть 7bit через SMTP. HTML-файлы (которые могут содержать более 1000 символов) и файлы с международными символами являются хорошими примерами этого. quoted-printable кодирование (определено в разделе 5.1 RFC 1341) предназначено для этого. Это делает две вещи:

• Определяет, как экранировать символы не-US-ASCII, чтобы они могли быть представлены только в 7-битных символах. (Краткая версия: они отображаются как знак равенства плюс два 7-битных символа.)
• Определяет, что строки будут не длиннее 76 символов, а разрывы строк будут представлены специальными символами (которые затем экранируются).

Цитируемый для печати, из-за коротких строк, гораздо труднее читать человеку, чем 7bit или же 8bit, но он поддерживает гораздо более широкий диапазон возможного контента.

Base64 кодирование

Если ваши данные в основном не текстовые (например, файл изображения), у вас не так много вариантов. 7bit со стола 8bit а также binary не были поддержаны до расширения RFC MIME. quoted-printable будет работать, но на самом деле неэффективно (каждый байт будет представлен 3 символами).

base64 хорошее решение для этого типа данных. Он кодирует 3 необработанных байта как 4 символа US-ASCII, что относительно эффективно. RFC 1341 дополнительно ограничивает длину линии base64-кодированные данные в 76 символов для размещения в SMTP-сообщении, но это относительно просто для управления, когда вы просто разделяете или объединяете произвольные символы фиксированной длины.

Большим недостатком является то, что base64закодированные данные практически полностью нечитаемы людьми, даже если это просто "простой" текст внизу.

Answer 2

С Content-Transfer-Encoding: 7bit байты, которые используются в теле (или, точнее, в границах части), должны представлять символы ascii, но не символы расширенного ascii. Это означает десятичное число 0-127 (8-й бит не используется).

Поскольку 8-й бит не используется, это означает, что вы не можете кодировать свой текст с помощью или байтов, потому что они используют 8-й бит. Вы также не можете добавить двоичный контент.

С Content-Transfer-Encoding: 8bit вы можете использовать любой возможный байт, что означает, что вы можете кодировать свой текст, используя байты или iso8859-7байт (оба предполагают, что 8BITMIMEрасширение используется в SMTP). Однако вы по-прежнему небезопасны при добавлении двоичного содержимого из-за ограничения максимальной строки, которое все еще применяется, что может привести к разрыву ваших байтов с новыми строками.

Теперь даже с 7-битным кодированием передачи контента вы все равно можете установить content-typeх charsetпараметр для utf-8пока вы все еще держите свои байты между границами 0-127.

Например, возможный способ представления символов вне ascii с использованием кодирования передачи содержимого может заключаться в использовании символов кода html (с content-type: text/html)

Многие почтовые клиенты устанавливают content-transfer-encodingили в зависимости от случая. Например 7bitпри отправке английского текста, 8bitпри отправке многоязычного текста. И всегда есть варианты quoted-printableа также base64чьи символы также не используют 8-й бит, но это выходит за рамки вопроса.