Martin Pokorný - CRONAX

E-mail je nestarší a dosud sloužící "součást" komunikace (norma popisující email je z roku 1982, počátky sahají až do 1971 resp. 1965, více v článku "Proč nepřišel e-mail")

Pro e-mail je "přirozené" použití jen čísel a písmen bez diakritiky. Tedy znaky, které mají v základní tabulce znaků (ASCII) čísla 32-126, které si vystačí se 7 bity. Ke zbytku, t.j. do 255, potřebujete už 8 bitů. To sice pramení ještě z doby, kdy byly linky pomalé a drahé a šetřilo se tak každým bitem, ale je to klíčové pro pochopení dalšího textu.

Zdrojový text e-mailu je rozdělen na dvě části: hlavička a tělo zprávy.

Z hlavičky mailu běžně vidíte jen odesilatele, příjemce, datum, subjekt. Těch informací je tam však více (např. cesta mailu internetem). Základní pravidlo dle norem říká, že v hlavičce mohou být jen 7-bitové znaky. Takže subjekt
"Příliš žluťoučký kůň pěl ďábelské ódy" 
bude interně uložen takto: 
=?ISO-8859-2?Q?=P=F8=EDli=B9_=BElu=BBou=E8k=FD_k=F9=F2_p=ECl_=EF=E1belsk=E9_=F3dy?=
nebo
=?UTF-8?B?UMWZw61sacWhIMW+bHXFpW91xI1rw70ga8WvxYggcMSbbCDEj8OhYmVsc2vDqSDDs2R5?=
Ač hodně divná věta, nehrabe mi - je to typický test zahrnující všechny znaky diakrity.

Stejným způsobem bude "zašifrováno" i jméno příjemce či odesilatele, pokud obsahuje češtinu. Co tento zápis znamená, t.j. jak jej "číst", pochopíte z následujícího textu.

Porušení normy 7-bitových znaků v hlavičce může být důvodem k zamítnutí příjmu e-mailu cílovým serverem !

Na tělo mailu nejsou normy tak striktní a připouštějí i 8-bitové znaky. To však neznamená, že jsou vždy použity; některé programy použijí 7-bitů a tím pádem "zašifrování" českých znaků stejně, jako v případě subjektu.

A co je to vlastně, v pojetí IT,  "čeština" ? Jde o přiřazení čísel (kterým rozumí počítač) konkrétnímu písmenu abecedy. Abeceda bez diakritiky a základní znaky obsazují čísla pod 127. Tabulek, podle kterých je písmeno přirazeno číslu, je více.

Celý problém češtiny v mailech se tak rozpadá na dva díly:

1. Kódování češtiny (tabulka přiřazení písmen k 8-bitovým číslům)
2. Zakódování 8-bitových čísel do 7-bitů.

Podstata všech problémů s češtinou v mailech (pověstné "jádro pudla") je v množství možností vedoucích k řešení každého jednoho z uvedených dvou problémů.

ad 1) Kódování češtiny. Jak uvidíte, je v tom "historický hokej"
V dobách DOSu se u nás používalo nejvíce tzv. "kódování Kamenických". Současně s tím Microsoft přes DOS prosazoval Latin2. S nástupem Windows došlo ke dvěma věcem: a) přejmenování Latin2 na CP852 a b) počátek druhé Microsoftí normy Win1250. Od Microsoftu tedy máte dvě normy se třemi názvy - Latin2/CP852 a Win1250. Aby toho nebylo málo, přišla další norma, tentoráte ISO, konkrétně ISO-8859-2. Až na drobnosti je shodná s Win1250, liší se jen v š, 't, ž (a slovenské Ľ)  Pokud se tedy setkáte s textem, kde je špatně jen š/'t/ž, čtete kódování Win1250 pomocí ISO-8859-2 nebo naopak. A to úplně pomíjím svět Apple, kde si vytvořili svou kódovou tabulku.
Vedle toho všeho vznikala norma "Unicode", která měla za cíl udělat jedno celosvětové kódování, včetně textů psaných zprava doleva (např. hebrejština). Výsledek přinesl několik komplikací s implementací do stávajících systémů a tak vzniklo několik typů kódování Unicode do čísel, nejznámnější je UTF-8 (s proměnlivou délkou 1-6 bytů), používají se však i UTF-16, UTF-32, UTF-2 (UNC) = původní Unicode.

Zkráceně - kódova tabulka udává vztah mezi číslem a písmenem (např. A = 65). Něco jako šifrovací tabulka: když budete mít špatnou šifru, dostanete špatný výsledek. Když Vám někdo napíše Š v kódování ISO-8859-2 = 169, musíte ho zpětně číst opět kódováním ISO. Pokud to přečtete v kódování Win1250, dostanete ©  a v kódování Latin2/CP852 dostanete ę

Pokud se tedy v mailu ztratí informace o kódování češtiny, nebo ji poštovní program přečte špatně, resp. ji ani nezná / nepodporuje, ztratí se "dešifrovací klíč" a zobrazený text může vypadat dost divoce.
Kódové tabulce jazyka se říká také "znaková sada".

