Набор интернет-протоколов |
---|
Уровень приложения |
Транспортный уровень |
|
Интернет-уровень |
Связующий слой |
|
|
Многоцелевые расширения почты Интернета ( 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. Обычно значение равно «1.0». Поле выглядит следующим образом:
MIME-Version: 1.0
По словам соавтора MIME Натаниэля Боренштейна, номер версии был введен, чтобы разрешить изменения в протоколе MIME в последующих версиях. Однако Боренштейн признал недостатки в спецификации, которые препятствовали реализации этой функции: «Мы не указали должным образом, как обрабатывать будущую версию MIME... столкнуться с 2.0 или 1.1? Мне казалось, что это очевидно, но оказалось, что все реализовали это по-разному. И в результате для Интернета было бы практически невозможно когда-либо определить 2.0 или 1.1 ».
Это поле заголовка указывает тип носителя содержимого сообщения, состоящий из типа и подтипа, например
Content-Type: text/plain
Благодаря использованию многостраничного типа MIME позволяет почтовым сообщениям иметь части, упорядоченные в древовидной структуре, где конечные узлы представляют собой любой не состоящий из нескольких частей тип контента, а нелистовые узлы - это любые из множества составных типов. Этот механизм поддерживает:
Исходные спецификации 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, либо одновременно с именем файла и именем параметра.
В 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 или quoted-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, señor!».
Формат закодированного слова не используется для имен полей заголовков (например, Тема). Эти имена обычно являются английскими терминами и всегда в необработанном сообщении в кодировке ASCII. При просмотре сообщения в почтовом клиенте, отличном от английского, имена полей заголовка могут быть переведены клиентом.
Составное сообщение MIME содержит границу в поле заголовка ; эта граница, которая не должна встречаться ни в одной из частей, помещается между частями, а также в начале и конце тела сообщения следующим образом: Content-Type:
MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=frontier This is a message with multiple parts in MIME format. --frontier Content-Type: text/plain This is the body of the message. --frontier Content-Type: application/octet-stream Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--
Каждая часть состоит из собственного заголовка содержимого (ноль или более Content-
полей заголовка) и тела. Составной контент может быть вложенным. Тип Content-Transfer-Encoding
multipart всегда должен быть «7-битным», «8-битным» или «двоичным», чтобы избежать сложностей, которые могут возникнуть из-за нескольких уровней декодирования. Многокомпонентный блок в целом не имеет кодировки; Не-ASCII-символы в заголовках частей обрабатываются системой Encoded-Word, а для тел частей могут быть указаны кодировки, если они подходят для их типа содержимого.
Примечания:
Стандарт 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 / alternate указывает, что каждая часть является «альтернативной» версией одного и того же (или подобного) контента, каждая в другом формате, обозначенном заголовком Content-Type. Порядок частей имеет значение. RFC1341 гласит: В общем, пользовательские агенты, которые составляют составные / альтернативные сущности, должны размещать части тела в порядке возрастания предпочтения, то есть с предпочтительным форматом последним.
Затем системы могут выбрать «лучшее» представление, которое они способны обработать; в общем, это последняя часть, которую может понять система, хотя на это могут повлиять другие факторы.
Поскольку клиент вряд ли захочет отправить версию, которая менее точна, чем версия в виде обычного текста, эта структура помещает версию в формате обычного текста (если она есть) первой. Это облегчает жизнь пользователям клиентов, которые не понимают составные сообщения.
Чаще всего multipart / alternate используется для электронной почты, состоящей из двух частей: одного простого текста (text / plain) и одного HTML (text / html). Часть простого текста обеспечивает обратную совместимость, а часть HTML позволяет использовать форматирование и гиперссылки. Большинство почтовых клиентов предлагают пользователю возможность предпочесть простой текст HTML; это пример того, как локальные факторы могут повлиять на то, как приложение выбирает «лучшую» часть сообщения для отображения.
Хотя предполагается, что каждая часть сообщения представляет одно и то же содержимое, стандарт не требует, чтобы это соблюдалось каким-либо образом. Когда -то фильтры защиты от спама проверяли только текстовую / простую часть сообщения, потому что ее легче анализировать, чем текстовую / html-часть. Но в конечном итоге спамеры воспользовались этим, создавая сообщения с безобидно выглядящей текстовой / простой частью и рекламой в текстовой / html-части. Программное обеспечение для защиты от спама в конечном итоге нашло этот трюк, наказывая сообщения с очень другим текстом в составных / альтернативных сообщениях.
Тип определен в RFC 2046.
Параметр multipart / related используется для обозначения того, что каждая часть сообщения является компонентом совокупного целого. Он предназначен для составных объектов, состоящих из нескольких взаимосвязанных компонентов - правильное отображение не может быть достигнуто путем индивидуального отображения составных частей. Сообщение состоит из корневой части (по умолчанию первая), которая ссылается на другие встроенные части, которые, в свою очередь, могут ссылаться на другие части. 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. example
Тип содержимого multipart / x-mixed-replace был разработан как часть технологии для имитации передачи на сервер и потоковой передачи по HTTP.
Все части сообщения со смешанной заменой имеют одинаковое семантическое значение. Однако каждая часть аннулирует - «заменяет» - предыдущие части, как только она получена полностью. Клиенты должны обрабатывать отдельные части, как только они поступят, и не должны ждать завершения всего сообщения.
Первоначально разработанный Netscape, он до сих пор поддерживается Mozilla, Firefox, Safari и Opera. Он обычно используется в IP-камерах как тип MIME для потоков MJPEG. Он поддерживался Chrome для основных ресурсов до 2013 года (изображения все еще могут отображаться с использованием этого типа контента).
Multipart / byterange используется для представления несмежных диапазонов байтов одного сообщения, он используется HTTP, когда сервер возвращает несколько диапазонов байтов, и определен в RFC 2616.