MIME - "Multipurpose Internet Mail Extensions" (Многоцелевые расширения почтового стандарта Internet). Этот стандарт описывает правила пересылки по электронной почте исполняемых, графических, мультимедийных, смешанных данные и просто текстовых файлов, то есть, когда необходимо, чтобы при пересылке не производилось никаких преобразований над данными.
Следует отметить, что еще существуют старые почтовые клиентские программы, которые не понимают MIME. Однако, большинство почтовых клиентов, имеют встроенную поддержку MIME: одна из самых первых и популярных - "Pine", разработанная в Вашингтонском университете и реализованная для платформ UNIX, VMS, DOS, Windows; а также почтовые клиенты Netscape Navigator и MSIE (Outlook Express).
Для некоторых почтовых систем имеются специальные шлюзы, обеспечивающие MIME-трансляцию. Но даже если у вас нет возможности использовать MIME-совместимую почтовую программу и нет доступа к подобному шлюзу, то можно также воспользоваться рядом программ, способных интерпретировать письма в MIME, сохраненные почтовой программой в файле. Например, программа "munpack", созданная в университете Carnegie Mellon. Существуют ее версии для Unix, PC, Macintosh, Amiga.
Долгое время для кодирования бинарных файлов в 7-битный формат (чтобы обеспечить их пересылку по почтовой системе Internet) использовалась кодировка UUENCODE, имеющая ряд технических ограничений. Стандарт MIME предполагает использование более устойчивой кодировки "Base64", которая специально разработана для обеспечения сохранности данных, пересылаемых по email, при различных преобразованиях, имеющих место в ходе прохождения почтовых шлюзов.
Стандарт MIME полностью описан в RFC 1521
Со времени опубликования в 1982 г., стандарт RFC 822 определил и полностью или частично внедрил формат текстовых писем в почтовой системе Internet. Но с расширением его использования, обнаружился ряд ограничений, заметно ограничивающих удовлетворение пользовательских потребностей. В частности, возможность пересылки нетекстовых данных, например, аудио и графики, посто не была упомянута в RFC822, описывавшем лишь формат текстовых сообщений. И даже в случае текста, RFC 822 обошел вниманием нужды пользователей, использующих расширенный набор символов, что характерно для азиатских и большинства европейских языков. Итак, требовалась дополнительная спецификация. Основное ограничение RFC822 - относительно короткие строки и 7-битная символьная таблица. Пользователям для отправки нетекстовых данных приходилось конвертировать тело своего письма в 7-битную форму с помощью UUENCODE, BINHEX и др.
Более очевидными стали ограничения RFC 822 при разработке почтовых шлюзов между хостами, использующими стандарт RFC822 и хостами, использующими стандарт X.400. X.400 имеет механизмы для включения нетекстовых данных в тело письма. В настоящее время стандарты для перевода почтовых сообщений из X.400 в RFC822 предполагают, что нетекстовые части тела письма должны быть сконвертированы (но не закодированы) в ASCII формат, либо должны быть "выброшены" из письма с уведомлением об этом получателя. А потеря информации крайне не желательна для пользователя.
MIME разработан как расширяемый механизм с расчетом на то, что набор пар content-type/subtype будет расти со временем. Некоторые другие поля заголовка MIMЕ, включая имена наборов символов, также , вероятно, получат большее число возможных значений. С этой целью MIME определяет процесс регистрации через Internet Assigned Numbers Authority (IANA), как центр регистрации этих значений. Описание процесса регистрации можно найти в приложении E RFC 1521.
2. Замечания, соглашения и обобщения
Термины "сообщение" и "письмо" являются синонимами. Термин "часть письма" или "часть тела письма" подразумевает одну из частей письма, разбитого на части разных типов данных. Часть тела письма, в свою очередь, имеет тело и заголовок, так что имеет смысл говорить о теле части тела письма. В дальнейшем, при отсутствии оговорок, "телом" будем называть тело рассматриваемого в данный момент объекта - части письма либо всего письма. Как уже ясно, формат MIME-сообщения, в общем случае, рекурсивен.
3. Поле заголовка "MIME-Version"
Поскольку старый стандарт RFC 822 все еще используется, а MIME возможно, изменится и дополнится в будущем, почтовой программе необходимо знать, применен ли новый стандарт в конкретном письме или нет. Поэтому в заголовок введено новое поле "MIME-Version", объявляющее версию стандарта, в соответствии с которым написано данное письмо.
Все почтовые сообщения, составленные в соответствии с MIME-стандартом, должны иметь это поле в своем заголовке, напрмер:
MIME-Version: 1.0
Так как возможно, в будущем формат заголовка письма может расшириться, формально содержание поля "MIME-version" дается следующим образом:
версия := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Т.о., будущие значения версии формата, которые могут заменить "1.0", должны быть целыми числами, разделенными точкой. Если письмо получено со значением версии MIME, отличным от "1.0", оно не будет рассматриваться почтовой программой, как соответствующее данной спецификации.
Важно, что поле заголовка "MIME-Version", должно располагаться в самам начале письма. Это не обязательно для каждой из частей тела письма в случае многочастевого письма, но обязательно для заголовков частей типа "message", если и только если эта часть сама по себе декларирована как соответствующая спецификации MIME.
Не возможно полностью определить как почтовая программа, поддерживающая MIME, должна интерпретировать письмо, имеющее значение MIME-version, отличное от "1.0". Но, как минимум, почтовая программа должна предупредить пользователя о том, что письмо написано в незнакомом ей формате.
Все поля заголовка, включая MIME-Version, Content-type, и т.д., должны соответствовать общим синтаксическим правилам, определенным в RFC 822. В частности, допускается включение комментариев (т.е., следующие 2 примера эквивалентны):
MIME-Version: 1.0 MIME-Version: 1.0 (Generated by GBD-killer 3.7)4. Поле заголовка "Content-Type"
Назначение этого поля - наиболее полное описание данных, содержащихся в теле, с тем, чтобы почтовый агент (программа) получателя могла выбрать соответствующий механизм для их обработки. Впервые это поле было определено в RFC 1049, но имело более простой синтаксис.
Данное поле включает в себя идентификаторы типа и подтипа, а также может содержать некоторую вспомогательную информацию, которая может потребоваться для конкретного типа данных. После идентификаторов типа и подтипа оставшаяся часть поля - просто набор параметров, заданных в порядке "атрибут/значение". Набор параметров зависит от типа данных. (В частности, не может быть глобально-значимых параметров, справедливых сразу для всех типов содержимого тела письма. Глобальные механизмы в MIME-модели реализованы с помощью введения дополнительных полей "Content-*"). Очередность параметров значения не имеет. В числе определенных параметров - "charset", декларирующий символьный набор (кодировку, кодовую страницу - это все синонимы) тела письма. Комментарии допускаются.
Вообще, поле Content-Type самого верхнего уровня используется для объявления общего типа данных, в то время как подтип определяет специальный формат для данных этого типа. Так, значение "image/xyz" поля Content-Type сообщает пользовательской программе, что данные являются графическим изображением (image), даже если эта почтовая программа не имеет понятия о специальном формате "xyz" этой картинки. Но эта информация может быть использована программой, например, чтобы решить, показывать ли пользователю строковые данные неизвестного подтипа -- показ таких данных может быть оправдан для незнакомых подтипов текста, но не для незнакомых подтипов графики, аудио или видео. По этой причине, данные зарегистрированного подтипа аудио, графики, текста или видео не должны содержать внутри себя части другого подтипа - для содержания в письме данных одного типа, но разных подтипов следует использовать тип "multipart" или "application".
Хотя многие параметры (модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр "boundary" применим только с типом "multipart", а параметр "charset" может использоваться с несколькими типами).
Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться засчет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегистрированный тип содержимого, ему должно быть дано имя, начинающееся с "X-", чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.
Правильное заполнение поля Content-Type:
содержимое := "Content-Type" ":" тип "/" подтип *(";" параметр)
; нечувствительное к регистру букв задание типа и подтипа
тип := "application" / "audio"
/ "image"/ "message"
/ "multipart" / "text"
/ "video"/ признак нестандартного типа
; Все значения нечувствительны к регистру букв
признак нестандартного типа := x- / iana-
iana- := <общепринятый признак расширения, зарегистрированный соответ-
ственно приложению "E" RFC 1521>
x- := <Два последовательных символа "X-" или "x-", без пробела
или другого символа между ними>
подтип := слово ; регистр безразличен
параметр := атрибут "=" значение
атрибут := слово; регистр безразличен
значение := слово / строка в кавычках
слово := любые ASCII-символы кроме пробелов, Ctrl-последова-
тельностей и специальных символов
Специальные символы:= "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
; Эти символы используются в строке значений параметров
Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов "/", "?", "=" и отсутствием символа ".".
Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными - в зависимости от параметра. Например, значения границ multipart-письма являются чувствительными, а значение "access-type" для message/External-body не является.
Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:
Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:
text -- текстовая информация. Основой подтип - "plain" - соответствует обычному неформатированному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуализацию, но для понимания идеи содержания можно обойтись и без дополнительного ПО. Возможные подтипы могут описывать легко читаемые форматы различных текстовых процессоров.
multipart -- содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимо независимых типов. Изначально определено четыре подтипа:
message -- письмо в письме. Тело,
содержащее данные типа "message", само является письмом или частью
письма, полностью отформатированного в соответствии со стандартом
RFC 822, которое, в свою очередь, может содержать свое собственное
поле заголовка "Content-Type".
Подтипы:
image -- графические данные. Графика требует соответствующего устройства вывода (графический дисплей, принтер, факс) для отображения своей информации. Изначально определены два подтипа для наиболее распространенных графических форматов - jpeg и gif.
audio -- звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип - "basic".
video -- видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единственный изначально определенный подтип - "mpeg".
application -- как правило,
не интерпретируемый двоичный код либо информация, предназначенная для
обработки почтовой программой.
Подтипы:
По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как "Content-type: text/plain; charset=us-ascii". Это значение полагается, если поле Content-type не определено. Поэтому почтовая программа получателя может неверно истолковать содержимое письма, если при отправке не было указано поле Content-type, но на самом деле текст письма имеет другую кодировку или даже тип.
При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip'ом и обработанный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. "text/plain; charset=us-ascii".
Необходимо учесть, что в будущем ожидается заметное
увеличение числа регистрированных типов и особенно подтипов
содержимого писем. Если почтовая программа встретит неизвестное ей
значение поля Content-type, она должна интерпретировать содержимое
этого письма как "application/octet-stream" (см.выше).
5. Поле заголовка Content-Transfer-Encoding
Многие типы данных, пересылаемых через email требуют "натурального" представления, то есть, 8-битный набор символов либо двоичный код (что для машины - одно и то же, только представимо для пользователя по-разному). В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.
Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлимый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.
В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно "ужать" бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: "читабельный" и "плотно ужимающий".
Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже:
конвертация := "Content-Transfer-Encoding" ":" механизм механизм := "7bit" ; / "quoted-printable" / "base64" / "8bit" / "binary" / x-token
Значения не чувствительны к регистру букв, то есть, Base64, BASE64 и bAsE64 - одно и то же. Значение "7BIT" означает, что тело письма уже имеет 7-битный формат и не требует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.
Значения "8bit", "7bit" и "binary" означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы. В частности:
"7bit" означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.
"8bit" означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).
"Binary" означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может не соблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.
Хотя на первый взгляд разница в значениях Content-Transfer-Encoding может показатся неважной - ведь все они означают, что никакого преобразования нет, но четкая разметка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и особенности работы, число которых со временем растет.
Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованных транспортов почты Internet, для которых является приемлимым включение в тело письма некодированных двоичных данных. Таким образом, значение "binary" фактически не является легальным в Internet. Но в соответствии с MIME, при использовании почтовой системой транспорта, умеющего работать с двоичными данными, в случае, когда необходимо послать двоичные данные по e-mail, необходимо указать это в заголовке в поле Content-Transfer-Encoding.
Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.
Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс "X-" ("x-"), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем. Использование X-значений позволяется только как результат взаимосоглашения между взаимодействующими системами.
Если поле Content-Transfer-Encoding появляется в заголовке тела какой-то части письма, оно применяется только к содержимому этой части. Если письмо (часть письма) имеет тип "multipart" или "message", то поле Content-Transfer-Encoding может иметь в качестве своего значения только длину символа ("7bit", "8bit" и т.д.) или "binary".
Необходимо заметить. что электронная почта является символьно-ориентированной, так что механизмы конвертации работают с данными как с потоком символов, а не битов. Если битовый поток должен быть кодирован посредством какого-либо из этих механизмов, сначала он должен быть конвертирован в 8-битный поток байтов, используя порядок битов, стандартный для сетей (старшие разряды в конце). То есть, передние биты в потоке становятся битами высшего порядка в байте. Если битовый поток оканчивается неполным байтом, недостающие разряды заполняются нулями.
Все кодирующие механизмы, определенные в спецификации MIME, кодируют любые данные в символьную форму. Так, к примеру, полагая, что тело письма (части письма) имеет поля заголовка вроде:
Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64
то это означает, что тело письма представляет собой ASCII-код base64 текстовых данных, которые в нормальном виде имеют языковую кодировку ISO-8859-1, и будут в этой языковой кодировке после декодирования.
Все множество определенных значений поля content-transfer-encoding кроме начинающихся с префикса "X-", зарезервировано в IANA для будущего использования. Частные соглашения по значениям content-transfer-encoding также настоятельно не рекомендуются.
Некоторые значения Content-transfer-encoding могут использоваться только с определенными типами (поле Content-Type). В частности, запрещено использовать любые значения кроме "7bit", "8bit", или "binary" с любым типом, рекурсивно включающим заголовки с полем Content-Type (как правило, это типы "multipart" и "message"). Все кодирования, необходимые для содержимого тел многочастного письма должны быть произведены на более низком уровне.
Замечания по ограничениям конвертации:
Необходимо предотвращать случаи вложенного кодирования, когда данные проходят через алгоритм конвертации несколько раз и должны столько же раз быть декодированы, чтобы быть читаемыми. Вложенное кодирование добавляет сложностей пользовательским почтовым программам: кроме очевидных проблем с множественной конвертацией, они могут скрыть основную структуру письма. В частности, они могут привести к тому, что несколько операций по декодированию могут потребоваться только для того, чтобы определить, объекты каких типов находятся в письме. Запрещение вложенного кодирования может осложнить работу некоторых почтовых шлюзов, но это будет меньшей проблемой по сравнению с трудностями для пользовательских почтовых программ.
ЗАМЕЧАНИЕ ПО ПЕРЕВОДУ КОДОВ: Конверторы quoted-printable и base64 разработаны так, что данные после их применения легко взаимоконвертируемы. Единственный нюанс, возникающий в подобной ретрансляции - признак конца строки. При конвертации из quoted-printable в base64 перевод строки должен быть заменен последовательностью CRLF. Соответственно и наоборот, но ТОЛЬКО при конвертации текстовых данных.
5.1. Механизм конвертации "Quoted-Printable"
Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе ASCII. В результате данного кодирования все байты будут иметь такие значения, гарантированные от дальнейшей модификации почтовым транспортом. Если конвертируемые данные в основном представляют собой ASCII-текст, то конечная их форма остается узнаваемой и читаемой для человека. Тело, полностью состоящее из ASCII-символов, также может быть конвертировано в Quoted-Printable, что гарантирует его содержимому целостность при прохождении через всякие шлюзы, в которых происходит языковая перекодировка символов или преобразование концов строк и т.д.
В Quoted-Printable байты должны быть представлены в соответствии со следующими правилами:
ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предваряемых знаком "=". При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.
ПРАВИЛО #2: (Буквенное представление). Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с '!' по '<' и с '>' по '~').
ПРАВИЛО #3: (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы "Табуляция" и "Пробел", но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.
ПРАВИЛО #4: (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF. Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.
Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлении текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.
ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется 'мягкий' перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:
Now's the time for all folk to come to the aid of their country.
то в Quoted-Printable encoding он может быть представлена следующим образом:
Now's the time = for all folk to come= to the aid of their country.
Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовым агентом.
Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)
ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует). Единственный способ добиться действительно надежной транспортировки через EBCDIC-шлюз - экранировать ASCII-символы
!"#$@[\]^`{|}~
в соответствии с правилом #1.
Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.
Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.
Синтаксис данных в quoted-printable описывается следующим образом:
quoted-printable := ([*(простой текст / ПРОБЕЛ / ТАБУЛЯЦИЯ) простой текст] ["="] CRLF) ; Максимальная длина строки - 76 символов, включая CRLF простой текст := байт /<любой ASCII-символ "=", ПРОБЕЛ или ТАБУЛЯЦИЯ> ; символы, не перечисленные в приложении B к RFC 1521 как безопас- ; ные для почты, также не рекомендуются к использованию байт := "=" 2(ЦИФРА / "A" / "B" / "C" / "D" / "E" / "F") ; байт используется для символов > 127, =, ПРОБЕЛ, или ТАБУЛЯЦИЯ, ; и рекомендуется для представления любых символов, не перечислен- ; ных в приложении B к RFC 1521 как безопасные для почты5.2. Механизм конвертации Base64
Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлет встроенного "чистого" текста.
Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ "=" используется для обозначения функции спец. обработки).
ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 - часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.
Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.
Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта (".", CR, LF) и для синтаксиса вложенных тел MIME ("-").
Таблица 1: Алфавит Base64 Значение Код Значение Код Значение Код Значение Код 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w = (заполнитель) 15 P 32 g 49 x 16 Q 33 h 50 y
Выходной поток (закодированные байты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.
Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель '='. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа '='; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода будут два символа Base64, с добавлением двух символов '='; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ '='.
Т.к. символ '=' является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.
Любые бессмысленные последовательности в коде Base64 вроде "=====" должны быть игнорированы.
Если кодируемый текст не находится в канонической форме. то перед конвертацией в Base64 необходимо сначала все концы строк заменить стандартной последовательностью CRLF. Предпочтительнее эту функцию встроить в кодировщик Base64, нежели заставлять пользователя производить предварительную канонизацию текста другими средствами.
Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ '-'.
6. Дополнительные Content- поля заголовка
6.1. Необязательное поле Content-ID
При создании почтового агента верхнего уровня может быть желательно позволить одному телу иметь ссылку на другое. Для этого поля могут быть помечены с помощью поля заголовка "Content-ID", синтаксически идентичного полю "Message-ID":
идентификатор := "Content-ID" ":" идентификатор письма
Как и значения поля Message-ID, значения поля Content-ID должны быть абсолютно уникальными (для всего мира).
Такой идентификатор может быть использован для идентификации тела письма (части письма) в нескольких контекстах, в частности, для кэширования данных, указываемых с помощью механизма message/external-body. Хотя поле Content-ID является необязательным в общем случае, его использование необходимо в реализациях, генерирующих данные, имеющие дополнительный тип "message/external-body" (поле Content-type). Каждое тело такого типа должно обязательно иметь в своем заголовке поле Content-ID для обеспечения ссылки на такие данные.
Значение поля Content-ID имеет специальную семантику в случае типа multipart/alternative. (См. соотв. пункт).
6.2. Необязательное поле Content-Description
Возможность ассоциировать некоторую описательную информацию с данными часто очень желательна. например, может быть полезным описать тело, содержащее графическое изображение, как "a picture of the Space Shuttle Endeavor." Этот текст и может быть помещен в поле заголовка Content-Description.
описание := "Content-Description" ":" *текст
Описание должно иметь языковую кодировку US-ASCII, хотя механизм, определенный в RFC-1522 может быть использован для не-US-ASCII значений.
7. Предопределенные значения поля Content-Type
Тип 'text' предназначен для пересылки текстовых материалов. Это значение поля - по умолчанию. Для обозначения языковой кодировки текста используется параметр "charset" для некоторых подтипов, включая основной подтип, "text/plain", соответствующий простому (неформатированному) тексту. В Internet'овской почте значением Content-Type по умолчанию является следующее: "text/plain; charset=us-ascii". Если текст является размеченным и нет соответствующего ПО для корректного визуального представления этого текста пользователю, имеет смысл сообщить ему подтип этих текстовых данных.
В отличие от других значений, значения этого параметра не являются чувствительными к регистру букв.
Спецификации любых новых подтипов типа 'text' должны определять, будет ли этот новый подтип использовать параметр "charset" либо наоборот, будет запрещать его использование. Любое тело, не содержащее внутри себя других, должно целиком быть в одной языковой кодировке. В частности, создатели новых подтипов должны уделить внимание многбайтным символьным наборам.
Дополнительно к предопределенным новые языковые кодировки могут быть зарегистрированы через IANA, хотя стандартизация их использования требует апробирования IESG (см. RFC-1340). Если используется 8-битная языковая кодировка (например, koi8 или cp866), то необходимо наличие поля заголовка Content-Transfer-Encoding для обеспечения передачи через ряд протоколов, в частности, SMTP.
Необходимо заметить, что управляющие символы (0-31, 127), включая DEL, не имеют определенного значения за исключением последовательности CRLF (13,10), означающей конец строки. Два символа де-факто широко употребляются: FormFeed (12), означающий, что следующий за ним текст должен начинаться на новой странице; и TAB (9), часто, но не всегда означающий "перевести курсор на следующий ближайший столбец после данной позиции, где номер столбца кратен восьми". Любое другое использование управляющих символов или DEL в теле должно быть в рамках частного соглашения между отправителем и получателем. Но такие соглашения крайне не рекомендуются и по возможности должны быть заменены другими возможностями MIME.
Существует огромное количество языковых кодировок, что не является положительным фактом. В дальнейшем предполагается ввести универсальную многобитную языковую кодировку, поддерживающую все языки мира. К сожалению, существующая практика говорит о том, что возможно, еще долгое время электронной почте придется иметь дело с многими кодировками. По этой причине предопределены имена для наиболее распространенных языковых кодировок:
Параметр "charset" был определен в основном для текстовых данных, но возможно, для бинарных данных тоже может потребоваться указать языковую кодировку, в этом случае должен использоваться тот же синтаксис те же значения.
Почтовое программное обеспечение должно руководствоваться принципом наименьшего набора символов, то есть, если письмо пишется как-бы в восьмибитной ISO-8859-1, но в письме используются символы лишь некоторого поднабора, например, семибитного US-ASCII, то почтовая программа должна автоматически определить имя символьной кодировки как US-ASCII. В этом случае уменьшится нагрузка в сети и увеличатся шансы, что получатель прочтет письмо без искажений.
Это основной подтип, соответствующий простому (неформатированному) тексту. Значение поля Content-Type для почты Internet по умолчанию - "text/plain; charset=us-ascii". Это тип данных, соответствующий RFC 822.
Других предопределенных подтипов для типа 'text' нет.
Формальный синтаксис для типа 'text':
тип := "text" "/" подтип [";" "charset" "=" имя языковой кодировки] подтип := "plain" / расширение (не предопределенный подтип) имя языковой кодировки:= "us-ascii"/ "iso-8859-1"/ "iso-8859-2" / "iso-8859-3" / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6" / "iso-8859-7" / "iso-8859-8" / "iso-8859-9" / расширение (не предопределенная кодировка)7.2. Тип 'multipart'
Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтекс письма RFC 822 (то есть, иметь заголовок,ь пустую строку и тело), но должна иметь открывающую и закрывающую границы.
Часть письма не должна интерпретироваться как настоящее письмо RFC 822. Вообще, для части письма наличие заголовка не обязательно, так что она может начинаться и с пустой строки, но при этом, все признаки, описываемые в заголовке, имеют значение по умолчанию. Для частей письма имеют смысл только поля, описывающие содержимое, то есть. начинающиеся с "Content-". Все остальные поля, необходимые в заголовке верхнего уровня, обычно игнорируются в частях письма при обработке почты, более того, в некоторых почтовых шлюзах они могут быть просто удалены. Для экспериментальных и частных целей могут использоваться "X-" поля, но информация, в них заложенная, может быть потеряна при прохождении некоторых почтовых шлюзов.
ЗАМЕЧАНИЕ: Различие между письмом RFC 822 и частью письма MIME является маленькой, но важной. Шлюз между почтой Internet и X.400, например, должен иметь возможность отличить часть письма, содержащую графическое изображение, от части письма, содержащей вложенное письмо, телом которого является графическое изображение. Для представления последнего соответствующая часть письма должна иметь "Content-Type: message" и ее тело после пустой строки должно являться вложенным письмом со своим собственным полем заголовка "Content-Type: image". Схожесть синтаксиса обеспечивает легкость конверсии от письма к части письма, но различие между ними должно быть усвоено производителями ПО.
Граница части письма не должна появляться внутри самой части письма.
Все существующие и будущие подтипы типа "multipart" должны иметь идентичный синтаксис. Они могут различаться своей семантикой. Это требование гарантирует, что совместимые пользовательские агенты смогут по крайней мере распознать и разделить части многочастного письма, даже имеющего неизвестный им подтип.
Как упомянуто в определении поля Content-Transfer-Encoding, использование других значений кроме "7bit", "8bit" или "binary" запрещено для типа "multipart". Почтовые шлюзы и другие почтовые агенты часто вносят изменения в заголовки верхнего уровня. В частности, они могут добавлять, убирать, переупорядочивать определенные поля. Такие изменения запрещены для заголовков частей письма, находящихся внутри тела типа "multipart".
7.2.1. Multipart: общий синтаксис
Поле Content-Type многочастного письма требует одного параметра, "boundary", который определяет границы вложения. Границей является строка, состоящая из двух символов "-" (десятичный код 45) и значения параметра 'boundary' из поля заголовка Content-Type.
ЗАМЕЧАНИЕ: Два символа "-" используются для совместимости с более ранним методом вложения писем, описанным в RFC 934 и для облегчения поиска границ. Однако, многочастные письма MIME не полностью совместимы с RFC 934; в частности, они не подчиняются соглашению RFC 934 по экранированию строк символом "-", так как с каждым новым уровнем экранирования длина строк увеличивается. А поскольку SMTP-транспорты часто обрезают длинные строки, этот механизм становится неприменимым в случае многоуровневой структуры письма типа 'multipart'.
ВНИМАНИЮ ПРОИЗВОДИТЕЛЕЙ ПО: синтаксис параметров поля Content-Type таков, что зачастую необходимо значения границ в параметре 'boundary' заключать в кавычки. Это не всегда требуется, но никогда не повредит. Программистам следует изучить синтаксис внимательно, чтобы не допустить ошибок в поле Content-Type. Типичное поле Content-Type для типа 'multipart' может выглядеть следующим образом:
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p
Но в следующем примере содержится ошибка:
Content-Type: multipart/mixed; boundary=gc0p4Jq0M:2Yt08jU534c0p
(из-за двоеточия), которая может быть исправлена следующим образом:
Content-Type: multipart/mixed; boundary="gc0p4Jq0M:2Yt08jU534c0p"
Это означает, что тело письма состоит из нескольких частей, каждая из которых соответствует синтаксису письма RFC 822, за исключением того. что область заголовка может быть абсолютно пустой и начальная граница каждой части отмечена последовательностью:
--gc0p4Jq0M:2Yt08jU534c0p
Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может не оканчиваться концом строки, что принципиально важно в случае бинарных данных. Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.
Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.
Метка границы, следующая за последней частью письма, должна отличаться от предыдущих меток, чтобы показать, что далее не последует другой части письма. Отличие последней метки состоит в добавлении двух дефисов в конец:
--gc0p4Jq0M2Yt08jU534c0p--
Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.
ЗАМЕЧАНИЕ: Эти области преамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME'овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.
ЗАМЕЧАНИЕ: Поскольку метки границы не должны появляться внутри тел частей письма, почтовая программа, создающая письмо, должна иметь алгоритм, позволяющий автоматически подобрать уникальную последовательность, не встречающуюся в теле ни одной из частей, либо имеющую минимальную вероятность появления, если данные предварительно не сканируются на наличие таковой.
В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет: