Multipurpose Internet Mail Extensions ( MIME ) — это стандарт, расширяющий формат сообщений электронной почты для поддержки текста в наборах символов, отличных от ASCII , а также вложений аудио, видео, изображений и прикладных программ. Тела сообщений могут состоять из нескольких частей, а информация заголовка может быть указана в наборах символов, отличных от ASCII. Сообщения электронной почты с форматированием MIME обычно передаются с помощью стандартных протоколов, таких как Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP) и Internet Message Access Protocol (IMAP).
MIME — это стандарт Интернета . Он указан в серии запросов на комментарии : RFC 2045 , RFC 2046 , RFC 2047 , RFC 4288 , RFC 4289 и RFC 2049. Интеграция с электронной почтой SMTP указана в RFC 1521 и RFC 1522 .
Хотя формализм MIME был разработан в основном для SMTP, его типы содержимого также важны в других протоколах связи . В протоколе передачи гипертекста (HTTP) для Всемирной паутины серверы вставляют поле заголовка MIME в начало любой веб-передачи. Клиенты используют заголовок типа содержимого или типа носителя для выбора соответствующего приложения просмотра для указанного типа данных.
MIME произошел от Andrew Messaging System, которая была частью проекта Andrew, разработанного в Университете Карнеги-Меллона (CMU), как кроссплатформенная альтернатива формату данных, специфичному для Andrew. [1]
Наличие этого поля заголовка указывает на то, что сообщение имеет формат MIME. Значение обычно равно "1.0". Поле выглядит следующим образом:
MIME-версия: 1.0
По словам одного из создателей MIME Натанаэля Боренштейна , номер версии был введен для того, чтобы разрешить внесение изменений в протокол MIME в последующих версиях. Однако Боренштейн признал недостатки в спецификации, которые препятствовали реализации этой функции: «Мы не указали должным образом, как обращаться с будущей версией MIME. ... Так что если вы пишете что-то, что знает 1.0, что вам следует делать, если вы столкнетесь с 2.0 или 1.1? Я как бы думал, что это очевидно, но оказалось, что все реализовали это по-разному. И в результате для Интернета было бы практически невозможно когда-либо определить 2.0 или 1.1». [2]
Это поле заголовка указывает тип носителя содержимого сообщения, состоящий из типа и подтипа , например
Тип содержимого: текст/обычный
Благодаря использованию типа multipart , MIME позволяет почтовым сообщениям иметь части, организованные в древовидную структуру , где конечные узлы являются любым не-multipart типом контента, а не-конечные узлы являются любым из множества multipart типов. Этот механизм поддерживает (не исчерпывающе):
Первоначальные спецификации MIME описывали только структуру почтовых сообщений. Они не решали проблему стилей представления. Поле заголовка content-disposition было добавлено в RFC 2183 для указания стиля представления. Часть MIME может иметь:
Помимо стиля представления, поле Content-Disposition также предоставляет параметры для указания имени файла, даты создания и даты изменения, которые могут использоваться почтовым агентом пользователя читателя для сохранения вложения.
Следующий пример взят из RFC 2183, где определено поле заголовка:
Содержимое-Расположение: вложение; имя файла=genome.jpeg; дата-изменения="Ср, 12 февр. 1997 16:29:51 -0500";
Имя файла может быть закодировано, как определено в RFC 2231.
По состоянию на 2010 год большинство пользовательских почтовых агентов не следовали этому предписанию в полной мере. Широко используемый почтовый клиент Mozilla Thunderbird игнорирует поля content-disposition в сообщениях и использует независимые алгоритмы для выбора частей MIME для автоматического отображения. Thunderbird до версии 3 также отправляет вновь составленные сообщения с встроенной диспозицией содержимого для всех частей MIME. Большинство пользователей не знают, как установить диспозицию содержимого на attached . [3] Многие пользовательские почтовые агенты также отправляют сообщения с именем файла в параметре name заголовка content-type вместо параметра filename поля заголовка Content-Disposition . Такая практика не рекомендуется, поскольку имя файла должно быть указано либо с параметром filename , либо с обоими параметрами filename и name . [4]
В HTTP поле заголовка ответа Content-Disposition: вложение обычно используется как подсказка клиенту представить тело ответа как загружаемый файл. Обычно при получении такого ответа веб-браузер предлагает пользователю сохранить его содержимое как файл, вместо того чтобы отображать его как страницу в окне браузера, с filename, предлагающим имя файла по умолчанию.
В июне 1992 года MIME (RFC 1341, с тех пор как устарел RFC 2045) определил набор методов для представления двоичных данных в форматах, отличных от текстового формата ASCII. Поле заголовка MIME content-transfer-encoding: имеет двустороннюю значимость:
Список кодировок RFC и IANA определяет значения, показанные ниже, которые не чувствительны к регистру. «7bit», «8bit» и «binary» означают, что не использовалось двоично-текстовое кодирование поверх исходного кодирования. В этих случаях поле заголовка фактически избыточно для почтового клиента при декодировании тела сообщения, но оно все равно может быть полезным в качестве индикатора типа отправляемого объекта. Значения « quoted-printable » и « base64 » сообщают почтовому клиенту, что использовалась схема двоично-текстового кодирования и что необходимо соответствующее начальное декодирование, прежде чем сообщение можно будет прочитать в исходном кодировании (например, UTF-8).
Не определено кодирования, которое явно предназначено для отправки произвольных двоичных данных через транспорты SMTP с расширением 8BITMIME. Таким образом, если BINARYMIME не поддерживается, base64 или quote-printable (с их связанной неэффективностью) иногда все еще полезны. Это ограничение не распространяется на другие виды использования MIME, такие как веб-службы с вложениями MIME или MTOM .
Начиная с RFC 2822, соответствующие имена полей заголовка сообщения и значения используют символы ASCII; значения, которые содержат данные, отличные от ASCII, должны использовать синтаксис MIME encoded-word (RFC 2047) вместо литеральной строки. Этот синтаксис использует строку символов ASCII, указывающую как исходную кодировку символов (" charset "), так и content-transfer-encoding, используемую для отображения байтов набора символов в символы ASCII.
Форма: « кодировка набора =?символов закодированный текст ».???=
Q", обозначающей Q-кодирование, похожее на кодировку quote-printable , либо " B", обозначающей кодировку base64 .Коды ASCII для вопросительного знака ("?") и знака равенства ("=") не могут быть представлены напрямую, поскольку они используются для разграничения закодированного слова. Код ASCII для пробела не может быть представлен напрямую, поскольку это может привести к тому, что старые синтаксические анализаторы будут нежелательно разбивать закодированное слово. Чтобы сделать кодировку меньше и легче для чтения, для представления кода ASCII для пробела используется подчеркивание, что создает побочный эффект, заключающийся в том, что подчеркивание не может быть представлено напрямую. Использование закодированных слов в определенных частях полей заголовков накладывает дополнительные ограничения на то, какие символы могут быть представлены напрямую.
Например,
Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=
интерпретируется как «Тема: ¡Hola, señor!».
Формат закодированного слова не используется для имен полей заголовков (например, Subject ). Эти имена обычно являются английскими терминами и всегда в ASCII в необработанном сообщении. При просмотре сообщения с помощью неанглоязычного почтового клиента имена полей заголовков могут быть переведены клиентом.
Составное сообщение MIME содержит границу в поле заголовка Content-Type:; эта граница, которая не должна встречаться ни в одной из частей, размещается между частями, а также в начале и конце тела сообщения следующим образом:
MIME-версия: 1.0 Тип содержимого: multipart / mixed ; border = frontier Это сообщение, состоящее из нескольких частей в формате MIME.--frontier Тип содержимого: текст / обычный Это текст сообщения.--frontier Тип содержимого: приложение / поток октетов Кодировка передачи содержимого: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--Каждая часть состоит из собственного заголовка содержимого (ноль или более Content-полей заголовка) и тела. Многокомпонентное содержимое может быть вложенным. Тип Content-Transfer-Encodingмногокомпонентного типа всегда должен быть "7bit", "8bit" или "binary", чтобы избежать осложнений, которые могут возникнуть из-за нескольких уровней декодирования. Многокомпонентный блок в целом не имеет набора символов; символы, не входящие в ASCII, в заголовках частей обрабатываются системой Encoded-Word, а тела частей могут иметь указанные наборы символов, если это подходит для их типа содержимого.
Примечания:
Стандарт MIME определяет различные подтипы multipart-message, которые определяют природу частей сообщения и их связь друг с другом. Подтип указывается в Content-Typeполе заголовка всего сообщения. Например, multipart MIME-сообщение, использующее подтип digest, будет иметь свой Content-Typeнабор как "multipart/digest".
Первоначально RFC определял четыре подтипа: смешанный, дайджест, альтернативный и параллельный. Минимально соответствующее приложение должно поддерживать смешанный и дайджест; другие подтипы являются необязательными. Приложения должны обрабатывать нераспознанные подтипы как «multipart/mixed». Дополнительные подтипы, такие как подписанный и form-data, с тех пор были отдельно определены в других RFC.
multipart/mixed используется для отправки файлов с различными Content-Typeполями заголовка в строке (или в виде вложений). При отправке изображений или других легко читаемых файлов большинство почтовых клиентов будут отображать их в строке (если явно не указано с помощью Content-Disposition: attached, в этом случае они предлагаются в виде вложений). Тип содержимого по умолчанию для каждой части — "text/plain".
Тип определен в RFC 2046. [5]
multipart/digest — простой способ отправки нескольких текстовых сообщений. Тип содержимого по умолчанию для каждой части — «message/rfc822».
Тип MIME определен в RFC 2046. [6]
Подтип multipart/alternative указывает, что каждая часть является «альтернативной» версией того же (или похожего) контента, каждая в другом формате, обозначенном заголовком «Content-Type». Порядок частей имеет значение. RFC1341 гласит: В общем случае пользовательские агенты, составляющие multipart/alternative сущности, должны размещать части тела в порядке возрастания предпочтения, то есть с предпочтительным форматом в конце. [7]
Затем системы могут выбрать «лучшее» представление, которое они способны обработать; как правило, это будет последняя часть, которую система может понять, хотя на это могут влиять и другие факторы.
Поскольку клиент вряд ли захочет отправлять версию, которая менее верна, чем версия с простым текстом, эта структура помещает версию с простым текстом (если она есть) первой. Это облегчает жизнь пользователям клиентов, которые не понимают многокомпонентные сообщения.
Чаще всего multipart/alternative используется для электронной почты с двумя частями: одна часть с обычным текстом (text/plain) и одна часть с HTML (text/html) . Часть с обычным текстом обеспечивает обратную совместимость, а часть с HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю возможность предпочесть обычный текст HTML; это пример того, как локальные факторы могут влиять на то, как приложение выбирает, какую «лучшую» часть сообщения отображать.
Хотя предполагается, что каждая часть сообщения представляет собой одно и то же содержимое, стандарт не требует, чтобы это было каким-либо образом реализовано. Одно время антиспамовые фильтры проверяли только текстовую/простую часть сообщения, [8] потому что ее легче анализировать, чем текстовую/html часть. Но спамеры в конечном итоге воспользовались этим, создав сообщения с безобидно выглядящей текстовой/простой частью и рекламой в текстовой/html части. Антиспамовое программное обеспечение в конечном итоге поняло этот трюк, штрафуя сообщения с сильно отличающимся текстом в многочастном/альтернативном сообщении. [8]
Тип определен в RFC 2046. [9]
multipart/related используется для указания того, что каждая часть сообщения является компонентом совокупного целого. Это для составных объектов, состоящих из нескольких взаимосвязанных компонентов — правильное отображение не может быть достигнуто путем индивидуального отображения составных частей. Сообщение состоит из корневой части (по умолчанию первой), которая ссылается на другие части в строке, которые, в свою очередь, могут ссылаться на другие части. Части сообщения обычно ссылаются с помощью Content-ID . Синтаксис ссылки не указан и вместо этого диктуется кодировкой или протоколом, используемым в части.
Одним из распространенных применений этого подтипа является отправка веб-страницы с изображениями в одном сообщении. Корневая часть будет содержать HTML- документ и использовать теги изображений для ссылки на изображения, хранящиеся в последних частях.
Тип определен в RFC 2387.
multipart/report — это тип сообщения, который содержит данные, отформатированные для чтения почтовым сервером. Он делится на text/plain (или какой-либо другой контент/тип, который легко читается) и message/delivery-status, который содержит данные, отформатированные для чтения почтовым сервером.
Тип определен в RFC 6522.
Сообщение multipart/signed используется для присоединения цифровой подписи к сообщению. Оно состоит ровно из двух частей тела, части тела и части подписи. Вся часть тела, включая поля mime, используется для создания части подписи. Возможны многие типы подписей, например "application/pgp-signature" (RFC 3156) и "application/pkcs7-signature" ( S/MIME ).
Тип определен в RFC 1847. [10]
Сообщение multipart/encrypted состоит из двух частей. Первая часть содержит контрольную информацию, необходимую для расшифровки второй части application/octet-stream. Подобно подписанным сообщениям, существуют различные реализации, которые идентифицируются по отдельным типам содержимого для контрольной части. Наиболее распространенными типами являются "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.