ASCII, UNICODE i UTF-8 - Predstavljanje znakova na računarima

Uvod

Citat koji ste upravo pročitali, preuzet je sa zvaničnog sajta konzorcijuma UNICODE i potcrtava osnovnu ideju koja stoji iza pomenutog standarda koji korisnicima najrazličitijih računarskih sistema već duže vreme omogućava upravo to što je navedeno - da na različitim uređajima, na različitim operativnim sistemima i u različitim programima, koriste maternji jezik (uz odgovarajuće pismo), ili bilo koji drugi jezik koji požele.

Reklo bi se da je 'nekako' red da početkom treće decenije dvadestog veka situacija bude takva, ali nije uvek bilo tako.

Nekada su "nad mutnom vodom graktale vrane" .....

ASCII - American Standard Code for Information Interchange

Pre nego što je postalo moguće na računarima koristiti "sve" * znakove iz bilo kog jezika (kako smo naveli u uvodu), na red su prvo došli znakovi engleskog jezika uz znakove interpunkije, znakove matematičkih operacija i određeni broj drugih ubičajenih znakova.

Međutim, bilo je potrebno (pre svega) uspostaviti osnovni sistem koji uopšte omogućava bilo kakvo korišćenje znakova na računarima (a ne brinite, osvrnućemo se malo kasnije i na vrane).

Da bismo vam malo "zakomplikovali život" (zapravo, pomogli da bolje razumete tematiku članka), pre nego što pređemo na ASCII i UNICODE, osvrnućemo se na osvnovni princip zapisivanja znakova na računarima.

Kako računari (uopšte) mogu razumeti znakove?

U članku u kome smo diskutovali o tome zašto binarni brojevni sistem (a ne dekadni) predstavlja svojevrsnu osnovu računarskih sistema, objasnili smo da računari - ne samo da nisu u stanju da neposredno razumeju dekadni brojevni sistem, već da (u opštem smislu) nisu u stanju da razumeju ni brojeve.

Ako računari nisu u stanju da neposredno razumeju (čak ni binarne) brojeve, nije za očekivati ni da budu u stanju da neposredno razumeju znakove?!

Međutim (u praktičnom smislu), logička kola u računarima prepoznaju dva različita naponska stanja: "nema napona" i "ima napona", koja se mogu shvatiti kao cifre (binarnog sistema) 0 i 1, pa se nule i jedinice dalje mogu nizati tako da tvore binarne brojeve, koji se kasnije mogu interpretirati (prikazivati korisnicima) kao dekadni.

Nizanjem bajtova se mogu kodirati i znakovi.

Osnovna ideja je da se, makar u okviru jednog računarskog sistema, za kodiranje određenog znaka koristi određena brojčana vrednost (uvek ista), pa ostaje "samo" pitanje kako uskladiti različite računarske sisteme.

Pre uvođenja ASCII standarda (period koji grubo možemo smatrati prvim godinama računarske industrije, to jest, druga polovina pedesetih i šezdesete godine dvadesetog veka), znakovi su se na računarima zapisivali na idiosinkratične načine (idiosinkratičan = sebi svojstven), koji nisu bili međusobno usklađeni, što praktično znači da nije bilo moguće razmenjivati teksutalne poruke između različitih računarskih sistema (makar ne bez programa za prevođenje).

U to vreme, kada su računari još uvek u kontekstu šire primene delovali kao nešto iz domena naučne fantastike, nemogućnost međusobne komunikacije računara nije bila preveliki problem (donekle), ali, razmišljalo se i o budućnosti, za koju se već tada očekivalo da će podrazumevati širu rasprostranjenost računara i veći obim komunikacije između računara i zaključeno je da takva budućnost neće biti moguća bez (pre svega) opšteprihvaćenog standarda za razmenu poruka između različitih računarskih sistema.

Uvođenje ASCII standarda

ASCII (American Standard Code for Information Interchange), je prvi široko rasprostranjen i opšteprihvaćen standard za kodiranje znakova u elektronskoj komunikaciji i kao takav, hardverski podržan od većine (koliko nam je poznato - skoro svih) računara koji su se u međuvremenu pojavili.

Prva specifikacija ASCII standarda je objavljena 1963, ali je ASCII svoj krajnji oblik poprimio krajem šezdesetih godina.

