MIME

Multipurpose Internet Mail Extensions (MIME) е интернет стандарт, който разширява имейл формата така, че да бъдат поддържани:

• Текст в набор от знаци, различни от ASCII таблицата
• Не-текстови прикачени файлове
• Тела на съобщенията с няколко части
• Заглавия (headers), съдържащи символи извън ASCII таблицата

OSI модел
7. Приложен слой
NNTP • SIP • SSI • DNS • FTP • Gopher • HTTP • NFS • NTP • SMPP • SMTP • DHCP • SNMP • SSH • Telnet • Netconf • други...
6. Представителен слой
MIME • XDR • TLS • SSL
5. Сесиен слой
Named Pipes • NetBIOS • SAP • L2TP • PPTP
4. Транспортен слой
TCP • UDP • SCTP • DCCP • SPX
3. Мрежов слой
IP (IPv4, IPv6) • ICMP • IPsec • IGMP • IPX • AppleTalk • IS-IS • OSPF • RIP • BGP • IGRP • EIGRP
2. Канален слой
MAC адрес • ATM • SDLC • HDLC • ARP • CSLIP • SLIP • PLIP • IEEE 802.3 • Frame Relay • ITU-T G.hn DLL • PPP • X.25 • Суич
1. Физически слой
EIA/TIA-232 • EIA/TIA-449 • ITU-T V-Series • I.430 • I.431 • POTS • PDH • SONET/SDH • PON • OTN • DSL • IEEE 802.3 • IEEE 802.11 • IEEE 802.15 • IEEE 802.16 • IEEE 1394 • ITU-T G.hn PHY • USB • Bluetooth • Хъб

Употребата на MIME се е разраснала отвъд описване на съдържанието на електронни писма и вече често се използва за описание на типове съдържание като цяло, както за уеб, така и за съхранение на богато съдържание в някои комерсиални продукти (IBM Lotus Domino и IBM Lotus Quickr)

Практически всички написани от човек имейли и сравнително голям дял от автоматичните имейли, се предават чрез обикновен протокол за трансфер на поща (Simple Mail Transfer Protocol) в MIME формат. Интернет електронната поща е дотолкова свързана с SMTP и MIME стандартите, че понякога е наричана „SMTP/MIME“ електронна поща.

Типовете съдържание, дефинирани от MIME стандарта, са от значение и извън електронните писма – например при комуникационните протоколи като HTTP за World Wide Web. HTTP изисква данните да бъдат предавани в контекста на подобните на имейл съобщения, въпреки че най-често информацията не е точно електронно писмо.

MIME е уточнен в шест свързани RFC меморандума: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 и RFC 2049. Заедно те дефинират спецификациите.

Въведение

Основният Интернет протокол за предаване на електронни писма, SMTP, поддържа единствено 7-битови ASCII символи.

Това ефективно лимитира Интернет електронната поща до съобщения, които „при предаване“ включват единствено символи, достатъчни за изобразяване на ограничен брой езици, основно английски. Други езици, използващи латиница, обикновено включват диакритични знаци и не са поддържани от 7-битовата ASCII таблица, от което следва, че тези езици няма да могат да бъдат правилно представени в основната електронна поща.

MIME дефинира механизми за изпращане на различни типове информация по електронната поща. В това число, текст на езици различни от английския, използващи кодиране на знаци, различни от тези в ASCII таблицата и 8-битово бинарно съдържание, като файлове, съдържащи изображения, звуци, филми и компютърни програми. Части от MIME се преизползват в комуникационни протоколи като HTTP, които изискват информацията да бъде предадена в контекста на подобните на имейл съобщения, въпреки че съдържанието може да няма (и обикновено няма) нищо общо с електронно писмо и тялото на съобщението може да бъде бинарно. Преобразуването на съобщенията в и от MIME формат обикновено се извършва автоматично от имейл клиент или от мейл сървър при изпращането или при получаването на SMTP/MIME електронни писма.

