MIME

MIME (/maɪm/, англ. Multipurpose Internet Mail Extensions — многоцелевые расширения интернет-почты) — стандарт, описывающий передачу различных типов данных по электронной почте, а также, в общем случае, спецификация для кодирования информации и форматирования сообщений таким образом, чтобы их можно было пересылать по Интернету.

MIME

Введение

править

MIME определяет механизмы для передачи разного рода информации внутри текстовых данных (в частности, с помощью электронной почты), а именно: текст на языках, для которых используются кодировки, отличные от ASCII, и нетекстовые данные, такие, как картинки, музыка, фильмы и программы. MIME является также фундаментальным компонентом коммуникационных протоколов, таких как HTTP, которым нужно, чтобы данные передавались в контексте сообщений, подобных e-mail, даже если данные реально не являются e-mail.

Основной формат электронных сообщений определен в RFC 5322, который является обновлённой версией RFC 2822 (который, в свою очередь, является обновлённой версией RFC 822). Эти стандарты определяют похожие форматы для текстовых e-mail-заголовков и содержимого и правил, относящихся к общеиспользуемым полям, таким как To:, Subject:, From: и Date:. MIME определяет набор e-mail-заголовков для определения дополнительных атрибутов сообщения, включая тип контента, и определяет множество кодировок, которые могут быть использованы для представления 8-битных бинарных данных с помощью символов из 7-битного ASCII. MIME также определяет правила для кодирования символов из Extended ASCII (с кодами 128—255) в заголовках e-mail-сообщения, таких как Subject:.

MIME расширяем для новых типов — его определение включает метод для регистрации новых типов контента и других атрибутов.

Организация данных

править

Формат MIME поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но и в виде иерархии с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиа-типы multipart/*. Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиа-типом). Если получателю неизвестно как работать с типом, то он обрабатывает его так же, как multipart/mixed.

Для передачи множественного сообщения в заголовок Content-Type добавляется параметр boundary (граница), который обозначает последовательность символов, разделяющих части сообщения. Граница может состоять из цифр, букв и символов '()+_,-./:=?. При использовании специальных символов (не цифр и букв) значение параметра boundary следует заключать в двойные кавычки ". Максимальная длина границы — 70 символов[1].

Начало каждой части сообщения обозначается строкой --boundary. Конец последнего сообщения обозначается строкой --boundary--. Самые первые символы переноса строки CRLF (коды 13 и 10), которыми начинаются и заканчиваются пограничные строки, не входят в содержимое самой части. Если за ними следуют ещё переносы строк, то они уже принадлежат включаемой части.

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

В самом начале включаемой части располагаются заголовки, описывающие её содержимое (Content-Type, Content-Length и т. п.). Перед непосредственно телом части обязательно должна быть пустая строка, даже если заголовки отсутствуют. Если не определён Content-Type, то он берётся по умолчанию — text/plain.

Тест Марка Криспина

править

Марк Криспин (Mark Crispin), автор протокола IMAP, написал тест для проверки корректности обработки MIME[2]. [3] Тест представляет собой письмо в формате mbox:

Это сумасшедшее письмо! В нём около 30 вложенных друг в друга частей. Очень хороший тест

разработчики SquirrelMail[4]

Стандарты

править
RFC Дата Тема Обновлён в (Updated by) Обновляет (Updates) Заменён (Obsoleted by) Заменяет (Obsoletes)
Устаревшие
RFC 822 13 августа 1982 STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
(Формат электронной почты)
1123, 1138, 1148, 1327, 2156 2822 733 (NIC #41952)
RFC 2048 ноябрь 1996 MIME Part Four: Registration Procedures 3023  — 4288, 4289 1521, 1522, 1590
Текущие
RFC 1556 декабрь 1993 Handling of Bi-directional Texts in MIME
(Обработка двунаправленных текстов в MIME)
 —  —  —
RFC 2045 ноябрь 1996 MIME Part One: Format of Internet Message Bodies
(MIME Часть первая: Формат тела сообщений)
2184, 2231, 5335, 6532  —  — 1521, 1522, 1590
RFC 2046 ноябрь 1996 MIME Part Two: Media Types
(MIME Часть вторая: типы содержимого)
2646, 3798, 5147  —  — 1521, 1522, 1590
RFC 2047 ноябрь 1996 MIME Part Three: Message Header Extensions for Non-ASCII Text
(MIME Часть третья: Расширения заголовка для не-ASCII-текста)
2184, 2231  —  — 1521, 1522, 1590
RFC 2049 ноябрь 1996 MIME Part Five: Conformance Criteria and Examples
(MIME Часть пятая: Соответствие критериям и примеры)
 —  —  — 1521, 1522, 1590
RFC 4288 декабрь 2005 Media Type Specifications and Registration Procedures  —  —  — 2048
RFC 4289 декабрь 2005 MIME Part Four: Registration Procedures  —  —  — 2048
RFC 4855 февраль 2007 Media Type Registration of RTP Payload Formats  —  —  —

См. также

править

Примечания

править
  1. "Common Syntax". p. 20. sec. 5.1.1. doi:10.17487/RFC2046. RFC 2046 https://datatracker.ietf.org/doc/html/rfc2046. {{citation}}: |title= пропущен или пуст (справка)
  2. Письмо от Марка Криспина с описанием теста (архив)
  3. Тест (недоступная ссылка)
  4. Примечание в документации squirrelmail о тесте Марка Криспина. Дата обращения: 10 июля 2009. Архивировано 12 июня 2009 года.

Ссылки

править