„Prvním“ počítačům (nebo spíše anglicky hovořícím uživatelům necítícím potřebu psát slova s cizími písmeny :-) stačila tabulka znaků o 128 položkách, tzv. ASCII:

Jednotlivé prvky tabulky mají přiřazená čísla 0-127 decimálně (aneb 0-7F hexadecimálně nebo 0-177 osmičkově) – k jejich zachycení v počítači tudíž stačí pouhých 7 bitů z každého bajtu.

Počítače však už standardně používaly bajty, tj. bitů 8. To dávalo k dispozici dalších 128 možných znaků. Není ale divu, že každý si do volného místa vymyslel něco úplně jiného, kupříkladu i grafické prvky:

Základní jednotkou paměti počítačů je jeden bajt. V rámci jednoho bajtu dokáží počítače uložit – a tím pádem i rozpoznat – právě 256 různých čísel.

Většinou jsou tato čísla příkazy pro procesor, co má vykonat za instrukci, případně číselná data těchto instrukcí. Pokud však daný úsek paměti představuje text, odpovídají uvedená čísla znakům tohoto textu. A jelikož téměř všechna jednobajtová kódování znaků používají celých osm bitů, umožňuje takovéto kódování přiřadit k těmto dvěma stům padesáti šesti číslům stejný počet různých znaků textu – prostě jaké číslo se v dané buňce paměti nachází, takový znak (podle příslušné dekódovací tabulky daného kódování) mu odpovídá.

Pro rozlišení mezi různými rozšířeními v osmém bitu se zavedly tzv. kódové stránky (CP = code pages). Příkladem budiž CP 852 (Latin 2), Windows 1250 (Central Europe) nebo ISO/IEC 8859-5 (Cyrillic).

Alespoň že se všichni shodli, že prvních 128 čísel (0-127) bude odpovídat znakům starého dobrého ASCII – důsledkem je, že text obsahující převážně písmena latinské abecedy bez diakritiky bývá zvětší části čitelný, i když je zobrazen ve špatném kódování (kdy se tedy znaky s čísly 128 až 255 nezobrazují všechny správně).

Mimochodem – nejen že co jazyk, to vlastní CP. Spíš co výrobce nebo program to vlastní CP *_* Pamětníkům dodnes vstávají vlasy hrůzou na hlavě, když si vzpomenou na různá kódování češtiny…

A nezapomeňme na východní jazyky, kterým pouhých 128/256 znaků na zaznamenání jejich obrázkových písem o desítkách tisíc znaků v žádném případě stačit nemohlo! Ty svůj problém vyřešily použitím tzv. DBCS-systému – něco se zapsalo bajtem jedním, něco (většina) dvěma.

Dlouho přehlížený problém, který se provalil na světlo s příchodem Internetu (a tedy do té doby nevídanou volnou výměnou dokumentů mezi různými počítači a systémy), naštěstí pár osvícenců^* řešilo už v osmdesátých letech. Výsledkem jejich snažení byla univerzální množina znaků, tzv.

UNICODE

PS: Kromě samotné tabulky znaků řeší Unicode ale i mnoho dalších věcí, zvláště pro implementátory – namátkou třebas řazení nebo vykreslování.

V Unicode'u má každý znak (jehož přesná definice není ani trochu triviální!) přiřazeno jedinečné konkrétní číslo, tzv. code point. Tak kupříkladu latinské A má číslo U+0041 a řecká α zase U+03B1.

Přiřazených znaků je v dané chvíli již přes sto tisíc, tudíž je jasné, že pro jejich zachycení si už dávno nevystačíme ani se dvěma bajty.

Nejjednodušším způsobem jak uložit text v Unicode'u bude asi prostě zapsat jeho code point přímo jako bajty (pro prvních 65536 znaků případ UTF-16). Číhá na nás ale několik zádrhelů:

• Ne všechny systémy ukládají vícebajtové hodnoty ve stejném pořadí (viz big-endian a little-endian)! Pořadí big-endian je tak nějak lidsky přirozenější – číslo 256, které už se nevleze do jednoho bajtu a musíme ho tak zapsat bajty dvěma, se v něm zapíše jako 00000001 00000000 (tedy 1*256^1 + 0*256^0), zatímco v little-endian je pořadí bajtů opačné, tj. 00000000 00000001 (neboli 0*256^0 + 1*256^1).
• Vidíte, kolik zbytečných nul bude obsahovat text, na který by bývalo stačilo ASCII?

První problém (pořadí bajtů) byl nuceně vyřešen (téměř) povinným zápisem jisté sekvence bajtů na začátek každého unicodového řetězce, tzv. BOM (byte order mark). Podle jejich pořadí pak program (interpretující danou sekvenci bajtů jako text) pozná, o kterou z obou variant jde.

Druhý problém si ovšem vyžádal hodně přemýšlení: Jak jednoznačně a výhodně zaznamenat oněch více jak sto tisíc znaků, aby se všechny vešly, ale přitom jsme nespotřebovávali zbytečně moc místa?

Naprosto geniálním řešením (i když východní Asie naše nadšení sdílet nemusí) je kódování UTF-8.

• Znaky s code points 0 až 127, tj. staré dobré ASCII, se vlezou do jednoho bajtu a jsou zaznamenány úplně stejně.
• Znaky s vyššími code points se zaznamenávají rozdílným počtem bajtů (dvěma až čtyřmi).

