MIME - MIME

Pro mim jako výkonnou uměleckou formu viz Mimový umělec . Pro jiná použití, vidět Mime (disambiguation) .
Sada internetových protokolů
Aplikační vrstva
Transportní vrstva
Internetová vrstva
Odkazová vrstva

Multipurpose Internet Mail Extensions ( MIME ) je internetový standard, který rozšiřuje formát e -mailových zpráv na podporu textu v jiných znakových sadách než ASCII , jakož i příloh zvukových, obrazových, obrazových a aplikačních programů. Těla zpráv se mohou skládat z více částí a informace o záhlaví mohou být specifikovány ve znakových sadách jiných než ASCII. E -mailové zprávy s formátováním MIME se obvykle přenášejí pomocí standardních protokolů, jako je například protokol SMTP ( Simple Mail Transfer Protocol ), protokol POP ( Post Office Protocol ) a protokol IMAP ( Internet Message Access Protocol ).

Standard MIME je uveden v řadě žádostí o komentáře : RFC 2045 , RFC 2046 , RFC 2047 , RFC 4288 , RFC 4289 a RFC 2049 . Integrace s e -mailem SMTP je specifikována v RFC 1521 a RFC 1522 .

Přestože byl formalismus MIME navržen hlavně pro SMTP, jeho typy obsahu jsou důležité i v jiných komunikačních protokolech . V protokolu HTTP ( HyperText Transfer Protocol ) pro World Wide Web servery vkládají pole záhlaví MIME na začátek jakéhokoli webového přenosu. Klienti používají záhlaví typu obsahu nebo typu média k výběru vhodné aplikace prohlížeče pro uvedený typ dat.

Pole záhlaví MIME

Verze MIME

Přítomnost tohoto pole záhlaví indikuje, že zpráva je ve formátu MIME. Hodnota je obvykle "1,0". Pole se zobrazí následovně: 

MIME-Version: 1.0

Podle spolutvůrce MIME Nathaniela Borensteina bylo číslo verze zavedeno, aby umožnilo změny protokolu MIME v následujících verzích. Borenstein však připustil nedostatky ve specifikaci, které bránily implementaci této funkce: „Nedostatečně jsme specifikovali, jak zacházet s budoucí verzí MIME ... Pokud tedy napíšete něco, co umí 1.0, co byste měli udělat, pokud setkat se s 2.0 nebo 1.1? Myslel jsem si, že je to zřejmé, ale ukázalo se, že to každý implementoval různými způsoby. A výsledkem je, že by bylo pro internet téměř nemožné definovat 2.0 nebo 1.1. "

Typ obsahu

Toto pole záhlaví indikuje typ média obsahu zprávy, skládající se z typu a podtypu , například 

Content-Type: text/plain

Díky použití vícedílného typu umožňuje MIME poštovním zprávám mít části uspořádané ve stromové struktuře, kde listovými uzly jsou jakýkoli typ obsahu, který není vícedílný, a nelistovými uzly jsou různé typy vícedílných typů. Tento mechanismus podporuje:

  • jednoduché textové zprávy používající text/plain (výchozí hodnota pro „Content-Type:“)
  • text plus přílohy ( vícedílné/smíšené s textovou/prostou částí a další netextové části). Zpráva MIME zahrnující připojený soubor obvykle uvádí původní název souboru v poli „Content-Disposition“, takže typ souboru je označen jak typem obsahu MIME, tak příponou názvu souboru (obvykle specifickou pro OS )
  • odpovědět s připojeným originálem ( vícedílný/smíšený s textovou/obyčejnou částí a původní zprávou jako zpráva/ část rfc822 )
  • alternativní obsah, jako zprávy zaslané jak prostý text a jiného formátu, například HTML ( multipart / alternativa se stejným obsahem v text / plain a text / html formy)
  • obrázek, zvuk, video a aplikace (například obrázek/jpeg , audio/mp3 , video/mp4 a aplikace/msword atd.)
  • mnoho dalších konstruktů zpráv

Dispozice obsahu

Původní specifikace MIME popisovaly pouze strukturu poštovních zpráv. Neřešili problém stylů prezentace. Pole záhlaví dispozice obsahu bylo přidáno v RFC 2183 k určení stylu prezentace. Část MIME může mít:

  • inline obsah dispozice, což znamená, že by měl být automaticky zobrazí, pokud se zobrazí zpráva, nebo
  • přílohu obsah dispozice, v takovém případě se nezobrazí automaticky a vyžaduje nějakou formu akce ze strany uživatele, aby ji otevřít.

