Multipurpose Internet Mail Extensions

MIME (ang. Multipurpose Internet Mail Extensions) – standard stosowany przy przesyłaniu poczty elektronicznej (ang. e-mail). MIME definiuje budowę komunikatu poczty elektronicznej.

Wiadomość w formacie MIME składa się z nagłówków i treści. Nagłówki określają różne parametry związane z przesyłaną wiadomością, takie jak nadawcę, temat, odbiorcę, rodzaj zawartości, kodowanie transportowe (określające sposób zamiany danych 8-bitowych – jak np. pliki binarne, zdjęcia, filmy, dźwięk – do formatu 7-bitowych danych w standardzie ASCII).

Tradycyjny e-mail umożliwiał jedynie przesyłanie tekstu, który mógł być wydrukowany na drukarkach obsługujących 7-bitowy kod ASCII. Dlatego też konieczne jest zakodowanie danych 8-bitowych na dane 7-bitowe. Powoduje to zwiększenie długości tych danych.

Typy MIME definiowane przez standard MIME są istotne również poza dziedziną przesyłania poczty elektronicznej, na przykład w protokołach komunikacyjnych takich jak HTTP. Protokół HTTP wymaga, by dane były transmitowane w kontekście podobnym do wiadomości e-mail, chociaż dane te same w sobie nie stanowią wiadomości e-mail.

Podstawowy protokół przesyłania wiadomości e-mail, SMTP, wspiera tylko 7-bitowe znaki ASCII. To powoduje ograniczenie poczty elektronicznej do wiadomości, które zawierają tylko znaki wystarczające do pisania w niewielkiej ilości języków, głównie w angielskim. Inne języki bazujące na alfabecie łacińskim zazwyczaj zawierają znaki diakrytyczne, które nie są wspierane przez 7-bitowe ASCII, co sprawia, że tekst w tych językach nie może być poprawnie reprezentowany w podstawowej wiadomości e-mail.

MIME definiuje mechanizmy do przesyłania innego rodzaju informacji wewnątrz wiadomości e-mail:

• tekstu w językach używających innego kodowania znaków niż ASCII,
• 8-bitowych danych binarnych, takich jak pliki zawierające obrazy, dźwięki i filmy, a także programy komputerowe.

Przekształcanie wiadomości w/z formatu MIME jest zazwyczaj wykonywane automatycznie przez klienta e-mail, bądź przez serwer pocztowy w trakcie wysyłania lub odbierania wiadomości poczty elektronicznej.

Podstawowy standard poczty elektronicznej określa następujące nagłówki wiadomości e-mail: „To:”, „Subject:”, „From:” oraz „Date:”. Określają one adresata wiadomości, jej temat, nadawcę oraz datę wysłania. MIME określa zaś zbiór nagłówków e-mail służących do określenia dodatkowych atrybutów wiadomości, włączając w to rodzaj zawartości (zwany „typem MIME”), oraz definiuje zbiór metod kodowania transportowego, które mogą być użyte do reprezentowania 8-bitowych danych binarnych przy użyciu znaków z 7-bitowego zbioru znaków ASCII. MIME określa również zasady kodowania znaków spoza ASCII wewnątrz nagłówków wiadomości e-mail, takich jak „Subject:”, pozwalając tym nagłówkom na zawieranie takich znaków.

MIME jest rozszerzalne. Jego definicja pozwala rejestrować nowe możliwe wartości Content-Type (typy MIME).

Cele definicji standardu MIME zawierały brak konieczności wprowadzania zmian do istniejących serwerów e-mail i umożliwienie funkcjonowania w obu kierunkach poczty e-mail składającej się z czystego tekstu przy użyciu istniejących klientów. Cele te zostały osiągnięte poprzez uczynienie nagłówków MIME opcjonalnymi, z wartościami domyślnymi zapewniającymi, że wiadomość niezgodna z MIME będzie poprawnie interpretowana przez klienty obsługujące MIME.