U osnovnom tehničkom smislu, ASCII standard podrazumeva da se brojevi u rasponu od 0 do 127 koriste za kodiranje velikih i malih slova engleskog alfabeta, cifara i drugih pažljivo biranih specijalnih znakova.

ASCII tabela

ASCII tabela sadrži 128 znakova (koje možete videti u donjem formularu) i formatirana je tako da prve 32 pozicije zauzimaju kontrolni znakovi (znakovi koji se ne vide u štampi, ili na ekranu), dok ostale pozicije zauzimaju znakovi koji se mogu videti i predstavljeni su grafičkim simbolima.

Što se tiče kontrolnih znakova koji zauzimaju početne pozicije (i ne vide se u ispisu), izdvojićemo nekoliko uobičajenijih (sa dekadnim kodovima, za lakše snalaženje):

• 8 - Backspace (taster BACKSPACE)
• 13 - Carriage return (taster "ENTER")
• 27 - Escape (taster ESC)
• 32 - Space (razmak na tastaturi)

(Za ostale znakove koje prepoznajete od ranije, možete videti grafičke simbole.)

Pravilnosti u dodeljivanju mesta u tabeli ciframa i slovima

ASCII tabela može delovati donekle nasumično na prvi pogled, međutim, kada su u pitanju slova i cifre, zapravo postoji prilično jasna ideja vodilja: udesiti tabelu tako da cifra 1, kao i veliko i malo slovo 'A' - "kreću od jedinice".

Kao prvo, jasno je da istu (prvu) poziciju u tabeli ne mogu zauzimati tri znaka istovremeno. Vidimo i to da nijedan od tri navedena znaka nije na prvoj poziciji u tabeli, a ne deluje ni da kodni brojevi 48, 65 i 97 mogu imati previše veze sa znakovima '0', 'A' i 'a'.

Međutim, ako pažljivije sagledamo binarne vrednosti pripisane ciframa i slovima, zapazićemo red i pravilnosti.

Ako posmatramo zapis cifara preko ASCII tabele (uzećemo samo nekoliko prvih za primer) ....

.... zapažemo da bitovi na najnižim pozicijama odgovaraju vrednostima cifara (uz uključene bitove na pozicijama 32 i 16, što daje zbir 48):

• cifra '0' ima ASCII kod 48, što možemo shvatiti kao 48 + 0
• cifra '1' ima ASCII kod 49, što možemo shvatiti kao 48 + 1
• cifra '2' ima ASCII kod 50, što možemo shvatiti kao 48 + 2

Ista ideja stoji i iza zapisa malih slova:

.... gde takođe zapažemo da bitovi na najnižim pozicijama odgovaraju pozicijama znakova u engleskom alfabetu ....

• znak 'A' ima ASCII kod 65, što možemo shvatiti kao 64 + 1
• znak 'B' ima ASCII kod 66, što možemo shvatiti kao 64 + 2
• znak 'C' ima ASCII kod 67, što možemo shvatiti kao 64 + 3

Velika slova takođe se kodiraju po sličnom principu:

Bitovi na najnižim pozicijama (ponovo) odgovaraju pozicijama znakova u engleskom alfabetu i takođe, kodne vrednosti su veće za 32 u odnosu na velika slova:

• znak 'a' ima ASCII kod 97, što možemo shvatiti kao 64 + 32 + 1
• znak 'b' ima ASCII kod 98, što možemo shvatiti kao 64 + 32 + 2
• znak 'c' ima ASCII kod 99, što možemo shvatiti kao 64 + 32 + 3

Poznavanje navedenih pravilnosti dobro dođe u pisanju određenih programa.

Manipulacija bitovima i drugi programski kodovi za ispis znakova

Manipulacijom bitova (pod uslovom da smo sigurni da dati znak jeste - "ono što bi trebalo da bude"), vrlo lako možemo pretvarati velika slova u mala, mala u velika i takođe, od znakove koji predstavljaju cifre lako možemo dobiti odgovarajuće celobrojne vrednosti.

Na primer:

		
malo_slovo   = veliko_slovo |  32;   // 'A' => 'a'
veliko_slovo = malo_slovo   & ~32;   // 'a' => 'A'
cifra        = znak_za_cifru  & 15;  // '1' => 1
		
	

