Rozšíření MIME (Multipurpose Internet Mail Extension) je tč. standardizováno normami RFC2045 až RFC2049. Zavedení MIME se snaží řešit omezení původního standardu podle RFC822. MIME je standardem, který doplňuje RFC822 a zajišťuje zpětnou kompatibilitu. Je navrženo tak, aby mohly být posílány stávajícím poštovním systémem zprávy obsahující diakritiku, obrázky, zvuk atd.
Tento standard řeší dvě otázky:
MIME zavádí hlavičky:
Tato hlavička je jediná hlavička MIME nezačínající řetězcem "Content-".
Hlavička specifikuje verzi normy MIME. Důvodem zavedení této hlavičky je zajištění kompatibility. Tj. podle přítomnosti této hlavičky v mailu klient rozpozná, že jde o zprávu rozšířenou podle MIME a verzi MIME podle kterého byla zpráva rozšířena. Rozšíření MIME podle RFC2045 až RFC2049 je verze 1.0. V budoucnu však mohou přijít další verze MIME s jiným repertoárem hlaviček.
Zpráva sestavená podle RFC2045 až RFC2049 musí tuto hlavičku vždy obsahovat. Tedy konkrétní tvar hlavičky vypadá takto:
Mime-Version: 1.0
Hlavička musí být uvedena před ostatními hlavičkami MIME.
Hlavička popisuje typ dat obsažených v těle zprávy tak, aby klient, který tuto zprávu obdrží mohl zvolit vhodný způsob prezentace obsahu zprávy.
Hlavička specifikuje charakter obsahu zprávy pomocí typu a podtypu a případně pomocí doplňkových informací. Doplňkové informace jsou uvedeny za oddělující středníkem jako parametry ve tvaru parametr=hodnota. Parametrů může být uvedeno i více a na jejich pořadí nezáleží. Jednotlivé parametry jsou rovněž odděleny středníkem.
Typ specifikuje o jaký typ dat se jedná, zda je v těle zprávy obsažen text, obrázek nebo např. obecný binární soubor.
Podtyp pak specifikuje konkrétní formát obrázku, textu a pod.
Např. hlavička
Content-Type: image/jpeg
informuje příjemce o tom, že obsahem zprávy je obrázek formátu jpeg.
RFC2045 až RFC2049 několik základních typů. Další typy mohou být podle
RFC2048 registovány odesláním příslušného formuláře na ietf-types@iana.org.
Registované typy jsou vystaveny na:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/
Typy jsou dvojího druhu:
Lze použít i experimentální typy, ty je však potřeba odlišit od standardních typů prefixem x- před jménem typu např. pro zprávu VRML se kdysi používalo x-world/x-vrml. Dnes však VRML (po ukončení experimentů) používá model/vrml.
Obecný tvar hlavičky:
Content-Type: typ/podtyp; parametr1=hodnota; parametr2=hodnota...
Jména typů, podtypů a parametry jsou case-insenzitive, tj. nezávislé na tom, zda je píšeme velkými nebo malými písmeny.
Data, které chceme posílat mailem jsou často 8 bitová nebo binární. Tato data není možné zpravidla poslat přímo. Proto je potřeba definovat mechanismus převodu - kódování skutečných dat do 7-bitového tvaru s krátkými řádky. Použitý typ kódování je uveden v této hlavičce.
RFC2045 až RFC2049 definuje několik základních algoritmů kódování. Další
algoritmy mohou být podle RFC2048 rovněž registovány odesláním příslušného
formuláře. Registované algoritmy jsou vystaveny na:
ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings
Nejčastější algoritmy kódování jsou:
Kódování quoted-printable a base64 se věnujeme samostatně v kapitole Standardní kódovací mechanismy.
7bit znamená, že jde o 7 bitovou zprávu vhodnou pro mail, žádné kódování ve skutečnosti tedy neproběhne. Jde o implicitní metodu kódování, která se předpokládá, pokud není tato hlavička vůbec uvedena.
Hodnoty 8bit, 7bit a binary vlastně nepředstavují žádné kódování, žádné kódování dat se ve skutečnosti neprovádí. Tyto hodnoty jsou potencionálně užitečné jako indikace typu dat v objektu.
Rozdíl mezi 8bit a binary spočívá v tom, že 8bit znamená, že každých 8 bitů reprezentuje jeden znak, kdežto binary specifikuje, že se jedná o spojitý tok bitů, který nereprezentuje žádné znaky - jedná se např. o spustitelný program. Avšak délka zprávy i u binary musí být násobkem 8 (8 bitů).
Nyní asi chcete namítnout, že od počátku tohoto textu zdůrazňujeme, že mail používá pouze sedmibitový přenos a najednou máme Content-Transfer-Encoding 8bit a binary. Skutečnost je taková, že většina dnešních mailových serverů podporuje. 8-bitový datový přenos zpráv (ne ASCII znaky se v žádném případě nesmí vyskytnout v záhlaví! - viz Znaky v hlavičce, které nejsou ASCII). Avšak obecně v Internetu není zaručeno, že na cestě mezi odesilatelem a příjemcem budou všechny servery zpracovávat 8-bitové zprávy.
Používají-li poštovní servery protokol ESMTP, pak můžete odeslat zprávu ve tvaru 8bit a tato zpráva dorazí na ESMTP-server, který už dále nemá spojení protokolem ESMTP (pouze protokolem SMTP), pak může automaticky provést kódování např. do base64 a příjemce obdrží zprávu kódovanou base64.
Hlavička se vztahuje k celému tělu zprávy. Pokud se hlavička objeví v konkrétní části zprávy, pak se vztahuje pouze na tuto část.
Musíme připomenou, že e-mail je znakově orientovaný, tj. mechanismus kódování se uplatní na osmice bitů nikoli na jednotlivé bity. Proto musí být posloupnost bitů před kódováním nejprve rozdělena na osmice - byty.
Kódovací mechanismus kóduje všechna data do ASCII znaků. Výsledkem kódování je tedy ASCII řetězec.
Hlavičky:
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: base64
interpretujeme takto: tělo zprávy je řetězec ascii znaků vzniklých kódováním base64. Původní data byla ve znakové sadě ISO-8859-2 a musí být do této sady opět převedena při zobrazování příjemci.
Experimentální kódování musí být odlišeno od standardu prefixem x-. Je ho možné použít pro experimenty nebo v případě že klient i server jsou na tomto kódování dohodnuti.
V klientech vyšší úrovně může být požadováno vytvořit odkaz z jedné zprávy do druhé. Tělo zprávy je možné proto označit identifikátorem v hlavičče Content-ID. Hodnota hlavičky může být použita pro jednoznačnou identifikaci zprávy. Hlavička je volitelná, její použití je ale povinné v implementaci, která generuje data typu message/external-body.
Hlavička obsahuje popisné informace o přenášené zprávě, např. název obrázku, který je jako tělo posílán.
Příklad:
Content-Description: "obrazek Prazskeho hradu".
Popis musí být v us-ascii.
I kdyř RFC2045 až RFC2049 nespecifikují žádné další hlavičky Content-, tak stačí odeslat např. programem Netscape mail a vidíte, že se v praxi používá např. Content-Length a Content-Disposition (specifikaci Content-Length lze nalézt v RFC2068 specifikující HTTP verze 1.1):
Message-ID: <335A2639.C79@pvt.cz> Date: Sun, 20 Apr 1997 16:20:41 +0200 From: Libor Dostalek <dostalek@pvt.cz> X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: dostalek@pvt.net Subject: (no subject) Content-Type: audio/wav; name="ding.wav" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ding.wav" X-Mozilla-Status: 0001 Content-Length: 15894 UklGRkYtAABXQVZFZm10IBAAAAABAAEAIlYAACJWAAABAAgAZGF0YSItAACAgICAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA ... |