МИМ

О пантомиме как виде исполнительского искусства см. «Мим» . Чтобы узнать о других значениях, см. Мим (значения) .

Многоцелевые расширения почты Интернета ( MIME ) — это стандарт, который расширяет формат сообщений электронной почты для поддержки текста в наборах символов, отличных от ASCII , а также вложений аудио, видео, изображений и прикладных программ. Тело сообщения может состоять из нескольких частей, а информация заголовка может быть указана в наборах символов, отличных от ASCII. Сообщения электронной почты в формате MIME обычно передаются по стандартным протоколам, таким как простой протокол передачи почты (SMTP), протокол почтового отделения (POP) и протокол доступа к сообщениям Интернета (IMAP).

MIME — это Интернет-стандарт . Это указано в серии запросов на комментарии : РФК 2045 , РФК 2046 , РФК 2047 , РФК 4288 , RFC 4289 и РФК 2049 . Интеграция с электронной почтой SMTP указана в RFC 1521 и РФК 1522 .

Хотя формализм MIME был разработан в основном для SMTP, его типы контента также важны и в других протоколах связи . В протоколе передачи гипертекста (HTTP) для Всемирной паутины серверы вставляют поле заголовка MIME в начале любой веб-передачи. Клиенты используют заголовок типа контента или типа мультимедиа , чтобы выбрать подходящее приложение просмотра для указанного типа данных.

История

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

Поля заголовка MIME

MIME-версия

Наличие этого поля заголовка указывает на то, что сообщение имеет формат MIME. Обычно это значение «1,0». Поле выглядит следующим образом:

MIME-Version: 1.0

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

Тип контента

Это поле заголовка указывает тип носителя содержимого сообщения, состоящий из типа и подтипа , например

Content-Type: text/plain

Благодаря использованию многочастного типа MIME позволяет почтовым сообщениям иметь части, расположенные в древовидной структуре , где конечные узлы представляют собой любой несоставной тип контента, а неконечные узлы представляют собой любой из множества составных типов.Этот механизм поддерживает:

• простые текстовые сообщения с использованием text/plain (значение по умолчанию для «Content-Type:»)
• текст плюс вложения ( составной/смешанный с текстовой/обычной частью и другими нетекстовыми частями). Сообщение MIME, включающее вложенный файл, обычно указывает исходное имя файла с заголовком «Content-Disposition», так что тип файла указывается как типом содержимого MIME, так и (обычно зависящим от ОС ). расширением имени файла
• ответ с прикрепленным оригиналом ( составной/смешанный с текстовой/обычной частью и исходным сообщением в виде части сообщения/rfc822 )
• альтернативный контент, например сообщение, отправленное как в обычном текстовом формате, так и в другом формате, например HTML ( многочастный/альтернативный с одинаковым содержимым в text/plain и text/html ). формах
• изображение, аудио, видео и приложение (например, image/jpeg , audio/mp3 , video/mp4 и application/msword и т. д.)
• многие другие конструкции сообщений

Содержание-Расположение

Исходные спецификации MIME описывали только структуру почтовых сообщений. Они не затронули вопрос стилей изложения. Поле заголовка content-disposition было добавлено в RFC 2183 для указания стиля представления. Часть MIME может иметь:

• расположение встроенного содержимого, что означает, что оно должно автоматически отображаться при отображении сообщения, или
• расположение содержимого вложения , и в этом случае оно не отображается автоматически и требует от пользователя определенных действий для его открытия.

Помимо стиля представления, поле Content-Disposition также предоставляет параметры для указания имени файла, даты создания и даты изменения, которые могут использоваться почтовым агентом читателя для хранения вложения.

Следующий пример взят из RFC 2183, где определено поле заголовка:

Content-Disposition: attachment; filename=genome.jpeg;  modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

Имя файла может быть закодировано, как определено в RFC 2231.