Основният формат на Интернет имейлите се дефинира от RFC 5322, който е обновена версия на RFC 2822 и RFC 822. Тези стандарти определят познатите формати за заглавията и тялото на текстовите съобщения, както и правила, отнасящи се за често използваните заглавни полета, като „До:“, „Относно:“, „От:“, и „Дата:“.

MIME дефинира колекция от заглавия (headers) на електронни писма, уточняващи допълнителни атрибути на съобщението, като „тип на съдържанието“, и дефинира набор от „предаващи кодировки“, които могат да бъдат използвани за представяне на 8-битово бинарно съдържание, използвайки символите от 7-битовата ASCII таблица.

MIME също така уточнява правила за кодиране на символи, непринадлежащи на ASCII таблицата в заглавните полета на електронните писма, като например „Относно:“, позволявайки на тези полета да съдържат символи, различни от латиницата.

MIME e разтегателен. Дефиницията му включва метод за регистриране на нови „типове съдържание“ и други MIME стойности на атрибутите.

Целите на дефиницията на MIME включват изискване за непроменяне на съществуващите сървъри за електронна поща и позволяването на имейли, съдържащи единствено текст да функционират двупосочно с вече съществуващи клиенти. Тези изисквания са постигнати чрез използването на допълнителни заглавни части в стил RFC822, за всички атрибути на MIME съобщенията, както и чрез добавянето на допълнителни стойности по подразбиране на MIME заглавните части, което гарантира че съобщения, различни от MIME, ще бъдат интерпретирани правилно от клиент, поддържащ MIME функционалност. Просто MIME текстово съобщение, може да бъде интерпретирано вярно от клиент, неподдържащ MIME, дори ако съдържа заглавни части, които неподдържащият MIME клиент не може да интерпретира.

MIME Заглавия

MIME-версии

Присъствието на това заглавие, свидетелства за това, че съобщението е в MIME формат. Типичната стойност обикновено е „1.0“, така, че това заглавие се появява като MIME-версия: 1.0.

Според един от създателите на MIME, Натаниел Боренщайн, идеята е била да се позволи на MIME да се променя, да напредне до версия 2.0 и т.н. Това решение в крайна сметка довежда до точно обратното и да се появи нова версия на стандарта, става почти невъзможно.

„Не успяхме адекватно да уточним как да се справим с нова версия на MIME“ казва Боренщайн. „Ако напишеш нещо, разбиращо 1.0, какво трябва да направиш ако се сблъскаш с 2.0 или 1.1? Мислех, че това е очевидно, но се оказа, че всеки имплементира това по различен начин. В резултат излиза, че за Интернет е невъзможно дори да се дефинира 2.0 или 1.1“

Съдържание-Тип (Content-Type)

Това заглавие показва, че интернет медия типът на съдържанието на съобщението, се състои от „тип“ и „подтип“, например:

Content-Type: text/plain

Чрез използването на „съставен“ тип, MIME позволява електронните съобщения да съдържат части, подредени в дървовидна структура, при която листата са някой от „не-съставните“ типове съдържание, а останалите разклонения са някои от многото съставни типове.

Механизмът поддържа:

• Прости текстови съобщения, използвайки text/plain (Стойността по подразбиране на “Content-Type: ”)
• Текст плюс прикачен файл („multipart/mixed“ заедно с „text/plain“ част, както и други нетекстови части). MIME съобщение, включващо прикачен файл, обикновено показва оригиналното име на файла чрез заглавието „съдържание-разпределение:“, така, че типа на файла се показва както от MIME съдържание-типът, така и от специфичното за операционната система файлово разширение.
• отговор с прикачен оригинал(„multipart/mixed“, заедно с част „text/plain“ и оригиналното съобщение като част „message/rfc822“)
• алтернативно съдържание, като например съобщение изпратено както под формата на прост текст, така и в друг формат, например HTML („съставно/алтернативно“ с еднакво съдържание съответно във форма „текст/обикновен“ и „текст/html“)
• изображение, аудио, видео и приложение (например: „image/jpeg“, “audio/mp3”, “video/mp4”, “application/msword” и т.н.)
• много други конструкции на съобщения

