Standardní kódovací mechanismy

1. Quoted-printable

Kódován může být i text , který obsahuje pouze ascii znaky a to např. z důvodu zajištění integrity dat, pokud data prochází přes gateway, která provádí náhradu znaků a/nebo zarovnání řádky.

Vrátí-li se nám náš mail jako nedoručitelný, pak se často setkáváme, že mailový server, který zprávu vrací, použije právě kódování quoted-printable.

Pravidla kódování

• Libovolná osmice bitů (kromě znaků konce řádky) je nahrazena znakem "=" následovaných hexadimální hodnotou osmice bitů.
• Osmice s desítkovou hodnotou od 33 do 60 a od 62 do 126 včetně jsou nahrazeny acsii znaky ( od ! do < a od > do ~).
• Osmice s hodnotou 9 a 32 jsou nahrazeny TAB a SPACE znaky. Nesmí být na konci řádku.
• Konec řádky je vyjádřen CRLF.
• Zakódovaná řádka musí mít maximálně 76 znaků. Pokud je řádka delší použije se měkký konec řádky, tj. vloží se znak = na konec řádky.

Příklad:

2. Base64

Kódovací algoritmus je jednoduchý. Používá tabulku base64 o 64 znacích (a znak "="). Pro kódování 64 znaků je třeba 6 bitů (2⁶=64).

Znak "=" (65) se používá ke speciálnímu účelu.

Z hlediska kódování se na zprávu nehledí jako na proud osmic bitů (bajtů), ale jako na proud šestic bitů. Každá šestice se pak kóduje podle tabulky base64.

Na začátku kódování se kódovaný text rozdělí na sekvence 24 bitů a ty následně na 4 šestice bitů. Každá šestice reprezentuje jeden znak v abecedě base64. Kóduje se zleva doprava. Každých 6 bitů je nahrazeno odpovídajícím znakem z tabulky znaků abecedy base64.

Tabulka base64:

   Value Encoding  Value Encoding  Value Encoding  Value Encoding
           0 A            17 R            34 i            51 z
           1 B            18 S            35 j            52 0
           2 C            19 T            36 k            53 1
           3 D            20 U            37 l            54 2
           4 E            21 V            38 m            55 3
           5 F            22 W            39 n            56 4
           6 G            23 X            40 o            57 5
           7 H            24 Y            41 p            58 6
           8 I            25 Z            42 q            59 7
           9 J            26 a            43 r            60 8
          10 K            27 b            44 s            61 9
          11 L            28 c            45 t            62 +
          12 M            29 d            46 u            63 /
          13 N            30 e            47 v
          14 O            31 f            48 w         (pad) =
          15 P            32 g            49 x
          16 Q            33 h            50 y

Všechny znaky pro konec řádky a jiné znaky, které nejsou obsaženy v tabulce base64, musí být dekódovacím programem ignorovány, mohou indikovat chybu přenosu.

Zbyde-li na konci textu po rozdělení méně než 24 bitů, doplní se nulové bity zprava. Přidáním na konec je indikováno znakem "=".

Znaky v hlavičce, které nejsou ASCII

RFC2047 řeší otázku jak do parametrů hlaviček dodat ne ASCII znaky. Problém i zde se skládá ze dvou částí:

• Co takový znak vyjadřuje (obdoba Content-Type)? Např. hexadecimálně znak F8 může v jedné abecedě představovat ř a v jiné azbukové š.
• Jak je kódován do ASCII (obdoba Content-Transfer-Encoding). Např. base64 nebo quoted printable.

=?charset?kódování?řetězec?=

charset je např. iso-8859-x
kódování je buď b pro base64 bebo q pro quoted printable.

Příklad:

From: =?iso8859-2?q?V=E1clav Vopi=E8ka?=

Je zpráva od Václava Vopičky

Typy dat v Content-Type

Text

Primární subtyp je plain, který označuje neformátovaný text. Subtypy se používají pro obohacené texty, texty s vylepšeným vzhledem. Příkladem je např. podtyp html, kdy text obsahuje příkazy jazyka HTML. Vlastností těchto textů je, že jsou čitelné i bez použití speciálního softwaru. To je odlišuje od textově nečitelných dat jako je obrázek.

V souladu s definovanými typy a podtypy tedy zpráva podle RFC822 může být uvozena např. hlavičkou:

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

Tento tvar hlavičky je implicitní.