Kad smo već kod programskih kodova, u C-u je veoma lako dobiti ispis kodne vrednosti znaka:

		
char c = 'A';
printf("%c\n", c); // A
printf("%d\n", c); // 65
		
	

.... a pomenimo i da se navedeno, može izvesti i preko Javascript-a (pri čemu ima i dodatnih mogućnosti):

		
let c = 65;

console.log(`&#c;`);         // A
console.log(c.toString(2));  // 01000001
console.log(c.toString(16)); // 41
console.log(c);              // 65
		
	

Naravno i mnogi drugi jezici omogućavaju slične zahvate.

Proširena ASCII tabela / kodne stranice

ASCII tabela je sedmobitna (nasleđe iz starijih vremena), ali se praktično zapisuje preko osam bita (1 bajt), pa je jasno da u takvom zapisu postoji mesta za dodatnih 128 znakova.

U periodu posle početnog 'uhodavanja' sa ASCII standardom, a pogotovo između početka osamdesetih i sredine devedesetih godina dvadesetog veka, pojavile su se brojne 'varijacije na temu' ASCII tabele.

Neke od tih proširenih tabela samo su dodavale znakove na pozicije preko 127, dok su druge tabele koristile eklektičan pristup koji je podrazumevao i zamenu ponekog znaka iz standardne ASCII specifikacije (koji se već u navedenom periodu sa kraja prošlog veka nisu koristili), drugim znakovima koji su smatrani praktičnijim za upotrebu.

Ovakve tabele nazivaju se još i kodnim stranicama (eng. code page), a za primer ćemo uzeti kodnu stranicu 437, proširenu ASCII tabelu koja je uvedena sa prvobitnim PC računarima, odnosno sa operativnim sistemom DOS:

		
199 - ╟

200 - ╚

201 - ╔

195 - ├

192 - └

218 - ┌

30 - ▲

31 - ▼
		
	

Zarad preglednosti, prikazali smo samo pojednine znakove (a programeri sa podužim stažom, setiće se vremena kada su se ovakvi znakovi koristili za kreiranje prozora u tekstualnom režimu).

Pre nego što konačno pređemo na UNICODE i UTF-8, osvrnućemo se ukratko i na kodne stranice sa znakovima različitih pisama koje možemo smatrati prethodnicima UNICODE-a, standarda koji (kao što je već pomenuto) objedinjuje znakove praktično svih pisama, kao i mnoge druge znakove.

Kodna stranica 1251 (ćirilica)

Kodna stranica (Code Page) 1251, odgovara znakovima srpskog ćiriličnog pisma (zarad preglednosti, i ovde ćemo navesti samo određene znakove) ....

		
230 - ж
142 - ћ
247 - ч
248 - ш
		
	

Kodna stranica 852 (latinica)

Za latinična pisma iz slovesnkih jezika, bila je zadužena kodna strancia 852:

		
159 - č
158 - ć
231 - š
190 - ž
		
	

Kodna stranica 737 (grčki alfabet)

Da bismo ilustrovali relativnu proizvoljnost principa korišćenja kodnih stranica, uzećemo za primer još i Kodnu Stranicu 737, preko koje su definisana grčka slova (pozicije koje se poklapaju sa pozicijama iz prošlog odeljka) ....

		
158 - η
159 - θ
231 - ύ
240 - Ώ
		
	

Dovoljno je pogledati prethodnih nekoliko i doći do zaključka da kodne stranice (bar iz današnje perspektive) deluju pomalo neorganizovano, kao i to da bilo kakva greška koja bi dovela do pogrešnog odabira kodne stranice, dovodi do toga da tekst postane praktično nečitljiv (greške su svakako manje izražene u slučajevima kada se pomešaju različite verzije latiničnih pisma, dok ako pomešamo, na primer, ćirilicu i grčko pismo - nećemo biti "takve sreće").

Naravno, možemo iz sadašnje perspektive gledati na kodne stranice na način kako pojedini ljudi posmatraju fosilne ostatke predaka homo sapiensa, ali, evolucija se ne dešava 'preko noći', nekada nije bilo 'mostova i puteva' i trebalo je ipak vremena i truda da se sve izgradi kako dolikuje.