Съдържание-Разпределение (Content-Disposition)

Оригиналните спецификации на MIME отговарят единствено за структурата на електронните писма. Те не засягат въпроса за стиловете на представяне. Заглавната част за разпределение на съдържанието бива добавена в RFC 2183 и служи за уточнение на стилът на представяне. MIME частта може да има:

• „inline“разпределение на съдържанието, което означава, че съдържанието трябва автоматично да се покаже, заедно със съобщението, или
• „attachment“ разпределение на съдържанието. В този случай, за да бъде визуализирано съдържанието е необходимо потребителят да извърши някакво действие.

В допълнение към стиловете на представяне, заглавната част за разпределение на съдържанието осигурява и полета за уточнение на името на файла и датите на създаване и модифициране на съобщението. Тези данни могат да се използват от пощенския потребителски посредник на читателя, за съхранение на прикрепената част.

Следният пример е изваден от RFC2183. В него заглавната част е дефинирана

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

Името на файла може да бъде шифровано според дефиницията на RFC2231.

От 2010 г. голяма част от клиентите за електронна поща не следват правилата изцяло. Широко използваният Mozilla thunderbird пощенски клиент, сам взима решения за това кои MIME части да бъдат автоматично визуализирани, игнорирайки заглавната част за разпределение на съдържанието в самите съобщения. Thunderbird версии по-стари от версия 3, също така изпращат новокомпозирани съобщения с „inline“ разпределение на съдържанието за всички части на MIME съобщението. Мнозинството потребители не са наясно с това, как да зададат разпределението на съдържанието на „attachment“ Много пощенски потребителски посредници също така изпращат съобщения с името на файла, записано в графа „име“ в заглавната част „content-type“, вместо в графа „файлово име“ в заглавната част „content-disposition“. Тази практика не се поощрява – името на файла трябва да бъде специфицирана или само от полето „файлово име“, или и от двете – „файлово име“ и „име“.

