Иногда случается так, что мы используем или ссылаемся на термин или технологию программного обеспечения много времени, не будучи очень знакомыми с ним. MIME — один из таких терминов для меня. Мы используем стандарты MIME для обмена сообщениями между различными конечными точками, например, в электронной почте, веб-службах и т. Д.
MIME везде, и мы могли бы использовать его бесчисленное количество раз за всю нашу карьеру в области программного обеспечения. Но что именно MIME? Я задал этот вопрос некоторым из моих друзей-разработчиков программного обеспечения и получил неоднозначные ответы. Некоторые называют MIME типом MIME, некоторые пытались процитировать полную форму MIME. Было ясно, что MIME — не очень хорошо понятая концепция. В этом посте мы попытаемся пролить свет на то, что это за MIME?
история
Согласно RFC 822 оригинальные почтовые протоколы были созданы для поддержки только стандартной кодировки США ASCII. Это оставляло желать лучшего.
- Что, если отправитель хочет отправить сообщение в другой кодировке, скажем, хинди, или на испанском или любой другой кодировке?
- Что если отправитель хочет отправить многокомпонентное сообщение?
- Что если отправитель хочет добавить не текстовое вложение?
- Что если отправители захотят установить заголовок сообщения в другой кодировке?
Чтобы решить эти проблемы, Инженерная рабочая группа по Интернету ( IETF ) разработала новый формат почтового сообщения. Это было расширение к известной RFC822. Этот новый формат упоминается как сообщения MIME.
Что такое MIME?
MIME расшифровывается как многоцелевые расширения электронной почты в Интернете. MIME — это интернет-стандарт, который расширяет поддержку сообщений электронной почты, не текстовое содержимое ASCII, нетекстовое вложение, тело сообщения Multipart и заголовок не US-ASCII. MIME был настолько успешным, что был принят в качестве формата сообщений для общей сети и множества других технологий. Формат MIME определяется с использованием следующих документов RFC.
- RFC 2045 : описывает различные заголовки, используемые для описания структуры сообщений MIME.
- RFC 2046 : определяет начальный набор типов носителей.
- RFC 2047 : Описывает расширения к RFC 822, чтобы разрешить текстовые данные не-US-ASCII в полях заголовка почты Интернета
- RFC 2048 : определяет различные процедуры регистрации IANA для объектов, связанных с MIME
- RFC 2049 : Предоставляет критерии соответствия MIME, а также некоторые примеры форматов сообщений MIME, подтверждений и библиографии.
Структура сообщения MIME
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
MIME-Version: 1.0 From: Nathaniel Borenstein <nsb@nsb.fv.com> To: Ned Freed <ned@innosoft.com> Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 --unique-boundary-1 ... Some text appears here ... --unique-boundary-1 Content-type: text/plain; charset=US-ASCII --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64 ... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here ... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64 ... base64-encoded image data goes here ... --unique-boundary-2-- --unique-boundary-1 Content-type: text/enriched <b>this is a test</b> --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable ... Additional text in ISO-8859-1 goes here ... --unique-boundary-1-- |
Выше приведен пример сообщения MIME. При ближайшем рассмотрении вы обнаружите, что он имеет следующие части.
- Заголовки
- Несколько частей тела, которые имеют разные типы контента
Multipart
Многокомпонентное сообщение MIME может содержать одну или несколько частей тела, которые могут иметь разные типы содержимого, части тела могут быть встроены в другую часть тела и заключены в границы, указанные в граничном параметре в заголовке типа содержимого родительской части тела.
Рассекающие заголовки MIME
Версия MIME
|
1
|
MIME-Version: 1.0 |
Наличие этого заголовка позволяет нам знать, что у нас есть сообщение электронной почты MIME. Первоначальное намерение этого заголовка состояло в том, чтобы поддержать будущие версии MIME. Но то, как реализован MIME, делает невозможным изменение версии. Теперь версия всегда установлена на 1.0 и означает, что у нас есть не американское ASCII-сообщение с нетекстовыми вложениями.
Заголовок типа контента
|
1
2
|
Content-Type: multipart/mixed; boundary=unique-boundary-1 |
Заголовок типа содержимого определяет тип данных, присутствующий в теле и частях тела сообщений. Это помогает клиенту выбрать подходящий механизм, с помощью которого он может отображать сообщение для пользователя. За определением типа / подтипа обычно следует граничное значение. Граничное значение представляет блок части тела, и вся часть тела должна начинаться и заканчиваться этой границей. Например
|
1
2
3
4
5
|
--unique-boundary-1--body part goes here--unique-boundary-1-- |
Заголовок расположения содержимого
|
01
02
03
04
05
06
07
08
09
10
|
content-disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-parm ) disposition-type = "attachment" | disp-extension-token disposition-parm = filename-parm | disp-extension-parm filename-parm = "filename" "=" quoted-string disp-extension-token = token disp-extension-parm = token "=" ( token | quoted-string )An example is Content-Disposition: attachment; filename="fname.ext" |
Тип тела сообщения MIME должен отображаться как есть, если только заголовок расположения содержимого не указан в качестве вложения. Если указан заголовок вложения Content-Disposition: тогда это означает, что часть тела не должна отображаться нормально, скорее она должна отображаться как вложение, и нажатие на нее должно привести к загрузке части тела в имени файла, указанном в параметре имени файла заголовка.
Content-Transfer-Encoding
Как мы знаем, многие протоколы, такие как SMTP, разрешают сообщения только с кодированием 7BIT. Теперь с MIME можно также отправлять 8-битные двоичные данные. Это становится возможным только путем кодирования 8-битных или двоичных данных в формате 7BIT. Для этого MIME предоставляет заголовок Content-Transfer-Encoding. Например, рассмотрим часть тела, состоящую из аудиофайла.
|
1
2
|
Content-Type: audio/basicContent-Transfer-Encoding: base64 |
Теперь, поскольку аудиофайл находится в двоичном формате, он должен быть перекодирован в формате 7BIT. Мы используем заголовок Content-Transfer-Encoding для преобразования его в формат 7BIT с кодировкой BASE 64. Помимо базы 64 у нас также есть следующая кодировка.
- 7BIT — по умолчанию
- Base64
- Экранированные кавычки
- 8BIT
- BINARY
- х-EncodingName
Я надеюсь, что этот пост проливает некоторый дополнительный свет на то, что MIME. Этот пост является результатом исследований и чтения, которые я провел в последние несколько дней, и, поскольку я человек, в нем также могут быть некоторые ошибки. Если кто-то из вас не найдет какие-то важные основные моменты, пожалуйста, дайте мне знать, чтобы я мог добавить их в пост. Если вы считаете этот пост полезным, оставьте комментарий или два.