Kromě stylu prezentace poskytuje pole Content-Disposition také parametry pro zadání názvu souboru, data vytvoření a data změny, které může uživatelský agent pošty čtenáře použít k uložení přílohy.

Následující příklad je převzat z RFC 2183, kde je definováno pole záhlaví: 

Content-Disposition: attachment; filename=genome.jpeg;
  modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

Název souboru může být kódován podle definice v RFC 2231.

V roce 2010 většina agentů pro správu pošty tento předpis plně nedodržela. Široce používaný poštovní klient Mozilla Thunderbird ignoruje pole pro zpřístupnění obsahu ve zprávách a používá nezávislé algoritmy pro automatický výběr částí MIME. Thunderbird před verzí 3 také rozesílá nově složené zprávy s vloženým obsahem pro všechny části MIME. Většina uživatelů neví, jak nastavit dispozice obsahu k příloze . Mnoho agentů poštovních uživatelů také odesílá zprávy s názvem souboru v parametru name záhlaví typu obsahu místo parametru název pole záhlaví Content-Disposition . Tato praxe se nedoporučuje, protože název souboru by měl být zadán buď pomocí parametru název_souboru , nebo pomocí parametrů název_souboru a název .

V HTTP se pole záhlaví odpovědi Content-Disposition: attachment obvykle používá jako nápověda pro klienta, aby prezentoval tělo odpovědi jako soubor ke stažení. Při přijímání takové odpovědi webový prohlížeč obvykle vyzve uživatele, aby uložil jeho obsah jako soubor, místo aby jej zobrazil jako stránku v okně prohlížeče, přičemž název souboru naznačuje výchozí název souboru.

Kódování přenosu obsahu

V červnu 1992 definovala MIME (RFC 1341, protože byla zastaralá RFC 2045) sadu metod pro reprezentaci binárních dat v jiných formátech, než je textový formát ASCII. Pole záhlaví přenosu obsahu: MIME má oboustranný význam:

  1. Pokud byla použita taková metoda kódování binárního textu, uvádí která.
  2. Pokud ne, poskytuje popisný štítek pro formát obsahu s ohledem na přítomnost 8bitového nebo binárního obsahu.

Seznam RFC a seznam kódování přenosu IANA definují níže uvedené hodnoty, které nerozlišují velká a malá písmena. Všimněte si toho, že '7bit', '8bit' a 'binary' znamená, že nebylo použito žádné kódování binárního textu na původní kódování. V těchto případech je pole záhlaví ve skutečnosti nadbytečné, aby e -mailový klient dekódoval tělo zprávy, ale stále může být užitečné jako indikátor toho, jaký typ objektu se odesílá. Hodnoty „ quoted-printable “ a „ base64 “ sdělují e-mailovému klientovi, že bylo použito schéma kódování binárního souboru na text a že je nutné příslušné počáteční dekódování, než lze zprávu přečíst s jejím původním kódováním (např. UTF-8).

  • Vhodné pro použití s ​​normálním SMTP:
    • 7bit - až 998 oktetů na řádek v rozsahu kódů 1..127 s CR a LF (kódy 13 a 10 v daném pořadí) se může objevit pouze jako součást konce řádku CRLF. Toto je výchozí hodnota.
    • quoted-printable -slouží ke kódování libovolných oktetových sekvencí do podoby, která splňuje pravidla 7bit. Navrženo tak, aby bylo efektivní a většinou čitelné pro lidi, pokud je používáno pro textová data skládající se převážně ze znaků US-ASCII, ale také obsahující malý podíl bajtů s hodnotami mimo tento rozsah.
    • base64 - slouží ke kódování libovolných oktetových sekvencí do podoby, která splňuje pravidla 7bit. Navrženo tak, aby bylo efektivní pro netextová 8bitová a binární data. Někdy se používá pro textová data, která často používají znaky jiné než US-ASCII.
  • Vhodné pro použití se servery SMTP, které podporují rozšíření 8BITMIME SMTP (RFC 6152):
    • 8bit - až 998 oktetů na řádek s CR a LF (kódy 13 a 10 v daném pořadí) se může objevit pouze jako součást konce řádku CRLF.
  • Vhodné pro použití se servery SMTP, které podporují rozšíření BINARYMIME SMTP (RFC 3030):
    • binární - libovolná sekvence oktetů.

