Как открыть кодировку передачи контента base64
Многие типы данных, отправляемых по электронной почте, требуют «естественного» представления, то есть 8-битного набора символов или двоичного кода (что то же самое для машины, которая просто отображается для пользователя в противном случае). В таком виде данные нельзя отправлять с помощью 7-битных почтовых протоколов, таких как RFC 821, который также ограничивает длину строки до 1000 символов.
Стандартные механизмы преобразования почты в формат коротких 7- битовые строки, приемлемые для передачи почты, описаны в заголовке поля Content-Transfer-Encoding.
В отличие от типов контента, нет необходимости и желания увеличивать набор значений кодирования передачи контента. Однако введение единого механизма преобразования невозможно. Существует противоречие между желанием эффективно сжимать двоичные данные и желанием преобразовать данные, которые хотя бы частично представляют собой 7-битный текст, чтобы их можно было прочитать. По этой причине необходимы как минимум 2 механизма преобразования: «читабельный» и «затянутый».
Это поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, указывающей тип преобразования, как показано ниже:
Значения нечувствительны к регистру, т.е. Base64, BASE64 и bAsE64 одинаковы. Значение «7BIT» означает, что тело сообщения уже имеет 7-битный формат и не требует дальнейшей обработки для пересылки почты. Это значение используется по умолчанию, если отсутствует поле заголовка кодирования передачи контента.
Значения «8-bit», «7-bit» и «binary» означают, что преобразование контента не выполняется. Однако они сделаны по-разному, чтобы указать, каково содержание письма, а затем обработка, которая может потребоваться для этой транспортной системы. В частности:
«7bit» означает, что данные представляют собой текст, короткие строки и кодировку языка US-ASCII.
«8bit» означает короткие строки , но может содержать не-ASCII-символы (128-255).
«Двоичный» означает, что тело сообщения может содержать не-ASCII-символы, но строки могут быть любой длины, т.е. слишком длинный для транспорта SMTP и может не соблюдать CRLF (конвенция транспорта SMTP).
Хотя на первый взгляд разница в значениях кодирования передачи контента может показаться незначительной; все в конечном итоге означает отсутствие преобразования, но четкая маркировка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и характеристики производительности, количество которых со временем растет.
Спецификация почтового транспорта для отправки незашифрованных сообщений 8- битовые данные указаны в RFC-1426. Однако не существует стандартизированных передач Интернет-сообщений, для которых допустимо включать незакодированные двоичные данные в тело сообщения. Таким образом, «двоичное» значение на самом деле не является законным в Интернете. Но согласно MIME, когда в почтовой системе используется двоичный транспорт, в случае, если вам нужно отправить двоичные данные по электронной почте, вы должны указать это в заголовке поля Content Transfer Encoding.
Пять значений определенные для поля Content Transfer Encoding ничего не говорят о типе контента, кроме указания алгоритма шифрования или требований для передачи почты в случае незашифрованных данных.
Почтовые провайдеры могут определить новые значения для поля Content Transfer Encoding, если это необходимо, но эти значения должны иметь префикс «X-» («x- «), чтобы подчеркнуть их нестандартность. Однако, в отличие от типов и подтипов в поле Content Type, ввод новых значений Content Transfer Encoding настоятельно не рекомендуется, поскольку это может нарушить совместимость почтовой системы. Использование значений X разрешено только по взаимному соглашению между сотрудничающими системами.
Если поле Encoding Content Transfer Code появляется в заголовке основной части электронной почты, оно применяется только к содержимому этой части. Если письмо (часть письма) типа «составное» или «сообщение», то поле Content-Transfer-Encoding может иметь только длину символа («7bit», «8bit» и т.д.) или «двоичный » в качестве его значения.
Необходимо отметить. это электронное письмо ориентировано на символы, поэтому механизмы преобразования обрабатывают данные как поток символов, а не битов. Если поток битов должен быть закодирован с использованием одного из этих механизмов, его необходимо сначала преобразовать в 8-битный поток байтов с использованием стандартного сетевого порядка битов (самые значащие биты последними). Это означает, что начальные биты потока становятся старшими битами байта. Если битовый поток заканчивается неполным байтом, отсутствующие биты дополняются нулями.
Все механизмы кодирования, определенные в спецификации MIME, кодируют любые данные как символы. Так, например, если предположить, что тело электронного письма (часть электронного письма) имеет поле заголовка например:
это означает, что тело письма представляет собой код текстовых данных base64 ASCII, который обычно имеет языковую кодировку ISO-8859-1 и будет в языковой кодировке после декодирования.
весь набор значений, определенных для языка кодирования передачи контента ISO-8859-1, за исключением тех, которые начинаются с префикса «X-», зарезервирован IANA для использования в будущем. Использование частных соглашений о значениях кодирования передачи контента настоятельно не рекомендуется.
Некоторые значения кодирования передачи контента могут использоваться только с определенными типами (поле «Тип контента»). В частности, запрещено использовать любое значение, кроме «7-bit», «8-bit» или «binary» с любым типом, который содержит заголовок рекурсивно с полем типа содержимого (обычно «multipart» и «message» типов). Все кодировки, необходимые для содержимого тела электронной почты, состоящего из нескольких частей, должны создаваться на более низком уровне.
Примечания об ограничениях преобразования
Случаи вложенного кодирования, когда данные проходят через алгоритм преобразования несколько раз и должны декодироваться одинаково, чтобы сделать его читабельным, следует избегать многократного повторения Вложенные кодировки увеличивают сложность пользовательских почтовых программ: помимо очевидных проблем с множественными преобразованиями, они могут скрывать основную структуру письма. В частности, они могут привести к тому, что может потребоваться несколько операций декодирования только для того, чтобы определить, какие типы объектов находятся на письме. сложность самой электронной почты.
ПРИМЕЧАНИЕ ПЕРЕВОДА КОДИРОВАНИЯ: Перечисленные конвертеры для печати и base64 предназначены для простого преобразования данных после применения. Единственный нюанс, который появляется в таком реле, это сигнал об окончании линии. При преобразовании из кавычек в base64 новая строка должна быть заменена последовательностью CRLF. Впоследствии и наоборот, но ТОЛЬКО при преобразовании текстовых данных.
Приведенный механизм преобразования для печати
Этот механизм предназначен для представления данных, состоящих в основном из байтов, соответствующих символам, имеющим изображение в файле ASCII. . В результате такой кодировки все байты будут иметь такие значения, гарантированные от последующей модификации почтовым транспортом. Если преобразуемые данные в основном представляют собой текст ASCII, то окончательная форма по-прежнему распознается и читается человеком. Тело символа ASCII также может быть преобразовано в Quoted-Printable, обеспечивая целостность его содержимого при передаче через любой шлюз, который кодирует языковые символы или разрывы строк и т. д.
В Quoted-Printable байты должны быть вставлены в соответствии со следующими правилами:
ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, за исключением тех, которые используются для обозначения конца строки, может быть представлен двумя шестнадцатеричными цифрами, которым предшествует символ «=». Шестнадцатеричные цифры от A до F должны быть в верхнем регистре. За исключением случаев, когда следующие правила допускают альтернативные кодировки, это правило является обязательным.
ПРАВИЛО №2: (буквенное представление). Десятичные байты с 33 по 60 и с 62 по 126 МОГУТ быть представлены символами ASCII, соответствующий этим значениям (‘!’ to ‘ ‘ to ‘
ПРАВИЛО №3: (Пробелы): байты со значениями 9 и 32 МОГУТ быть представлены как символы ASCII «Tab» и «Пробел», но НЕ ДОЛЖНЫ быть представлены как таковые в конце строки. Если они представлены соответствующими символами ASCII, за ними должен следовать символ с графическим изображением (печатный символ). В конце строки строки, символы табуляции и пробелы должны отображаться в соответствии с правилом №1, так как некоторые почтовые переводы могут удалять пробелы в конце строки.
ПРАВИЛО №4: (Конец строки): Конец строки в теле письма должен быть представлен (согласно RFC 822) последовательностью CRLF, так как каноническое представление не требует текстовых символов в конце строки, Quoted-Printable не использует символы с отображается для обозначения конца строки. Кодировка Base64 предпочтительнее для представления двоичных данных.
Следует отметить, что многие реализации почты могут кодироваться по-разному. Особенно при отображении текста в системах, использующих другое окончание строки. конвенции (т.е. кроме CRLF). Такие реализации не допускаются, и генерация окончаний строк должна быть повсеместно стандартизирована, чтобы не было необходимости распознавать, используется ли какое-то альтернативное представление.
ПРАВИЛО № 5: (мягкий конец строки): Согласно Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется «мягкий» перевод строки, представленный знаком равенства. Например, если исходная строка выглядела так:
, то в кодировке Quoted-Printable это могло быть представлено следующим образом:
Это предоставляет почтовому агенту механизм восстановления исходной длины
Поскольку дефис («-«) отображается в Quoted-Printable обычным способом, необходимо соблюдать особую осторожность. быть взято для закрытия тела в Quoted-Printable составным шрифтом, чтобы граница этого включения нигде не фигурировала в этом включении (обозначение границы лучше всего выбрать в виде последовательности символов «=_», которая никогда не появляется в цитируемом печатном теле.)
ПРИМЕЧАНИЕ: Quoted-Printable является своего рода компромиссом между читаемостью и переносимостью. Тела в Quoted-Printable будут хорошо защищены при прохождении через множество почтовых шлюзов, но могут не пройти через некоторые шлюзы, использующие преобразование EBCDIC. (Теоретически шлюз EBCDIC должен кодировать цитируемое печатное тело с помощью base64, а затем декодировать его, но такого шлюза пока не существует.) Единственный способ добиться действительно надежной передачи через шлюз EBCDIC — экранировать символы ASCII
в соответствии с правилом № 1.
Поскольку данные в Quoted-Printable ориентированы на строки, ожидайте, что передача почты изменит представление разрывов строк в Quoted-Printable так же, как обычный текст может измениться, когда рассылаются по электронной почте между системами. с различными соглашениями для представления концов строк. Если такие изменения могут нарушить целостность данных, то имеет смысл использовать кодировку base64 вместо Quoted-Printable.
Вниманию разработчиков программного обеспечения: если двоичные данные отправленные в Quoted-Printable, вы должны быть осторожны при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как «=0D=0A», иначе, если CRLF означает конец строки, она может быть неправильно понята на платформах с другими соглашениями о конце строки.
Синтаксис данные в quoted-printable описаны ниже:
Механизм преобразования Base64
Этот алгоритм предназначен для представления произвольных последовательностей байтов в удобочитаемой форме. Алгоритмы кодирования и декодирования очень просты, но зашифрованные данные примерно на 33% больше, чем незашифрованные данные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанных в RFC 1421, с одним отличием: base64 не принимает встроенный «обычный» текст.
Base64 использует 65-символьное подмножество US-ASCII. , выделяя 6 бит для каждого печатного символа. (65-й символ «=» используется для обозначения специальной функции обработки.)
ПРИМЕЧАНИЕ: Это подмножество имеет важное свойство идентичности всем версиям кодировки языков ISO 646, включая US ASCII, а также все версии EBCDIC. Другие популярные механизмы кодирования (uuencode, base85, часть PostScript уровня 2) не обладают этими свойствами и, следовательно, не отвечают требованиям переносимости для двоичных данных электронной почты.
В процессе кодирования 4 входных символа преобразуются в группу. из 24 бит и обрабатывает их слева направо. Затем эти группы обрабатываются как 4 конкатенированные группы по 6 бит, каждая из которых преобразуется в одну буквенную цифру с основанием 64. base64, входной поток байтов должен быть отсортирован по MSB.
Каждая 6-битная группа используется в качестве индекса в 64-символьном массиве высокой печати. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны для универсального представления и исключают символы, имеющие особое значение для транспорта SMTP (.»», CR, LF) и для синтаксиса вложенного тела MIME («-«).
Выходной поток (закодированные bfights ) не должно содержать строк длиннее 76 символов. Декодер base64 должен игнорировать все разрывы строк и другие символы, не указанные в таблице 1. Введите данные Base64, символы, не указанные в таблице. 1, новые строки и т. д. должны указывать на ошибку передачи данных, и отправитель должен уведомить об этом пользователя.
Если в хвосте закодированного потока данных осталось менее 24 бит, справа добавляются нулевые биты. пока не будут сформированы целые 6-битные группы. А перед концом 24-битной группы отсутствуют от 0 до 3 6-битных групп, каждая из которых заменяется символом заполнения ‘=’. Поскольку весь входной поток представляет собой целое число 8-битных групп (то есть только байтовые значения), возможны только следующие случаи: (1) входной поток завершается только 24-битной группой. В этом случае выходной поток будет заканчиваться четырьмя символами Base64 без символа ‘=’; (2) конец входного потока имеет длину 8 бит. Тогда в конце выходного кода будет два символа Base64 с добавлением двух символов ‘=’; (3) конец входного потока имеет длину 16 бит. В конце вывода будет три символа Base64 и один символ ‘=’.
Потому что символ «=» является конечным заполнителем, его появление в теле письма может означать только то, что достигнут конец данных. Однако такой гарантии нет, если число передаваемых битов кратно 24.
Любые бессмысленные последовательности Base64, такие как «=====», следует игнорировать.
Если это закодированный текст находится не в канонической форме. то вы должны сначала заменить все окончания строк стандартной последовательностью CRLF перед преобразованием в Base64. Лучше встроить это в кодировщик Base64, чем заставлять пользователя предварительно канонизировать текст другими способами.
При кодировании Base64 нет необходимости экранировать вложенные тела в составном теле, потому что существует нет символа ‘-‘ в кодировке Base64.
Шрифт