Multipurpose Internet Mail Extensions: Porovnání verzí

Smazaný obsah Přidaný obsah
m Styl
Ray11 (diskuse | příspěvky)
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", kterékterá může být použitopoužita pro reprezentování 8 bitových binárních dat užívajících znaky 7 bitového ASCII. MIME také specifikuje pravidla pro dekódování znaků"ne odlišnýchASCII" od ASCIIznaků v hlavičce e-mailu, jako např. u „Předmětu“, umožňující tomutov tomto poli obsahovatpoužít i neanglické znakynapř. MIMEčeskou je rozšiřitelný. Jeho definice obsahuje metodu pro registrování nových „Content-type“ a ostatních atributůdiakritiku.
 
== MIME hlavička ==
 
MIME hlavička obsahuje několik položek: MIME-Version, Content-Type, Content-Transfer-Encoding, Content-ID, Content-Description.
 
=== MIME-Version ===
Řádek 27:
 
MIME-Version: 1.0
 
 
=== Content-Type ===
Řádek 39 ⟶ 40:
Content-Type: image/jpeg; parametr1=hodnota;
 
 
=== Content-Transfer-EndcodingEncoding ===
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 hlaviččehlavičce "Content-ID" pro jednoznačnou identifikaci zprávy. SložíSlouží k vytvoření odkazu z jedné zprávy na druhou.
 
message/external-body
 
 
=== Content-Description ===
Řádek 61 ⟶ 65:
Content-Description: "popis obrazku"
 
 
===Syntaxe Encoded-word===
Od RFC 2822 jsou jména hlaviček a jejich hodnoty vždy ASCII znaky, hodnoty obsahující jiné než ASCII znaky musí použít MIME Encoded-word syntaxy (RFC 2047) místo písmenného řetězce. Syntaxe používá řetězec ASCII znaků indikující jak originální znakovou sadu tak „content-transfer-encoding“ k převodu originálních bytů do ASCII znaků.
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 hranici v hlavičce „Content„content-type:“type“ oddělovač(boundary), tatotento hraniceoddělovač je umístěnaumístěn mezi částičástmi zprávy a na začátek a+ konec těla zprávy, zde je příklad:
 
MIME-version: 1.0
Řádek 85 ⟶ 91:
--frontier--
 
Každá část se skládá ze své vlastní hlavičky a těla. Multipart obsah může být vložený. Multipartmultipart bloky jako celek nemají znakovou sadu, znakyje odlišnézde odtřeba [[ASCII]]použít vsyntaxi hlavičkách"encoded-word", částípokus zprávynepracujeme jsous zpracovány pomocí Encoded-word syntaxe a[[ASCII]], těla jednotlivých částí zprávy mohou použít znakovou sadu pokud náležínáležící do jejich "content-typu".
 
 
===Multipart podtypy===
MIME standart definuje různé podtypy multipart zpráv, které specifikují povahudruh jednotlivých částí zpráv a jejich vztah k ostatním částem. Podtyp je definován v „Content„content-type“ hlavičkyhlavičce celé zprávy. Například multipart MIME zpráva používající podtyp „digest“ by mělabyla „Content-type“v hlavičce nastavenazapsána jako „multipart/digest“.
 
RFCStandartně definuje 4 podtypy: mixed, digest, alternative a parallel. Standartnípoužívané jsou podtypy mixed a digest, ostatní jsou volitelné.
 
Seznam nejvíce používaných subtypů:
 
'''Seznam nejvíce používaných subtypů:'''
'''Mixed''' -
„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====
'''Message''' -
„Multipart/mixed“ je používáno pro odesílání souborů s různými vkládanýmihlavičkami. Používá „Content-type“se pokud hlavičkamijsou jednotlivé části těla zprávy odlišné a je třeba je uspořádat. Pokud se odesílají např. 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“.
Message/rfc822 část obsahuje každá zpráva zahrnující jakékoliv hlavičky.
 
====Message====
'''Alternative''' -
Message/rfc822 část obsahuje každáhlavička zprávav zahrnujícíkaždé jakékoliv hlavičkyzprávě.
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í.
'''====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. Systém Formátysi jsou seřazené podle toho, jak jsou věrné jsou originálu, s nejvíce věrnými na konci. Systémy potom mohoumůže vybrat nejlepší reprezentaci, která je nejvhodnější pro zpracování 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/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ů.
'''====Signed''' -====
„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.
 
'''====Encrypted''' -====
'''Signed''' -
„Multipart„multipart/signed“encrypted“ je využívánslouží k přiloženíšifrování digitálníhozprávy podpisua do zprávy. Má dvě části,. těloPrvní aobsahuje podpisovouinformace část.potřebné Celék tělodekódování, včetnědruhá MIME hlavičekčást je užitopak určena přímo pro vytvořeníčást podpisovéurčenou částik dekódování. ExistujeNejběžnějšími mnohotypy podpisových typů jakojsou „application/pgp-signature“(RFCencrypted“ 3156) neboa „application/xpkcd7-pkcs7-signature“ (S/MIME)mime“.
 
'''Encrypted''' -
„Multipart/encrypted“ má dvě části. První obsahuje kontrolní informaci, která je potřeba k dekódování druhé části „application/octet-stream“. Nejběžnějšími typy jsou „application/pgp-encrypted“ (RFC 3156) a „application/pkcd7-mime“
 
==Související články==