UNICODE

Sada kada razumemo dobru oragnizaciju ASCII znakova po pitanju znakova engleskog alfabeta i cifara, ali i očigledne nedostatke indeksiranja različitih skupova znakova (različitih svetskih pisama) preko proširenih ASCII tabela, jasno je da je bilo potrebno opštije i bolje implementirano rešenje.

UNICODE predstavlja standard iza koga stoji nekoliko osnovnih ideja:

• osnovni cilj je - obuhvatiti sve znakove, iz svih svetskih jezika, odnosno - koliko god je moguće znakova
• svaki znak mora imati jedinstvenu kodnu poziciju (eng. code point) - što je pristup sličan ASCII standardu
• UNICODE mora biti potpuno kompatibilan sa ASCII specifikacijom (kodovi znakova iz ASCII tabele odgovaraju kodnim pozicima koji dati znakovi zauzimaju u UNICODE specifikaciji)

UNICODE konzorcijum osnovan je krajem osamdesetih godina dvadesetog veka. Osnivači ovog projekta su programeri Džo Beker (Joe Becker), Li kolins (Lee Collins) i Mark Dejvis (Mark Davis), a podršku pružaju brojni saradnici iz različitih računarskih kompanija (pogotovo onih koje su direktno zainteresovane za održavanje standarda u oblasti obrade teksta na računarima).

U početku, specifikacija je obuhvatale nekoliko desetina hiljada znakova (što svakako nije mali broj), ali, već do početka XXI veka, prevaziđen je broj od 100 hiljada znakova ....

....što je zahtevalo 'prepravljanje' tehničkih rešenja za enkodiranje znakova.

Kada smo kod tehničkih rešenja, od svih odlika UNICODE-a koje smo naveli, posebno se ističe očuvanje kompatibilnosti sa ASCII standardom (pri čemu je doneta racionalna i praktična odluka da se ASCII tabela "ne dira" - već samo proširi), što posebno dolazi do izražaja ako se za enkodiranje UNICODE znakova koristi UTF-8 specifikacija (o svemu navedenom ćemo govoriti u nastavku).

Enkodiranje UNICODE znakova

Znakovi se u ukviru UNICODE standarda kodiraju prema dogovoru, tako da svakom znaku odgovara jedinstvena 'kodna pozicija' (eng. code point), čime je otklonjena zbrka koju je (ranije) unosilo korišćenje različitih kodnih stranica:

• prvih 127 pozicija zauzimaju redom znakovi iz ASCII tabele.
• zatim slede uobičajenija pisma nalik na engleski alfabet (u koja možemo ubrojati ćirilicu i latinicu, grčki i ruski alfabet), čiji znakovi zauzimaju kodne pozicije relativno blizu početnih ASCII pozicija.
• više pozicije zauzimaju manje uobičajena (ali i dalje široko rasprostranjena) pisma sa velikim brojem znakova (kinesko, japansko, korejsko, indijsko i sl).
• najviše / najudaljenije pozicije zauzimaju najrazličitije vrste specijalnih znakova (emotikoni i sl).

Sledeće pitanje je: kako to sve zapisati, odnosno kodirati?

ASCII znakovi zauzimaju 1 bajt (zapravo manje od jednog celog bajta), dok sa UNICODE znakovima, kojih ima mnogo više od 2^7, to nije i ne može biti slučaj.

Na primer, sledeći znakovi (uzmimo za primer nekoliko znakova različite "udaljenosti" od ASCII pozicija) ....

		
Č  - 268
∑  - 8721
✅ - 9989
🙂 - 128578

		
	

.... shodno svojim kodnim pozicijama, očigledno zahtevaju više od jednog bajta za zapis (dva, tri, ili četiri).

Prvobitno rešenje (UCS-2), koje je podrazumevalo kodiranje svakog znaka preko dva bajta, koristilo se pre 2000. - u vreme dok je ukupan broj kodnih pozicija bio manji od 2^16 (65536), ali došao je i trenutak kada je broj kodnih pozicija prerastao navedenu vrednost ....

UNICODE Transformation Format (UTF-16 - UTF-32 - UTF-8)