По состоянию на 2010 год большинство почтовых пользовательских агентов не полностью следовали этому предписанию. Широко используемый почтовый клиент Mozilla Thunderbird игнорирует поля размещения содержимого в сообщениях и использует независимые алгоритмы для выбора частей MIME для автоматического отображения. Thunderbird до версии 3 также отправляет вновь составленные сообщения со встроенным расположением содержимого для всех частей MIME. Большинство пользователей не знают, как настроить расположение содержимого для вложения . Многие почтовые пользовательские агенты также отправляют сообщения с именем файла в имени параметре заголовка типа контента вместо параметра имени файла в поле заголовка Content-Disposition . Такая практика не рекомендуется, так как имя файла должно быть указано либо с параметром filename , либо с обоими параметрами filename и name .

В HTTP поле заголовка ответа Content-Disposition: Attachment обычно используется как подсказка клиенту, чтобы он представил тело ответа в виде загружаемого файла. Обычно, получая такой ответ, веб-браузер предлагает пользователю сохранить его содержимое в виде файла, а не отображать его в виде страницы в окне браузера, при этом имя файла предполагает имя файла по умолчанию.

Кодирование передачи контента

В июне 1992 года MIME (RFC 1341, устаревший благодаря RFC 2045) определил набор методов для представления двоичных данных в форматах, отличных от текстового формата ASCII. Поле заголовка Content -Transfer-Encoding: MIME имеет двустороннее значение:

• Он указывает, использовалась ли схема кодирования двоичного текста в текст поверх исходной кодировки, как указано в заголовке Content-Type:

1. Если использовался такой метод кодирования двоичного текста в текст, указывается, какой именно.
2. В противном случае он предоставляет описательную метку для формата контента с учетом наличия 8-битного или двоичного контента.

RFC и список кодировок передачи IANA определяют приведенные ниже значения, которые не чувствительны к регистру. «7бит», «8бит» и «двоичный» означают, что поверх исходной кодировки не использовалось преобразование двоичного текста в текст. В этих случаях поле заголовка на самом деле является избыточным для почтового клиента для декодирования тела сообщения, но оно все равно может быть полезно в качестве индикатора того, какой тип объекта отправляется. Значения ' quoted-printable ' и ' base64 ' сообщают почтовому клиенту, что использовалась схема кодирования двоичного текста и что необходимо соответствующее начальное декодирование, прежде чем сообщение можно будет прочитать в исходной кодировке (например, UTF-8).

• Подходит для использования с обычным SMTP:
  • 7 бит – до 998 октетов на строку диапазона кодов 1..127, при этом CR и LF (коды 13 и 10 соответственно) могут появляться только как часть окончания строки CRLF. Это значение по умолчанию.
  • Quote-printable — используется для кодирования произвольных последовательностей октетов в форму, удовлетворяющую правилам 7 бит. Разработан так, чтобы быть эффективным и в основном удобным для чтения человеком при использовании для текстовых данных, состоящих в основном из символов US-ASCII, но также содержащих небольшую часть байтов со значениями вне этого диапазона.
  • base64 – используется для кодирования произвольных последовательностей октетов в форму, удовлетворяющую правилам 7 бит. Разработан для эффективной работы с нетекстовыми 8-битными и двоичными данными. Иногда используется для текстовых данных, в которых часто используются символы, отличные от US-ASCII.
• Подходит для использования с SMTP-серверами, поддерживающими расширение SMTP 8BITMIME (RFC 6152):
  • 8 бит - до 998 октетов в строке, при этом CR и LF (коды 13 и 10 соответственно) могут появляться только как часть окончания строки CRLF.
• Подходит для использования с SMTP-серверами, поддерживающими расширение SMTP BINARYMIME (RFC 3030):
  • двоичный – любая последовательность октетов.

Не определена кодировка, которая явно предназначена для отправки произвольных двоичных данных через транспорт SMTP с расширением 8BITMIME. Таким образом, если BINARYMIME не поддерживается, иногда все еще могут быть полезны base64 или quote-printable (с связанной с ними неэффективностью). Это ограничение не распространяется на другие виды использования MIME, такие как веб-службы с вложениями MIME или MTOM .

