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:
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: <[email protected]>
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:
textimageaudiovideoapplicationDopuszcza 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ć:
inline, czyli treść powinna być automatycznie wyświetlana wewnątrz wiadomości; lubattachment, 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:
Przykładowe wartości nagłówka Content-Transfer-Encoding:
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?=
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.
Uczę się języka hebrajskiego. Tutaj go sobie utrwalam.
Zawartość tej strony pochodzi stąd.
