Standardní kódovací mechanismy

1. Quoted-printable

Toto kódování je určeno pro data, která z větší části obsahují tisknutelné ascii znaky. Výsledkem kódování je ascii text, který je i bez dekódování z velké části pro člověka čitelný.

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í

Příklad:

Řetězec Václav Vopička bude kódován v quoted-printable jako V=E1clav Vopi=E8ka protože:
á je hexadecimálně E1
č je hexadecimálně E8

2. Base64

Je určeno pro obecná binární data, která nemusí být čitelná pro člověka. Kódovaná data jsou pouze o třetinu delší než data původní.

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ů (26=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ýstupní - zakódovaný text musí být uspořádán do řádek max 76 znaků dlouhých.

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

Znaky, které nejsou ASCII by se v žádném případě neměly vyskytnout v záhlaví zprávy. Na otázku co se stane, když se tam takový znak vyskytne není jednoznačná odpověď. Zpráva může dojít příjemci bez problému, zpráva může být nějakým serverem na cestě vrácena nebo se může ztratit.

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

Syntaxe parametru hlavičky je v tomto případě

=?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:

Chce-li si odesilatel do hlavičky From zadat své jméno s diakritikou, pak:

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

Je zpráva od Václava Vopičky

Typy dat v Content-Type

Text

Tento typ je určen pro posílání textových informací. Jde o implicitní hodnotu. U typu je možné použít parametr CHARSET, který indikuje použitou znakovou sadu.

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

Parametr CHARSET indikuje použitou znakovou sadu. Implicitní hodnota je US-ascii. Není case-senzitive.

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

Tento typ je určen pro data, které je třeba zpracovat nějakou aplikací, aby byly čitelné pro uživatele. Jsou definovány dva podtypy: octet-stream a PostScript. Obecně podtyp bývá jménem aplikace, pro kterou jsou data určena. Uživatel musí být nějakým způsobem informován, jak dotyčná data zpracovat, např. průvodním dopisem. Pouze z hlavičky se o jejich bližším charakteru uživatel nemusí dozvědět všechny informace.

Podtypy:

Příkald:
Content-Type: application/msword; name="soubor.doc"

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

Image

Obsahem těla je obrázek. K jeho prezentaci je třeba odpovídající prohlížeč. Subtypy jsou definovány pro nejznámější používané formáty jpeg a gif. Opět na ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/ lze nalézt jednotlivé podtypy.

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

Audio

Tělo zprávy obsahuje zvuk, definovaný podtyp je basic (mono se vzorkovacím kmitočtem 8 kHz).

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

Video

Obsahem těla zprávy je video, primární typ je mpeg.

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

Model

Popisem tohoto typu se zabývá RFC2077. Modelem se rozumí reprezentace tří a v9cedimenzionálních systému, ve kterých lze zavést pravoúhlou soustavu souřadnic, tj. buď konečně dimenzionální prostory nebo nekonečnědimenzionální ale se spočetnou bází (Hilbertovy prostory). Např. sešikmené prostory, prostory s eleptickými souřadnicemi, různé vektorové prostory atp.

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

Doposud jsme se zabývali pouze zprávami, které se skládaly z jedné části.

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:

Multipart

Tělo zprávy tohoto typu obsahuje několik různých částí - několik dílčích zpráv. Každá část těla začíná úvodním oddělovačem, pak následují hlavičky této části, prázdný řádek a vlastní tělo dílčí zprávy. Poslední část je ukončena koncovým oddělovačem.

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:

Message

Tento typ umožňuje odeslat mailovou zprávu jako tělo jiné mailové zprávy (rfc822), dlouhou zprávu odeslat jako několik kratších (partial) nebo namísto těla zprávy odeslat jen informace, že se zpráva nachází na nějakém serveru (external-body).

Definované podtypy:

From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 1 of 2)
Message-ID: <id1@host.com>
MIME-Version: 1.0
Content-type: message/partial; id="ABC@host.com"; number=1; total=2

Message-ID: <anotherid@foo.com>
Subject: Audio mail MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64

... Prvni cast audio mailu ...
From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail (part 2 of 2)
MIME-Version: 1.0
Message-ID: <id2@host.com>
Content-type: message/partial; id="ABC@host.com"; number=2; total=2

... druha cast audiomailu ...
From: Bill@host.com
To: joe@otherhost.com
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
Subject: Audio mail
Message-ID: <anotherid@foo.com>
MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64

... prvni cast audiomailu ...
... druha cast audiomailu ...