FAV-ZCU/KIV PPA1/19. Kódování znaků.md

# Kodování znaků

- Určuje, jakým „číslem“ jsou jednotlivé znaky (a řetězce složené ze znaků) reprezentovány

### Základní pojmy

- Terminologie není jednotná, liší se u velkých firem a organizací
	- Stejné pojmy se používají pro různé věci
	- Pro stejné věci existují různé pojmy
- V dalším textu bude využita terminologie z Unicode – Character Encoding Model
	- Viz https://www.unicode.org/reports/tr17/

#### Organizace kódování znaků

- Pro kódování znaků lze použít několikaúrovňovou organizaci
	- Znaková sada (množina kódovaných znaků – Coded Character Set – CCS) 
		- Mapování mezi množinou (abstraktních) znaků a množinou nezáporných celých čísel (kódové body – code points)
		- Např. ```A = 41``` (abstraktní znak ```A``` má kódový bod ```41``` (hexadecimálně))
		- Příklady znakových sad jsou US-ASCII, ISO-8859-1, Unicode
	- Forma kódování znaků (Character Encoding Form – CEF)
		- Mapování množiny nezáporných celých čísel (prvků CCS) na množinu kódových jednotek dané šířky (např. 32bitových hodnot ```int```)
		- Např. ```A = 00 00 00 41``` (znak ```A``` namapovaný na 32bitový ```int```) 
	- Kódovací schéma (Character Encoding Scheme – CES) 
		- Alternativní název charset – budeme používat dále, odpovídá třídě v ```Javě java.nio.charset.Charset```
	- Způsob mapování kódových jednotek z CEF do posloupnosti bytů
	- Např. ```A = 00 41``` (znak ```A``` pro znakovou sadu Unicode a kódovací schéma UTF-16BE)
	- Pro jednu znakovou sadu může existovat více charsetů 
		- Např. pro znakovou sadu Unicode existují charsety UTF-8, UTF16 a UTF-32
	- Často ale pro jednu znakovou sadu existuje jen jeden charset
		- Např. ISO-8859-2 
	ěžně je jeden soubor napsán v jednom charsetu
- Teoreticky je ale možné, aby byl jeden soubor současně napsán
	- Ve více znakových sadách (např. Unicode, ISO-8859-2)
	- Za použití více charsetů (UTF-8, ISO-8859-2)
	- Kombinací obou předchozích – nejhorší případ
- Různé soubory jsou běžně v různých charsetech

#### Trocha historie

- Sedmibitový ASCII kód (US-ASCII)
	- American Standard Code for Information Interchage
	- Základem většiny kódování používaných v současnosti (alespoň v Evropě a Americe)
	- Protože data se standardně ukládají po bytech, je osmý (nejdůležitější) bit (Most Significant Bit – MSB – ten nejvíc vlevo) vždy 0
	- Umožňuje uložit 128 znaků
		- Stačí pouze pro čistě anglické texty
	- Nestačí pro uložení dalších znaků jiných jazyků (např. diakritické znaky češtiny) používajících latinku a už vůbec ne pro uložení znaků jiných abeced
- 8bitové kódy založené na ASCII
	- Použila se zbývající polovina rozsahu jednoho bytu (MSB roven 1), což dává dalších 128 znaků 
	- Protože jeden znak je jeden byte, není třeba používat speciální charset (kódovací schéma) 
		- Znaková sada má stejný název jako charset 
	- 128 znaků navíc ale nestačí pro požadavky všech jazyků (ani pro všechny jazyky používající latinku) najednou
		- Vzniklo mnoho charsetů, každý reprezentující specifické požadavky jednoho či skupiny jazyků) 
		- I pro jeden jazyk vzniklo více (různých) charsetů 
			- Vznikají charsety dle normy ISO ISO-8859-1 až ISO-8859-15 (pro různé skupiny jazyků)
			- Vznikají charsety v národních standardizačních organizacích
			- Vznikají propietární charsety, které jsou platformově závislé (Cp1250 pro Windows, MacCentralEurope)
- 16bitový CEF
	- Řeší problém s nedostatečným počtem znaků použitím 16 bitů (2 bytů) pro jeden znak => to dává až 65536 možných znaků
	- Na vývoji pracují cca od roku 1990 paralelně dvě organizace
		- Unicode Consortium
			- Znaková sada Unicode
		- ISO (International Organization for Standardization)
			- Znaková sada ISO/EIC 10646, ve zkratce UCS (Universal Character Set)
		- Pro běžné použití netřeba rozlišovat, jednotlivé znaky mají stejné kódové body
