MIME

Многоцелевые расширения почты Интернета ( 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 [ править ]

MIME-версия [ править ]

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

MIME-версия: 1.0

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

Content-Type [ править ]

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

Тип содержимого: текст / простой

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

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

Content-Disposition [ править ]

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

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

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

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

Content-Disposition: вложение; filename = genome.jpeg; модификация-date = "среда, 12 февраля 1997 г. 16:29:51 -0500";

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

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

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

Content-Transfer-Encoding [ править ]

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

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

Encoded-Word [ править ]

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

Форма такая: « =?кодировка ?кодированного ?текста?= ».

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

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

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

Например,

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

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

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

Составные сообщения [ править ]

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

MIME-версия: 1.0 Content-Type: multipart / mixed ; граница = граница  Это сообщение состоит из нескольких частей в формате MIME.--frontier Content-Type: текст / простой Это тело сообщения.--frontier Content-Type: приложение / поток октетов Кодирование передачи содержимого: base64 PGh0bWw + CiAgPGhlYWQ + CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA + VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3gow= CiAg5 + CiAg5

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

Заметки:

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

Составные подтипы [ править ]

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

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

смешанный [ править ]

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

Тип определен в RFC 2046. ^[4]

дайджест [ править ]

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

Тип MIME определен в RFC 2046. ^[5]

альтернатива [ править ]

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

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

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

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

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

Тип определен в RFC 2046. ^[8]

связанные [ править ]

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

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

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

отчет [ редактировать ]

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

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

подписано [ править ]

Составное / подписанное сообщение используется для прикрепления цифровой подписи к сообщению. У него ровно две части тела, часть тела и часть подписи. Вся часть тела, включая поля mime, используется для создания части подписи. Возможны многие типы подписи, такие как «application / pgp-signature» (RFC 3156) и «application / pkcs7-signature» ( S / MIME ).

Тип определен в RFC 1847. ^[9]

зашифрованный [ править ]

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

Тип MIME, определенный в RFC 1847. ^[10]

данные формы [ править ]

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

x-mixed-replace [ править ]

Тип содержимого multipart / x-mixed-replace был разработан как часть технологии для имитации передачи на сервер и потоковой передачи по HTTP.

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

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

byterange [ править ]

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

Документация RFC [ править ]

• RFC 1426, Расширение службы SMTP для 8-битного транспорта MIME . Дж. Кленсин , Н. Фрид , М. Роуз , Э. Штефферуд , Д. Крокер. Февраль 1993 г.
• RFC 1847, Безопасность Multiparts для 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 Multipart / Related Content-type
• RFC 1521, Механизмы определения и описания формата тел Интернет-сообщений

См. Также [ править ]

• 8BITMIME
• Юникод и электронная почта
• Двоичное кодирование текста
• Прямая Internet Message Encapsulation (DIME) - это в настоящее время заменен Microsoft -proposed протокол , предназначенный как обтекаемый MIME, в первую очередь для использования в веб - службах .
• Простой протокол передачи почты (SMTP)
• Mailcap
• mime.types
• Связывание и внедрение объектов (OLE)
• S / MIME
• SOAP с вложениями
• Uuencoding
• ВПИМ

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Хьюз, Л. (1998). Протоколы электронной почты в Интернете, стандарты и реализация . Издательство Artech House. 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  - список каталогов типов и подтипов контента, поддерживаемый Internet Assigned Numbers Authority .
• Список наборов символов
• Правильная настройка типов MIME сервера
• Легкое для понимания описание составных сообщений от MH & nmh
• «Ребята из MIME: как два интернет-гуру навсегда изменили электронную почту» . 1 февраля 2011 г.
• Бесплатная онлайн-проверка PHP MIME
• Бесплатный онлайн-валидатор электронной почты MIME