что такое mime тип
MIME types
Организация Internet Assigned Numbers Authority (IANA) является ответственной за все официально признанные MIME типы, и вы можете найти самый последний и полный лист MIME типов на их странице Медиа Типов.
Важно: Для принятия решения о том, как обрабатывать URL, браузеры используют MIME типы, а не расширения файлов, так что серверам необходимо отправлять правильные MIME типы в Content-Type заголовке ответа. При неточном задавании этого заголовка, браузеры с большой вероятностью будут неправильно интерпретировать и обрабатывать содержание файлов, из-за чего сайт будет работать неверно.
Структура MIME типа
Простейший MIME тип состоит из типа и подтипа — двух строк разделённых наклонной чертой ( / ), без использования пробелов.
Необязательный параметр может быть добавлен для указания дополнительных деталей
MIME типы являются нечувствительными к регистру, но традиционно их пишут строчными буквами, за исключением значений параметров.
Все типы можно разделить на два класса: дискретные и многокомпонентные. Дискретные типы представляют одиночные файлы, например, одиночный текстовый, музыкальный или видео файл. Многокомпонентные типы представляют документы, составленные из нескольких частей, каждая из которых может иметь свой отдельный MIME тип, или они могут заключать в себе несколько отдельных файлов, передаваемых в одном сообщении. Например, многокомпонентные MIME типы используются для передачи нескольких изображений в одном email.
Дискретные типы
В настоящее время на IANA зарегистрированы следующие дискретные типы:
Любые текстовые документы без определённого подтипа стоит отправлять, как text/plain тип. Аналогичным образом, application/octet-stream тип подойдёт бинарным документам при неопределённом или неизвестном подтипе.
Многокомпонентные типы
Многокомпонентные типы описывают категории разграниченных на части документов, где каждая из частей может иметь свой отдельный MIME тип. При работе с электронными письмами, они могут использоваться для описания нескольких отдельных файлов, передаваемых в одном сообщении. Они представляют составные документы.
За исключением multipart/form-data типа, используемого в POST методе HTML форм, и multipart/byteranges типа, используемом в ответе 206 Partial Content для отправки части документа, HTTP никаким особым образом не обрабатывает многокомпонентные типы, и просто отправляет данные в браузер (который, с большой вероятностью, предложит сохранить переданный файл, тоже не зная как его обработать).
Существуют два многокомпонентных типа:
Важные для Web-разработчиков MIME типы
application/octet-stream
text/plain
Этот тип является базовым для текстовых файлов. Несмотря на то, что он означает «неопределённые текстовые данные», браузеры всё равно могут его отображать.
Заметьте: text/plain не означает «любой вид текстовых данных». Если браузер ожидает получения какого-то конкретного типа текстовых данных, то с большой вероятностью он не будет считать text/plain подходящим типом. Например, при загрузке text/plain документа через элемент, браузер не будет его признать правильным CSS файлом и использовать для применения стилей. Только text/css тип должен использоваться для загрузки CSS документов.
text/css
CSS документы, используемые для стилизации web-страниц должны отправляться, как text/css тип. Большинство браузеров не смогут распознавать CSS документы, загруженные с отличным от text/css MIME типом.
text/html
Все HTML данные должны пересылаться с данным типом. Альтернативные MIME типы для XHTML (например, application/xhtml+xml ) почти не используются в настоящее время.
text/javascript
По исторически сложившимся причинам, MIME Sniffing Standard (стандарт, определяющий, как браузеры должны интерпретировать медиа типы и выяснять, как обрабатывать данные при неправильно заданных медиа типах) позволяет серверам отправлять JavaScript документы, используя один из нижеперечисленных типов:
Типы изображений
Лишь несколько типов изображений достаточно распространены, чтобы безопасно использоваться на веб-страницах.
Аудио и видео типы
Так же как в случае с изображениями, стандарт HTML не обязывает браузеры поддерживать какие-либо определённые форматы и кодеки для и элементов, так что при их выборе, важно брать в расчёт целевую аудиторию и диапазон браузеров (а так же версии этих браузеров), которые она может использовать.
Наше руководство по медиа форматам предоставляет список общепринятых типов, включая информацию об особых случаях при их использовании, их недостатках, совместимости, а так же других деталях.
Руководства по аудио и видео кодекам перечисляют часто поддерживаемые браузерами кодеки, предоставляя детали по их совместимости и техническую информацию, например как много аудио каналов они поддерживают, какой тип сжатия используют, и так далее. Руководство по используемым в WebRTC кодекам развивает эту тему ещё дальше, конкретно описывая кодеки, поддерживаемые популярными браузерами, так чтобы вы могли выбрать кодеки, которые имеют наилучшую поддержку в диапазоне браузеров по вашему выбору.
Что касается MIME типов для аудио и видео файлов, то чаще всего они указывают на формат контейнера (тип файла). Необязательный параметр codecs может быть добавлен к MIME типу для более точного указания, какой кодек и параметры использовались для пересылаемого файла.
Ниже перечислены наиболее часто используемые на веб-страницах MIME типы. Обратите внимание, что это не полный перечень всех доступных типов. Более полный список поддерживаемых форматов может быть наеден в руководстве по медиа форматам.
multipart/form-data
multipart/form-data тип может быть использован при отправке значений из заполненной HTML Формы на сервер.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
MIME (Multipurpose Internet Mail Extensions)
| Protocol stack | |
| Purpose | Передача различных типов данных по электронной почте |
|---|---|
| Developer(s) | IETF (Internet Engineering Task Force) |
| Introduced | 1991 ; 30 years ago ( 1991 ) |
| OSI layer | Уровень представления |
| RFC(s) | RFC 1341, RFC 1342, RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289, RFC 2049, RFC 2045, RFC 1521, RFC 1522, RFC 2183, RFC 2231, RFC 6152, RFC 3030, RFC 2822, RFC 2387, RFC 2388, RFC 6522, RFC 1847, RFC 3156, RFC 7578, RFC 2616 |
MIME (англ. Multipurpose Internet Mail Extensions — многоцелевые расширения интернет-почты) — стандарт, описывающий передачу различных типов данных по электронной почте (позволяющий вставлять изображения, звуки и текст в сообщение), который впервые был предложен Bell Communications в 1991 году. Также является спецификацией для кодирования информации и форматирования сообщений таким образом, чтобы их можно было пересылать по Интернету. Первоначально он был определен RFC 1341 и RFC 1342 в июне 1992 года. Используя заголовки, MIME описывает тип содержимого сообщения и используемую кодировку. [Источник 1]
MIME добавляет следующие функции в службу электронной почты:
MIME указан в шести связанных RFC-стандартах: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 и RFC 2049 с интеграцией с электронной почтой SMTP, подробно описанной в RFC 1521 и RFC 1522.
Содержание
Заголовки MIME
MIME-Version
Наличие этого заголовка указывает, что сообщение имеет формат MIME. Обычно это значение «1.0», поэтому этот заголовок отображается так:
По словам создателя MIME Натаниэля Боренштейна, целью было разрешить MIME изменяться до версии 2.0 и так далее, но это решение привело к противоположному результату. Стало почти невозможно создать новую версию стандарта. Со слов Боренштейна они не определили как будут обрабатывать будущую версию MIME.
Content-Type
Этот заголовок указывает тип мультимедийного содержимого сообщения, состоящего из типа и подтипа, например: Content-Type: text/plain Благодаря использованию типа multipart, MIME даёт возможность почтовым сообщениям иметь части, расположенные в древовидной структуре, где листовые узлы являются любым многокомпонентным типом содержимого, а не листовые узлы являются любым типом из множества многокомпонентных типов. Этот механизм поддерживает:
Content-Disposition
Исходные спецификации MIME описывали только структуру почтовых сообщений. Они не затрагивали проблему стилей презентации. Поле заголовка Content-Disposition было добавлено в RFC 2183 для определения стиля представления. Часть MIME может иметь:
В дополнение к стилю представления данный заголовок также предоставляет поля для указания имени файла, даты создания и даты изменения, которые могут использоваться почтовым агентом читателя для хранения вложения. Следующий пример взят из RFC 2183, где определяется заголовок:
Имя файла может быть закодировано в соответствии с RFC 2231.
В HTTP заголовок Content-Disposition: attachment используется для указания представления клиенту тела ответа в виде загружаемого файла. Обычно при получении такого ответа веб-браузер предлагает пользователю сохранить его содержимое в виде файла, а не отображать его как страницу в окне браузера с параметром имени файла, предлагающим имя файла по умолчанию (это полезно для динамически сгенерированного содержимого, при котором извлечение имени файла из URL-адреса может быть бессмысленным или сложным для пользователя).
Content-Transfer-Encoding
В июне 1992 года MIME определил набор методов для представления двоичных данных в форматах, отличных от текстового формата ASCII. Кодирование передачи содержимого (Content-Transfer-Encoding): заголовок MIME имеет двустороннее значение:
RFC и список кодов передачи IANA определяют значения, указанные ниже, которые не чувствительны к регистру. Стоит отметить, что ‘7bit’, ‘8bit’ и ‘binary’ означают, что кодировка от двоичного кода к тексту не использовалась поверх исходной кодировки. В этих случаях заголовок фактически является избыточным для декодирования тела сообщения, но он может быть полезен в качестве индикатора того, какой тип объекта отправляется. Значения ‘quoted-printable’ и ‘base64’ указывают клиенту электронной почты, что используется схема кодирования двоичного текста в текст, и для того, чтобы сообщение могло быть прочитано с его оригинальной кодировкой (например, UTF-8), необходимо соответствующее начальное декодирование.
Не определено кодирование, которое явно предназначено для отправки произвольных двоичных данных через SMTP с расширением 8BITMIME. Таким образом, если BINARYMIME не поддерживается, иногда полезно использовать base64 или quoted-printable (с их ассоциированной неэффективностью). Это ограничение не распространяется на другие виды использования MIME, такие как веб-службы с MIME-приложениями или MTOM.
Закодированные слова
Различия между кодированием Quoted-printable и Q-кодированием
Коды ASCII для вопросительного знака («?») и знака равенства («=») могут быть представлены не напрямую, поскольку они используются для ограничения кодированного слова. Код ASCII для пространства не может быть представлен напрямую, потому что это может привести к тому, что более старые парсеры будут беспорядочно делить закодированное слово. Чтобы сделать кодировку меньше и чтобы её было проще читать, используют символ подчёркивания для представления кода ASCII для пространства, создающего побочный эффект, который не может быть представлено напрямую. Использование закодированных слов в некоторых частях заголовков накладывает дополнительные ограничения на то, какие символы могут быть представлены непосредственно.
Например, Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?= Это можно перевести как: «Subject:¡Hola, señor!»
Формат кодированного слова не используется для имен заголовков (например, Subject). Эти имена заголовков всегда пишутся на английском языке в исходном сообщении. При просмотре сообщения с почтовым клиентом, отличным от английского, имена заголовков обычно переводится клиентом на нужный язык.
Многокомпонентные сообщения
Многокомпонентное сообщение MIME содержит границу в заголовке «Content-Type:»; Эта граница, которая не должна встречаться ни в одной из частей, помещается между частями, а в начале и в конце тела сообщения следующим образом:
Каждая часть состоит из собственного заголовка содержимого (ноль или более полей Content-header) и тела. Многостраничный контент может быть вложенным. Кодирование передачи содержимого многокомпонентного типа всегда должно быть «7bit», «8bit» или «binary», чтобы избежать осложнений, которые могли бы возникнуть из-за нескольких уровней декодирования. Многокомпонентный блок в целом не имеет кодировки. Не-ASCII-символы в заголовках элементов обрабатываются системой Encoded-Word, а в телах деталей могут быть заданы кодировки, если это необходимо для их типа содержимого.
Подтипы многокомпонентного сообщения
Стандарт MIME определяет различные подтипы multipart-сообщений, которые определяют характер частей сообщения и их взаимосвязь друг с другом. Подтип указан в заголовке «Content-Type» для всего сообщения. Например, для многокомпонентного MIME-сообщения, использующего подтип дайджест, его Content-Type будет установлен как «multipart/digest». RFC первоначально определил 4 подтипа: смешанный, дайджест, альтернативный и параллельный. Минимально совместимое приложение должно поддерживать смешанный тип и тип дайджест. Другие подтипы являются необязательными. Приложения должны обрабатывать не распознанные подтипы как «multipart/mixed». Дополнительные подтипы, такие как подпись и данные формы, с тех пор были отдельно определены в других документах RFC. Ниже приведен список наиболее часто используемых подтипов. Он не является исчерпывающим.
Смешанный
Дайджест
Сообщение
Message/rfc822 содержит сообщение электронной почты, включая любые заголовки. Это используется для дайджестов, а также для пересылки электронной почты. Определено в RFC 2046.
Альтернативный
Подтип multipart/alternative указывает, что каждая часть является «альтернативной» версией того же (или подобного) контента, каждый в другом формате, обозначенном его заголовком «Content-Type». Порядок частей является важным. RFC1341 утверждает, что, в общем случае, пользовательские агенты, создающие multipart/alternative объекты, должны размещать части в порядке возрастания предпочтений, то есть с предпочтительным последним форматом. Затем системы могут выбрать «лучшее» представление, которое они способны обрабатывать. Это будет последняя часть, которую система может понять, хотя на это могут влиять и другие факторы. Поскольку клиент вряд ли захочет отправить версию, которая менее верна, чем версия простого текста, эта структура сначала поместит версию простого текста (если она присутствует). Это облегчает жизнь пользователям клиентов, которые не понимают многокомпонентных сообщений. Чаще всего multipart/alternative используется для электронной почты с двумя частями, одним простым текстом (text/plain) и одним HTML (text/html). Текстовая часть обеспечивает обратную совместимость, в то время как часть HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю вариант использования обычного текста поверх HTML. Это пример того, как локальные факторы могут влиять на то, как приложение выбирает «лучшую» часть отображаемого сообщения. Хотя предполагается, что каждая часть сообщения представляет один и тот же контент, стандарт не требует, чтобы это применялось каким-либо образом. В свое время фильтры защиты от нежелательной почты рассматривали только текстовую/обычную часть сообщения (text/plain), поскольку ее легче анализировать, чем часть text/html. Но в конечном итоге спамеры воспользовались этим, создав сообщения с безобидным текстом/простой частью и рекламой в части text/html. Программное обеспечение для защиты от спама в конечном итоге подхватило этот трюк, штрафуя сообщения с очень разным текстом в multipart/alternative сообщении. Определено в RFC 2046, раздел 5.1.4.
Связанный
Отчёт
Подписанный
Multipart/signed используется для присоединения цифровой подписи к сообщению. Он имеет ровно две части тела: часть тела и подпись. Вся часть тела, включая заголовки mime, используется для создания части подписи. Возможны многие типы сигнатур, например «application/pgp-signature» (RFC 3156) и «application/pkcs7-signature» (S/MIME). Определено в RFC 1847, Раздел 2.1.
Зашифрованные
Сообщение multipar /encrypted состоит из двух частей. Первая часть содержит управляющую информацию, необходимую для дешифрования второй части приложения/октетного потока. Подобно подписанным сообщениям, существуют различные реализации, которые идентифицируются по отдельным типам контента для элемента управления. Наиболее распространенными типами являются «application/pgp-encrypted» (RFC 3156) и «application/pkcs7-mime» (S/MIME). Определено в RFC 1847, раздел 2.2.
Form-Data
Как следует из названия, multipart/form-data используется для выражения значений, представленных через форму. Первоначально определенный как часть HTML 4.0 наиболее часто используется для отправки файлов через HTTP. Определено в RFC 7578 (ранее RFC 2388).
Смешанно-заменяемый
Byteranges
Параметр multipart/byterange используется для представления несмежных диапазонов байтов одного сообщения. Он используется HTTP, когда сервер возвращает несколько байтовых диапазонов и определен в RFC 2616.
Тест Марка Криспина
Марк Криспин, автор протокола IMAP, написал тест для проверки корректности обработки MIME. Тест представляет собой письмо в формате mbox с таким содержанием: «Это сумасшедшее письмо! В нём около 30 вложенных друг в друга частей. Очень хороший тест». [Источник 4]
Почтовый стандарт «MIME» (RFC1521)
Долгое время для кодирования бинарных файлов в 7-битный формат (чтобы обеспечить их пересылку по почтовой системе Internet) использовалась кодировка UUENCODE, имеющая ряд технических ограничений. Стандарт MIME предполагает использовние более устойчивой кодировки «Base64», которая специально разработана для обеспечения сохранности данных, пересылаемых по email, при различных преобразованиях, имиеющих место в ходе прохождения почтовых шлюзов.
Стандарт MIME полностью описан в RFC-1521
1. Введение
Более очевидными стали ограничения RFC 822 при разработке почтовых шлюзов между хостами, использующими стандарт RFC822 и хостами, использующими стандарт X.400. X.400 имеет механизмы для включения нетекстовых данных в тело письма. В настоящее время стандарты для перевода почтовых сообщений из X.400 в RFC822 предполагают, что нетекстовые части тела письма должны быть сконвертированы (но не закодированы) в ASCII формат, либо должны быть «выброшены» из письма с уведомлением об этом получателя. А потеря информации крайне не желательна для пользователя.
2. Замечания, соглашения и обобщения
3. Поле заголовка «MIME-Version»
Поскольку старый стандарт RFC 822 все еще используется, а MIME возможно, изменится и дополнится в будущем, почтовой программе необходимо знать, применен ли новый стандарт в конкретном письме или нет. Поэтому в заголовок ввелено новое поле «MIME-Version», объявляющее версию стандарта, в соответствии с которым написано данное письмо.
Все почтовые сообщения, составленные в соответствии с MIME-стандартом, должны иметь это поле в своем заголовке, напрмер:
Так как возможно, в будущем формат заголовка письма может расшириться, формально содержание поля «MIME-version» дается следующим образом:
Т.о., будущие значения версии формата, коорые могут заменить «1.0», должны быть целыми числами, разделенными точкой. Если письмо получено со значением версии MIME, отличным от «1.0», оно не будет рассматриваться почтовой программой, как соответствующее данной спецификации.
Важно, что поле заголовка «MIME-Version», должно располагаться в самам начале письма. Это не обязательно для каждой из частей тела письма в случае многочастевого письма, но обязательно для заголовков частей типа «message», если и только если эта часть сама по себе декларирована как соответствующая спецификации MIME.
Не возможно полностью определить как почтовая программа, поддерживающая MIME, должна интерпретировать письмо, имеющее значение MIME-version, отличное от «1.0». Но, как минимум, почтовая программа должна предупредить пользователя о том, что письмо написано в незнакомом ей формате.
Все поля заголовка, включая MIME-Version, Content-type, и т.д., должны соответствовать общим синтаксическим правилам, определенным в RFC 822. В частности, допускается включение комментариев (т.е., следующие 2 примера эквивалентны):
4. Поле заголовка «Content-Type»
Хотя многие параметры (модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр «boundary» применим только с типом «multipart», а параметр «charset» может использоваться с несколькими типами).
Пока имен типов только семь, и пока этого достаточно. Кроме того, предполагается, что расширение существующего набора поддерживаемых типов данных будет производиться засчет введения новых подтипов этих изначально определенных типов данных. В будущем добавление имен типов верхнего уровня может быть произведено только при принятии новой версии стандарта MIME. Если по какой-либо другой причине в существующей версии используется незарегестрированный тип содежимого, ему должно быть дано имя, начинающееся с «X-«, чтобы подчеркнуть его нестандартный статус и заранее предупредить конфликт с официальным именем типа, которое может быть введено позднее.
Правильное заполнение поля Content-Type:
Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов «/», «?», «=» и отсутствием символа «.».
Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:
Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:
По умолчанию, письма, как и в стандарте 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
Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлимый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.
В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно «ужать» бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: «читабельный» и «плотно ужимающий».
Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже:
Значения «8bit», «7bit» и «binary» означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы. В частности:
«7bit» означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.
«8bit» означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).
«Binary» означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может несоблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.
Спецификация на почтовый транспорт для пересылки некодированных 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, кодируют любые данные в символьную форму. Так, к примеру, полагая, что тело письма (части письма) имеет поля заголовка вроде:
то это означает, что тело письма представляет собой 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»). Все кодирования, необходимые для содержимого тел многочастного письма должны быть произведены на более низком уровне.
Замечания по ограничениям конвертации:
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 символов. В противном случае используется ‘мягкий’ перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:
то в Quoted-Printable encoding он может быть представлена следующим образом:
Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.
Поскольку символ дефиса («-«) представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов «=_», которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)
в соответствии с правилом #1.
Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.
Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как «=0D=0A», в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.
Синтаксис данных в quoted-printable описывается следующим образом:
5.2. Механизм конвертации Base64
Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного «чистого» текста.
Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ «=» используется для обозначения функции спец. обработки).
Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.
Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта («.», CR, LF) и для синтаксиса вложенных тел MIME («-«).
Выходной поток (закодированные бфайты) должен иметь длину строк не более 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
Как и значения поля 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.
Описание должно иметь языковую кодировку US-ASCII, хотя механизм, определенный в RFC-1522 может быть использован для не-US-ASCII значений.
7. Предопределенные значения поля Content-Type
7.1 Тип ‘Text’
7.1.1. Параметр ‘charset’
В отличие от других значений, значения этого параметра не являются чувствительными к регистру букв.
Спецификации любых новых подтипов типа ‘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. В этом случае уменьшится нагрузка в сети и увеличаися шансы, что получатель прочтет письмо без искажений.
7.1.2. Подтип ‘Text/plain’
Других предопределенных подтипов для типа ‘text’ нет.
Формальный синтаксис для типа ‘text’:
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’ может выглядеть следующим образом:
Но в следующем примере содержится ошибка:
(из-за двоеточия), которая может быть исправлена следующим образом:
Это означает, что тело письма состоит из нескольких частей, каждая из которых соответствует синтаксису письма RFC 822, за исключением того. что область заголовка может быть абсолютно пустой и начальная граница каждой части отмечена последовательностью:
Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может неоканчиваться концом строки, что принципиально важно в случае бинарных данных. Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.
Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.
Метка границы, следующая за последней частью письма, должна отличаться от предыдущих меток, чтобы показать, что далее не последует другой части письма. Отличие последней метки состоит в добавлении двух дефисов в конец:
Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.
ЗАМЕЧАНИЕ: Эти области приамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME’овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.
ЗАМЕЧАНИЕ: Поскольку метки границы не должны появляться внутри тел частей письма, почтовая программа, создающая письмо, должна иметь алгоритм, позволяющий автоматически подобрать уникальную последовательность, не встречающуюся в теле ни одной из частей, либо имеющую минимальную вероятность появления, если данные предварительно не сканируются на наличие таковой.
В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет:
Часть письма, в свою очередь, также может иметь тип ‘multipart’, то есть. быть многочастным телом, но при этом метки границ, использующиеся во внешнем и во внутреннем multipart-телах, должны отличаться друг от друга.
Использование типа ‘multipart’ в одночастном письме может быть полезно в некоторых контекстах и не запрещено.
Единственным обязательным параметром для типа ‘multipart’ является параметр ‘boundary’, состоящий из 1-70 символов без хвостовых пробелов (которые могут быть удалены в процессе пересылки, и тогда почтовая программа получателя не сможет разделить вложенные части).
ЗАМЕЧАННИЕ: В некоторых транспортах такие ограничения RFC 822, как использование тольеко печатных символов в теле, могут не действовать. Ослабления таких ограничений должны быть истолкованы как локальные расширения определения тела письма настолько, насколько они поддерживаются почтовым транспортом и адекватно документированы в поле заголовка Content-Transfer-Encoding. Однако, ни при каких обстоятельствах в заголовках как письма, так и его частей, не должно содержаться каких-либо символов, кроме US-ASCII.
7.2.2. Основной подтип «multipart/mixed»
Это основной подтип для типа ‘multipart’, он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу ‘mixed’.
7.2.3. Подтип «multipart/alternative»
Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику.
Почтовые системы должны распознавать, что данные из разных частей взаимозаменяемы. Системы должны выбрать наиболее подходящий вариант для локальной платформы и других условий, в некоторых случаях, с согласия пользователя. Как и в предыдущем случае, порядок частей в письме существенен. В этом случае альтернативы располагаются в порядке уменьшения отличия от оригинала. Обычно, выбирается последняя часть (альтернатива) из тех, которые имеют тип, поддерживаемый локальной системой получателя.
Multipart/alternative может быть использована, к примеру, для пересылки текста в некотором гипотетическом формате:
В этом примере пользователь, чья система понимает этот гипотетический формат, увидят именно эту версию, в то время как остальные будут видеть размеченный либо простой текст в зависимости от возможностей их системы.
Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных (иначе зачем было бы его изобретать?), пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив. В случае, если одна из альтернатив сама имеет тип ‘multipart’ и содержит подчасти неизвестных типов, пользовательский агент может выбрать, показывать ли эту альтернативу, предыдущую или обе.
ЗАМЕЧАНИЕ: С точки зрения программиста, может показаться более удобным располагать альтернативы в обратном порядке, но данный порядок позволяет устаревшим не-MIME’овским почтовым программам отобразить в первую очередь наиболее понятный вариант.
ЗАМЕЧАНИЕ ПО СЕМАНТИКЕ ПОЛЯ ‘CONTENT-ID’ В ПИСЬМЕ MULTIPART/ALTERNATIVE: Рекомендуется, чтобы каждая часть имела уникальное значение поля Content-ID в случае, если содержимое этих частей не является идентичным. Однако, там, где содержащаяся информация идентична (например, если несколько частей типа «application/external- body» определяют альтернативные пути доступа к одним и тем же внешним по отношению к письму данным), должно использоваться одно и то же значение Content-ID, чтобы оптимизировать работу кэширующего механизма на системе получателя. Однако, не рекомендуется, чтобы значения Content-ID, использующиеся для частей, отличались от значения Content-ID, использующегося в заголовке верхнего уровня, если такое поле в нем присутствует.
7.2.4. Подтип «multipart/digest»
Этот подтип идентичен подтипу ‘multipart/mixed’, но имеет другую семантику. Например, для ‘digest’ значением по умолчанию является не «text/plane», а «message/rfc822».
В соответствии с этим подтипом, письмо-дайджест может выглядеть следующим образом:
7.2.5. Подтип «multipart/parallel»
Отличие этого подтипа от «multipart/mixed», в частности, состоит в том, что порядок расположения частей письма не принципиален.
Данные этого подтипа должны отображаться одновременно, если платформа получателя обладает соответствующими возможностями. Однако, почтовый агент отправителя должен сознавать, что программа получателя может не иметь подобных возможностей и отобразить все части письма последовательно.
7.2.6. Другие подтипы типа «multipart»
В будущем ожидается введение новых подтипов. Программистам рекомендуется интерпретировать незнакомые подтипы типа ‘multipart’ аналогично «multipart/mixed».
Формальный синтаксис поля Content-Type для данных типа «multipart»:
Полный пример Multipart-письма
7.3. Тип ‘message’
При пересылке почты часто возникает необходимость включить внутрь письма другое письмо. Для этого и используется тип ‘message’.
ЗАМЕЧАНИЕ: Для перенаправляемой и возвращаемой почты можно было бы определить отдельные подтипы, однако, такая почта может пересылаться как multipart-письмо, в котором первая часть содержит некоторую пояснительную текстовую информацию, а другая, имеющая тип ‘message/rfc822’, содержит перенаправляемое/возвращаемое письмо. Подобный способ перенаправления/возвращения почты сохраняет информацию о типе оригинального письма и позволяет ему быть корректно представленным получателю, и поэтому настоятельно рекомендуется.
7.3.1. Основной подтип ‘message/rfc822’
Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей «From», «Subject» и, по крайней мере, одного поля «To».
Не смотря на использование числа «822», тело, имеющее подтип ‘message/rfc822’, может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо ‘message/rfc822’ может быть MIME-письмом.
7.3.2. Подтип ‘message/partial’
Этот подтип определен с целью обеспечения возможности пересылки очень больших объектов в виде нескольких раздельных частей, автоматичски «склеиваемых» почтовой программой получателя. Этот механизм может пригодиться, когда промежуточные почтовые шлюзы ограничивают индивидуальный размер пересылаемых писем. Т.о., этот подтип говорит о том, что письмо содержит лишь часть большого послания.
Для этого подтипа необходимо указание трех параметров:
Пример: часть 2 3-х частного послания имеет следующие варианты заголовка:
Но часть 3 обязательно должна содержать параметр «total»:
Необходимо заметить, что нумирация частей начинается с 1, а не с 0.
Когда подобным образом разбитые части собираются вместе, они образуют полное MIME-письмо, содержимое которого может иметь любой другой тип и, соответственно, свое поле заголовка Content-Type, описывающее этот тип.
Семантика partial-письма должна быть та же, как в обычном письме с содержимым данного типа, а не как в письме, содержащем «внутреннее» письмо. Это позволяет, например, переслать большой аудио-файл ввиде нескольких более мелких, остающихся, тем не менее, видимыми получателю как обычные аудио-письма, а не как вложенные аудио-письма.
При «сборке» таких посланий в пункте назначения должны учитываться следующие правила:
(1) Все поля заголовка части 1, кроме начинающихся с «Content-» и специальных «Message-ID», «Encrypted» и «MIME-Version» должны быть скопированы в заголовок нового (общего) письма.
(2) Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с «Content-«, а также поля «Message-ID», «Encrypted» и «MIME-Version», должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.
(3) Заголовки второй и последующих частей целиком игнорируются.
Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом:
А вторая может выглядеть так:
После того, как расколотое послание воссоздано заново для отображения получателю, оно должно выглядеть следующим образом:
Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа «message» никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде. Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим «8-бит» и «binary», запрещается их использование для данных message/partial.
Многие почтовые агенты могут автоматически фрагментировать большие письма.
Включение поля «References» в заголовки второй и последующих частей, ссылающегося на идентификатор предыдущей части, может оказаться полезным для почтовых программ, понимающих и обрабатывающих ссылки. Однако, наличие этого поля не обязательно.
Поле заголовка «Encrypted» вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial.
7.3.3. Подтип ‘Message/External-Body’
Письмо (часть письма) этого подтипа состоит из заголовка, двух последовательных концов строки и заголовка вложенного письма. Если встречается другая пара концов строки, она означает конец заголовка вложенного письма. Однако, поскольку тело вложенного письма является внешним, оно не следует за концом заголовка. Например,
Область в конце, которую можно назвать «призрачным телом», игнорируется для большинства писем подтипа ‘external-body’. Однако, в нее можно помещать дополнительную информацию, как например, в случае, когда параметр ‘access-type’ равен «mail-server». Во всех остальных случаях призрачное тело игнорируется.
Дополнительно, следующие три параметра являются необязательными для всех способов доступа:
Вложенные заголовки во ВСЕХ телах типа message/external-body ДОЛЖНЫ включать поле заголовка Content-ID для задания уникального идентификатора, указывающего на внешние данные.
Обозначения, описывающие данные типа external-body, такие как имена файлов или команды mail-сервера, должны быть в символьном наборе US-ASCII.
Как и для типа message/partial, тело типа message/external-body должно иметь значение content-transfer-encoding «7-bit» (по умолчанию). В частности, даже в системах, поддержиавющих 8-битный транспорт, применение content-transfer-encoding «8-bit» и «binary» запрещено для данных типа message/external-body.
7.3.3.1. Типы доступа «ftp» и «tftp»
Тип доступа по FTP или TFTP означает, что тело сообщения доступно как внешний файл по протоколу FTP [RFC-959] или TFTP [RFC-783] соответственно. Для этих типов доступа обязательны следующие дополнительные параметры:
Перед тем, как начнется считывание данных по FTP, пользователь обычно должен быть спрошен на предмет логина и пароля для машины, указанной в параметре ‘site’. По причинам безопасности логин и пароль не указываются как параметры Content-Type и должны быть получены от получателя письма.
Дополнительно определены следующие необязательные параметры:
7.3.3.2. Способ досупа «anon-ftp»
Этот способ доступа идентичен «ftp», за исключением того, что пользователю не требуется указывать свой логин и пароль для удаленной машины. FTP-протокол будет использоваться с логином «anonymous» и email-адресом получателя вместо пароля.
7.3.3.3. Способы доступа «local-file» и «afs»
Способ доступа «local-file» означает, что тело письма доступно как файл на локальной машине. «afs» означает, что тело доступно как файл через общую файловую систему AFS. В обоих случаях требуется единственный обязательный параметр:
Следующий необязательный параметр может быть использован для локализации ссылки на файл и содержит адрес сайта или сайтов, на которых данный файл виден:
7.3.3.4. Способ доступа «mail-server»
Применяется, когда тело письма доступно через почтовый сервер. Обязательный параметр для этого способа доступа:
Так как почтовые серверы предполагают множество различных синтаксисов, некоторые из них могут быть многострочными, полная команда, которую нужно послать на mail-сервер, не включается как параметр в однострочное поле ‘content-type’. Вместо этого она помещается в мнимое тело, когда значением поля ‘content-type’ является ‘message/external-body’, и параметр ‘access-tyoe’ имеет значение ‘mail-server’.
Необязательный параметр для этого способа доступа:
MIME-стандарт не определяет синтаксиса обращения к почтовому серверу. Поэтому он допускает включение полной команды для mail-сервера в мнимое тело.
В отличие от других способов доступа, доступ через mail-сервер не синхронен, и данные могут быть получены в непредсказуемый момент в будущем. По этой причине важно иметь механизм, обеспечивающий вставку полученных от mail-сервера данных в исходное письмо. Mail-сервер при отправке запрошенных данных должен использовать то же самое значение поля Content-ID в заголовке письма с возвращаемыми данными, какое было в первоначальном «бестелесном» письме, чтобы облегчить работу этого механизма.
7.3.3.5. Примеры и дополнительные пояснения
Если внешнее тела письма доступно посредством нескольких различных механизмов, отправитель может включить несколько частей типа message/external-body в письмо типа multipart/alternative.
Однако, механизм external-body не должен быть ограничен получением удаленных файлов. Например, можно представить использование видеосервера с внешними ссылками на видеофрагменты.
Поля заголовка вложенного письма, которые на самом деле являются телом общего письма типа «message/external-body», должны нести информацию о типе содержимого внешнего (удаленного) тела, если оно не является простым ASCII-текстом (что подразумевается по умолчанию), поскольку эти внешние данные сами по себе не имеют заголовка, опрпеделяющего их тип. Также, необходимо указывать Content-transfer-encoding, если он имеет значение, отличное от «7-bit». Так, полное письмо типа message/external-body, ссылающееся на документ в формате PostScript, может выглядеть следующим образом:
В приведенных примерах значение Content-transfer-encoding для внешних данных в формате postscript полагается по умолчанию как «7bit».
Заголовки общего и вложенного(их) писем (имеющих внешнее тело) должны удовлетворять тем же правилам, что и для типа message/partial во избежание путаницы.
Поскольку внешнее тело не пересылается в виде почты, то оно не обязано удовлетворять требованиям длины строк и иметь 7-битную форму, оно может быть просто бинарным файлом. Поэтому поле Content-Transfer-Encoding не является необходимым, хотя его наличие допускается.
Тело письма типа «message/external-body» обрабатывается в сответствии с основным синтаксисом стандарта RFC 822, в частности, все, что идет до первой последовательной пары концов строки (CRLF), является заголовком письма, а все, что идет после, является «мнимым» телом письма, которое игнорируется для большинства типов доступа.
7.4. Тип ‘Application’
Этот тип используется для данных, неподпадающих под остальные категории, в частности, для данных, обрабатываемых прикладными почтовыми программами. Это информация, которая должна быть обработана соответствующим приложением для того, чтобы принять наглядную либо исполняемую для получателя форму. Предполагаемое использование для этого типа включает в себя пересылку файлов по почте, таблицы, данные для почтовых систем расписания, языки лдя «активной» (вычислительной) почты. (Последняя, в частности, может поднять проблемы безопасности, которые должны быть поняты разработчиками ПО и рассмотрены ниже в параграфе «Application/PostScript»).
Например, тот, кто занимается расписанием встреч, может определить стандартное представление информации о датах запланированных встреч. «Умный» пользовательский почтовый агент может использовать эту информацию для проведения диалога с пользователем, и может затем посылать в дальнейшем почту, основанную на том диалоге. Вообще, существует несколько «активных» почтовых языков, разработанных для специализированных программ, которые посылаются по почте и автоматчески запускаются в системе получателя.
Подобные приложения могут быть определены как подтипы для типа «application». Изначально предопределено два подтипа: «octet-stream» и «PostScript».
В общем, подтип для ‘application’ зачастую может быть именем приложения, для которого предназначены пересылаемые данные. Однако, это не означает, что любое имя прикладной программы может свободно использоваться как подтип для ‘application’. Такие употребления (кроме подтипов, начинающихся с «x-«) должны быть зарегестрированы в IANA.
7.4.1. Основной подтип ‘Application/Octet-Stream’
Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):
Дополнительный параметр, «conversions», определенный в [RFC-1341], был исключен в последствии.
Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля «Content-Type» (например, в параметре «interpreter=»), использующей в качестве входных данных тело письма.
7.4.2. Подтип ‘Application/PostScript’
PostScript-документы представляют собой интерпретируемые программы, которые могут содержать операторы обращения к диску и действий с файлами. Поэтому PostScript-документы представляют потенциальную опасность для системы получателя.
В некоторых интерпретаторах PostScript могут иметь место ошибки, которые могут быть использованы хакерами для несанкционированного доступа к системе получателя, и нельзя предложить какого-либо специфического действия для предотвращения подобной возможности, кроме исправления со временем подобных ошибок (если они, конечно, есть) производителями соответствующего ПО.
7.4.3. Другие подтипы типа Application
Ожидается, что многие подтипы типа ‘Application’ будут введены в будущем. MIME-совместимые почтовые программы должны интерпретировать любой незнакомый им подтип как эквивалент ‘application/octet-stream’.
Формальный синтаксис дла поля ‘content-type’ для данных типа ‘application’ дается следующим образом.
7.5. Тип ‘Image’
Формальный синтаксис поля ‘Content-Type’:
7.6. Тип ‘Audio’
Этот подтип означает, что тело содержит аудио-данные. Хотя пока еще нет консенсуса по «идеальному» аудио-формату для компьютеров, сейчас имеется сильная потребность в универсальном формате.
Формальный синтаксис лдя поля ‘Content-Type’:
7.7. Тип ‘Video’
Этот тип означает, что в теле письма содержится анимационное изображение, возможно, со звуком и цветом. Термин «video» используется безотносительно к технологии получения подвижного во времени изображения. Подтип «mpeg» указывает на видео, кодированное в соответствии со стандартом MPEG.
Хотя MIME-стандарт запрещает смешение разнородных мультимедийных данных в одном теле (письма или части письма), многие так называемые «video»-форматы включают синхронизированный звук, что допускается для подтипов типа «video».
Формальный синтаксис лдя поля ‘Content-Type’:
7.8. Экспериментальные значения поля ‘Content-Type’
Значение типа, начинающееся с «X-«, считается частным, предназначенным для использования по договоренности между двумя или более почтовыми системами. Публично определенные (регестрированные) значения никогда не должны начинаться с префикса «X-«.
В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.
Все определенные на сегодняшний день типы и подтипы
| ТИП | ПОДТИП |
|---|---|
| text | plain |
| richtext | |
| enriched | |
| tab-separated-values | |
| multipart | mixed |
| alternative | |
| digest | |
| parallel | |
| appledouble | |
| header-set | |
| message | rfc822 |
| partial | |
| external-body | |
| news | |
| application | octet-stream |
| postscript | |
| oda | |
| atomicmail | |
| andrew-inset | |
| slate | |
| wita | |
| dec-dx | |
| dca-rft | |
| activemessage | |
| rtf | |
| applefile | |
| mac-binhex40 | |
| news-message-id | |
| news-transmission | |
| wordperfect5.1 | |
| zip | |
| macwriteii | |
| msword | |
| remote-printing | |
| image | jpeg |
| gif | |
| ief | |
| tiff | |
| audio | basic |
| video | mpeg |
| quicktime |
Значения полей Content-Type и subtype, а также другие параметры заголовка являются чувствительными к регистру букв, если только не оговорены исключения для конкретного значения параметра.
Применение возможностей MIME в транспортных почтовых системах
Хотя новые возможности, предоставляемые MIME, ориентированы в основном на пользовательские почтовые программы, однако, транспортные системы тоже могут воспользоваться преимуществами MIME.
Усилия создателей MIME были максимально сфокусированы на том, чтобы не требовать абсолютно никаких изменений на уровне транспортировки сообщений. Потому почта в MIME-формате проходит прозрачно на всех интернет- и интернет-подобных системах. То есть, при разработке и установке почтовых транспортов можно (хотя и не обязательно) полностью игнорировать существование MIME. Однако, MIME предоставляет некоторые возможности, которые могут быть полезными ответственным за транспортные услуги лицам. Используя эти возможности, транспортные системы могут обеспечить дополнительные виды услуг, недоступных в настоящее время недоступных, но могущих смягчить существующие проблемы.
Чтобы заниматься реализацией любого из механизмов, описанных ниже, необходимо ознакомиться с отличием между службой почтового транспорта и шлюзовой службой. В основном, почтовый транспорт ответственен за перемещение почтовых сообщений в пределах пространства почтовых сетей, подобных друг другу. С другой стороны, почтовые шлюзы совершают обмен почтой между двумя принципиально отличными почтовыми пространствами, в том числе и через неэлекторнные службы (как бумажная почта, например).
Общеполагается для почтовых транспортных систем неприемлимым изменять содержимое сообщений. В случае почтовых шлюзов, изменения зачастую неизбежно. Таким образом, многие из механизмов, описаных ниже, применяются только к шлюзам, и не должны использоваться в простых транспортных системах. Однако, возможно, что в некоторых специфических ситуациях (таких как в случае SMTP-соединений через межконтинентальную связь) может потребоваться изменять содержимое для обеспечения приемлимого обслуживания для таких ситуаций, и потому такой почтовый транспорт должен считаться уже фактически шлюзом. То есть, почтовые транспорты, которые намерены использовать описанные ниже функции, должны переклассифицировать себя как шлюзы.
1. Непринятая почта
К сожалению частой обязанностью транспортных служб является отсылка почты обратно отправителю. Такое может произойти, если почту невозможно доставить или если она не удовлетворяет требованиям шлюза (слишком большой объем, например).
Раньше не было стандартных правил для отказа от принятия почтовых сообщений. Это было досадной, но не главной проблемой для текстовых сообщений. Для нетекстовых, однако, недостаток в стандартном формате отказа от приема является более критичным, потому что типично возвращенные пиьсма представляются их отправителю как текст, и пользователь, просматривающий картинку или звук, как если бы они были текстом, редко бывает счастлив от этого.
Подчеркивается, что транспорные программы вообще не нуждаются в распознавании структуры возвращаемого письма. От них лишь требуется правильно вложить его. Следующий пример показывает, как любое MIME-письмо может быть вложено (инкапсулировано) в письмо возврата так, что вся информация в нем будет корректно воспроизведена, если получатель (он же первый отправитель) будет читать его с помощью MIME-ориентированной почтовой программы:
В данном примере единственная вещь, которая не берется из стандартного набора фраз, это выбор метки границы. Фраза «unique-boundary» должна быть заменена строкой, не появляющейся ни в одной из частей сообщения.
2. Разбиение (фрагментация) и сборка больших писем
Одна из проблем, встречающихся все чаще и чаще в Internet-почте, возврат писем из-за ограничений по их объему. Особенный рост этой проблемы обусловлен расширением использования MIME, так как MIME позволяет посылать очень большие объекты, такие как звук, видео, графику. К счастью, MIME также обеспечивает механизмы, которые могут помочь ослабить эту проблему.
В частности, к ним относится MIME-тип «message/partial», который можно использовать для автоматического разбиения и сборки больших писем. Эта функция может поддерживаться полностью как на уровне пользовательских почтовых агентов, так и транспортными службами, которые могут его использовать для обеспечения полее разумного поведения при шлюзовании почты.
Ниже приводится пример, показывающий, как простое коротенькое письмо может быть разбито на два письма типа «message/partial». На практике, конечно, данное свойство разумно применять лишь для очень больших писем.
Фрагментирование таких писем, вместо их отсылки обратно, было бы вполне обусловлено для применения шлюзовыми службами. Конечно, шлюзу часто неизвестны ограничения по размеру в другой системе, но разумные предположения всегда возможны.
Фрагментирование и сборка писем могут быть выполнены, в зависимости от обстоятелств, как отправляющей, так и принимающей системой, в зависимости от того, какая из них знает больше о способностях другой.
3. Использование или удаление указателей External-Body (внешнего тела)
Другой MIME-тип, ориентированный на слишком большие письма, это «message/external-body». Он обеспечивает почтовым транспортным службам, оптимизировать почтовый траффик в своей системе. Однако, когда почта пересекает медленный и дорогой участок, например, звено спутниковой связи через Тихий океан, может иметь смысл считать указываемые данные и передать их в качестве действительного тела письма, либо скопировать в новое, более доступное место, соответствующим образом изменив ссылку в заголовке письма. Поскольку спецификация данного типа допускает наличие даты аннулирования ресурса, почтовый транспорт может идти на компромисс между пропускной способностью своей системы и ее дисковым пространством, отданным под хранение внешних данных писем, чтобы оптимизировать использование этих внешних данных.
Такое поведение требует осторожного анализа соотношения затрат и выгоды. Однако, потенциальные выгоды очевидны, так что разумное использование таких возможностей не повредит.
Например, приведенное ниже письмо содержит ссылку на внешние PostScript-данные:
Этот пример предполагает как выгоду (немедленно доступные получателю данные), так и возможные затраты (если список рассылки велик, то письмо придется разослать всем, хотя только некотоые из получателей обратились бы за данными письма в ближайшее время).
Кроме того, вместо замены ссылки на внешние данные их натуральным включением в письмо, можно трансформировать оригинальное письмо в письмо типа «multipart/alternative», содержащее как ссылку на внешние данные, так и копию этих данных. Это означает, что при перенаправлении письма другому пользователю перенаправлена будет только та часть, которая содержит ссылку. Кроме того, получатель, хоть и получит данные сразу целиком, все равно не потеряет информацию о местоположении оригинального ресурса, и при необходимости сможет скачать более новую его версию в будущем. Это иллюстрируется следующим примером:
Аналогично, в случае, когда внешние данные копируются транспортной системой на локальный FTP, можно сделать в письме две части типа ‘external-body’, что позволит получателю выбрать, с какого из FTP предпочтительнее забирать тело письма.
4. Преобразование графических и других форматов
Почтовые транспортные системы могут оптимизировать и траффик, и удобства получателей разумной трансляцией этих форматов (а также других, которые могут быть добавлены в будущем). Если письмо типа image/gif пересылается на длинную дистанцию, оно может быть перетранслировано в image/jpeg. Когда же данные типа image/jpeg получены системой, в которой находится получатель, для конечной доставки, они снова могут быть перетранслированы в GIF для удобств получателя.
Подобные преобразования форматов также рекомендуются и для аудио-данных.
Если преобразование выполнено, настоятельно рекомендуется добавлять каким-либо образом (например, в поле заголовка Received) информацию об истории преобразований документа, в письме содержащегося.
Однако, трансляция форматов обычно ограничивается шлюзовыми службами и менее предпочтительна для обычных транспортных служб. Причем, те службы, которые выполняют преобразования, должны распознавать поле Conterent-Conversion, в котором отправитель может разрешить либо запретить любые преобразования форматов данных, поскольку многие пользователи принципиально неприемлют преобразования, так как считают, что при некоторые из них могут привести к ухудшению качества документа:
По умолчанию (если это поле отсутствует) предполагается значение ‘permitted’.