RFC2045 až RFC2049 definuje pouze podtyp text/plain. RFC2068 (protokol HTTP/1.1) specifikuje subtyp html.

Příklad:
Content-Type: text/html; charset=ISO-8859-2

Parametr CHARSET

RFC2045 až RFC2049 definuje charset jako jednoznačné mapování řetězce bytů na znaky, které již nepotřebuje žádné dodatečné informace.

RFC2045 až RFC2049 uvádí seznam předdefinovaných znakových sad. Další znakové sady mohou být registrovány prostřednictvím IANA.

Jednotlivé registrované znakové sady jsou uveřejněny na:

ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets

Pro nás jsou zajímavé zejména sady US-ASCII, ISO-8859-2 ("ISO-LATIN2"), Windows-1250 a případně IBM850.

Příklad:
Content-Type: text/html; charset=ISO-8859-2

Application

Podtypy:

• Octet-Stream - indikuje, že tělo obsahuje binární data. Lze uvést parametry:

Type - druh binárních dat (pro informaci uživatele)

Doporučená akce při obdržení takovéto zprávy je uložit data do souboru, bez dekódování a použít aplikaci.

• PostScript - indikuje, že v tělě zprávy je postscriptový dokument.
• Další podtypy lze opet nalézt na ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/. Jsou zde definovány např. podtypy msword pro MS-WORD, zip, pgp-encrypted atd.

Příklad:
Content-Type: application/octet-stream; name="coin.ani"

Image

Příklad:
Content-Type: image/jpeg

Audio

Příklad:
Content-Type: audio/wav

Video

Příklad:
Content-Type: video/mpeg

Model

Model může zahrnovat další faktory jako je síla, rychlost, zrychlení, hybnost, čas atd.

Model se skládá z jednoho nebo více objektů mezi kterými je definován scénář typu master/slave. Objekt se skládá s elementů, které mají mezi sebou definovány vztahy.

Hovorově se místo slova model používá označení "virtuální realita".

Příklad:
Content-Type: model/vrml

Kompozitní typy v Content-Type

Nyní se budeme zabývat zprávami složenými z více jednotlivých zpráv. Zpráva může ve svém těle nést:

• Několik dílčích zpráv, pak je použito hlavičky Content-Type: multipart.
• Dlouhá zpráva může být transportována jako několik kratších (Content-Type: message).

Multipart

Jednotlivé dílčí zprávy nejsou interpretovány podle RFC822. Mohou ale také nemusí obsahovat hlavičky (prázdný řádek za záhlavím však musí být vždy uveden). Pokud nejsou hlavičky u části uvedeny, uplatní se implicitní hlavičky ze záhlaví celé zprávy.

Oddělovač je speciální sekvence znaků, která se nesmí vyskytnou nikde uvnitř částí. Oddělovač se definuje v záhlaví celé zprávy v hlavičce Content-Type parametrem boundary.

Parametr má tvar boundary=řetězec. Oddělovač je pak řádka, která začíná dvěma pomlčkami "- -", pak následuje řetězec z parametru. Maximální délka oddělovače je 70 znaků.

Příklad:
Content-Type: multipart/mixed; boundary="gc0p4J:2408t"

Tato hlavička vyjadřuje, že je tělo zprávy složeno z několika částí, každá část má strukturu podle RFC822, přičemž hlavičky jednotlivých částí nemusí být uvedeny. Každá část začíná řádkou:
- - gc0p4J:2408t
Koncový oddělovač určuje, že již nenásleduje žádná část a má tvar:
- - gc0p4J:2408t - -
tj. je na konci doplněný ješte dvěma pomlčkami.

Podtypy:

• Multipat/Mixed - je primárním podtypem. Je určen pro zprávy, které obsahují nezávislé části, které je potřeba svázat v daném konkrétním pořadí.

 

 

Příklad mailu o dvou částech:

From: Libor Dostalek <dostalek@pvt.cz>
To: drdak@pvt.net
Subject: Zprava obsahujici me 2 nazory
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="HRANICE"

Toto je preambule, která je ignorována. Je to proto místo
vhodné k vlození informací pro klienty, kterí
nepodporují MIME.
--HRANICE

Prvni nazor
Vsimnete si, ze tato cast neobsahuje zadne hlavicky,
presto obsahuje prazdny radek oddelujici zahlavi od tela.
Text nekonci koncem radky.
--HRANICE
Content-type: text/plain; charset=iso-8859-2