ad 2) Zakódování 8-bitových čísel do 7-bitů
Toto zakódování vůbec neřeší češtinu jako takovou a celý 8-bitový rozsah (0-255) kóduje do tzv. tisknutelných znaků, t.j. znaků základní ASCII tabulky s čísly 33-126. Může (ale nemusí) tak být kódován vlastní e-mailu, ale vždy jsou takto kódovány všechny přílohy e-mailu (kromě příloh v prostém textu).

Nejpoužívanější jsou dva typy. Starší (už méně používaný) UUEncode a dnes téměř výhradně používaný standard Mime s kódováním Base64.

Jak takový převod probíhá je zbytečné zde popisovat (odkážu na Wikipedii), ve vztahu k e-mailu to není důležité. Ukáži však, jak vypadá převod slova "pokus" do obou kódování:
UUEncode: $=&5S=```
Base64: cG9rdXM=
Mechanika převodu způsobí, že se kódovaná data natáhnou v průměru o 33%.

Když tedy posíláte např. fotky někomu, kdo má limit na mail 10MB, můžete přiložit fotky v celkové velikosti max. 7MB, pro jednoduchost a jistotu doporučuji jen polovinu. Uvedené kódování totiž v textu mailu (interně) natáhe velikost dat - a cílový server nezajímá, co je uvnitř; pokud mail přesáhne povolenou velikost, zamítne ho.

U kratších textů (části HTML, subjekt a pod) se občas vyskytuje jednoduché kódování, které vše, kromě čísel a písmen A-Z zapíše jako =XX, kde XX je hexadecimální vyjádření čísla daného znaku. Těch cest, jak se vyhnout diakritice (resp. znakům 128-255) je více; nebudu to víc rozebírat, článek není o metodách kódování, ale o tom, že software příjemce musí umět správně interpretovat způsob kódování odesilatele.

Jak vidíte, je v sestavení mailu s češtinou a zpětném správném zobrazení řada míst, kde může dojít k chybě. Celé to ještě mírně komplikuje hafo dalších nařízení norem - např. že řádek v mailu nesmí mít 80 a více znaků (obvykle se dodržuje max. sudá délka, t.j. 78), že pokud je řádek delší, musí končit rovnítkem a následující řádek musí mít na prvním místě mezeru nebo tabelátor (= pokračování předchozího řádku), linux zalamuje řádky znakem LF, windows CR+LF, atd.atd.. Stačí tedy málo, doslova jeden chybně umístěný/přečtený znak a celý řádek je interpretován jinak.

Kde může dojít k chybě?

1. Drobné chyby v poštovních programech. Pokud obě strany používají tentýž a podobné verze, většinou se vše tváří v pořádku, přestože je v těle mailu nějaká chybka... použitím stejného programu se neprojeví. Je to podobné, jako když si budete myslet, že se ve slově "bydlet" píše měkké I a příjde vám slovo "bidlet", tak to nebudete považovat za chybu, přestože je tam chyba zcela evidentně.
   
   
2. Nedodržování standardů, neaktuálnost software - zkrátka přičiny nekompatibilit. Je všeobecně známé, že Microsoft si se standardy hlavu neláme a vytváří své... to pak způsobuje různé problémy. Neaktuální software může mít za následek nepodporování některého kódování či opravenou chybu v kódování či dekódování - a projeví se to vždy jen straně příjemce.
   
   
3. Různé antivirové a antispamové filtry na cestě mohou do těla mailu nepatřičně zasáhnout. Převezmou mail, dekódují, otestují, zakódují "po svém" a pošlou dál. Pokud udělají chybu (stačí vypustit jeden znak), nemusí to příjemce přečíst správně.

Největší problémy jsou mezi s Outlookem, příp. Exchange serverem a jinými poštovními programy. Je to dáno několika věcmi: Outlooky jsou dva - zdarma ve Windows a jiný, který je součástí Office. Každý pracuje jinak, má jiné chyby a jinou podporu všecho možného. Dále, Outlook z Office umožňuje posílat maily jak přímo, tak přes Microsoftí Exchange Server - tomu pak neposílá maily klasické, ale ve svém formátu "msg" a až Exchange z toho dělá standardní mail. A postarších (a mnohdy nezáplatovaných) Exchange Serverů, coby součást SBS serveru, je velké množství.
Kromě toho, že Microsoft zrovna standardy neřeší (bez uzardění pošle v hlavičce mailu 8-bitové znaky), zaváděl podporu UTF hodně pozdě a nasekal v tom množství chyb. Takže nezáplatované Outlooky a Exchange servery odesilatelů jsou zdrojem mnoha problémů u příjemců.

V posledních letech Microsoft hodně zdražil Exchange Servery s cílem převést tyto uživatlee na Office365 (taky Exchange) a problémů s kódováním tak výrazně ubývá - v posledních verzích Exchange až asi vychytali všechny chyby (dokud nezanesou nové...)