Kada je broj kodnih pozicija prevazišao smeštajni kapacitet od 16 bita, uveden je standard UTF-16, koji predstavlja proširenje UCS-2 specifikacije, a potom i standardi UTF-32 (koji koristi 4 bajta), kao i UTF-8.

U nastavku ćemo posvetiti pažnju tehničkim detaljima ovih metoda za kodiranje znakova, njihovim prednostima i nedostacima, kao i oblastima primene.

Iako u naslovu članka stoji (samo) UTF-8, standardu UTF-16 ćemo svakako posvetiti svu dužnu pažnju

UTF-16

UTF-16 je unapređenje standarda UCS-2, koji je podrazumevao korišćenje dva bajta za zapis svakog znaka.

Upravo je to osnovna ideja koja stoji i iza UTF-16 zapisa, ali, pretpostavka da će ((za)uvek) biti dovoljno koristiti 2^16 znakova je, kao što smo već nagovestili, odavno opovrgnuta.

Kada su u pitanju niže pozicije, za UTF-16 zapis znaka (baš kao i u slučaju starog standarda UCS-2), izdvojićemo dva bajta, a razliku u odnosu na UCS-2 predstavljaju pozicije preko 65536, u kom slučaju se u okviru UTF-16 zapisa koristi poseban postupak uz koišćenje dva dodatna bajta.

Primera radi, znak 'Č' (koji smo već pominjali), čija je kodna pozicija 268, u UTF-16 enkodiranju koristi dva bajta i ima sledeći raspored bitova:

Za ovakav znak, korišćenje dva bajta je racionalan i optimalan izbor.

Ako isti princip primenimo na znak 'A', čija je kodna pozicija ("i dalje") 65 ....

.... vidimo da je zapis (naravno) moguć, ali da pri tom dolazi do (reklo bi se - nepotrebnog) dupliranja memorijskog zauzeća.

Na slici vidimo da prvi bajt (praktično) ne igra nikakvu ulogu, ali, iako UTF-16 dozvoljava korišćenje dodatne grupe od dva bajta (po potrebi), nije moguće selektivno koristiti samo jedan bajt za znakove sa prvih 127 pozicija (čime se za zapis ASCII znakova preko UTF-8 standarda ne bi koristilo duplo više memorije).

Sada možemo uzeti u obzir i kodne pozicije koje ne mogu stati u 16 bita ....

Zapis kodnih pozicija većih od 65535 - parovi surogata

Kada je u pitanju UNICODE specifikacija, postoji "rupa" / 'bermudski trougao' između kodnih pozicija 55296 (0xD800) i 57343 (0xDFFF).

Ova čudna 'tvorevina' predstavlja raspon od dve grupe po 1024 pozicije, koje se ne koriste za indeksiranje znakova, već omogućavaju da se, prostim nadovezivanjem vrednosti iz ovih grupa, adresira 2^20, odnosno, 1048576 znakova.

Na ovaj način, preko standarda UTF-16, obavlja se enkodiranje / dekodiranje kodnih pozicija većih od 65536, pri čemu:

• pozicije od 55296 do 56319 zauzimaju tzv. viši surogati (high surrogates)
• pozicije od 56320 do 57343 zauzimaju niži surogati (low surrogates)

Naarvno, pomenuti proces se ne dešava sam od sebe (i - pre svega - ne verujemo da prethodna priča može biti jasna sama po sebi), pomenuti "surogati" ne nastaju tek tako, ali, procedura je relativno jednostavna, pa ćemo je detaljno razmotriti.

Prvo je potrebno od kodne pozicije oduzeti 65536:

Surogat je 20-bitni zapis date vrednosti, pri čemu se deli na dva 10-bitna bloka, od kojih će viših 10 bitova biti 'utisnuto' u raspon viših surogata, dok će drugih 10 bitova biti 'utisnuto' u raspon nižih surogata.

Da bismo to izveli, prvih 10 bitova sabiramo sa početnom pozicijom raspona viših surogata (55296, odnosno 0xD800):

Dobijeni rezultat zapisujemo kao prvu kombinaciju od dva bajta:

Nižih 10 bitova sabiramo sa početnom pozicijom raspona nižih surogata (563200, odnosno 0xDC00):