- 32bitový CEF
	- Při zahrnutí ideografických písem (typicky asijská písma) však ani 65536 znaků není dostatečné množství
	- Řeší se použitím 32 bitů (4 bytů) pro jeden znak => to dává teoreticky přes 4 × 10**9 možných znaků, kdy se však nevyužívá celý rozsah

#### Problém pojmenování charsetů

- Je běžné, že jeden charset má několik jmen, které se od sebe částečně nebo zcela liší 
	- Způsobeno tím, že charsety nově pojmenovávají i různí výrobci (HW a/nebo SW), i když už jméno charsetu existuje
	- Např. US-ASCII má 14 dalších evidovaných jmen
		- ISO646-US, IBM367, ASCII, cp376, default, ascii7, ANSI_X3.4-1986, iso-ir-6, us, 646, iso_646.irv:1983, csASCII, ANSI_X3.4-1968, ISO_646.irv:1991
- Pořádek zavádí IANA (Internet Assigned Numbers Authority)
- Rozlišuje se základní pojmenování (nejoficiálnější), tzv. kanonické jméno, a ostatní evidovaná jména, tzv. aliasy
	- Např. US-ASCII je kanonické jméno a iso-ir-6 je jeho evidovaný alias 
- Může se stát, že jméno charsetu není evidováno v IANA, ale charset je podporován některými aplikacemi
	- Pak se používá stejný princip kanonického jména a aliasů, ale kanonické jméno musí začínat „x-“ nebo „X-“
	- Např. Java Core API podporuje charset x-MacCentralEurope s aliasem MacCentralEurope 

### Jednobytové kódy

- Ačkoliv se čím dál více užívá Unicode, stále se můžeme setkat s použitím jednobytových kódu
	- Především historické soubory, které (dosud) nebyly převedeny do Unicode

#### US-ASCII (ASCII)