В HTTP, Content-Disposition: attachment заглавната част отговор, обикновено се използва за да подскаже на програмата клиент, че съответното тяло трябва да бъде подадено като файл за изтегляне. Обикновено, при получаване на такъв отговор, уеб браузърът ще запита потребителят дали да запази съдържанието на съобщението под формата на файл, вместо да го визуализира в прозореца. По подразбиране за файлово име се използва параметъра „име на файла“ (това е доста удобно при динамично генерирано съдържание, т.к. използване на име от URL би било безсмислено и би объркало потребителя.

Трансфер на съдържанието – кодиране (Content-Transfer – Encoding)

През юни 1992 MIME (RFC 1341, вече заместен от RFC 2045) дефинира набор от методи за представяне на бинарни данни във формати различни от текстовия формат на ASCII. Заглавната част „content-transfer-encoding“ на MIME е двустранно значима:

• показва дали е използван кодиращ метод „binary-to-text“, върху оригиналното кодиране, както е указано от заглавната част „content-type“.

1. ако такъв метод е бил използван, се отбелязва кой точно е той.
2. ако не е използван такъв метод, се предоставя описателен етикет засягащ формата на съдържанието, с приоритет на присъствието на 8-битово или бинарно съдържание.

RFC и IANA's list за кодиране при предаване, дефинират изброените по-долу стойности, който не са чувствителни към малки и главни букви. Забележете, че „7-битово“, „8-битово“ и „бинарно“, означава, че върху оригиналното кодиране не е било използвано друго кодиране от вида „binary-to-text“. В тези случаи, заглавната част не е необходима на имейл клиента за декодирането на тялото на съобщението, но може да бъде полезна за означаване на типа на изпращаното съдържание. Стойностите „quoted-printable“ и „base64“ указват на имейл клиента, че е било употребено „binary-to-text“ кодиране. Преди съобщението да може да бъде прочетено в оригиналното си кодиране (напр. UTF-8), то трябва да се приложи първоначално декодиране.

• подходящи за използване с нормален SMTP:
  • „7-bit“ – до 998 октета на линия от кода 1..127 с CR и LF (кодове 13 и 10 респективно) разрешено е да се появява само като част от CRLF край на линията. Това е стойността по подразбиране.
  • „quoted-printable“ – използва се за кодиране на случайни последователности от октети до форма, задоволяваща правилата на 7-битовото кодиране. Създадена е да бъде ефикасна и най-вече четима от хора, в случаите когато е използвана за текстово съдържание, състоящо се главно от US-ASCII символи, но също съдържащо и малка част символи, извън този обхват.
  • „base64“ – използва се за кодиране на случайни последователности от октети до форма, задоволяваща правилата на 7-битовото кодиране. Създадено е да бъде ефикасно за не-текстово 8-битово съдържание, както и за бинарно съдържание. Понякога то се използва и за текстово съдържание, което често използва символи, различни от US-ASCII символите.
• Подходящо за използване от SMTP сървъри, поддържащи 8BITMIME SMTP extension.
  • „8-bit“ – до 998 октета на линия с CR и LF (кодове 13 и 10 респективно) разрешено е да се появява само като част от CRLF край на линията.
• Подходящо за използване от SMTP сървъри, поддържащи BINARYMIME SMTP разширение (RFC 3030):
  • „binary“ – всяка последователност от октети

Няма дефинирано кодиране, специално създадено за изпращане на случайно бинарно съдържание чрез SMTP transports с 8BITMIME разширение. Поради тази причина, се налага да бъдат използвани base64 или quoted-printable (въпреки свързаната с тях неефикасност). Тези ограничения не се отнасят за други употреби на MIME, като например Web Services with MIME attachments or MTOM

Кодирана-дума (Encoded-Word)

От RFC 2822 насам, имената на заглавните части и техните стойности трябва да са изписани със символи от ASCII. Стойности, които съдържат символи извън ASCII, трябва задължително да използват MIME „encoded word“ синтаксисът (RFC 2047), вместо низов литерал. Този синтаксис използва низ от ASCII символи, посочващи както оригиналното кодиране, така и кодирането за пренос на съдържанието („”charset““), използвано като карта на байтовете от набора на знаци в ASCII символи.

Формата е: =?charset?encoding?encoded text?=.

• „charset“ може да бъде всяко множество от символи, регистрирано в Организцията за присвояване в интернет (Internet Assigned Numbers Authority). Обикновено, той е същият, като използвания в тялото на съобщението.
• „encoding“ може да бъде или Q, отбелязващо Q-encoding, което е подобно на „quoted-printable“ кодиране, или B, отбелязващо „base64“ кодиране.
• „encoded-text“ е Q-кодиран или база64-кодиран текст.
• „encoded-word“ може да бъде дума, не по-дълга от 75 символа, включваща „charset“, „encoding“, „encoded-text“ и разделители. Ако има нужда да бъде кодиран текст, който не може да се събере в „encoded-word“, могат да бъдат използвани множество „encoded-word“ (разделени от CRLF интервал).

Разлики между Q-encoding и quoted-printable

ASCII кодовете за въпросителен знак („?“) и знак за равенство („=“), могат да не бъдат представени, по начина по който се използват за разделители между думите. ASCII кодът за интервал, може да не бъде представен директно, т.к. той може да накара по-стари парсъри да разделят думата по нежелан начин. За да бъде кодирането по-малко и по-лесно за четене, подчертаващото тире е използвано за представяне на ASCII кодът за интервал. Като резултат, подчертаващото тире също не може да бъде представено директно. Използването на кодирани думи на определени места от заглавните части, налага още ограничения върху това, кои символи могат да бъдат представени директно.

Например:

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

се интерпретира като: „Subject: ¡Hola, señor!“.

Форматът „encoded-word“ не се използва за имената на заглавните части (напр. Subject) Те са винаги на английски език в необработеното съобщение. При изобразяването му от не-английски имейл клиент, имената на заглавните части обикновено се превеждат от самия клиент.

Съставни съобщения (Multipart messages)

Съставното съобщение в 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-header полета) и тяло. Съставното съдържание може да е вложено. Content-transfer-encoding на съставен тип трябва винаги да е „7 битово“, „8 битово“ или „бинарно“, за да се избегнат усложненията, които ще са породени от няколко нива на декодиране. Съставният блок като цяло не разполага с набор от знаци; не-ASCII символите в заглавната част се обработват от Encoded-Word системата, и частичните тела могат да имат набор от знаци, определени при необходимост за техните content-type.

