Многоцелевые расширения почты Интернета ( MIME ) — это интернет-стандарт , который расширяет формат сообщений электронной почты для поддержки текста в наборах символов , отличных от ASCII , а также вложений аудио, видео, изображений и прикладных программ. Тело сообщения может состоять из нескольких частей, а информация заголовка может быть указана в наборах символов, отличных от ASCII. Сообщения электронной почты в формате MIME обычно передаются по стандартным протоколам, таким как простой протокол передачи почты (SMTP), протокол почтового отделения (POP) и протокол доступа к сообщениям Интернета (IMAP).
Стандарт MIME указан в серии запросов на комментарии : RFC 2045 , RFC 2046 , RFC 2047 , RFC 4288 , RFC 4289 и RFC 2049 . Интеграция с электронной почтой SMTP указана в RFC 1521 и RFC 1522 .
Хотя формализм MIME был разработан в основном для SMTP, его типы контента также важны и в других протоколах связи . В протоколе передачи гипертекста (HTTP) для Всемирной паутины серверы вставляют поле заголовка MIME в начале любой веб-передачи. Клиенты используют заголовок типа контента или типа мультимедиа , чтобы выбрать подходящее приложение просмотра для указанного типа данных.
MIME возник из системы обмена сообщениями Эндрю, которая была частью проекта Эндрю , разработанного в Университете Карнеги-Меллон (CMU), как кроссплатформенная альтернатива формату данных, специфичному для Эндрю. [1]
Наличие этого поля заголовка указывает на то, что сообщение имеет формат MIME. Обычно это значение «1,0». Поле выглядит следующим образом:
MIME-версия: 1.0
По словам соавтора MIME Натаниэля Боренштейна , номер версии был введен для того, чтобы разрешить изменения протокола MIME в последующих версиях. Однако Боренштейн признал недостатки спецификации, которые препятствовали реализации этой функции: «Мы не указали должным образом, как обрабатывать будущую версию MIME. ... Итак, если вы пишете что-то, что знает 1.0, что вам делать, если вы столкнулись с 2.0 или 1.1? Я вроде как думал, что это очевидно, но оказалось, что все реализовали это по-разному. И в результате для Интернета было бы практически невозможно когда-либо определить 2.0 или 1.1». [2]
Это поле заголовка указывает тип носителя содержимого сообщения, состоящий из типа и подтипа , например
Тип контента: текстовый/обычный
Благодаря использованию составного типа MIME позволяет почтовым сообщениям иметь части, расположенные в древовидной структуре , где конечные узлы представляют собой любой несоставной тип контента, а неконечные узлы представляют собой любой из множества составных типов. Этот механизм поддерживает:
Исходные спецификации MIME описывали только структуру почтовых сообщений. Они не затронули вопрос стилей изложения. Поле заголовка content-disposition было добавлено в RFC 2183 для указания стиля представления. Часть MIME может иметь:
Помимо стиля представления, поле Content-Disposition также предоставляет параметры для указания имени файла, даты создания и даты изменения, которые могут использоваться почтовым агентом читателя для хранения вложения.
Следующий пример взят из RFC 2183, где определено поле заголовка:
Содержание-Диспозиция: вложение; имя файла = геном.jpeg; модификация-дата="Ср, 12 февраля 1997 г. 16:29:51 -0500";
Имя файла может быть закодировано, как определено в RFC 2231.
По состоянию на 2010 год большинство почтовых пользовательских агентов не полностью следовали этому предписанию. Широко используемый почтовый клиент Mozilla Thunderbird игнорирует поля размещения содержимого в сообщениях и использует независимые алгоритмы для выбора частей MIME для автоматического отображения. Thunderbird до версии 3 также отправляет вновь составленные сообщения со встроенным расположением содержимого для всех частей MIME. Большинство пользователей не знают, как настроить расположение содержимого для вложения . [3] Многие почтовые пользовательские агенты также отправляют сообщения с именем файла в параметре имени заголовка типа контента вместо параметра имени файла в поле заголовка Content-Disposition . Такая практика не рекомендуется, так как имя файла должно быть указано либо с параметром filename , либо с обоими параметрами filename и name . [4]
В HTTP поле заголовка ответа Content-Disposition: Attachment обычно используется как подсказка клиенту представить тело ответа в виде загружаемого файла. Обычно, получая такой ответ, веб-браузер предлагает пользователю сохранить его содержимое в виде файла, а не отображать его в виде страницы в окне браузера, где имя файла предполагает имя файла по умолчанию.
В июне 1992 года MIME (RFC 1341, устаревший благодаря RFC 2045) определил набор методов для представления двоичных данных в форматах, отличных от текстового формата ASCII. Поле заголовка Content -Transfer-Encoding: MIME имеет двустороннее значение:
RFC и список кодировок передачи IANA определяют приведенные ниже значения, которые не чувствительны к регистру. «7бит», «8бит» и «двоичный» означают, что поверх исходной кодировки не использовалось преобразование двоичного текста в текст. В этих случаях поле заголовка фактически является избыточным для почтового клиента для декодирования тела сообщения, но оно все равно может быть полезно в качестве индикатора того, какой тип объекта отправляется. Значения ' quoted-printable ' и ' base64 ' сообщают почтовому клиенту, что использовалась схема кодирования двоичного текста и что необходимо соответствующее начальное декодирование, прежде чем сообщение можно будет прочитать в исходной кодировке (например, UTF-8).
Не определена кодировка, которая явно предназначена для отправки произвольных двоичных данных через транспорт SMTP с расширением 8BITMIME. Таким образом, если BINARYMIME не поддерживается, иногда все еще могут быть полезны base64 или quote-printable (с связанной с ними неэффективностью). Это ограничение не распространяется на другие виды использования MIME, такие как веб-службы с вложениями MIME или MTOM .
Начиная с RFC 2822, соответствующие имена и значения полей заголовка сообщения используют символы ASCII; значения, содержащие данные, отличные от ASCII, должны использовать синтаксис кодированного слова MIME (RFC 2047) вместо строки-литерала. В этом синтаксисе используется строка символов ASCII, указывающая как исходную кодировку символов (« набор символов »), так и кодировку передачи контента, используемую для преобразования байтов набора символов в символы ASCII.
Форма: « =?кодировка ?кодировки ?закодированного текста?= ».
Q", обозначающей Q-кодировку, аналогичную кодировке, доступной для печати , либо " B", обозначающую кодировку base64 .Коды ASCII для вопросительного знака («?») и знака равенства («=") не могут быть представлены напрямую, поскольку они используются для разделения закодированного слова. Код ASCII для пробела не может быть представлен напрямую, поскольку это может привести к тому, что старые анализаторы нежелательно разделят закодированное слово. Чтобы сделать кодировку меньше и ее легче читать, подчеркивание используется для представления кода ASCII для пробела, создавая побочный эффект, заключающийся в том, что подчеркивание не может быть представлено напрямую. Использование закодированных слов в определенных частях полей заголовка накладывает дополнительные ограничения на то, какие символы могут быть представлены напрямую.
Например,
Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=
интерпретируется как «Тема: ¡Hola, сеньор!».
Формат закодированного слова не используется для имен полей заголовков (например, Тема ). Эти имена обычно представляют собой английские термины и всегда в формате ASCII в необработанном сообщении. При просмотре сообщения в почтовом клиенте, отличном от английского, имена полей заголовка могут быть переведены клиентом.
Составное сообщение MIME содержит границу в поле заголовка Content-Type:; эта граница, которая не должна встречаться ни в одной из частей, размещается между частями, а также в начале и конце тела сообщения следующим образом:
MIME-версия: 1.0 Тип контента: multipart / mix ; граница = граница Это сообщение, состоящее из нескольких частей в формате MIME.--frontier Тип контента: текст / обычный Это тело сообщения.--frontier Тип контента: приложение / октетный поток Кодирование передачи контента: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--Каждая часть состоит из собственного заголовка контента (ноль или более Content-полей заголовка) и тела. Содержимое, состоящее из нескольких частей, может быть вложенным. Многочастный Content-Transfer-Encodingтип всегда должен быть «7-битным», «8-битным» или «двоичным», чтобы избежать сложностей, которые могут возникнуть из-за нескольких уровней декодирования. Составной блок в целом не имеет кодировки; Символы, отличные от ASCII, в заголовках частей обрабатываются системой Encoded-Word, а для тел частей могут быть указаны кодировки, соответствующие их типу содержимого.
Примечания:
Стандарт MIME определяет различные подтипы многочастных сообщений, которые определяют природу частей сообщения и их взаимосвязь друг с другом. Подтип указывается в Content-Typeполе заголовка общего сообщения. Например, составное MIME-сообщение, использующее подтип дайджеста, будет установлено Content-Typeкак «multipart/digest».
Первоначально RFC определил четыре подтипа: смешанный, дайджест, альтернативный и параллельный. Минимально совместимое приложение должно поддерживать смешанный и дайджест-анализ; другие подтипы являются необязательными. Приложения должны рассматривать нераспознанные подтипы как «составные/смешанные». Дополнительные подтипы, такие как подписанные и данные формы, с тех пор были определены отдельно в других RFC.
multipart/mixed используется для отправки файлов с различными Content-Typeполями заголовков внутри строки (или в виде вложений). При отправке изображений или других легко читаемых файлов большинство почтовых клиентов отображают их внутри (если явно не указано с помощью Content-Disposition: Attachment, в этом случае они предлагаются как вложения). Тип контента по умолчанию для каждой части — «текст/обычный».
Тип определен в RFC 2046. [5]
multipart/digest — это простой способ отправить несколько текстовых сообщений. Тип контента по умолчанию для каждой части — «message/rfc822».
Тип MIME определен в RFC 2046. [6]
Подтип multipart/alternative указывает, что каждая часть представляет собой «альтернативную» версию того же (или аналогичного) контента, каждая в другом формате, обозначенном заголовком «Content-Type». Порядок частей имеет большое значение. В RFC1341 говорится: Как правило, пользовательские агенты, составляющие составные/альтернативные сущности, должны размещать части тела в порядке возрастания предпочтений, то есть предпочтительный формат должен быть последним. [7]
Затем системы могут выбрать «лучшее» представление, которое они способны обработать; в общем, это будет последняя часть, которую сможет понять система, хотя на это могут повлиять и другие факторы.
Поскольку клиент вряд ли захочет отправить версию, которая менее верна, чем версия в виде обычного текста, эта структура помещает версию в виде обычного текста (если она присутствует) первой. Это облегчает жизнь пользователям клиентов, которые не понимают составные сообщения.
Чаще всего multipart/alternative используется для электронной почты, состоящей из двух частей: обычного текста (text/plain) и HTML (text/html) . Часть обычного текста обеспечивает обратную совместимость, а часть HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю возможность предпочесть простой текст HTML; это пример того, как местные факторы могут влиять на то, как приложение выбирает «лучшую» часть сообщения для отображения.
Хотя предполагается, что каждая часть сообщения представляет одно и то же содержимое, стандарт не требует какого-либо соблюдения этого требования. Когда-то антиспам-фильтры проверяли только текстовую/обычную часть сообщения [8] , потому что ее легче анализировать, чем текстовую/html-часть. Но спамеры в конечном итоге воспользовались этим, создавая сообщения с безобидной на вид частью text/plain и рекламой в части text/html. Программное обеспечение для защиты от спама в конечном итоге уловило этот трюк, наказывая сообщения с сильно отличающимся текстом в составных/альтернативных сообщениях. [8]
Тип определен в RFC 2046. [9]
Составной/связанный используется для обозначения того, что каждая часть сообщения является компонентом совокупного целого. Это для составных объектов, состоящих из нескольких взаимосвязанных компонентов — корректного отображения невозможно добиться, отображая составные части по отдельности. Сообщение состоит из корневой части (по умолчанию — первой), которая ссылается на другие части, встроенные в сообщение, которые, в свою очередь, могут ссылаться на другие части. На части сообщения обычно ссылается Content-ID . Синтаксис ссылки не указан и вместо этого определяется кодировкой или протоколом, используемым в этой части.
Одним из распространенных вариантов использования этого подтипа является отправка веб-страницы с изображениями в одном сообщении. Корневая часть будет содержать HTML- документ и использовать теги изображений для ссылки на изображения, хранящиеся в последних частях.
Тип определен в RFC 2387.
multipart/report — это тип сообщения, который содержит данные, отформатированные для чтения почтовым сервером. Он разделен на текст/обычный текст (или какой-либо другой легко читаемый контент/тип) и сообщение/статус доставки, которое содержит данные, отформатированные для чтения почтовым сервером.
Тип определен в RFC 6522.
Составное/подписанное сообщение используется для прикрепления к сообщению цифровой подписи . У него ровно две части тела: часть тела и часть подписи. Вся часть тела, включая поля MIME, используется для создания части подписи. Возможны многие типы подписей, например «application/pgp-signature» (RFC 3156) и «application/pkcs7-signature» ( S/MIME ).
Тип определен в RFC 1847. [10]
Многочастное/зашифрованное сообщение состоит из двух частей. Первая часть содержит управляющую информацию, необходимую для расшифровки второй части приложения/октетного потока. Подобно подписанным сообщениям, существуют различные реализации, которые идентифицируются отдельными типами контента для части управления. Наиболее распространенными типами являются «application/pgp-encrypted» (RFC 3156) и «application/pkcs7-mime» ( S/MIME ).
Тип MIME, определенный в RFC 1847. [11]
MIME-тип multipart/form-data используется для выражения значений, отправленных через форму. Первоначально определенный как часть HTML 4.0, он чаще всего используется для отправки файлов по протоколу HTTP . Он указан в RFC 7578, заменяющем RFC 2388. пример
Тип контента multipart/x-mixed-replace был разработан как часть технологии эмуляции передачи данных с сервера и потоковой передачи через HTTP.
Все части сообщения смешанной замены имеют одинаковое семантическое значение. Однако каждая часть аннулирует – «заменяет» – предыдущие части, как только она получена полностью. Клиенты должны обрабатывать отдельные части сразу по их прибытии и не должны ждать завершения всего сообщения.
Первоначально разработанный Netscape , [12] он до сих пор поддерживается Mozilla , Firefox , Safari и Opera . Он обычно используется в IP-камерах как тип MIME для потоков MJPEG . [13] Chrome поддерживал его для основных ресурсов до 2013 года (изображения по-прежнему могут отображаться с использованием этого типа контента). [14]
multipart/byterange используется для представления несмежных диапазонов байтов одного сообщения. Он используется HTTP, когда сервер возвращает несколько диапазонов байтов, и определен в RFC 2616.