Druhy názor (tentokrat s hackami a carkami)
Text je ukoncen koncem radky.

--HRANICE--
Toto je zaver, je také ignorován.

• Multipart/Alternative Zpráva tohoto typu obsahuje několik částí, přitom všechny části obsahují shodné informace, pouze tvar je odlišný. Např. táž zpráva jednou napsaná v US-ASCII, potom v ISO-8859-2 a nakonec třeba namluvena, tj. audio. Nejlepší prezentace informací je uváděna jako poslední část. Příjemcův software musí rozpoznat, které formy je schopen zobrazit a vybrat z nich tu nejlepší.

 

 

Příklad:

   From:  bilbo@pvt.net
   To: gandalf@hrad.org
   Subject: Pozvani
   MIME-Version: 1.0
   Content-Type: multipart/alternative; boundary=boundary42

   Pro pripad, ze Tvuj prohlizec neumi MIME, 
   tak Te proste zvu na vylet .
 
   --boundary42
   Content-Type: text/plain; charset=us-ascii

   Zvu te i bez hacku a carek

   --boundary42
   Content-Type: text/html; charset=us/ascii

   Pridej se <H1>k nam</H1>

   --boundary42
   Content-Type: audio/basic
   Content-Transfer-Encoding: base64

   UklGRkYtAABXQVZFZm10IBAAAAABAAEAIlYAACJWAAABAAgAZGF0YSItAACAgICAgICAgICA    
   gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
   gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
   ...

   --boundary42--

Software vytvářející zprávu tohoto typu musí řadit části ve vzrůstající kvalitě.
• Multipart/Digest - Zatímco podtyp multipart/mixed umožňoval vytvořit posloupnost jednotlivých zpráv, tak podtyp multipart/digest umožňuje aby jedna nebo více zpráv byly tvořeny posloupností zpráv.

 

 

V praxi se setkáváme s případem, že zpráva je tvořena pomocí multipart/mixed dvěmi dílčími zprávami. První dílčí zpráva tvoří obsah a druhá pomoci multipart/digest se skládá z jednotlivých kapitol.

Implicitní hlavička Content-Type pro jednotlivé části je změněna z text/plain na message/rfc822.

Příklad:

From:
To:
Date:
Subject: Internet Digest
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="---- Hlavni hranice ----"

------ Hlavni hranice ----

... Seznam zprav, ktere posilam ...
(Napr. Posilam ti zpet maily, ktere nejsem schopen dale dorucit)

------ Hlavni hranice ----
Content-Type: multipart/digest; boundary="---- Hranice ----"

------ Hranice ----
From: odesilatel1
Date:
To:
Subject: Zprava1

Telo zpravy

------ Hranice ----
From: odesilatel2
Date:
To:
Subject: Zprava2

Telo zpravy2

------ Hranice ------
------ Hlavni hranice ------

• Multiparrt/Parallel U tohoto podtypu nezáleží na pořadí částí. Klientem mají být všechny části prezentovány uživateli současně. Např. zvuk na pozadí obrázku.

 

 

MIME-Version: 1.0
From:
To:
Date:
Subject: Priklad
Content-Type: multipart/mixed; boundary=unique-boundary-1

Zde je misto pro text, kterym je mozne objasnit smysl zpravy pro ty,
kteri nejsou schopni zpravu podle MIME interpretovat.

Treti dilci zprava obsahuje obrazek na jehoz pozadi se ma spustit hudba.

--unique-boundary-1

Prvni dilci zprava

--unique-boundary-1
Content-type: text/plain; charset=US-ASCII

Druha dilci zprava

--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64

... base64-kodovane mono se vzorkovacim kmitoctem 8 KHz
--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64

... base64-kodovany obrazek formatu JPEG
--unique-boundary-2--
--unique-boundary-1--

• Multipart/Signed a Multipart/Encrypted jsou subtypy definovane v RFC1847.

 

 

Subtyp Multipart/Signed spcifikuje zprávu skládající se ze dvou částí:

• Zprávy
• Elektronického podpisu této zprávy
Subtyp Multipart/Encrypted pak specifikuje šifrovanou zprávu (zprávu v elektronické obálce).

Není definován subtyp pro zprávy elektronicky podepsané a zároveň šifrované. Na takovýto požadavek je nutné uplatnit oba typy postupně za sebou.

