Введение

Многоцелевые расширения интернет-почты (Multipurpose Internet Mail Extensions, MIME) — это стандарт, расширяющий формат электронных сообщений для поддержки текста в кодировках, отличных от ASCII, а также для присоединения аудио-, видеофайлов, изображений и приложений. Тело сообщения может состоять из нескольких частей, а информация в заголовках может быть указана с использованием символов, отличных от ASCII. Электронные сообщения, отформатированные с использованием MIME, обычно передаются по стандартным протоколам, таким как Простой протокол передачи почты (SMTP), протокол POP (Post Office Protocol) и протокол IMAP (Internet Message Access Protocol). MIME является интернет-стандартом, описанным в серии документов RFC: , , , и . Интеграция с электронной почтой SMTP описана в и . Хотя формализм MIME был разработан главным образом для SMTP, типы контента, используемые в нем, также важны для других протоколов связи. В протоколе передачи гипертекста (HTTP), используемом для Всемирной паутины, серверы добавляют поле заголовка MIME в начало каждой передачи данных. Клиенты используют заголовок типа контента или типа носителя для выбора подходящего приложения для отображения данных указанного типа.

История

MIME берет свое начало в системе обмена сообщениями Andrew, разработанной в рамках проекта Andrew в Университете Карнеги-Меллона (CMU), как кроссплатформенная альтернатива специфичному для Andrew формату данных.

Версия MIME

Наличие этого поля заголовка указывает на то, что сообщение имеет формат MIME. Значение обычно равно "1.0". Поле выглядит следующим образом:
MIME Version: 1.0

По словам одного из создателей MIME, Натаниэля Боренштейна, номер версии был введен, чтобы позволить вносить изменения в протокол MIME в последующих версиях. Однако Боренштейн признал недостатки спецификации, которые помешали реализации этой функции: "Мы недостаточно чётко указали, как обрабатывать будущие версии MIME. Так что, если вы создали программу, которая работает с версией 1.0, что ей делать при встрече с версией 2.0 или 1.1? Мне казалось, что это очевидно, но оказалось, что каждый реализовал это по-своему. В результате Интернету будет практически невозможно определить, что такое версии 2.0 или 1.1."

Кодированное слово

С момента публикации RFC 2822, имена и значения полей заголовков сообщений, соответствующие стандартам, используют символы ASCII; значения, содержащие данные, не относящиеся к ASCII, должны использовать синтаксис MIME-кодированных слов (RFC 2047) вместо литеральной строки. Этот синтаксис использует строку символов ASCII, указывающую как исходную кодировку символов ("charset"), так и кодировку передачи содержимого, используемую для преобразования байтов charset в символы ASCII. Формат: "=?charset?encoding?закодированный текст?=". charset может быть любым набором символов, зарегистрированным в IANA. Как правило, это будет тот же charset, что и у тела сообщения. encoding может быть либо "Q", обозначающим Q-кодирование, аналогичное quoted-printable кодированию, либо "B", обозначающим base64 кодирование. закодированный текст – это текст, закодированный с использованием Q-кодирования или base64. Длина закодированного слова не должна превышать 75 символов, включая charset, encoding, закодированный текст и разделители. Если необходимо закодировать текст, превышающий 75 символов, можно использовать несколько закодированных слов, разделенных CRLF SPACE.

Многочастичные подтипы

Стандарт MIME определяет различные подтипы многокомпонентных сообщений, которые указывают на природу частей сообщения и их взаимосвязь. Подтип указывается в поле заголовка всего сообщения. Например, многокомпонентное сообщение MIME, использующее подтип "digest", будет иметь значение поля "Content-Type" равным "multipart/digest". RFC изначально определил четыре подтипа: смешанный, дайджест, альтернативный и параллельный. Приложение, соответствующее минимальным требованиям, должно поддерживать смешанный и дайджест; другие подтипы являются необязательными. Приложения должны рассматривать неизвестные подтипы как "multipart/mixed". Дополнительные подтипы, такие как signed и form-data, впоследствии были определены в других RFC.

смешанные

multipart/mixed используется для отправки файлов с различными полями заголовков непосредственно в теле письма (или в виде вложений). Если отправляются изображения или другие файлы, которые легко просмотреть, большинство почтовых клиентов отображают их непосредственно в теле письма (если явно не указано Content-Disposition: attachment, в этом случае они предлагаются как вложения). Тип контента по умолчанию для каждой части – "text/plain". Этот тип определен в RFC 2046.

переварить

Multipart/digest — это простой способ отправки нескольких текстовых сообщений. Тип содержимого по умолчанию для каждой части — "message/rfc822". Тип MIME определен в RFC 2046.

альтернативный

