Multipurpose Internet Mail Extensions (MIME) е интернет стандарт, който разширява имейл формата така, че да бъдат поддържани: Текст в набор от знаци, различни от ASCII таблицата Не-текстови прикачени файлове Тела на съобщенията с няколко части Заглавия (headers), съдържащи символи извън ASCII таблицата
Употребата на 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“. ако такъв метод е бил използван, се отбелязва кой точно е той. ако не е използван такъв метод, се предоставя описателен етикет засягащ формата на съдържанието, с приоритет на присъствието на 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 край на линията.