Dobijeni rezultat zapisujemo kao drugu kombinaciju od dva bajta.

Ovim je znak formairan.

Situacija u kojoj se, pri čitanju UTF-16 znakova, vrednost iz raspona nižih surogata pojavi pre odgovarajuće vrednosti iz raspona viših surogata, ili se vrednost iz raspona viših surogata pojavi samostalno - predstavlja signal da je došlo do greške u čitanju (ovo je kontrolni mehanizam čiji je cilj da predupredi greške u prenosu znakova).

Prednosti, nedostaci, oblast upotrebe

Da bi UTF-16, kao način kodiranja znakova, bio zaista univerzalan, morala bi biti otklonjena dva nedostatka:

• UTF-16 zapis očigledno nije direktno kompatibilan sa ASCII datotekama (direktno čitanje ASCII datoteke, pri čemu bi se znakovi koji inače zauzimaju jedan bajt, čitali u blokovima od po dva bajta, dovelo bi do grešaka)
• konvertovanje ASCII datoteka u UTF-16 datoteke, duplira memorijsko zauzeće.

Pomenuti nedostaci čine UTF-16 nepraktičnim za kodiranje web stranica i trajno čuvanje teksta, ali je zato UTF-16 i dalje način zapisa znakova koji se najčešće koristi interno, u operativnim sistemima, aplikacijama i programskim jezicima (gde dodatno memorijsko zauzeće ne predstavlja preveliki problem, pa stoga UTF-16 predstavlja praktičnije rešenje od UTF-8 zapisa i starijih, pervaziđenih rešenja).

UTF-32

UTF-32 predstavlja način da se znak sa bilo kojom kodnom pozicijom zapiše neposredno, bez šifriranja / utiskivanja bitova (kao što je slučaj sa UTF-16 kodiranjem, kao i sa stanrdom UTF-8, o kome ćemo tek pisati).

Znak '🙂' (popularni smajli), čija je kodna pozicija 128578, zahteva 3 bajta za zapis ....

.... pri čemu je (čak i u ovom, najmanje "dramatičnom") slučaju, jasno da se jedan bajt uopšte ne koristi:

Po pitanju "rasipanja" prostora, stvari su joše gore kada zapisujemo uobičajenije UNICODE znakove:

.... u kom slučaju se nepotrebno koriste dva bajta ....

..... a naravno, najgora situacije je sa zapisom znakova iz ASCII specifikacije ....

.... u kom slučaju se nepotrebno koriste tri bajta:

UTF-32 (za razliku od standarda UTF-16 i UTF-8) nije toliko zastupljen, ali se često koristi u aplikacijama za zapis pojedinačnih znakova.

Kao što smo već ranije spominjali, za prenos i čuvanje većih količina teksta, najčešće se koristi prilično elegantno rešenje u vidu UTF-8 specifikacije ....

UTF-8 specifikacija

Osnovna ideja koja stoji iza UTF-8 zapisa je da se za kodiranje znakova koriste blokovi od 8 bita, tako da se znakovi iz ASCII tabele (i dalje) zapisuju preko jednog bajta, a da se za ostale znakove uvode dodatni bajtovi, ali - samo po potrebi.

Da budemo precizniji: zapis prvih 128 znakova je isti kao i preko ASCII tabele, a ostali znakovi zapisuju se na nešto komplikovaniji način koji omogućava prostornu uštedu ali zahteva malo više procesorskog vremena pri čitanju i pisanju znakova.

Sve što smo naveli "lepo zvuči", ali, glavno pitanje je - kako se ideja sprovodi u delo.

Primeri formiranja kodnih pozicija preko jednog ili dva bajta

Znakovi iz ASCII tabele ....

.... zapisuju se (kao što smo rekli) na isti način kako se zapisuju u samoj ASCII tabeli.

Međutim - glavna informacija u smislu enkodiranja/dekodiranja znaka je (kao što verovatno naslućujete) - prvi bit:

• ako je prvi bit 0 - u pitanju je (praktično) znak iz ASCII tabele
• ako je prvi bit 1 - u pitanju je znak sa kodnom pozicijom preko 127, koji se kodira preko (bar) dva bajta