Není definováno žádné kódování, které je výslovně určeno pro odesílání libovolných binárních dat prostřednictvím přenosů SMTP s příponou 8BITMIME. Pokud tedy není podporován BINARYMIME, jsou někdy stále užitečné base64 nebo quoted-printable (s jejich související neefektivitou). Toto omezení se nevztahuje na jiná použití MIME, jako jsou webové služby s přílohami MIME nebo MTOM .

Kódované slovo

Od RFC 2822 používají názvy a hodnoty polí záhlaví odpovídajících znaků znaky ASCII; hodnoty, které obsahují data jiná než ASCII, by místo doslovného řetězce měly používat syntaxi kódovaného slova MIME (RFC 2047). Tato syntaxe používá řetězec znaků ASCII, který označuje jak původní kódování znaků („ znaková sada “), tak kódování pro přenos obsahu používané k mapování bajtů znakové sady na znaky ASCII.

Formulář je „ =?charset ?kódování ?kódován textu?= “.

  • znakovou sadou může být jakákoli znaková sada registrovaná u IANA . Obvykle by to byla stejná znaková sada jako tělo zprávy.
  • kódování může být buď „ Q“ označující Q-kódování, které je podobné kódování pro tisk v uvozovkách , nebo „ B“ označující kódování base64 .
  • kódovaný text je text kódovaný Q nebo base64.
  • Kódovaný-slovo nesmí být delší než 75 znaků, včetně znakové sady , kódování , kódovaného textu a oddělovače. Pokud je žádoucí kódovat více textu, než se vejde do kódovaného slova o délce 75 znaků, lze použít více kódovaných slov s (oddělených mezerou CRLF).

Rozdíl mezi kódováním Q a tiskem v uvozovkách

Kódy ASCII pro otazník ("?") A znaménko rovná se ("=") nemusí být reprezentovány přímo, protože se používají k oddělení kódovaného slova. Kód ASCII pro mezeru nemusí být reprezentován přímo, protože by mohl způsobit, že starší analyzátory nežádoucí kód rozdělí na kódované slovo. Aby bylo kódování menší a lépe čitelné, podtržítko se používá k reprezentaci kódu ASCII pro prostor vytvářející vedlejší efekt, že podtržítko nelze reprezentovat přímo. Použití kódovaných slov v určitých částech polí záhlaví ukládá další omezení, u kterých mohou být znaky přímo zastoupeny.

Například,

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

je interpretován jako „Předmět: ¡Hola, señor!“.

Formát kódovaného slova se nepoužívá pro názvy polí záhlaví (například Předmět ). Tyto názvy jsou obvykle anglické výrazy a vždy v ASCII v nezpracované zprávě. Při prohlížení zprávy s neanglickým e-mailovým klientem může klient překládat názvy polí záhlaví.

Vícedílné zprávy

Zpráva MIME multipart obsahuje v poli záhlaví hranici ; tato hranice, která se nesmí vyskytovat v žádné z částí, je umístěna mezi částmi a na začátku a na konci těla zprávy takto: Content-Type:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier

This is a message with multiple parts in MIME format.
--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á z vlastního záhlaví obsahu (nula nebo více Content-polí záhlaví) a těla. Vícestránkový obsah lze vnořit. Content-Transfer-EncodingVícedílné typu musí být vždy „7bit“, „8bit“ nebo „binární“, aby se předešlo komplikacím, které by mohly představovat více úrovní dekódování. Vícedílný blok jako celek nemá znakovou sadu; znaky jiné než ASCII v hlavičkách dílů zpracovává systém Encoded-Word a v tělech dílů mohou být zadány znakové sady, je-li to vhodné pro jejich typ obsahu.

Poznámky:

  • Před první hranicí je oblast, kterou klienti kompatibilní s MIME ignorují. Tato oblast se obecně používá k odeslání zprávy uživatelům starých klientů jiných než MIME.
  • Je na odesílajícím poštovním klientovi, aby si vybral hraniční řetězec, který nebude v rozporu s hlavním textem. Obvykle se to děje vložením dlouhého náhodného řetězce.
  • Poslední hranice musí mít na konci dvě spojovníky.

Vícedílné podtypy