- Většina (nejen) jednobytových kódů vychází ze US-ASCII
- Původně využito pouze 7 bitů
	- ```00``` až ```1F``` (0 až 31) – řídící znaky (např. ```<CR>```, ```<LF>``` atd.)
	- ```20``` (32) – mezera
	- ```21``` až ``2F`` (33 až 47) – interpunkce (např. „!“, „,“, „"“ atd.) 
	- ```30``` až ```39``` (48 až 57) – číslice „0“ až „9“
	- ```3A``` až ```40``` (58 až 64) – další znaky (např. „;“, „:“, „<“, „@“ atd.)
	- ```41``` až ```5A``` (65 až 90) – velká písmena „A“ až „Z“
	- ```5B``` až ``60`` (91 až 96) – další znaky (např. „^“, „[“, atd.)
	- ```61``` až ```7A``` (91 až 122) – malá písmena „a“ až „z“
	- ```7B``` až ```7F``` (123 až 127) – další znaky (např. „{“, „~“, „|“ atd.)
- I v anglicky mluvících zemích se začalo využívat dalších 128 znaků (MSB roven 1), ač nebyly potřeba pro běžné znaky anglické abecedy
	- Využití mj. pro znaky s čárami umožňující vykreslení „grafických“ oken v textovém prostředí

#### Různá jednobytová kódování češtiny

- Stejně jako pro mnoho jiných jazyků i pro češtinu vznikl jednobytový kód vycházející z ASCII 
	- Prvních 128 znaků stejných jako US-ASCII (MSB roven 0)
	- Dalších 128 znaků použito pro diakritické a další znaky (MSB roven 1) 
- Bohužel vzniklo hned několik kódů, které se vzájemně liší pozicí některých znaků s diakritikou
	- Běžněji se vyskytujících je cca 11
	- Pokud předpokládáme, že soubor je uložen v jednom kódování a ve skutečnosti je uložen v jiném, některé znaky s diakritikou nebudou zobrazeny správně (tj. budou místo nich zobrazeny jiné znaky)
	- Některá kódování se liší jen v několika málo znacích, proto je možné si nesrovnalostí na první pohled nevšimnout
- Jednobytová kódování pro češtinu (a slovenštinu a další středo a východoevropské jazyky), se kterými je možné se setkat 
	- ISO-8859-2 – Latin Alphabet No. 2
		- Aliasy – ibm912, l2, ibm-912, ISO_8859-2, latin2, csISOLatin2, iso8859_2, 912, 8859_2, ISO8859-2, iso-ir-101
		- Základní charset pro východoevropské země – mezinárodní standard dle ISO
		- Dříve se používalo na Linuxu téměř výhradně (dnes na Linuxu většinou nahrazeno UTF-8) 
	- windows-1250 – Windows Eastern European
		- Aliasy – cp1250, cp5346
		- Proprietární charset firmy Microsoft
		- Podporován operačními systémy (Windows) a aplikacemi této firmy
		- Od ISO-8859-2 se v češtině liší pouze ve znacích „š“, „Š“, „ž“, „Ž“, „ť“, „Ť“ 
	- IBM852 – MS-DOS Latin-2 (POZOR! – Liší se od ISO-8859-2 ale i od windows1250) 
		- Aliasy – 852, ibm-852, csPCp852, ibm852
		- Proprietární charset firmy IBM
		- Používaný charset v českém MS-DOS
		- Stále používaný implicitní charset v konzoli českých Windows 
			- Obzvláště bizardní situace, kdy konzole používá IBM852 a zbytek systému používá windows-1250 
			- Důvod, proč mohou nastat problémy s diakritickými znaky při jejich vstupu/výstupu z/do konzole
				- Java předpokládá na standardním vstupu/výstupu charset operačního systému (což je windows-1250), ale konzole používá IBM852
				- Od verze Java 1.8 zlepšení, ale stále nefunguje univerzálně 
	- x-MacCentralEurope – Macintosh Latin-2 
		- Alias MacCentralEurope
		- Proprietární charset firmy Apple 

### Unicode

- Řeší problému s nedostatkem znaků použitím více bitů (bytů)
	- Původně (verze 1.0, 1991) 16 bitů (2 byty)  až 65536 znaků
	- Brzy se ukázalo (verze 2.0, 1996), že 16 bitů není dost a přešlo se na 32 bitů teoreticky přes 4 × 109 možných znaků, ale v současnosti se neplánuje využití více než 21 bitů
	- Prvních 128 znaků mají stejné kódové body (code points) jako znaky v 7bitové US-ASCII
- Kódové body (code points) jednotlivých znaků se označují jako ```U+hexaČíslo```
	- ```hexaČíslo``` jsou typicky 4 hexadecimální číslice, může jich být až 6 (vzhledem k uvažovanému rozsahu maximálně 21 bitů – každé 2 číslice reprezentují 1 byte) 
	- Např. ```U+0041``` je znak „```A```“ – odpovídá zápisu ```\u0041``` v Javě

#### Současné rozdělení rozsahu znaků Unicode 

- Ze 32 bitů se využívá pouze 21 bitů
	- Konkrétně hodnoty ```U+000000``` až ```U+10FFFF```
- Tento rozsah je rozdělen na 17 skupin (sfér – planes), každá o velikosti 65536 znaků => celkem přes 10**6 znaků 
	- Původní sada znaků, která se vejde do 16 bitů (2 byty) se označuje jako BMP (Basic Multilingual Plane) 
		- Je první v pořadí, rozsah ```U+000000``` až ```U+00FFFF```
		- Zahrnuje všechny znaky používané v Evropě a Americe a základní ideografická písma čínštiny, japonštiny a korejštiny (HAN písmo)
		- Samotné BMP je vnitřně děleno do bloků, které (na rozdíl od sfér) nemají konstantní velikost
			- Např. ASCII (rozsah ```U+000000``` až ```U+00007F```) je tzv. Basic Latin Block 
	- Dalších 16 sfér v rozsahu ```U+010000``` až ```U+10FFFF``` jsou tzv. doplňkové sféry (supplementary planes), které se v oblasti střední Evropy téměř nikdy nepoužívají
		- V současnosti (2022 – Unicode verze 15.0) má pět doplňkových sfér přiřazeny znaky a celkem šest sfér je pojmenováno 
	- V současnosti (2022 – Unicode verze 15.0) je namapováno (tj. kódovým bodům jsou přiřazeny znaky) 149697 znaků
		- Unicode verze 1.0.1 měl 28327 znaků 

#### Kódovací schémata (charsety) Unicode

- Protože znak může být uložen na více bytech, je možné používat více charsetů (kódovacích) schémat
- Unicode má tři základní charsety UTF (Unicode Transformation Format), přičemž dva z nich mají další varianty  celkem 7 charsetů
	- UTF-8
	- UTF-16
		- Další varianty UTF-16BE a UTF-16LE přesně specifikující pořadí uložení bytů
	- UTF-32
		- Další varianty UTF-32BE a UTF-32LE přesně specifikující pořadí uložení bytů
	- Všechny charsety jsou schopny uložit celý rozsah Unicode (21 bitů)
	- Jednotlivé charsety jsou popsány v Kap. 28.3.4 až 28.3.6

#### Problém pořadí bytů, značka bytového pořadí

- Pokud ukládáme do paměti či souboru vícebytové entity (v tomto případě znaky), je potřeba rozlišit pořadí bytů
	- Např. pokud uvažujeme uložení znaku „```A```“ (```U+0041```) na dvou bytech, může být uložen jako
		- Little Endian (LE – „obrácené uložení“) – ```41 00```
		- Big Endian (BE – „přirozené uložení“) – ```00 41```
	- Pokud uvažujeme uložení znaku „```A```“ na čtyřech bytech, může být uložen jako
		- Little Endian – ```41 00 00 00```
		- Big Endian – ```00 00 00 41```
- Způsob ukládání závisí na platformě (Windows LE), programovacím jazyku (Java vždy BE), aplikaci atd.
- Jaký způsob je použit, je důležité při čtení souboru pro správné načtení vícebytových znaků
- Charsety Unicode mohou pro identifikaci používat počáteční značku bytového pořadí
	- Byte Order Mark (BOM)
	- Zapisuje se na úplný začátek souboru
	- Pro tento účel Unicode definuje dva kódové body
		- ```U+FEFF``` – pevná mezera nulové délky (zero width no-break space)
		- ```U+FFFE``` – není kód znaku (not a character code) 
	- Pro UTF-16 má BOM tvar ```FE FF``` pro BE a``` FF FE``` pro LE
		- Pokud je značka načtena správně, pak by se pevná mezera nulové délky neměla ze své podstaty zobrazit
		- Pokud je načtena nesprávně (zamění se BE za LE nebo naopak), opět by se neměla zobrazit, protože se jedná o neplatný znak
	- BOM se může nebo nesmí vyskytovat, což je dáno definicí konkrétního charsetu
	- U UTF-8 má BOM tvar ```EF BB BF```
		- Není vyžadována ani doporučována, nicméně není zakázána 
		- Může nastat problém se zdrojovými soubory ```.java```, které mohou být uloženy v UTF-8
		- Překladač javac nepředpokládá na začátku souboru BOM (i když není zakázáno, aby tam byla), některé editory ji tam však umístí  program pak nelze přeložit

### UTF-8

- Bylo vytvořeno, aby se znaky Unicode daly zakódovat posloupností bytů, se kterými umí pracovat každá aplikace a každý souborový systém
- Obecně rozšířený a používaný charset
	- Např. řetězce v .class souborech jsou uloženy v UTF-8
	- Ze zmíněných sedmi charsetů Unicode se UTF-8 používá v Evropě a v Americe pravděpodobně nejčastěji
- Pro texty využívající pouze znaky anglické abecedy je UTF-8 totožné s US-ASCII
	- Využívá se jen jeden byte na jeden znak
	- Soubory tak zabírají stejně místa, jako kdyby byly kódovány v US-ASCII
- Pro diakritické znaky se využívají dva byty, pro speciálnější znaky z BMP tři byty
	- Protože diakritických znaků je např. v českém textu cca 10 %, velikost souboru s českým textem naroste oproti použití jednobytového kódování (např. windows-1250) pouze o cca 10 %
- Pro znaky mimo BMP se využívají čtyři byty
- Základní nevýhoda UTF-8
	- Znaky obecně nemají stejnou délku => není možné skočit přímo na určitý znak
		-  „Přeskoč prvních 20 znaků“
- Princip kódování znaků v UTF-8
	- Aby bylo jasné, zda daný znak je uložen jako 1, 2, 3 nebo 4 byty, používá se MSB
	- Principiálně je možné zakódovat pomocí UTF až 31 bitů
		- ```1111 110u 10vv vvvv 10ww www 10xx xxxx 10yy yyyy 10zz zzzz```
- Princip čtení UTF-8
	- Pokud má byte nastaveno MSB na ```1```, pak počet jedničkových bitů za ním udává počet následujících bytů za prvním bytem znaku, přičemž každý následující byte začíná ```10``` (viz Tab. 28.2)
	- Pokud nečteme text od začátku a „trefíme“ se doprostřed vícebytového znaku, poznáme to podle bitů ```10``` => pak je třeba přeskočit všechny byty začínající ```10```
- V UTF-8 je zbytečná BOM – je jen jedno možné pořadí bytů 
	- Podle specifikace není ani vyžadována ani doporučena, není však zakázána
	- Některé aplikace však BOM u UTF-8 vyžadují a některé s ní naopak mají problémy 

#### UTF-16

- Vychází z UCS-2, což je kódování ISO s pevnou šířkou 2 byty na znak, což pokryje celou BMP
- Protože však Unicode přešel na 21 bitů, 2 byty (16 bitů) nestačí (pro znaky mimo BMP)
- Proto nastupuje UTF-16, které některé znaky kóduje 4 byty (tj. dvěma znaky UCS-2)
	- Oba „znaky“ se dohromady nazývají zástupné páry (surrogate pairs)
	- Mezi UCS-2 a UTF-16 je podobný vztah jako mezi ASCII a UTF-8
- UTF-16 se využívá pro uložení řetězců v operační paměti v Javě
- Při uložení UTF-16 do souborů se využívá BOM pro určení pořadí uložení bytů (LE nebo BE) 
	- Varianty UTF-16LE a UTF-16BE mají pořadí uložení bytů přímo určeno a BOM nesmí obsahovat 
		- Pokud BOM přesto obsahují, je ignorována
- Oproti UTF-8 zabírá pro běžné texty psané latinkou téměř dvojnásobek místa
	- Pro texty psané pouze znaky anglické abecedy přesně dvojnásobek

#### UTF-32 

- Kódování s pevnou šířkou 4 byty na znak
	- Každý znak je uložen jako 4 byty
	- Na 4 bytech jsou tak přímo uloženy kódové body Unicode 
	- Pouze 21 bitů je významových
	- Prakticky odpovídá UCS-4 (kódování ISO, rovněž 4 byty na znak) 
- Při uložení UTF-32 do souboru se rovněž využívá BOM pro určení pořadí uloženy bytů (LE nebo BE) 
	- Varianty UTF-32LE a UTF-32BE mají pořadí uložení bytů přímo určeno a BOM nesmí obsahovat
		- Pokud ho přesto obsahují, je ignorován 

### Praktické použití v Javě

- Java vnitřně ukládá řetězce do paměti jako UTF-16, většina souborů je však uložena v UTF-8 nebo v různých jednobytových charsetech
	- Při čtení a zápisu řetězců z/do souborů (i na standardní vstup a výstup) je tedy nutná konverze 

#### Nastavení charsetu při čtení a zápisu z/do textových souborů

- Konverzi provádějí třídy pro práci se soubory, jejichž název končí ```…Reader/Writer```
	- Jsou určeny pro práci se znaky
- Charset vstupního/výstupního souboru lze popsat instancí třídy ```Charset```
	- Metoda třídy ```Charset.forName(kódování)```
		- Vrátí instanci třídy ```Charset``` reprezentující daný charset na základě jeho jména
		- Lze použít kanonické jméno i aliasy
	- Metody z třídy ```Files``` pro čtení a zápis z/do souboru umožňují zadat charset souboru jako instanci třídy ```Charset```
		- Metoda ```Files.readAllLines(soubor, charset)```
		- Metoda ```Files.newBufferedReader(soubor, charset)```
		- Metoda ```Files.newBufferedWriter(soubor, charset)```

#### Správné zobrazení češtiny v konzoli Windows

- Od verze Javy 1.8 se čeština v konzoli Windows někdy zobrazuje správně, někdy však stále chybně 
	- Správně se zobrazují literály s diakritickými znaky zapsané přímo ve zdrojovém kódu
	- Špatně se zobrazují řetězce načtené ze standardního vstupu a vypsané na standardní výstup
	- Do verze Javy 1.7 včetně se zobrazovaly špatně i literály zapsané přímo ve zdrojovém kódu
- Problém je způsoben rozdílným standardním charsetem Windows (windows-1250) a konzole (implicitně IBM852 – lze změnit) 
	- Tyto charsety nejsou totožné (liší se v některých znacích)
	- Java tak očekává na standardním vstupu a výstupu charset windows-1250, ale v konzoli je IBM852 
- Korektní zobrazení v Java programech v konzoli Windows lze zařídit nastavením odpovídajícího charsetu pro standardní vstup a standardní výstup
	- Pro standardní vstup stačí nastavit charset v konstruktoru třídy Scanner
		- Zadává se pouze název charsetu jako řetězec
	- Standardní výstup funguje od Javy 1.8 korektně
- POZOR!
	- Problémy se týkají pouze konzole (příkazové řádky) Windows
	- Konzole IDE nástrojů (např. Eclipse) přebírají charset Windows (jsou to grafická okna) a čeština v nich funguje správně