Na gornjoj slici, prvi bajt nije uključen i upravo je to informacija UTF-8 parseru da za dekodiranje datog znaka neće biti potrebno čitanje dodatnih bajtova.

U tome leži pomenuta elegancija UTF-8 pristupa: ASCII je 7-bitni standard, ali se (kao što znamo) tipično prenosi preko osam bita, što ostavlja mogućnost da se prvi bit koristi kao prenosilac informacije o tome da li će za dekodiranje određene kodne pozicije biti dovoljno da se pročita jedan bajt (kao u prethodnom slučaju), ili će biti potrebni i dodatni bajtovi.

Ako je (nasuprot prethodnom slučaju) prvi bit uključen, to podrazumeva čitanje bar dva bajta:

• preko prvih nekoliko bitova u prvom bajtu, definisan je ukupan broj bajtova koji se koriste za enkodiranje znaka (posmatra se ukupan broj uzastopnih jedinica na početku, posle čega mora biti zapisana nula)
• prva dva bita u ostalim bajtovima moraju biti redom 1 i 0
• preko preostalih bitova (u svim bajtovima), zapisuje se kodna pozicija

Na prethodnoj slici smo videli kako se preko dva bajta, po UTF-8 specifikaciji, formira znak 'Č'.

Da pojasnimo dodatno primer očitavanja znaka za čije se kodiranje koriste dva bajta: kada na prvoj poziciji (u prvom bajtu) pronađemo jedinicu, očitaćemo i drugi bit i ako na drugoj poziciji takođe pronađemo jedinicu, a na trećoj poziciji nulu:

.... to će značiti da je za formiranje kodne pozicije potrebno pročitati još jedan bajt (ili možda malo drugačije, "samo" još jedan bajt, odnosno, da se za dati znak koriste ukupno dva bajta):

Drugi bajt mora počinjati kombinacijom bitova 10, a, kada se izdvoje preostali bitovi u oba bajta ....

.... dobija se 11 bitova preko kojih možemo zapisivati znakove sa kodnim pozicijama u rasponu od 0 do 2047 (2 ^ 11 - 1).

Konkretna kombinacija bitova 100001100, formira vrednost 268 (256 + 8 + 4), što je kodna pozicija znaka 'Č', sa kojom smo se već susretali.

Svrha kontrolnih bitova

Kodiranje drugog bajta (odnosno, ostalih bajtova, u opštem slučaju), kombinacijom bitova 10 na samom početku, deluje (na prvi pogled) malo "napotrebno", ali, u pitanju je kontrolni mehanizam koji je uveden zarad situacija u kojima se tekst ne prenosi u obliku datoteka, već znak-po-znak (streaming).

U takvim situacijama, početna dva bita pružaju informaciju o potencijalnim greškama koje mogu nastati u prenosu:

• ako drugi bajt počinje nulom, to je signal da znak nije pravilno enkodiran, što znači da prethodni bajt treba odbaciti (i formirati vrednost korišćenjem samo drugog bajta, koji se u tom slučaju prepoznaje kao samostalni "ASCII" znak)
• ako drugi bajt počinje sa 11, to je takođe signal da prethodni bajt treba odbaciti, a u ovom slučaju se zarad formiranje vrednosti kodne pozicije moraju pročitati i ostale jedinice na početku (da bismo ustanovili koliko je dodatnih bajtova potrebno čitati) i potom sledeći bajt (ili bajtovi) koji mora(ju) počinjati kombinacijom bitova 10

(U oba slučaja smo naravno podrazumevali da se prethodno pojavio bajt koji počinje jedinicom i da razmatramo bajt za koji očekujemo da počinje sa 10.)

Primer formiranja kodne pozicije preko tri ili više bajtova

Za formiranje kodnih pozicija koje prevazilaze vrednost 2047, koristićemo tri bajta, po prethodno opisanom principu: u prvom bajtu je zapisano koliko bajtova se koristi za enkodiranje/dekodiranje znaka, a ostali počinju sa 10.

Za enkodiranje je raspoloživo 16 bitova, te je stoga maksimalna kodna pozicija koja se može zapisati na ovaj način 65535.

Za formiranje kodnih pozicija koje prevazilaze 65535, potrebno je koristiti četiri bajta.