Standard MIME definuje různé podtypy vícedílných zpráv, které určují povahu částí zprávy a jejich vzájemný vztah. Podtyp je uveden v poli Content-Typezáhlaví celkové zprávy. Například vícedílná zpráva MIME používající podtyp digest by byla Content-Typenastavena jako „multipart/digest“.

RFC původně definoval čtyři podtypy: smíšený, souhrnný, alternativní a paralelní. Minimálně vyhovující aplikace musí podporovat mix a digest; další podtypy jsou volitelné. Aplikace musí považovat nerozpoznané podtypy za „vícedílné/smíšené“. Další podtypy, jako jsou podepsaná a formulářová data, byly od té doby samostatně definovány v jiných RFC.

smíšený

multipart/mixed se používá pro odesílání souborů s různými Content-Typepoli záhlaví vloženými (nebo jako přílohy). Pokud odesíláte obrázky nebo jiné snadno čitelné soubory, většina poštovních klientů je zobrazí vložené (není-li to výslovně uvedeno u Content-Disposition: příloha, v takovém případě nabízena jako přílohy). Výchozí typ obsahu pro každou část je „text/prostý“.

Typ je definován v RFC 2046.

strávit

multipart/digest je jednoduchý způsob odesílání více textových zpráv. Výchozí typ obsahu pro každou část je „zpráva/rfc822“.

Typ MIME je definován v RFC 2046.

alternativní

Podtyp vícedílný/alternativní označuje, že každá část je „alternativní“ verzí stejného (nebo podobného) obsahu, každá v jiném formátu označeném záhlavím „Content-Type“. Pořadí dílů je významné. RFC1341 uvádí: Obecně platí, že uživatelští agenti, kteří vytvářejí vícedílné/alternativní entity, by měli umisťovat části těla ve vzestupném pořadí preferencí, tj. S preferovaným formátem jako poslední.

Systémy si pak mohou vybrat „nejlepší“ reprezentaci, kterou jsou schopné zpracovat; obecně to bude poslední část, které může systém porozumět, i když to mohou ovlivnit další faktory.

Protože je nepravděpodobné, že by klient chtěl odeslat verzi, která je méně věrná než verze prostého textu, umístí tato struktura nejprve verzi prostého textu (pokud existuje). To usnadňuje život uživatelům klientů, kteří nerozumí vícedílným zprávám.

Nejčastěji se pro e -maily používá více částí/alternativa se dvěma částmi, jedním prostým textem (text/prostý) a jedním HTML (text/html) . Část prostého textu poskytuje zpětnou kompatibilitu, zatímco část HTML umožňuje použití formátování a hypertextových odkazů. Většina e -mailových klientů nabízí uživatelskou možnost upřednostňovat prostý text před HTML; toto je příklad toho, jak mohou místní faktory ovlivnit, jak si aplikace vybere, která „nejlepší“ část zprávy se má zobrazit.

I když je zamýšleno, že každá část zprávy představuje stejný obsah, standard nevyžaduje, aby toto bylo jakkoli vynuceno. Antispamové filtry by najednou zkoumaly pouze textovou/prostou část zprávy, protože je jednodušší analyzovat než textovou/html část. Ale spammeři toho nakonec využili a vytvořili zprávy s neškodně vypadající textovou/obyčejnou částí a reklamami v části text/html. Anti-spamový software nakonec tento trik dohnal a penalizoval zprávy s velmi odlišným textem ve vícedílné/alternativní zprávě.

Typ je definován v RFC 2046.

příbuzný

Vícedílný/související se používá k označení, že každá část zprávy je součástí agregovaného celku. Je to pro složené objekty skládající se z několika vzájemně souvisejících komponent-správného zobrazení nelze dosáhnout individuálním zobrazením jednotlivých částí. Zpráva se skládá z kořenové části (standardně první), která odkazuje na jiné části vložené, což může zase odkazovat na jiné části. Na části zpráv se běžně odkazuje Content-ID . Syntaxe odkazu není specifikována a je místo toho diktována kódováním nebo protokolem použitým v části.

Jedním z běžných použití tohoto podtypu je odeslání webové stránky s obrázky v jedné zprávě. Kořenová část bude obsahovat dokument HTML a pomocí značek obrázků bude odkazovat na obrázky uložené v posledních částech.

Typ je definován v RFC 2387.

zpráva