Příklad: České slovo svět je v UTF-8 zakódováno do 5 bajtů, ačkoli má pouze 4 písmenka – 73 76 C4 9B 74 (hexadecimálně). Zvětšení jde na vrub písmenku ě, které potřebuje bajty dva (C4 9B), zatímco zbylá tři písmenka jsou zakódována stejně jako v ASCII (porovnejte s příklady jednobajtových kódování).

Konkrétně platí, že začíná-li bajt v UTF-8 zakódovaném textu na jedničku, jde o součást vícebajtové reprezentace jednoho konkrétního znaku s codepointem v rozsahu 128+:

PS: Otazníčky v posledním sloupečku jsou pochopitelně úkol na příslušné hodině ^_~ Nicméně přímý převod z bitů na počet znaků je pouze teoretické maximum, které sráží asi tak na polovinu výrazně komplikovanější struktura Unicode'u, než by člověk na první pohled čekal. (Ne všechny dostupné číselné rozsahy jsou totiž použity pro codepoints, tedy vlastní určení znaku. Navíc se také uplatňuje pravidlo, že je-li možné daný codepoint v bajtech zapsat vícero způsoby, vybírá se ten kratší, čímž se delší varianta vyřadí z množiny dostupných hodnot.)

Podívejme se na zoubek českému slovu svět v kódování UTF-8:

Písmenu ě tedy odpovídá sekvence bajtů \xc4\x9b, zatímco písmena s, v a t jakožto členy spodní části ASCII-tabulky jsou reprezentována sama sebou. V tomto případě můžeme toto rozdělení vykoukat snadno přímo (pouze jeden znak je zaznamenán dvoubajtově), ale správně ho zjistíme až z odpovídající binární podoby:

Podle algoritmu pro kódování UTF-8 získáme pro jednotlivé znaky odpovídající číslo do unicodové tabulky:

Aniž bychom koukali do standardu, jaké znaky těmto unicodovým codepointům odpovídají, můžeme daná čísla přímo použít pro znakové HTML-entity s v ě t: „svět“

Podívejme se na zoubek japonskému znaku 狼 (ookami = vlk) v kódování UTF-8:

Jednotlivé bajty mají následující binární podobu:

Podle algoritmu pro kódování UTF-8 získáme odpovídající číslo do unicodové tabulky:

A decimální 29436 je skutečně codepoint odpovídající v Unicode'u znaku 狼.

Zatímco české znaky s nabodeníčky v libovolném jednobajtovém (tedy osmibitovém) kódování zabírají samozřejmě právě jeden bajt, v kódování UTF-8 zabírají bajty dva.

      192:  À  Á  Â  Ã  Ä  Å  Æ  Ç  È  É  Ê  Ë  Ì  Í  Î  Ï
      208:  Ð  Ñ  Ò  Ó  Ô  Õ  Ö  ×  Ø  Ù  Ú  Û  Ü  Ý  Þ  ß
      224:  à  á  â  ã  ä  å  æ  ç  è  é  ê  ë  ì  í  î  ï
      240:  ð  ñ  ò  ó  ô  õ  ö  ÷  ø  ù  ú  û  ü  ý  þ  ÿ
      256:  Ā  ā  Ă  ă  Ą  ą  Ć  ć  Ĉ  ĉ  Ċ  ċ  Č  č  Ď  ď
      272:  Đ  đ  Ē  ē  Ĕ  ĕ  Ė  ė  Ę  ę  Ě  ě  Ĝ  ĝ  Ğ  ğ
      288:  Ġ  ġ  Ģ  ģ  Ĥ  ĥ  Ħ  ħ  Ĩ  ĩ  Ī  ī  Ĭ  ĭ  Į  į
      304:  İ  ı  IJ  ij  Ĵ  ĵ  Ķ  ķ  ĸ  Ĺ  ĺ  Ļ  ļ  Ľ  ľ  Ŀ
      320:  ŀ  Ł  ł  Ń  ń  Ņ  ņ  Ň  ň  ʼn  Ŋ  ŋ  Ō  ō  Ŏ  ŏ
      336:  Ő  ő  Œ  œ  Ŕ  ŕ  Ŗ  ŗ  Ř  ř  Ś  ś  Ŝ  ŝ  Ş  ş
      352:  Š  š  Ţ  ţ  Ť  ť  Ŧ  ŧ  Ũ  ũ  Ū  ū  Ŭ  ŭ  Ů  ů
      368:  Ű  ű  Ų  ų  Ŵ  ŵ  Ŷ  ŷ  Ÿ  Ź  ź  Ż  ż  Ž  ž  ſ    

Podobně asijská písma dříve typicky zapisovaná pomocí svých specifických dvoubajtových kódování zabírají v UTF-8 na každý znak bajty tři (což jejich záznam v tomto kódování pochopitelně značně prodlužuje).

Odpověď je dvojí a nehezká:

• Python 3 – pokud není řečeno jinak, je vše pokládáno za UTF-8. *nirvána* I když díky BOMu bohužel zdaleka ne tak úplná, jak by mohla být – viz rozdíl mezi kódováními utf-8 a utf-8-sig 0_o
• Python 2 – vše je pokládáno za sekvence bajtů v případě potřeby interpretované jako řetězce v aktuálním kódování (to jako vážně!) a pokud vám to nestačí, připravte se na škrábání levou rukou za pravým uchem s nohama svázanýma do kozelce. U Python'u 2 vás budou zajímat metody takovéhoto „řetězce“ decode() a encode() plus velmi často systémová knihovna codecs.