Za enkodiranje je raspoloživ 21 bit, te je stoga maksimalna kodna pozicija koja se može zapisati na ovaj način 2097151.

Teoretski, preko UTF-8 specifikacije, moguće je koristiti i pet, pa i šest bajtova (što možete isprobati u mini-aplikaciji na kraju ovog članka), ali, budući da se preko četiri bajta može zapisati bilo koji znak čija je kodna pozicija između 65536 i 2097151, pri čemu navedena gornja granica daleko prevazilazi broj znakova koji su trenutno prisutni u UNICODE specifikaciji, formatima koji koriste više od četiri bajta (u praktičnom smislu) ne moramo pridavati preveliki značaj.

Primer čitanja poruke enkodirane po UTF-8 specifikaciji

Da bismo još bolje utvrdili princip kodiranja znakova preko UTF-8 specifikacije, razmotrićemo primer.

Tekstualna datoteka sastoji se iz sledećih bajtova: 196 140 97 197 161 97:

.... i potrebno je pročitati poruku koja je u datoteci sadržana.

Prvi bajt ....

.... sugeriše da je za dešifrovanje znaka potrebno počitati još jedan bajt:

Preko 11 bitova, formiraćemo vrednost 268, što predstavlja znak 'Č':

Sledeći bajt, počinje nulom ....

.... što znači da odmah možemo pročitati preostalih 7 bitova, koji daju vrednost 97, što predstavlja znak 'a':

Četvrti bajt ....

.... (kao i prvi) sugeriše da je za dekodiranje znaka potrebno pročitati dva bajta (odnosno - još jedan bajt) ....

.... a preko datih 11 bitova, definisana je vrednost 353, odnosno znak 'š':

Šesti (poslednji) bajt počinje nulom ....

.... što znači da odmah možemo dekodirati znak preko preostalih 7 bitova:

Poruka sadržana u tekstualnoj datoteci je "Čaša".

Formular: UTF-8 enkoder / dekoder

Zaključak / kraka analiza

U ovom članku smo se podosta "napričali" o metodama enkodiranja/dekodiranja znakova, ali, tema za razgovor ima još ....

Iako smo najviše prostora posvetili UTF-8 standardu i implicirali da ovaj standard predstavlja najoptimalnije rešenje, osvrnućemo se i na prilično očigledne nedostatke UTF-8 zapisa:

• za predstavljanje znakova pojedinih pisama preko UTF-16 enkodiranja (primer: kinesko pismo), dovoljna su 2 bajta, dok je, kada se za iste znakove koristi UTF-8 enkodiranje, potrebno koristiti 3 bajta
• procedure enkodriranja i dekodiraja UTF-8 znakova su relativno komplikovane za implementaciju, pa je time i enkodiranje / dekodiranje UTF-8 znakova nešto sporije

Ako izraz "win-win" (iz engleskog jezika) shvatimo kao nešto što označava pogodbe u kojima svaka strana dobija, ili situacije u koijma sve izlazi na dobro, onda bismo situaciju sa metodama UTF enkodiranja mogli (pomalo slikovito) shvatiti kao svojevrsnu "lose-lose" situaciju.

Sa jedne strane, nijedna od opcija nije skroz dobra, ali sa druge strane, nedostaci nisu baš previše "zabrinjavajući", pa je na kraju potrebno biti praktičan:

• tamo gde je optimalnije koristiti UTF-16, koristi(će) se UTF-16 (isto važi i za UTF-32, koji se ipak, kao što smo već naveli, ređe koristi)
• programski jezici godinama unazad sadrže funkcije za UTF-8/16/32 enkodiranje/dekodiranje, tako da programeri koji ne žele time da se bave - ne moraju time da se bave
• savremeni računari su duži niz godina dovoljno brzi da omoguće da razlika u brzini između čitanja ASCII, ili UTF-16 datoka (sa jedne strane) i UTF-8 datoteka (sa druge) - bude skoro zanemarljiva

Takođe, mogli bismo spomenuti da metode enkodiranja UTF-16, UTF-32 i UTF-8 nisu jedine postojeće (ali, svakako jesu najuobičajenije, pogotovo UTF-8), pa, ako vas tematika predstavljanja znakova na računarima dodatno zanima, i to može biti ideja za dalje istraživanje ....