multipart/report je typ zprávy, který obsahuje data formátovaná pro čtení poštovním serverem. Je rozdělen na text/prostý text (nebo jiný snadno čitelný obsah/typ) a stav zprávy/doručení, který obsahuje data formátovaná pro čtení poštovním serverem.

Typ je definován v RFC 6522.

podepsaný

K připojení digitálního podpisu ke zprávě se používá vícedílná/podepsaná zpráva. Má přesně dvě části těla, část těla a část podpisu. Celá část těla, včetně mimických polí, slouží k vytvoření podpisové části. Možných je mnoho typů podpisů, například „application/pgp-signature“ (RFC 3156) a „application/pkcs7-signature“ ( S/MIME ).

Typ je definován v RFC 1847.

šifrované

Vícedílná/šifrovaná zpráva má dvě části. První část obsahuje řídicí informace, které jsou potřebné k dešifrování druhé části aplikace/oktetového proudu. Podobně jako u podepsaných zpráv existují různé implementace, které jsou identifikovány svými samostatnými typy obsahu pro ovládací část. Nejběžnějšími typy jsou „šifrování aplikací/pgp“ (RFC 3156) a „aplikace/pkcs7-mime“ ( S/MIME ).

Typ MIME definovaný v RFC 1847.

formulářová data

K vyjádření hodnot odeslaných prostřednictvím formuláře se používá typ MIME multipart/form-data . Původně byl definován jako součást HTML 4.0, nejčastěji se používá k odesílání souborů pomocí HTTP . Je uvedeno v dokumentu RFC 7578, který nahrazuje příklad RFC 2388.

x-mixed-nahradit

Typ obsahu multipart/x-mixed-replacement byl vyvinut jako součást technologie pro emulaci push serveru a streamování přes HTTP.

Všechny části zprávy se smíšenou náhradou mají stejný sémantický význam. Každá část však zneplatňuje - „nahrazuje“ - předchozí části, jakmile je zcela přijata. Klienti by měli jednotlivé části zpracovat hned, jak dorazí, a neměli by čekat, až celá zpráva skončí.

Původně byl vyvinut společností Netscape , stále jej podporují Mozilla , Firefox , Safari a Opera . Běžně se používá v IP kamerách jako typ MIME pro streamy MJPEG . Chrome jej podporoval u hlavních zdrojů do roku 2013 (obrázky lze i nadále zobrazovat pomocí tohoto typu obsahu).

meziprostor

Multipart/byterange se používá k reprezentaci nesouvislých bajtových rozsahů jedné zprávy, používá ho HTTP, když server vrací více bajtových rozsahů a je definován v RFC 2616.

Dokumentace RFC

  • RFC  1426 , rozšíření služby SMTP pro přenos 8bit-MIME . J. Klensin , N. Freed , M. Rose , E. Stefferud , D. Crocker. Února 1993.
  • RFC  1847 , Zabezpečení Multiparts pro MIME: Multipart/Signed a Multipart/Encrypted
  • RFC  3156 , zabezpečení MIME s OpenPGP
  • RFC  2045 , MIME Část první: Formát těl internetových zpráv
  • RFC  2046 , MIME Část druhá: Typy médií . N. Freed, Nathaniel Borenstein . Listopadu 1996.
  • RFC  2047 , MIME Část třetí: Rozšíření záhlaví zpráv pro text bez ASCII . Keith Moore . Listopadu 1996.
  • RFC  4288 , MIME Část čtvrtá: Specifikace typu média a postupy registrace .
  • RFC  4289 , MIME Část čtvrtá: Postupy registrace . N. Freed, J. Klensin. Prosinec 2005.
  • RFC  2049 , MIME Část pátá: Kritéria a příklady shody . N. Freed, N. Borenstein. Listopadu 1996.
  • RFC  2183 , Sdělování informací o prezentaci v internetových zprávách: Pole záhlaví Dispozice obsahu . Troost, R., Dorner, S. a K. Moore. Srpna 1997.
  • RFC  2231 , hodnota parametru MIME a rozšířená kódovaná slova: sady znaků, jazyky a pokračování . N. Freed, K. Moore. Listopadu 1997.
  • RFC  2387 , vícedílný/související obsahový typ MIME
  • RFC  1521 , Mechanismy pro specifikaci a popis formátu internetových zpráv

Viz také

Reference

Další čtení

externí odkazy