4. diel - Babylonskej zmätenie kódovanie

V minulej lekcii, Reprezentácie čísel v počítači , sme sa zaoberali reprezentáciou čísel v počítači. Dnes sa budeme baviť o reprezentáciu textu. Ako asi tušíte, problematika bude tiež komplikovaná

Určite poznáte biblický príbeh babylonského zmätenie jazykov, ľudia si nerozumeli. Mali pošramotený komunikačný kanál. Čo je na tomto príbehu odstrašujúci, je, že sa to bohužiaľ v dnešnom svete počítačov deje tiež. Na úvod si ukážme ochutnávku kódovanie rôznych medzinárodných znakov v rôznych znakových sadách:

Použime ASCII

Ako prvý použijeme kódovanie ASCII. To je skratkou pre American Standard Code for Information Interchange. V prvej sade ASCII z roku 1963 išlo len o to poslať nejaké znaky, takže neobsahovala ani malé písmená. To v roku 1967 trochu napravili. Ak ste ale aspoň trochu zbehlí v počítačovej histórii, tak viete, že vtedy bola pamäť počítačov veľmi obmedzená a panovala túžba ušetriť každý bit (v dnešnej gigabytovou dobe nepredstaviteľné), takže ASCII sada bola 7-bitová. Mohli ste teda reprezentovať spolu až 127 znakov, čo je pre znaky 0 - 9, A - Z, a - z a špeciálne symboly v anglickej abecede celkom dosť. Základné ASCII tabuľka je vidieť na obrázku nižšie:

S rozvojom komunikačných protokolov dohodami, ako sa budú posielať bajty, sa prišlo na to, že by sa mal posielať znak po 8-mi bitoch. Zrazu bolo možné posielať 256 znakov. Ako ich doplniť?

Problémy začínajú

Maďarsko, Poľsko, Česko, Francúzsko, Rusko a ďalšie krajiny na svete napadlo, že by si do novej polovice ASCII sady, tzv. Extended časti, mohli dať svoju vlastnú abecedu. Samozrejme niekoľko ľudí na svete napadlo, že by mohli posielať napríklad aj srdiečka, smajlíky a ďalšie. No a zrazu sme mali hromadu nezávislých a nekompatibilných kódovanie. Presne to, čo sme nechceli. Preto si veľa ľudí povedala, že urobia svoje vlastné, lepšie kódovanie, napr. Windows 1250 (pre Windows), Latin 2 (pre UNIX) ... zhýralosť, prostopaš a mamon vo svete.

UNICODE

Prvá celosvetová snaha o riešenie je 32-bitové Unicode. Tzn. možno reprezentovať až 4 294 967 295 znakov a aj keď je ich pár zakázaných (okolo 2047), možno v Unicode reprezentovať japončinu, klingonštinu, elfštine, čínštinu, ruštinu a hieroglyfy. A zostalo nám ešte vážne veľa miesta, keby prileteli mimozemšťania a chceli si s nami písať emaily. Unicode je však len zoznam znakov, nedefinuje ako máme znaky v pamäti uložiť. To rieši nasledujúce kódovanie: UTF-32, UTF-16, UTF-8, UCS-2 ...

UTF-32

Máme formát, ktorý je 32-bitový, tak budeme každý znak písať na 4B. Pre každý znak tak máme rovnaký počet núl a jednotiek. Ale má to háčik. Napríklad sa príliš plytvá miestom. V ASCII sme na každý znak použili 1B. Ak sme Angličania a píšeme celý život romány, bohato nám stačí ASCII as každým znakom inak zahodíme 3B. Aj keby sme napísali román, kde Klingóni pristanú medzi pyramídami a privíta je faraón, ktorý v hieroglyfoch zosiela prastarú elfskú mágiu, sotva nám znak zaberie viac ako 3B. Formát je príliš robustná.

UCS-2

Povedzme si, že nepotrebujeme klingonštinu ani elfštine a budeme na jeden znak používať len dolných 16 bitov (2B). Zas ale nemožno napísať román o stretnutie faraona s kapitánom Kirkom v dobovej reči ... Prídeme tým o polovicu abecedy.

UTF-16

Skúsme na to ísť inak. Pre znaky 0 - 65535 budeme používať 2B, pre vyššiu 4B. Ako ale počítač pozná, či je to 4B znak, alebo dvakrát 2B za sebou? Pomôžu nám pre to zakázané znaky. Tie sú niečím ako (medzičlánok), tzn. že počítač vie, že po jeho prečítaní musí prečítať ešte ďalší znak. Hovorí sa im tzv. Surrogate - zástupca. 4B znak je v podstate kombináciou dvoch surrogate za sebou. Samy o sebe nemajú význam, ale keď sa ich hodnota skombinuje, adresujú celý priestor znakov.