Obecność tego nagłówka wskazuje, że wiadomość jest sformatowana zgodnie z MIME. Typowa wartość to „1.0”, więc nagłówek ten prezentuje się tak:

MIME-Version: 1.0

Nagłówek Content-ID jest używany głównie w wiadomościach wieloczęściowych. Jest to unikatowy identyfikator części wiadomości, pozwalający na odwoływanie się do niej. Identyfikator taki jest otoczony nawiasami kątowymi. Przykład:

Content-ID: <5.31.32252.1057009685@server01.example.net>

Ten nagłówek wskazuje typ MIME zawartości wiadomości. Składa się z typu i podtypu. Na przykład:

Content-Type: text/plain

Skład nagłówka Content-Type:

1. Nazwa typu mediów:

• text
• image
• audio
• video
• application

Dopuszcza się czasem jeszcze dwie wartości: multipart i message. Przez użycie typu multipart, MIME pozwala, by wiadomość posiadała wiele części, z których każda może mieć określony swój własny typ MIME.

2. Nazwa podtypu, np. xhtml+xml lub plain itp.

3. Wymagane parametry (nie każdy typ tego wymaga)

4. Opcjonalne parametry (nie każdy typ tego wymaga), np. charset="us-ascii"

Ten nagłówek określa sposób prezentacji wiadomości. Każda część wiadomości w formacie MIME może mieć:

• styl inline, czyli treść powinna być automatycznie wyświetlana wewnątrz wiadomości; lub
• styl attachment, w przypadku którego treść nie jest wyświetlana automatycznie, lecz wymaga jakiejś akcji ze strony użytkownika, by ją otworzyć (czyli popularne załączniki).

Oprócz stylu prezentacji, nagłówek Content-Disposition dostarcza także pól do określenia nazwy pliku, daty jego utworzenia i daty modyfikacji, które mogą być użyte przez klienta do zapisania załącznika.

Przykład nagłówka Content-Disposition:

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

Niektóre implementacje klienta poczty elektronicznej dokonują swoich własnych decyzji o tym, które części wiadomości w formacie MIME powinny być automatycznie wyświetlone, ignorując nagłówek Content-Disposition zawarty w wiadomości.

Wiele klientów pocztowych wysyła też wiadomości, w których wstawia nazwę pliku do parametru name nagłówka Content-Type, zamiast do parametru filename nagłówka Content-Disposition. Praktyka taka jest niezalecana. Zaleca się natomiast umieszczanie nazwy pliku albo tylko w parametrze filename, albo w obu parametrach naraz^[1].

Określa sposób reprezentacji danych binarnych przy użyciu siedmiobitowych znaków ASCII. Nagłówek Content-Transfer-Encoding spełnia dwie funkcje:

1. Wskazuje czy zastosowano kodowanie danych binarnych do postaci tekstowej oprócz oryginalnego kodowania określonego w nagłówku Content-Type (np. UTF-8); oraz
2. Jeżeli taka metoda kodowania danych binarnych do postaci tekstowej została użyta, wskazuje która to metoda.

Przykładowe wartości nagłówka Content-Transfer-Encoding:

• 7bit – wartość domyślna
• quoted-printable
• base64

Wartość „7bit” oznacza, że nie zostało użyte żadne kodowanie z postaci binarnej do tekstowej. W takim przypadku określający tę wartość nagłówek jest właściwie nadmiarowy. Wartości „quoted-printable” i „base64” mówią klientowi e-mail, że użyto kodowania danych binarnych do postaci tekstowej, a więc że trzeba najpierw wykonać odpowiednie dekodowanie zanim wiadomość będzie mogła zostać odczytana zgodnie ze swoim oryginalnym kodowaniem określonym w nagłówku Content-Type (np. UTF-8).