Забележка:

• Преди първата граница да е област, която е игнорирана от MIME-compliant клиенти. Тази област обикновено се използва за пускане на съобщение до потребителите на стари не-MIME клиенти.
• Зависи от изпращащия пощенски клиент да избере граничен низ, който не съвпада с основния текст. Обикновено това се прави чрез поставянето на произволен низ.
• Последната граница трябва да има две тирета в края

Съставни подтипове (Multipart subtypes)

MIME стандарта дефинира различни подтипови съставни съобщения, които определят характера на частите на съобщението и връзката им един към друг. Подтипът е посочен в заглавието „Content-Type“ на цялостното съобщение. Например, съставно съобщение MIME, което използва кратък подтип ще има свое Content-Type зададен като „съставно/кратък“.

Първоначално RFC дефинира 4 подтипа: смесен, кратък, алтернативен и паралелен. Минималното съвместимо приложение трябва да поддържа смесен и кратък подтип, другите не са задължителни. Приложенията трябва да разглеждат непознатите подтипове като „съставно/смесен“.

По-долу е даден списък на най-често използваните подтипове, той не е предназначен да бъде изчерпателен списък.

Смесен (Mixed)

Съставно/смесен подтип се използва за изпращане на файлове с различни „Content-Type“ заглавни редове (или като прикачени файлове). Ако изпращаме снимки или други лесно четими файлове, повечето пощенски клиенти ще ги покажат на реда (освен ако не е посочено друго със заглавието „Content-disposition“). В противен случай ще им се представи като прикачен файл. По подразбиране content-type за всяка част е „текстово /обикновен“.

Дефинирано в RFC 2046, Section 5.1.3

Кратък (Digest)

Съставно/краткия подтип е лесен начин да изпратите няколко текстови съобщения. По подразбиране content-type за всяка част е „съобщение/RFC882“.

Дефинирано в RFC 2046, Section 5.1.5

Съобщение (Message)

Част съобщение/RFC822 съдържа пощенско съобщение, включително всички заглавия. RFC822 е погрешно употребен термин, тъй като посланието може да бъде пълно MIME съобщение.

Дефинирано в RFC 2046

Алтернативен (Alternative)

Съставно/алтернативния подтип показва, че всяка част е „алтернативна“ версия на същото (или подобно) съдържание, всяка в различен формат, обозначен с неговото заглавие „Content-Type“. Форматите са подредени по това верни са на оригинала, с най-малко верен първият и най-много верен последният. Системите тогава могат да изберат „най-доброто“ представяне, на което са способни да обработят. Като цяло, това ще бъде последната част, която системата може да разбере, въпреки че и други фактори могат да повлияят на това.

Тъй като клиент е малко вероятно да иска да изпрати една версия, която е по-малко вярна от обикновена версия текст, тази структура поставя обикновената версия текст (ако има такава) на първо място. Това улеснява живота на потребителите на клиенти, които не разбират съставните съобщения.

Най-често съставно/алтернативен подтип се използва електронна поща с две части, един обикновен текст (текстово/обикновен) и един HTML (текст/HTML). Обикновената част на текста осигурява обратна съвместимост, докато HTML позволява използването на форматиране и хипервръзки. Повечето пощенски клиенти предлагат опция, потребителя да избере обикновен текст пред HTML. Това е един пример как местните фактори могат да повлияят на това как едно приложение избира кои „най-добри“ части от съобщението да покаже.