UTF-8

Prečo je tu ešte UTF-8, keď to vyzerá, že je UTF-16 ideálny? Dobre ... Niekto mal stále pocit, že sa plytvá pamäťou a tak si povedal, že by sa niečo mohlo indexovať 1B, 2B, 3B a niečo 4B. A teraz ... ako je odlíšiť?

No, 1B musí začínať 0, pretože znaky z ASCII sú od 0 do 127 a my chceme UTF kompatibilná s ASCII sadou. Práve tieto znaky chceme indexovať 1B, atď ... Vždy logicky vyradíme nižšiu poriadok a prvé logicky možný je poriadok, ktorý chceme.

Tu je vidieť, ako reťazec niekoľkých špeciálnych znakov vyjadríme v rôznych Unicode kódovaniach:

Svet Unicode

Začali sme s tým, že chceme zjednocovať a vo výsledku máme len ďalší hromadu znakových sád? Ale dobre, už je to trochu lepšie. Problémy by mohli prestať ... alebo aj nie

Smer textu

Chceme si dopisovať s kamarátom z Tel Avivu a máme opačný smer textu? Čo s tým, že my píšeme zľava doprava a on sprava doľava? Dobre, môžeme si povedať, že na začiatku každého textu bude nejaká magická konštanta, ktorá nám povie smer textu? Dobre ..., čo ak ale chceme písať emaily v angličtine a mená miest v hebrejčine? Takže máme text, ktorý má v sebe ďalší text v inom smere, takto: -> -> -> -> -> -> <- <- <-> -> -> -> -> ... Existujú teda kontrolnej znaky. Ale tie nie sú v štandarde, môže to byť čokoľvek ...

Textu si nevšímajte

Kombinované znaky

Chceme uložiť znaky ako á, čo je znak a + ´ (a + čiarka), ď potom je d + ˇ + háčik) atď ... Toto sú tzv. Kombinované znaky. Znak môžeme skombinovať z mnohých ďalších. Lenže niektoré znaky sa používajú tak často, že sa pre ne vymyslela skratka ako znak jeden. Takže zrazu porovnávate reťazce, ktoré majú byť rovnaké, ale v bitovom zápise potom nie je á uložené ako a + ´.

Endianita

A zas prišla slávna endianita. Každý počítač môže mať poradie bajtov opačné a text môže zrazu vyzerať úplne inak ...

Konce riadkov

Keby toho nebolo málo, tak aj keď máme rovnaké kódovanie aj rovnakú endianita, napriek tomu môžeme naraziť s konci riadok.

Predtým sa písalo na písacích strojoch. Skúste sa vžiť do tej atmosféry, počujete klapať prstíky, potom zrazu ticho. Škrty, kkkkkr, a nanovo. Keď pisateľ dopísal, otočil valec, posunul na začiatok a písal odznovu.

Urobili sa teda znaky CR a LF, ktoré označujú Carrige Return (návrat tlačovej hlavy) a Line Feed (posun papiera o riadku). Preto sa uznieslo, že sa budú konca riadok písať ako CR, LF. Na konci riadok sú teda vždy 2 znaky. Teda ... boli. Windows používa túto kombináciu stále, ale niekto sa na to pozrel a povedal ... Nepotrebujeme predsa 2 znaky, stačí nám jeden. A tak si vybrali ... každý niečo iné. Windows má CRLF, UNIX má LF a MacOS má CR. Takže keď pošlete dokument z Windows do Linuxu a skontroluje ho niekto tretí na MacOS, tak vás pri editáciu textu čaká pekné popoludnie ...

Čo z toho?

Snahy zjednotiť boli nakoniec odmenené len čiastočne. Unicode sa rozdrobil a jednotlivé platformy sa líši tým, čo kde používajú. S tým súvisí aj to, ako budete čítať súbory a do nich zapisovať. Veľmi výstižne to vystihol jeden komentár:

Je hanbou, že v 21. storočí ešte nemáme vyriešené jednotné zobrazovanie znakov.

.<>

Malá čerešnička na záver

Keď už sme hovorili o špeciálnych znakoch, koniec riadky nevidíte. Ten si proste nevytlačíte. Akonáhle by ste chceli vytlačiť koniec riadky, program by sám odřádkoval. Teraz si vezmite, že existuje niečo ako EOF, čiže End Of File. Skúsite si ho predstaviť? To ani nejde! Akonáhle by niekto do nejakej učebnice napísal, ako vyzerá EOF, v ten moment by učebnice skončila

V budúcej lekcii, Architekt, kam som si ten výpočet uložil ...? , sa budeme venovať pamätiam.