Multipurpose Internet Mail Extensions: Porovnání verzí
Smazaný obsah Přidaný obsah
m Styl |
Bez shrnutí editace |
||
Řádek 13:
* informace v hlavičce v jiné znakové sadě než ASCII
MIME definuje mechanismus pro posílání různých informací v e-mailu. V těchto informacích jsou zahrnuty texty využívající jiné [[kódování]] než ASCII (psané v jiných jazycích, než je angličtina), přenášet 8 bitový [[binární]] obsah (obrázky, zvuky, filmy, programy a podobně).
MIME je dnes podstatnou součástí komunikačních protokolů jako je [[http]], které vyžaduje, aby byla data přenášena v kontextu zpráv odpovídajícím e-mailu, třebaže data nebudou vhodné do kontextu. Mapování zpráv do a z MIME formátu je typicky vykonáváno automaticky e-mailovým klientem nebo mail serverem, když odesílá nebo přijímá e-mail.
Základní formát e-mailu je definován v [[RFC]] 2822, který je aktualizovanou verzí RFC 822. Tyto standarty specifikují běžné formáty pro hlavičku a tělo e-mailu a pravidla pro běžně používané pole hlavičky jako „Komu:“, „Předmět:“, „Od:“ a „Datum:“. MIME definuje sadu e-mailových hlaviček pro specifikaci doplňkových atributů zprávy obsahující "Content-type" a definuje sadu "Transfer-encoding",
== MIME hlavička ==
MIME hlavička obsahuje
=== MIME-Version ===
Řádek 27:
MIME-Version: 1.0
=== Content-Type ===
Řádek 39 ⟶ 40:
Content-Type: image/jpeg; parametr1=hodnota;
=== Content-Transfer-
Definuje sadu metod pro reprezentaci binárních dat v textovém formátu ASCII.
Řádek 50 ⟶ 52:
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: base64
=== Content-ID ===
Označuje identifikátor v
message/external-body
=== Content-Description ===
Řádek 61 ⟶ 65:
Content-Description: "popis obrazku"
===Syntaxe Encoded-word===
Počínaje RFC 2822 jsou hlavičky a jejich hodnoty v ASCII znacích, pokud chceme použít jinou znakovou sadu, musíme použít "Encoded-word" syntaxi. V syntaxi je zahrnut jak originální text v ASCII, tak požadovaná cílová znaková sada a dekodovací metoda(„content-transfer-encoding“), pomocí těchto parametrů se pak text zobrazí ve správné znakové sadě.
Forma zápisu: "=?charset?encoding?encoded text?="
===Multipart zprávy===
MIME multipart zpráva obsahuje
MIME-version: 1.0
Řádek 85 ⟶ 91:
--frontier--
Každá část se skládá ze své vlastní hlavičky a těla.
===Multipart podtypy===
MIME standart definuje různé podtypy multipart zpráv, které specifikují
Seznam nejvíce používaných subtypů:▼
▲'''Seznam nejvíce používaných subtypů:'''
„Multipart/mixed“ je používáno pro odesílání souborů s různými vkládanými „Content-type“ hlavičkami. Pokud se odesílají obrázky nebo jinak lehce čitelné soubory, vetšina e-mailových klientů zobrazí tyto hlavičky jako vkládané(inline). Jinak je uvede jako přílohy(attachments). Standartní „Content-type“ pro každou část je „text/plain“.▼
====Mixed====
▲„Multipart/mixed“ je používáno pro odesílání souborů s různými
Message/rfc822 část obsahuje každá zpráva zahrnující jakékoliv hlavičky. ▼
====Message====
'''Alternative''' - ▼
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 „Content-type“ hlavičkou. Formáty jsou seřazené podle toho, jak jsou věrné jsou originálu, s nejvíce věrnými na konci. Systémy potom mohou vybrat nejlepší reprezentaci, která je nejvhodnější pro zpracování.▼
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/tml). Část s prostým textem zajišťuje zpětnou kompatibilitu, zatímco HTML část 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í. ▼
▲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
▲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/tml). Část s prostým textem zajišťuje zpětnou kompatibilitu, zatímco HTML část 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 se 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í podpis|digitálního podpisu]] do zprávy, ta má dvě části. V první je tělo zprávy opatřené digitálním podpisem, druhá část obsahuje kontrolu digitálního podpisu.
▲'''Signed''' -
▲'''Encrypted''' -
==Související články==
|