Wartości nagłówków wiadomości e-mail są zawsze znakami ASCII. Wartości, które zawierają dane spoza ASCII, muszą używać specjalnej składni MIME (zwanej „encoded word”) zamiast oryginalnego ciągu znaków. Składnia ta używa ciągów znaków ASCII wskazujących zarówno oryginalny sposób kodowania znaków, jak i metodę kodowania transportowego użytą do przekształcenia bajtów pierwotnego zbioru znaków w znaki podstawowe ASCII.

Wygląda to w ten sposób: „=?charset?kodowanie?zakodowany_tekst?=”, gdzie

• charset może być nazwą dowolnego zbioru znaków zarejestrowanego przez IANA. Zazwyczaj jest to ten sam zbiór znaków, którego używa ciało wiadomości.
• kodowanie może przyjmować wartość „Q” oznaczającą tzw. „kodowanie Q” (które jest podobne do kodowania „quoted-printable”), bądź też wartość „B” oznaczającą kodowanie „base64”.
• zakodowany_tekst jest tekstem zakodowanym przy użyciu kodowania „Q” lub „base64”.

Poniższy przykład pokazuje sposób zakodowania ciągu „Czaplo, czy umówisz się ze mną?”:

Subject: =?iso-8859-2?Q?Czaplo=2C_czy_um=F3wisz_si=EA_ze_mn=B1=3F?=

Jak widać, został użyty zbiór znaków ISO-8859-2. Przykład pokazuje też, że polskie litery zawierające znaki diakrytyczne, przecinki i znaki zapytania nie są reprezentowane dosłownie, lecz podlegają odpowiedniemu kodowaniu. Takiemu samemu kodowaniu musi podlegać znak równości, ponieważ – podobnie jak znak zapytania – jest on znakiem specjalnym używanym przez encoded word. Znak spacji jest zastępowany znakiem podkreślenia, a więc znak podkreślenia, gdyby wystąpił w treści ciągu, także musiałby być odpowiednio zakodowany.

Zaprezentowane w tym punkcie kodowanie nie jest używane do kodowania nazw nagłówków wiadomości (np. Subject). Nazwy nagłówków są zawsze w języku angielskim i używają podstawowych znaków ASCII. W trakcie wyświetlania wiadomości przez klienty używające innego języka niż angielski, nazwy tych nagłówków są najczęściej przez nie tłumaczone.

Wiadomość wieloczęściowa MIME (multipart) zawiera definicję separatora w nagłówku Content-Type. Separator ten, który nie może wystąpić wewnątrz jakiejkolwiek części wiadomości, umieszcza się potem pomiędzy częściami oraz na początku i na końcu ciała wiadomości. Na przykład:

From: zuraw@[http://example.com/ example.com]
To: czapla@[http://example.com/ example.com]
Subject: =?iso-8859-2?Q?Czaplo=2C_czy_um=F3wisz_si=EA_ze_mn=B1=3F?=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="xxxToJestSeparator0000xxx"

This is a message with multiple parts in MIME format.

--xxxToJestSeparator0000xxx
Content-Type: multipart/alternative;
      boundary="xxxToJestSeparatorZagniezdzony1111xxx"

--xxxToJestSeparatorZagniezdzony1111xxx
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

To jest tre=B6=E6 wiadomo=B6ci.
--xxxToJestSeparatorZagniezdzony1111xxx
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-2"></HEAD>
<BODY><FONT face=3DArial size=3D2>To jest tre=B6=E6 wiadomo=B6ci.</FONT></BODY></HTML>

--xxxToJestSeparatorZagniezdzony1111xxx--

--xxxToJestSeparator0000xxx
Content-Type: image/gif; name="obrazek.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="obrazek.gif"

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==

--xxxToJestSeparator0000xxx--

Każda część składa się ze swojego własnego nagłówka określającego zawartość (zero lub więcej nagłówków rozpoczynających się od Content-) oraz ciała.

Zawartość wieloczęściowa może być zagnieżdżana – znaczy to, że dana część wiadomości może zawierać wewnątrz siebie podział na kolejne części. W takim przypadku konieczne jest zdefiniowanie nowego separatora w nagłówku Content-Type na początku części wiadomości, którą chcemy dalej rozdzielać, oraz umieszczenie go pomiędzy zagnieżdżonymi częściami oraz na początku i na końcu ciała części wiadomości, którą rozczłonkowaliśmy.

W przykładzie powyżej pokazano zagnieżdżanie. Cała wiadomość jest typu multipart/mixed i składa się z dwóch głównych części: pierwsza jest typu multipart/alternative, a druga typu image/gif. Pierwsza część została dalej podzielona (a więc doszło do zagnieżdżenia) i też zawiera dwie części: pierwszą typu text/plain i drugą typu text/html. W tym przypadku obie zagnieżdżone części przenoszą tę samą informację, lecz w różnych formatach – najpierw jako czysty tekst, a potem w formacie HTML.

Nagłówek Content-Transfer-Encoding typu multipart nie może być ustawiony na „quoted-printable” ani na „base64”, żeby uniknąć komplikacji związanych z wielopoziomowym dekodowaniem.

Blok multipart jako całość nie ma określonego zestawu znaków. Znaki spoza ASCII w nagłówkach części są obsługiwane przez system „encoded-word” opisany w poprzednim punkcie. Ciało każdej części może mieć określony własny sposób kodowania znaków w swoim nagłówku Content-Type.

Obszar przed pierwszym separatorem jest ignorowany przez klienty zgodne z MIME. Jest on zazwyczaj używany do przekazywania komunikatu użytkownikom starszych klientów, które nie są zgodne z MIME.

Określenie separatora, który nie koliduje z tekstem ciała wiadomości, jest zależne całkowicie od klienta poczty elektronicznej wysyłającego wiadomość. Zazwyczaj jest to robione przez wstawienie długiego ciągu losowych znaków.

Ostatni separator musi mieć dwa łączniki na końcu (czyli dwa znaki minusa, tak jak w przykładzie wyżej). Tego samego wymaga ostatni separator każdego poziomu zagnieżdżenia.

• typ MIME
• SMTP
• POP3

• N.N. Freed N.N., N.N. Borenstein N.N., Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, IETF, listopad 1996, DOI: 10.17487/RFC2045, ISSN 2070-1721, OCLC 943595667  (ang.).
• N.N. Freed N.N., N.N. Borenstein N.N., Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, RFC 2046, IETF, listopad 1996, DOI: 10.17487/RFC2046, ISSN 2070-1721, OCLC 943595667  (ang.).
• K.K. Moore K.K., MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text, RFC 2047, IETF, listopad 1996, DOI: 10.17487/RFC2047, ISSN 2070-1721, OCLC 943595667  (ang.).
• N.N. Freed N.N., J.J. Klensin J.J., JonJ. Postel JonJ., Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures, RFC 2048, IETF, listopad 1996, DOI: 10.17487/RFC2048, ISSN 2070-1721, OCLC 943595667  (ang.).
• N.N. Freed N.N., N.N. Borenstein N.N., Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples, RFC 2049, IETF, listopad 1996, DOI: 10.17487/RFC2049, ISSN 2070-1721, OCLC 943595667  (ang.).

Zobacz w Wikiźródłach tekst listę typów MIME

• „Dan’s Mail Format Site – Headers – MIME”
• Bardziej szczegółowy przegląd MIME. mgrand.home.mindspring.com. [zarchiwizowane z tego adresu (2006-06-23)]. (1993)
• MIME Media Types – zawiera listę typów i podtypów Content-Type, strona utrzymywana przez Internet Assigned Numbers Authority.
• Lista zbiorów znaków
• Properly Configuring Server MIME Types. developer.mozilla.org. [zarchiwizowane z tego adresu (2011-05-11)].
• W3 School’s Multimedia MIME Reference. w3schools.com. [zarchiwizowane z tego adresu (2011-03-05)].