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.
Wprowadzenie
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.
NagÅówki MIME
MIME-Version
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
Content-ID
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>
Content-Type
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"
Content-Disposition
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].
Content-Transfer-Encoding
OkreÅla sposób reprezentacji danych binarnych przy użyciu siedmiobitowych znaków ASCII. NagÅówek Content-Transfer-Encoding speÅnia dwie funkcje:
- Wskazuje czy zastosowano kodowanie danych binarnych do postaci tekstowej oprócz oryginalnego kodowania okreÅlonego w nagÅówku Content-Type (np. UTF-8); oraz
- 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).
Kodowanie wartoÅci nagÅówków
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: â
â, gdzie
=?charset?kodowanie?zakodowany_tekst?=
- 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Åci wieloczÄÅciowe
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.
Zobacz też
Przypisy
- â Ned Freed: name and filename parameters. 2008-06-21. [dostÄp 2008-06-23]. [zarchiwizowane z tego adresu (2008-12-11)].
Bibliografia
- N. Freed , N. Borenstein , 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. Freed , N. Borenstein , 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. Moore , 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. Freed , J. Klensin , Jon Postel, 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. Freed , N. Borenstein , 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.).
Linki zewnÄtrzne
- â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)].