Подтип multipart/alternative указывает, что каждая часть является "альтернативной" версией одного и того же (или аналогичного) содержимого, представленной в различном формате, определяемом заголовком "Тип контента". Порядок частей имеет значение. RFC1341 определяет: "В общем случае, пользовательские агенты, формирующие сущности multipart/alternative, должны располагать части тела в порядке возрастания предпочтения, то есть наиболее предпочтительный формат – последним. Системы могут затем выбрать "наилучшее" представление, которое они способны обработать; как правило, это будет последняя часть, которую система может понять, хотя на это могут влиять и другие факторы. Поскольку клиенту вряд ли потребуется отправлять версию, менее точную, чем версия обычного текста, эта структура располагает версию обычного текста (если она присутствует) первой. Это упрощает работу пользователям клиентов, не поддерживающих многокомпонентные сообщения. Чаще всего multipart/alternative используется в электронной почте, состоящей из двух частей: одна – обычный текст (text/plain), другая – HTML (text/html). Часть с обычным текстом обеспечивает обратную совместимость, а часть с HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предоставляют пользователю возможность отдавать предпочтение обычному тексту перед HTML; это пример того, как локальные факторы могут повлиять на выбор приложения, какую "наилучшую" часть сообщения отображать. Хотя предполагается, что каждая часть сообщения представляет одно и то же содержание, стандарт не требует принудительного соблюдения этого правила. Ранее антиспам-фильтры анализировали только часть сообщения в формате text/plain, поскольку её проще разбирать, чем text/html. Однако спамеры со временем воспользовались этим, создавая сообщения с безобидной частью text/plain и рекламой в части text/html. Программное обеспечение для борьбы со спамом в конечном итоге обнаружило этот трюк и стало наказывать сообщения с существенно различающимся текстом в multipart/alternative сообщении.

связанные

Многокомпонентный/связанный тип используется для указания того, что каждая часть сообщения является компонентом единого целого. Он предназначен для составных объектов, состоящих из нескольких взаимосвязанных компонентов, правильное отображение которых невозможно достичь путем отображения отдельных составных частей. Сообщение состоит из корневой части (по умолчанию, первой), которая содержит ссылки на другие части, которые, в свою очередь, могут ссылаться на другие части. На части сообщения обычно ссылаются по идентификатору содержимого (Content-ID). Синтаксис ссылки не определен и зависит от кодировки или протокола, используемого в данной части. Распространенное применение этого подтипа – отправка веб-страницы, включающей изображения, в одном сообщении. Корневая часть содержит HTML-документ и использует теги изображений для ссылки на изображения, хранящиеся в других частях сообщения. Этот тип определен в RFC 2387.

Отчет

multipart/report — это тип сообщения, содержащий данные, отформатированные для чтения почтовым сервером. Он состоит из двух частей: text/plain (или другого легко читаемого типа контента) и message/delivery-status, содержащей данные, предназначенные для обработки почтовым сервером. Этот тип определен в RFC 6522.

подписан

Многокомпонентное/подписанное сообщение используется для присоединения цифровой подписи к сообщению. Оно состоит ровно из двух частей: основной части и части с подписью. Вся основная часть, включая MIME-поля, используется для создания части с подписью. Существует множество типов подписей, таких как "application/pgp signature" (RFC 3156) и "application/pkcs7 signature" (S/MIME). Тип определяется в RFC 1847.

зашифрованный

Многокомпонентное/зашифрованное сообщение состоит из двух частей. Первая часть содержит управляющую информацию, необходимую для расшифровки второй части, представляющей собой поток данных приложения/октетов. Подобно подписанным сообщениям, существуют различные реализации, идентифицируемые по отдельным типам контента для управляющей части. Наиболее распространенными типами являются "application/pgp-encrypted" (RFC 3156) и "application/pkcs7-mime" (S/MIME). Тип MIME определен в RFC 1847.

форма-данные

Тип MIME multipart/form-data используется для передачи значений, отправленных через форму. Изначально определён в HTML 4.0, он наиболее часто применяется для отправки файлов по протоколу HTTP. Он специфицирован в RFC 7578, заменяя RFC 2388. Пример.

x-смешанная замена

Контент типа multipart/x mixed replace был разработан в рамках технологии эмуляции серверных push-уведомлений и потоковой передачи данных по HTTP. Все части сообщения mixed replace имеют одинаковое семантическое значение. Однако каждая часть, будучи полностью получена, аннулирует и заменяет предыдущие части. Клиентам следует обрабатывать отдельные части по мере их поступления и не дожидаться завершения получения всего сообщения. Изначально разработанный компанией Netscape, он до сих пор поддерживается браузерами Mozilla, Firefox, Safari и Opera. Он широко используется в IP-камерах в качестве MIME-типа для MJPEG-потоков. Браузер Chrome поддерживал его для основных ресурсов до 2013 года (изображения по-прежнему могут отображаться с использованием этого типа контента).

битаранж

Многокомпонентный/байтовый диапазон используется для представления не смежных диапазонов байтов одного сообщения. Он применяется в HTTP, когда сервер возвращает несколько диапазонов байтов, и описан в RFC 2616.