Multipurpose Internet Mail Extensions

Tento článek potřebuje úpravy.

Můžete Wikipedii pomoci tím, že ho vylepšíte. Jak by měly články vypadat, popisují stránky Vzhled a styl, Encyklopedický styl a Odkazy.

MIME, plným názvem Multipurpose Internet Mail Extensions („víceúčelová rozšíření internetové pošty“), je internetový standard, který umožňuje přenášet texty v různých kódováních, binární data a vícedílné zprávy (např. opatřené elektronickým podpisem) kanály původně navrženými pouze pro přenos textových zpráv v kódování ASCII. Standard vyvinutý pro elektronickou poštu používají i další aplikační protokoly (např. HTTP). Standard MIME je definován šesti dokumenty: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 a RFC 2049.

Původní standard internetové elektronické pošty (RFC822 z roku 1982 a jeho předchůdci ze 70. let 20. století) dovoloval pouze přenos textových zpráv tvořených relativně krátkými řádky v kódování ASCII. Proto nebylo dlouho možné používat v elektronické poště znaky s diakritikou ani posílat zprávy s přílohami. Částečným řešením bylo například použití uuencodingu nebo jiných metod, avšak citelně scházela celosvětová standardizace.

Rozšíření MIME představená v roce 1992 rozšiřují použití e-mailu o tyto možnosti:

• podpora jinĂ˝ch kĂłdovĂĄnĂ­ textu neĚŞ US-ASCII
• podpora přenosu binĂĄrnĂ­ch dat
• podpora příloh (obrĂĄzky, zvuky, filmy, programy a podobně) a vĂ­cedĂ­lnĂ˝ch zprĂĄv
• informace v hlavičkĂĄch v jinĂ˝ch kĂłdovĂĄnĂ­ch neĚŞ ASCII

FormĂĄt e-mailu s pouĚŞitĂ­m MIME je definovĂĄn v RFC 5322 (dříve RFC2822). Tento standard specifikuje formĂĄtovĂĄnĂ­ hlaviček, těla e-mailu a pravidla pro běžně pouŞívanĂŠ hlavičky jako To: (Komu:), Subject: (Předmět:), From: (Od:) a Date: (Datum:). MIME definuje sadu hlaviček pro specifikaci dopl̈kovĂ˝ch atributĚŝ zprĂĄvy obsahujĂ­cĂ­ "content-type" a definuje sadu "transfer-encoding", kterĂĄ mĚŝĚŞe bĂ˝t pouĚŞita pro reprezentaci 8bitovĂ˝ch binĂĄrnĂ­ch dat pomocĂ­ textu v 7bitovĂŠm kĂłdovĂĄnĂ­ ASCII.

Přítomnost této hlavičky značí, že zpráva je formátována podle MIME, a udává verzi MIME. Jediná dosud definovaná hodnota je „1.0“:

MIME-Version: 1.0

Tato hlavička určuje typ internetového média (text, audio, video,…) obsaženého v těle zprávy. Skládá se z typu a podtypu a popřípadě doplňkové informace uvedené za středníkem (parametr). Informuje příjemce o obsahu zprávy.

Typ - definuje o jaký typ souboru se jedná (text, obrázek, video, zvuk,…)

Podtyp - definuje formĂĄt souboru

Doplňkové informace - např. parametr udávající hodnotu

Content-Type: image/jpeg; parametr1=hodnota;

Udává, v jaké reprezentaci jsou přenášena data v těle zprávy, aby vyhovovala možnostem přenosového kanálu:

7bit

Textové soubory obsahující pouze krátké řádky v kódování ASCII lze přenášet i sedmibitovými kanály „tak jak jsou“ s uvedením tohoto přenosového kódování.

8bit

Textové soubory s krátkými řádky v jiném kódování než ASCII lze přenášet osmibitovými kanály s uvedením tohoto přenosového kódování.

binary

Přenosové kódování pro přenos libovolných dat (dlouhé řádky, možnost ne-ASCII znaků) kanály, které to umožňují.

quoted-printable

Určené pro přenos textových souborů, které obsahují i nevelký podíl ne-ASCII znaků a mohou obsahovat dlouhé řádky, sedmibitovými kanály; není příliš efektivní (každý ne-ASCII znak je zakódován 3 znaky).

base64

Určené pro přenos libovolných dat sedmibitovými kanály; kóduje libovolná data pomocí ASCII textu; reprezentuje 3 oktety dat pomocí 4 ASCII znaků.

Příklad kombinace hlaviček pro přenos českého textu v kódování ISO-8859-2 (mělo by se raději používat UTF-8) sedmibitovým kanálem:

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

Označuje identifikátor v hlavičce pro jednoznačnou identifikaci zprávy. Slouží k vytvoření odkazu z jedné zprávy na druhou.

message/external-body

Obsahuje popis informace o přenášené zprávě, např. název obrázku, který je ke zprávě přiložen. Popisuje se v us-ASCII.

Content-Description: "popis obrazku"

Počínaje RFC 2822 musí být jména hlaviček i jejich hodnoty zapsány pouze pomocí ASCII znaků. Vybraná pole mohou obsahovat informace v jiném kódování; tyto informace však musí být zakódovány pomocí "Encoded-word" syntaxe jako ASCII řetězec tvaru

=?charset?encoding?encoded text?=

• charset udĂĄvĂĄ znakovĂŠ kĂłdovĂĄnĂ­ pĚŝvodnĂ­ho textu
• encoding mĚŝĚŞe bĂ˝t Q pro (mĂ­rně upravenĂŠ) kĂłdovĂĄnĂ­ quoted-printable, nebo B pro kĂłdovĂĄnĂ­ base64
• encoded text je přenĂĄĹĄenĂ˝ text zakĂłdovanĂ˝ do podoby ASCII řetězce neobsahujĂ­cĂ­ho znaky otaznĂ­k ani mezery