Въпреки че се подразбира, че всяка част от съобщението представлява едно и също съдържание, стандартът не изисква това да бъде изпълнено по никакъв начин. По едно време, антиспам филтрите ще разгледат текстово/обикновената част от съобщението, защото е по-лесно от това да се направи разбор на текст/HTML част. Но спамерите в крайна сметка се възползват от това, създавайки съобщения с безвреден на вид текстово/обикновена част и реклама в текст/HTML част. Антиспам софтуер в крайна сметка достига този трик, налагайки наказания на съобщения с много различен текст в съставно/алтернативното съобщение.

Дефинирано в RFC 2046, Section 5.1.4

Свързан (Related)

Съставно/свързани подтипове се използват, за да покаже, че всяка част от съобщението е компонент от цялата съвкупност. Това е за съставни обекти, състоящи се от няколко взаимосвързани компонента – правилното излагане не може да бъде постигнато чрез индивидуално показване на съставните части. Съобщението се състои от основна част (първа по подразбиране), която се обръща към другите части на реда, което на свой ред може да препоръча други части. Частите на съобщение често са посочени от заглавната част „Content-ID“. Синтаксиса на препоръката е неуточнен и вместо това е продиктувано от кодиращата или протоколна използвана част.

Една честа употреба на този подтип е да изпратите уеб страница пълна с изображения в едно съобщение. Основната част ще съдържа HTML документ и ще използва тагове за изображения до препоръчаните изображения, съхранени в последните части.

Дефинирано в RFC 2387

Доклад (Report)

„Съставно/докладвания“ подтип е вид съобщение, което съдържа данни, форматирани за четене от пощенски сървър. Той е разделен между текстово/обикновен (или някой друг лесно четим content/type) и message/delivery-status, който съдържа данните, форматирана за четене от пощенския сървър.

Дефинирано в RFC 6522

Подписан (Signed)

Съставно/подписаното съобщение се използва за прикрепяне на цифров подпис към съобщение. То има точно две части на тялото, част от тялото и част с подпис. Цялата част на тялото, включваща MIME заглавия се използва за създаване на частта с подпис. Много видове подписи са възможни, като „application/pgp-signature“ (RFC 3156) и „application/pkcs7-signature“ (S/MIME).

Дефинирано в RFC 1847, Section 2.1

Криптиран (Encrypted)

Съставно/криптираното съобщение има две части. Първата част има контролна информация, която е необходима да се декриптира втората application/octet-stream част. Подобно на подписаните съобщения има различни изпълнения, които са идентифицирани от техните типове със съдържание за контролната част. Най-често срещаните видове са „application/pgp-encrypted“ (RFC 3156) и „application/pkcs7-mime“ (S/MIME).

Дефинирано в RFC 1847, Section 2.2

Формуляр от данни (Form Data)

Както подсказва името му, съставно/формуляр от данни се използва за изразяване на стойностите, представени чрез формуляр. Първоначално определен като част от HTML 4.0, той най-често се използва предоставяне на файлове чрез HTTP.

Дефинирано в RFC 2388

Смесено-Заменен (Mixed-Replace)

Типът със съдържание съставно/смесено-заменен бил разработен като част от технология, за да подражават качването към сървъра и стрийминг чрез HTTP.

Всички части от смесено-замененото съобщение имат семантично значение. Все пак всяка част анулира – „замества“ – предишните части, веднага след като се приеме напълно. Клиентите трябва да обработят отделните части, веднага след като те пристигнат и не трябва да чакат за цялото съобщение, за да приключат.

Първоначално разработено от Netscape, все още се поддържа от Mozilla, Firefox, Chrome, Safari, Opera, но традиционно се пренебрегва от Microsoft. Обикновено се използва от IP камери като MIME тип за MJPEG потоци.

Byteranges

Съставно/byteranges подтип се използва за представяне на несъседни byte ranges от едно съобщение. Използва се от HTTP, когато сървър връща множество byte ranges.

Дефинирано в RFC 2616.

Външни препратки

• Списък, следящ черновите и стандартите, свързани с електронната поща в Интернет Архив на оригинала от 2006-10-04 в Wayback Machine.
• Списък на позволените от IANA, MIME Медийни формати
• Списък на Символни Формати
• wiki.debian.org