Закодированное слово

Начиная с RFC 2822, соответствующие имена и значения полей заголовка сообщения используют символы ASCII; значения, содержащие данные, отличные от ASCII, должны использовать синтаксис кодированного слова MIME (RFC 2047) вместо строки-литерала. В этом синтаксисе используется строка символов ASCII, указывающая как исходную кодировку символов (« набор символов »), так и кодировку передачи контента, используемую для преобразования байтов набора символов в символы ASCII.

Форма такая: " =?кодировка ?кодирование ?закодированный текст ?=".

• charset может быть любым набором символов, зарегистрированным в IANA . Обычно это та же кодировка, что и тело сообщения.
• кодировка может быть либо " Q" обозначает Q-кодировку, аналогичную кодировке , доступной для печати , или " B", обозначающий кодировку base64 .
• Закодированный текст — это текст в кодировке Q или Base64.
• Закодированное слово не может иметь длину более 75 символов, включая кодировку , кодировку , закодированный текст и разделители. Если желательно закодировать больше текста, чем помещается в закодированное слово из 75 символов, можно использовать несколько кодированных слов (разделенных CRLF SPACE).

Разница между Q-кодированием и цитируемой печатью

Коды ASCII для вопросительного знака («?») и знака равенства («=") не могут быть представлены напрямую, поскольку они используются для разделения закодированного слова. Код ASCII для пробела не может быть представлен напрямую, поскольку это может привести к тому, что старые анализаторы нежелательно разделят закодированное слово. Чтобы сделать кодировку меньше и ее легче читать, подчеркивание используется для представления кода ASCII для пробела, создавая побочный эффект, заключающийся в том, что подчеркивание не может быть представлено напрямую. Использование закодированных слов в определенных частях полей заголовка накладывает дополнительные ограничения на то, какие символы могут быть представлены напрямую.

Например,

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

интерпретируется как «Тема: ¡Hola, сеньор!».

Формат закодированного слова не используется для имен полей заголовков (например, Тема ). Эти имена обычно представляют собой английские термины и всегда в формате ASCII в необработанном сообщении. При просмотре сообщения в почтовом клиенте, отличном от английского, имена полей заголовка могут быть переведены клиентом.

Многочастные сообщения

Составное сообщение MIME содержит границу в поле заголовка. Content-Type:; эта граница, которая не должна встречаться ни в одной из частей, размещается между частями, а также в начале и конце тела сообщения следующим образом:

MIME-Version: 1.0Content-Type: multipart/mixed; boundary=frontierThis is a message with multiple parts in MIME format.--frontierContent-Type: text/plainThis is the body of the message.--frontierContent-Type: application/octet-streamContent-Transfer-Encoding: base64PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==--frontier--

Каждая часть состоит из собственного заголовка контента (ноль или более Content- поля заголовка) и тело. Содержимое, состоящее из нескольких частей, может быть вложенным. Content-Transfer-Encoding составного типа всегда должен быть «7бит», «8бит» или «двоичный», чтобы избежать сложностей, которые могут возникнуть из-за нескольких уровней декодирования. Составной блок в целом не имеет кодировки; Символы, отличные от ASCII, в заголовках частей обрабатываются системой Encoded-Word , а для тел частей могут быть указаны кодировки, соответствующие их типу содержимого.

Примечания:

• Перед первой границей находится область, игнорируемая MIME-совместимыми клиентами. Эта область обычно используется для отправки сообщений пользователям старых клиентов, не поддерживающих MIME.
• Отправляющий почтовый клиент должен выбрать граничную строку, которая не конфликтует с основным текстом. Обычно это делается путем вставки длинной случайной строки.
• Последняя граница должна иметь в конце два дефиса.

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

Стандарт MIME определяет различные подтипы многочастных сообщений, которые определяют природу частей сообщения и их взаимосвязь друг с другом. Подтип указан в Content-Type Поле заголовка всего сообщения. Например, составное MIME-сообщение, использующее подтип дайджеста, будет иметь Content-Type установить как «многочастный/дайджест».

Первоначально RFC определил четыре подтипа: смешанный, дайджест, альтернативный и параллельный. Минимально совместимое приложение должно поддерживать смешанный и дайджест-анализ; другие подтипы являются необязательными. Приложения должны рассматривать нераспознанные подтипы как «составные/смешанные». Дополнительные подтипы, такие как подписанные и данные формы, с тех пор были определены отдельно в других RFC.

смешанный

multipart/mixed используется для отправки файлов с разными Content-Type поля заголовка встроены (или в виде вложений). При отправке изображений или других легко читаемых файлов большинство почтовых клиентов будут отображать их внутри (если явно не указано с помощью Content-Disposition: Attachment, и в этом случае они предлагаются как вложения). Тип контента по умолчанию для каждой части — «текст/обычный».

Тип определен в RFC 2046.

переваривать

multipart/digest — это простой способ отправить несколько текстовых сообщений. Тип контента по умолчанию для каждой части — «message/rfc822».

Тип MIME определен в RFC 2046.

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

Подтип multipart/alternative указывает, что каждая часть представляет собой «альтернативную» версию того же (или аналогичного) контента, каждая в другом формате, обозначенном заголовком «Content-Type». Порядок частей имеет большое значение. В RFC1341 говорится: Как правило, пользовательские агенты, составляющие составные/альтернативные сущности, должны размещать части тела в порядке возрастания предпочтений, то есть предпочтительный формат должен быть последним.

Затем системы могут выбрать «лучшее» представление, которое они способны обработать; в общем, это будет последняя часть, которую сможет понять система, хотя на это могут повлиять и другие факторы.

Поскольку клиент вряд ли захочет отправить версию, которая менее точна, чем версия в виде обычного текста, эта структура помещает версию в виде обычного текста (если она присутствует) первой. Это облегчает жизнь пользователям клиентов, которые не понимают составные сообщения.

Чаще всего multipart/alternative используется для электронной почты, состоящей из двух частей: обычного текста (text/plain) и HTML (text/html) . Часть обычного текста обеспечивает обратную совместимость, а часть HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю возможность предпочесть простой текст HTML; это пример того, как местные факторы могут влиять на то, как приложение выбирает «лучшую» часть сообщения для отображения.

Хотя предполагается, что каждая часть сообщения представляет одно и то же содержимое, стандарт не требует какого-либо соблюдения этого требования. Когда-то антиспам-фильтры проверяли только текстовую/обычную часть сообщения. потому что его легче анализировать, чем текстовую/html-часть. Но спамеры в конечном итоге воспользовались этим, создавая сообщения с безобидной на вид частью text/plain и рекламой в части text/html. Программное обеспечение для защиты от спама в конечном итоге подхватило этот трюк, наказывая сообщения с сильно отличающимся текстом в составных/альтернативных сообщениях.

Тип определен в RFC 2046.

связанный

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

Одним из распространенных вариантов использования этого подтипа является отправка веб-страницы с изображениями в одном сообщении. Корневая часть будет содержать HTML- документ и использовать теги изображений для ссылки на изображения, хранящиеся в последних частях.

Тип определен в RFC 2387.

отчет

multipart/report — это тип сообщения, который содержит данные, отформатированные для чтения почтовым сервером. Он разделен на текст/обычный текст (или какой-либо другой легко читаемый контент/тип) и сообщение/статус доставки, которое содержит данные, отформатированные для чтения почтовым сервером.

Тип определен в 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 был разработан как часть технологии эмуляции передачи данных с сервера и потоковой передачи через HTTP.

Все части сообщения смешанной замены имеют одинаковое семантическое значение. Однако каждая часть аннулирует – «заменяет» – предыдущие части, как только она получена полностью. Клиенты должны обрабатывать отдельные части сразу по их прибытии и не должны ждать завершения всего сообщения.

Первоначально разработанный Netscape , он по-прежнему поддерживается Mozilla , Firefox , Safari и Opera . Он обычно используется в IP-камерах как тип MIME для MJPEG . потоков Он поддерживался Chrome для основных ресурсов до 2013 года (изображения по-прежнему могут отображаться с использованием этого типа контента).

диапазон байтов

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

RFC-документация

• RFC 1426 , Расширение службы SMTP для 8-битного MIME-транспорта . Дж. Кленсин , Н. Фрид , М. Роуз , Э. Стефферуд , Д. Крокер. Февраль 1993 года.
• RFC 1847 , Составные части безопасности для MIME: Multipart/Signed и Multipart/Encrypted
• RFC 3156 , Безопасность MIME с OpenPGP
• RFC 2045 , MIME, часть первая: формат тел интернет-сообщений
• RFC 2046 , MIME, часть вторая: типы носителей . Н. Фрид, Натаниэль Боренштейн . Ноябрь 1996 года.
• RFC 2047 , MIME, часть третья: расширения заголовков сообщений для текста, отличного от ASCII . Кейт Мур . Ноябрь 1996 года.
• RFC 4288 , MIME, часть четвертая: спецификации типов носителей и процедуры регистрации .
• RFC 4289 , MIME, часть четвертая: процедуры регистрации . Н. Фрид, Дж. Кленсин. Декабрь 2005 г.
• RFC 2049 , MIME, часть пятая: критерии соответствия и примеры . Н. Фрид, Н. Боренштейн. Ноябрь 1996 года.
• RFC 2183 , Передача информации о представлении в интернет-сообщениях: поле заголовка Content-Disposition . Трост Р., Дорнер С. и К. Мур. Август 1997 года.
• RFC 2231 , Значение параметра MIME и расширения закодированных слов: наборы символов, языки и продолжения . Н. Фрид, К. Мур. Ноябрь 1997 года.
• RFC 2387 , Многочастный/связанный тип контента MIME
• RFC 1521 , Механизмы определения и описания формата тел интернет-сообщений.
• RFC 7578 , Возврат значений из форм: multipart/form-data

См. также

• 8БИТМИМ
• Кодирование двоичного кода в текст
• Прямая инкапсуляция сообщений Интернета (DIME) — ныне замененный Microsoft, предложенный протокол, предназначенный как упрощенный MIME, в первую очередь для использования в веб-службах .
• Тип носителя
• Связывание и внедрение объектов (OLE)
• S/MIME
• Простой протокол передачи почты (SMTP)
• SOAP с вложениями
• Юникод и электронная почта
• Uuкодирование
• ВПИМ

Дальнейшее чтение

• Хьюз, Л. (1998). Протоколы электронной почты Интернета, стандарты и реализация . Издательство «Артех Хаус». ISBN  978-0-89006-939-4 .
• Джонсон, К. (2000). Протоколы электронной почты Интернета: Руководство разработчика . Аддисон-Уэсли Профессионал. ISBN  978-0-201-43288-6 .
• Лошин, П (1999). Основные стандарты электронной почты: RFC и протоколы стали практичными . Джон Уайли и сыновья. ISBN  978-0-471-34597-8 .
• Ротон, Дж (1999). Руководство программиста по электронной почте в Интернете: SMTP, POP, IMAP и LDAP . Эльзевир. ISBN  978-1-55558-212-8 .
• Вуд, Д. (1999). Программирование Интернет-почты . О'Рейли. ISBN  978-1-56592-479-6 .

Внешние ссылки

• Типы мультимедиа MIME — список каталогов типов и подтипов контента, поддерживаемый Управлением по присвоению номеров в Интернете .
• Список наборов символов
• Правильная настройка типов MIME сервера
• Легкое и понятное описание составных сообщений от MH и nmh.
• «Ребята из MIME: Как два интернет-гуру навсегда изменили электронную почту» . 1 февраля 2011 г.
• Бесплатная онлайн-проверка PHP MIME
• Бесплатный онлайн-валидатор электронной почты MIME