Například text Přihláška do soutěže vyjĂĄdřenĂ˝ v kĂłdovĂĄnĂ­ UTF-8 mĚŝĚŞe bĂ˝t zakĂłdovĂĄn jako =?UTF-8?Q?P=C5=99ihl=C3=A1=C5=A1ka_do_sout=C4=9B=C5=BEe?=nebo =?UTF-8?B?UMWZaWhsw6HFoWthIGRvIHNvdXTEm8W+ZQ=?=.

VĂ­cedĂ­lnĂŠ zprĂĄvy (MIME multipart) v hlavičce Content-Type definujĂ­ oddělovač (boundary). Oddělovač je umĂ­stěn mezi částmi zprĂĄvy a na začátku a konci těla zprĂĄvy, zde je příklad:

MIME-version: 1.0
Content-type: multipart/mixed; boundary="frontier"

--frontier

Content-type: text/plain

This is the body of the message. 
--frontier

Content-type: application/octet-stream
Content-transfer-encoding: base64

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

Každá část se skládá ze své vlastní hlavičky a těla. Multipart bloky jako celek nemají definované kódování, takže pokud nepracujeme s ASCII, je třeba použít syntaxi „encoded-word“; těla jednotlivých částí zprávy mohou použít znakovou sadu náležící do jejich "content-typu".

MIME standard definuje různé podtypy vícedílných zpráv (multipart), které specifikují druh jednotlivých částí zpráv. Podtyp je definován v „content-type“ hlavičce celé zprávy. Například multipart zpráva používající podtyp „digest“ by byla v hlavičce zapsána jako „multipart/digest“.

Standardně používané jsou podtypy mixed a digest, ostatní jsou volitelné.

Seznam nejvíce pouŞívaných subtypů:

„Multipart/mixed“ slouží pro přenos částí, které spolu nesouvisí. Používá se pokud jsou jednotlivé části těla zprávy odlišné a je třeba je uspořádat. Pokud se odesílají např. obrázky, většina e-mailových klientů zobrazí tyto hlavičky jako vkládané (inline).

„Multipart/related“ slouží pro přenos celku, který se skládá z více částí – například HTML stránka a vložené obrázky.

Část typu Message/rfc822 obsahuje kompletní e-mail včetně hlaviček.

Podtyp „multipart/alternative“ znamená, že každá část je alternativní verze stejného (nebo podobného) obsahu, každá v jiném formátu označená svou hlavičkou. Systém si může ze všech reprezentací vybrat jednu, která je nejvhodnější pro zobrazení zprávy. Běžně je „multipart/alternative“ užíván pro e-mail složený ze dvou částí, jedna je prostý text (text/plain) a druhá HTML (text/html). Část s prostým textem dovoluje čtení i v nejjednodušších klientských programech, zatímco HTML část umožňuje formátování a vytvoření odkazů. Většina e-mailových klientů nabízí volbu, zda prostý text preferovat před HTML. Toto je příklad toho, jak lokální faktory mohou ovlivnit „počínání“ aplikace, která část zprávy je „nejlepší“ pro zobrazení. Zde je pro ilustraci příklad:

From: Jan NovĂĄk <jan.novak@seznam.cz>
To: Alois StarĂ˝ <a.stary@ibm.com>
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42

--boundary42

Content-Type: text/plain; charset=us-ascii

--boundary42

Content-Type: text/x-whatever

--boundary42
 
Content-Type: text/richtext

--boundary42--

Systém uživatele si v tomto příkladu nejvíce "rozumí" s formátem text/richtext, který je první v pořadí relevantnosti (poslední vypisovaný formát je nejlepší) a proto jej využije, jiný systém si však může vybrat i z nabídky druhých dvou formátů.

„multipart/signed“ je využíván k přiložení digitálního podpisu do zprávy. Zpráva bude mít dvě části; v první je text zprávy, ve druhé jeho digitální podpis.

„multipart/encrypted“ slouží k šifrování zprávy a má dvě části. První obsahuje informace potřebné k dekódování, druhá část jsou vlastní zakódované informace. Nejběžnějšími typy jsou „application/pgp-encrypted“ a „application/pkcd7-mime“.

RFC 1426

SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. Ăşnor 1993.

RFC 1847

Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted

RFC 3156

MIME Security with OpenPGP

RFC 2045

MIME Part One: Format of Internet Message Bodies.

RFC 2046

MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. listopad 1996.

RFC 2047

MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. listopad 1996.

RFC 4288

MIME Part Four: Media Type Specifications and Registration Procedures.

RFC 4289

MIME Part Four: Registration Procedures. N. Freed, J. Klensin. prosinec 2005.

RFC 2049

MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. listopad 1996.

RFC 2183

Communicating Presentation Information in Internet Messages: The Content-Disposition Header. Troost, R., Dorner, S. and K. Moore. srpen 1997.

RFC 2231

MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. listopad 1997.

RFC 2387

The MIME Multipart/Related Content-type

RFC 1521

Mechanisms for Specifying and Describing the Format of Internet Message Bodies

• Base64
• HTTP
• S/MIME
• SMTP
• Typ internetovĂŠho mĂŠdia

• Multipurpose Internet Mail Extensions v ÄŒeskĂŠ terminologickĂŠ databĂĄzi knihovnictvĂ­ a informačnĂ­ vědy (TDKIV)