Rozšíření MIME

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:

Hlavička Mime-Version

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 Content-Type

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.

Hlavička Content-Transfer-Endcoding

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.

Hlavička Content-ID

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 Content-Description

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.

Další hlavičky

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
    ...
    


Standardní kódovací mechanismy