Subtypy Multipart/Signed a Multipart/Encrypted otevřely cestu k použití tzv. bezpečného mailu. Dnes existují čtyři nezávislé standardy pro bezpečný mail:

• PGP (RFC 1991)
• PEM (RFC 1421 až 1424)
• MOSS (RFC 1848)
• S/MIME
PGP a PEM vůbec MIME nepoužívají, tj. informace o šifrování nejsou uvedeny v hlavičkách zprávy, ale ve zprávě samotné, proto lze jen těžko automaticky příjemci zobrazovat takovéto zprávy (zpráva se musí uložit jako soubor, na který se spustí dešifrovací program). Existuje i specifikace pro PGP přes MIME (RFC 2015), ale v praxi se zatím neprosadila.

MOSS a S/MIME používá subtypy Multipart/Signed a Multipart/Encrypted. S/MIME (Secure MIME) je využito v popularním Netscape Comunicatoru, takže jeho masové nasazení lze předpokládat.

Existuje i rozšířeni S/MIME pro dávkové transkace realizující elektronické platby označované jako S/MIME-3P ("trojstranné bezpečné MIME") umožňující transakce mezi zákazníkem, obchodníkem a bankou.

Této preoblematice se budeme podobněji věnovat v samostatném textu.

Message

Definované podtypy:

• Message/rfc822 specifikuje, že tělo obsahuje vnořenou zprávu, která má syntaxi podle RFC822.Často je totiž třeba poslat mailovou zprávu jako tělo jiné mailové zprávy. Pro tento účel je definován typ message. Na rozdíl od RFC822 však není nutné, aby každé tělo zprávy typu message/rfc822 obsahovalo hlavičky From, Subject a To. Vnořená zpráva může být MIME zpráva.
• Message/Partial je definován proto, aby bylo možné posílat dlouhé zprávy jako několik kratších a příjemcův software je mohl automaticky zobrazit jako jednu (sloučenou) zprávu.

 

 

RFC 2046 uvádí následující příklad. Příjemce obdržel 2 maily:

Příjemcův software zjistil, že se jedná o dvě části téže zprávy o identifikaci (id) ABC@host.com. Jednotlivé části jsou číslovány pomocí parametru number. Celkový počet částí (total) je 2. Takže příjemcův software ma k dispozici celou zprávu a může jí zobrazit jako:

Jelikož se jedná o Content-Type: audio/basic, tak zpráva není zobrazena jako textový soubor, ale přehrána jako audio.

• Message/External-Body specifikuje pouze informace o zprávě, která je uložena na nějakém serveru.

 

 

Parametr acces-type specifikuje o jaký server (protokol) se jedná. Nejčastější typy servery jsou ftp, anon-ftp (anonymní FTP-server), mail-server (list server) a local-file (soubor na lokálním počítači). Další typy lze nalézt na: ftp://ftp.isi.edu/in-notes/iana/assignments/access-types

Význam některých dalších parametrů:

• name - jméno souboru
• site - jméno počítače (serveru se souborem)
• directory - adresář ve kterém soubor leží
• expiration - čas do kdy tam soubor bude (do kdy bude aktuální).
Příklad (RFC 2046):

From:
To:
Date:
Subject:
MIME-Version: 1.0
Message-ID: <id1@host.com>
Content-Type: multipart/alternative; boundary=42
Content-ID: <id001@guppylake.bellcore.com>

--42
Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; mode="image"; access-type=ANON-FTP; directory="pub"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>

--42
Content-Type: message/external-body; access-type=local-file; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.bellcore.com"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>

--42
Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>

--42--

V tomto příkladu odesilatel posílá tři odkazy na stejná data. První kopie dat je na anonymním FTP-serveru, druhá na lokálním disku a třetí lze získat z archivu list serveru.

Zatímco identifikace celé zprávy je nepovinná (<id1@host.com>), tak identifikace obsahu dílčí zprávy je povinná (<id42@guppylake.bellcore.com>).

Důležité je si také uvědomit, že obsahem těla dílčí zprávy nejsou data, ale informace o této zprávě. Hlavičku Content-Type tak máme použitu celkem ve třech různých významech:

1. Content-Type: multipart/alternative; boundary=42

Specifikuje typ zprávy jako celku.
2. Content-Type: message/external-body;

Specifikuje, typ dílčí zprávy - jedná se o odkaz.
3. Content-type: application/postscript

Toto v podstatě není hlavička, ale obsah zprávy, kterým se specifikuje typ dat, na které je odkazováno.