Unikod

Ovaj članak daje pregled načina kodiranja višejezičnog teksta u elektronskoj formi koristeći Unicode standard, sa posebnim osvrtom na varijantu UTF-8.

UTF-8 varijanta je najzgodnija za kodiranje većinski latiničnog teksta. Dato je i kratko uputstvo za korišćenje te varijante u Microsoft Word-u, Netscape Composer-u i tekstualnom editoru Kate. U tekstu su takođe preporučeni standardni Unicode fontovi koji omogućavaju laku prenosivost teksta sa računara na računar ili za objavljivanje teksta na Internet.

Prvi računari su bili pravljeni pretežno za englesko govorno područje i imali su podršku samo za engleski alfabet, za brojeve, zagrade i još poneki kontrolni karakter, što je činilo ukupno 128 mogućih slova (u 7 bita). To je bio tzv. ASCII ili US-ASCII standard.

Kasnije je skup karaktera proširen na 256 (8 bita), a „gornjih“ 128 karaktera je bilo korišćeno za dodatne karaktere. Iz neke navike je i ovaj prošireni ASCII nazivan ASCII, tako da tu često dolazi do zabune. Da bi postojala podrška za više jezika, smišljane su tzv. kodne strane (Code Page) koje definišu ponašanje tog dodatnog skupa slova. Osnovna kodna strana na personalnim računarima (PC437) u tom gornjem setu karaktera definiše razne grafičke karaktere za crtanje tekstualnih prozora i slično. Kasnije je razvijeno još puno kodnih strana koje podržavaju određene jezike. Tako postoje Latin1 (ISO-8859-1) za latinična pisma Zapadne Evrope (Francuska, Njemačka, Španija, ...), Latin2 (ISO-8859-2) i Windows-1250 za latinična pisma Istočne Evrope (naša latinica i sl.), ISO-8859-5, KOI8-R i Windows-1251 za ćirilicu... Osnovni problem sa kodnim stranama je to što se međusobno isključuju, tj. cijeli dokument mora da bude napisan istim pismom. To uglavnom nije problem realizovati, ali ako bi bilo potrebno pomiješati dva pisma, kao na primer u nekom turističkom vodiču gde zajedno postoji i tekst na bosanskom, na engleskom i na francuskom, nailazi se na problem. Zbog toga se došlo do ideje da se napravi jedinstveni zapis za sve jezike - Unicode.

Postoji više verzija Unicode-a. Bazična verzija je dvobajtni format zapisa do 2¹⁶ = 65536 karaktera. Njen naziv je UCS-2 zato što koristi dva okteta, odnosno dva bajta. Sa tih 65536 karaktera riješen je problem zapisa skoro svih postojećih pisama (uključujući čak i neka izmišljena, kao na primer klingonsko pismo). Ovaj tip Unicode-a se naziva Plain UCS-2 ili UTF-16.

Sada se javlja problem alokacije prostora za Unicode poruku na medijumu koji se koristi. Ako je reč o nekom dokumentu na disku, on će da zauzima duplo više prostora nego konvencionalan dokument jer će se svaki karakter zapisivati sa dva bajta umesto samo sa jednim. Ako je riječ o prenosu podataka preko računarske mreže, biće potrebno prenijeti duplo više podataka, pa će samim tim i prenos da traje duplo više (odnosno da košta duplo više). Postavlja se pitanje da li je to suviše velika cijena za univerzalno pismo i da li postoji neki način da se taj problem prevaziđe i izbjegne. Kao rješenje uvijek stoji mogućnost da se zapisuje nekom odgovarajućom kodnom stranicom i troši bajt po karakteru, ako nije neophodno korišćenje više pisama u istom dokumentu (što se rijetko dešava). Drugo rješenje je korišćenje tzv. transformacionih šema za pogodniji zapis i prenos podataka korišćenjem Unicode-a.

Prvo je razvijena Unicode transformaciona šema sa osnovnom jedinicom od 8 bita (UTF-8). Pomoću nje se karakter zapisuje u jednom, dva ili tri bajta, u zavisnosti od toga o kom je karakteru reč. Ova transformaciona šema je prevashodno zgodna za upotrebu u jezicima koji koriste latinicu. O UTF-8 će biti više reči u poglavlju Ukratko o UTF-8.

Jedan dio Mail Transfer Agent-a, kao i zvanični standard za Internet poštu (IETF: STD 11, RFC 822) podržava samo 7-bitne mail poruke. MIME standardi (RFC 2045, RFC 2046, RFC 2047, RFC 2048 i RFC 2049) omogućavaju prenos višebitnih riječi preko Internet mail-a, koristeći Base64 i Quoted Printable načine kodiranja, međutim, oni nisu pravljeni za prenos Unicode-a nego za prenos bilo kakvih fajlova i nisu bili najoptimalnija rješenja. Zbog toga je kasnije razvijena 7-bitna transformaciona šema UTF-7. Tu se karakter zapisuje u jednom ili u nekoliko bajtova, slično kao i u UTF-8. Osnovna razlika je u tome što UTF-7 koristi samo Base64 karaktere koji bez problema mogu da se prenose putem elektronske pošte. Za takvu namenu se pokazalo da je UTF-7 optimalniji zapis nego UTF-8 kada se kodira sa Base64 ili sa Quoted Printable algoritmima kodiranja.

Postoji i noviji Unicode standard pod nazivom UCS-4 koji koristi 4 bajta za zapis 2³¹ = 2147483648 karaktera podijeljenih u tzv. ravni. Prva dva bajta definišu ravan, tako da ima 2¹⁵ = 32768 ravni. Druga dva bajta definišu karakter unutar ravni, tako da ima 2¹⁶ = 65536 karaktera po ravni. Taj noviji format je više napravljen kao plan za budućnost nego kao realna opcija, pošto još uvijek nijedan karakter nije alociran u novodobijeni prostor, odnosno svi za sada definisani karakteri (cijeli UCS-2) se nalaze u ravni 0 ili osnovnoj višejezičnoj ravni (Basic Multilingual Plane, BMP). Međutim, pošto je UCS-4 novi standard za Unicode, treba i njega imati u vidu. Da bi se UCS-4 transparentno uveo u upotrebu redefinisani su formati zapisa UTF-7, UTF-8, UTF-16 i UTF-32. To je učinjeno tako da svaki karakter iz UCS-2 ima istu reprezentaciju u UTF-7 i UTF-8 kao i ranije. UTF-16 je u neku ruku sinonim za UCS-2 i sadrži više od dva bajta samo u slučaju da se kodira neki karakter van "Osnovne jezičke ravni" (BMP), koji za sada ne postoje. Za više informacija, pogledajte tabelu Šema kodiranja UCS-4 u UTF-8. UTF-32 je u stvari način zapisa UCS-4 u kome se koriste sva četiri bajta. Zbog toga što viši i niži bajt (ili dva bajta) mogu da se zapišu u memoriju na dva načina, postoje još po dvije podvarijante UTF-16 i UTF-32 koje se razlikuju po redoslijedu bajtova. To su UTF-16BE (big endian) i UTF-16LE (little endian) i UTF-32BE i UTF-32LE. Ovo nije uvedeno da bi se uvela dodatna zabuna i zbrka, nego zato što različite arhitekture računara različito čuvaju podatke.

Takođe bih želio da napomenem da postoje dvije organizacije koje definišu dva standarda za Unicode. Jedan format je razvijen od strane tzv. The Unicode Consortium pod nazivom The Unicode Standard. Drugi standard je razvila Međunarodna organizacija za standardizaciju - International Organization for Standardization, pod nazivom ISO/IEC 10646. Ta dva standarda su skoro identična i razlikuju se po pitanju tzv. Han unifikacije (predstavljanje japanskih, kineskih i korejskih znakova jednim jedinstvenim skupom znakova), oko dodatnih karaktera za definisanje akcenata, a od skoro i u tome što Unicode Consortium nije još podržao UCS-4 standard. Međutim, za našu upotrebu slobodno možemo da smatramo da su potpuno identični. Međunarodna organizacija koja definiše standarde za Internet - Internet Engineering Task Force, IETF je u svojim standardima, tzv. "zahtjevima za komentarima" (Request for Comments, RFC), u kojima je definisano sve što postoji na Internetu, prihvatila UTF-7 (RFC 1642 i RFC 2152), UTF-8 (RFC 2044 i RFC 2279) i UTF-16 (RFC 2781), čime su oni i "zvanično" ušli u upotrebu na Internetu, tj. svuda. U najnovijim standardima IETF je izostavio Unicode Consortium i koristi samo verziju ISO 10646, što znači da je zvanično priznata verzija ISO 10646.

U HTML jeziku za opis veb stranica se javljaju još dva načina za kodiranje Unicode karaktera. Ovi načini troše mnogo više prostora nego originalni Unicode zapis i namijenjeni su za korišćenje unutar neke od kodnih stranica za ubacivanje ponekog karaktera iz neke druge kodne stranice. Jedan način je zapis oktalnih vrednosti UTF-8 bajtova. Zapisuje se tako što se prvo zapiše karakter \, pa onda oktalna vrijednost bajta. Ako taj karakter u UTF-8 kodiranju sadrži više bajtova, svaki bajt se zapisuje na isti način. Tako, na primjer, karakter Ф čiji je UCS-2 kod U+0424 (U+ označava da je riječ o Unicode karakteru), a UTF-8 zapis 0xD0 0xA4 ima svoj HTML oktalni zapis kao \320\244, pošto je 0xD0 = 0320(oktalni) = 208(decimalni) i 0xA4 = 0244 = 164.

Drugi način zapisa Unicode karaktera u HTML-u je putem decimalne vrijednosti njihovog UCS-2 koda. Zapisuje se tako što se prvo zapišu karakteri &#, pa onda decimalna vrijednost UCS-2 koda i na kraju karakter ;. Tako bi se, na primjer, gore pomenuti karakter Ф sa UCS-2 kodom U+0424 zapisao u HTML decimalnom zapisu kao Ф, pošto je 0x0424 = 02044 = 1060.

UTF-8 je zamišljen kao format koji najviše odgovara latiničnom tekstu. To je veoma pogodno za korišćenje u izvornom kodu programa ili u raznoraznim markup jezicima (HTML, XML, \LaTeX, ...) jer su standardne komande tih programskih/markup jezika uvijek ASCII, a tekst koji se koristi može da bude i ASCII i UTF-8. Na taj način se ne ometa rad programskog kompajlera ili parsera markup jezika, a omogućava se korišćenje višejezičke podrške.

U UTF-8 se karakter zapisuje u obliku jednog bajta ako u svom zapisu sadrži samo najnižih 7 bita, odnosno, ako je reč o ASCII karakteru (vidi poglavlje Razvoj elektronskog zapisa teksta). Ukoliko karakter u svom Unicode zapisu sadrži samo najnižih 11 bita, u UTF-8 se zapisuje u obliku dva bajta. I na kraju, ako karakter sadrži svih 16 bita, zapisuje se u obliku tri bajta. U tabeli 1 je data šema kako se UCS-4 transformiše u UTF-8. Tabela je data za pun, četvorobajtni Unicode, a ako je reč o dvobajtnom Unicode-u, tj. o UCS-2, treba gledati samo prva tri reda u tabeli. Detaljniji opis algoritma za transformaciju može se naći u RFC 2279.

UTF-8 nije najoptimalniji način zapisa za kineski i japanski tekst jer umjesto da se koriste dva bajta po karakteru, za takav tekst bi bilo korišćeno čak tri bajta po karakteru, ali to i nije toliko važno za nas. Za ćirilični tekst je, sa druge strane, svejedno da li se koristi čisti Unicode ili UTF-8, pošto se svaki ćirilični karakter zapisuje u obliku dva bajta i u jednom i u drugom formatu. Za nas je ipak optimalniji UTF-8 jer postoji mogućnost pisanja i ćirilicom i latinicom, pa ako u ćirilici već ne može da se izbjegne upotreba dva bajta, u latinici se skoro svi karakteri zapisuju samo jednim bajtom (osim šđčćž).

Jedan od najčešće korišćenih programa za obradu teksta pod Windows "operativnim sistemom" je Microsoft Word for Windows. On u svom formatu već ima podršku za više jezika. Ako je potrebno da se neki Word dokument prebaci na Internet u obliku HTML fajla, potrebno je naglasiti da se sačuva u UTF-8 formatu. To otprilike izgleda ovako:

1. Prvo treba napisati sam dokument, naravno.
2. Kada se dokument prebacuje na Internet, treba iz File menija izabrati opciju Save as Web.
3. U dijalogu koji će se pojaviti treba izabrati gdje se čuva fajl i prije nego što se stvarno sačuva, treba iz menija tools izabrati opciju Web Options.
4. U novootvorenom dijalogu treba izabrati stranicu Encoding i tu u polju Save this document as izabrati Unicode (UTF-8).

Popularni Web čitač Netscape Communicator u svom sklopu ima i editor za Web stranice, tzv. Composer. On naravno može da bira na koji način će da čuva Web stranice i može da izabere i Unicode i to i UTF-8 i UTF-7. Nas zanima samo UTF-8, mada je postupak manje - više isti.

Postoje dva načina da se u Netscape Composer-u tekst sačuva u UTF-8 formatu. Moguće je jednostavno izabrati iz menija View opciju Charset i tu izabrati UTF-8 kao format.Poslije toga se fajl najnormalnije sačuva i bude sačuvan u UTF-8 formatu.

Drugi način je da se fajl sačuva umjesto opcijom File->Save, opcijom File->Save As Charset. Tada se dobija dijalog u kome može da se izabere način zapisa fajla i tu treba izabrati UTF-8.

Neki tekstualni editori takođe imaju opciju da tekst sačuvaju na više načina kodiranja. Jedan od takvih je Kate koji je sastavni deo KDE grafičkog okruženja pod LINUX operativnim sistemom. On takođe može da sačuva tekst i u čistom UCS-2 formatu ili u UTF-16 (kao delu UCS-4). Za nas je bitan samo format UTF-8. Jednostavno se iz menija Prikaz izabere podmeni Podesi kodiranje i tu se izabere željeno kodiranje, odnosno UTF-8.

Na UNIX operativnim sistemima postoji biblioteka iconv koja vrši konverziju iz jednog u drugi način kodiranja na veoma jednostavan način. Postoji i ekvivalentan command line program koji konvertuje fajlove iz i u sve moguće načine kodiranja. Lista kodova iz kojih i u koje ova biblioteka/program može da konvertuje zauzima više od 3 pune strane i može se reći da podržava sve moguće načine kodiranja.

Da bi se koristio Unicode u pripremi dokumenata, potrebno je imati odgovarajuće fontove koji ga (barem djelimično) podržavaju. Od fontova dostupnih na Windows-u, Unicode sigurno podržavaju Arial, Times New Roman, Helvetica, Verdana i Courier New fontovi, a takođe su instalirani na svim Windows platformama, tako da bi generalno trebalo da se koristi neki od tih fontova. Fontovi tipa TimesCirilica ili YULTimes mogu da prikažu naše karaktere, ali su daleko od Unicode-a i u prenosu fajla sa jednog na drugi računar u elektronskom obliku postoji velika šansa da taj fajl neće biti lepo čitljiv na drugom računaru, tako da bi trebalo da se takvi nestandardni fontovi izbegavaju koliko god je to moguće.

Na LINUX-u i ostalim UNIX-ima se u samom nazivu fonta vidi da li podržava unicode ili ne, pošto poslednji deo naziva fonta predstavlja character set fonta. Ako tu piše iso10646, to znači da je font Unicode kompatibilan. Međutim, i ovde bih radi prenosivosti dokumenata, preporučio da se koriste standardni (Adobe) fontovi, kao što su Times (-adobe-times-*-iso10646-1), Utopia (-adobe-utopia-*-iso10646-1), Helvetica (-adobe-helvetica-*-iso10646-1), Courier (-adobe-courier-*-iso10646-1).

Svjetski trendovi razvoja baza podataka idu ka uvođenju Unicode-a, kao standardni način zapisa podataka i XML-a, kao standarni jezik za prenos i prezentaciju tih podataka.

Većina baza podataka već duže vreme podržava Unicode. Dobar deo aplikacija za rad sa bazama koriste XML za prezentovanje i prenos podataka, zato što se pokazalo da je XML jednostavan jezik za programiranje, za koji već postoji puno parser-a i zato što se pokazalo da je XML dovoljno fleksibilan da može da prenese bilo kakav tip podataka na sličan način. Da bi se programi međusobno "razumjeli", razvijeni su razni standardi za opis podataka koristeći XML (kao što je, na prijmer, Encoded Archival Description standard).

To uvođenje XML-a kao glavnog jezika za podršku bazama podataka je još više učvrstilo poziciju Unicode-a, pošto se XML fajlovi standardno pišu u UTF-8 ili UTF-16. Zanimljiva je i ta činjenica da je Microsoft, koji se uglavnom protivi svim standardima i trudi se da definiše svoje, prihvatio XML i koristi ga gdje god može. Cela .NET tehnologija je XML bazirana. Zbog toga može da se očekuje da će u budućnosti biti samo više XML-a i više Unicode-a i da je bitno što ranije se orijentisati ka njima.

U tabeli 2 su izlistani skoro svi karakteri koji se kod nas koriste, sa svojim UCS-2 kodom, UTF-8 zapisom i sa HTML oktalnim i decimalnim zapisima (za više informacija pogledajte poglavlje 2).

 

U Unikodu srpski i makedonski jezik, odnosno njihova ćirilička pisma, nisu tzv. „građani prvog reda”, kao što se može videti na slici desno. Pri dizajnu Unikoda početkom 1990-ih godina, nije uzeto u obzir da se ćirilička pisma manje-više razlikuju u dizajnu pojedinih slova. To se ispoljava u kurzivu (iskošeno ili polupisano), ali, kao što se vidi na slici, i sa malim slovom б u osnovnom režimu. U ruskoj verziji ono veoma nalikuje broju 6, dok u srpskoj verziji to nije slučaj, osim u izuzetno malim veličinama.

Zbog veličine tržišta (Ruska Federacija i okolne zemlje iz bivšeg Sovjetskog Saveza, kao i Bugarska), većina fontova koja sadrže ćirilicu, preferira rusku ćirilicu na standardnim mestima Unikoda, odnosno ruski dizajn grafije, pa srpski i makedonski jezik najviše trpe zbog ovoga. Iako su velika preduzeća kao što su Adobi sistems (Adobe Systems) i Majkrosoft (Microsoft) upoznata sa ovim problemom, još uvek se ne zna da li će i kada i ovi jezici postati „građani prvog reda” u sistemu Unikod.

U međuvremenu, rešenje može pružiti tehnologija kao što je Opentajp (OpenType, naročito njeno svojstvo locl (locale)), softver koji je podržava i moderni fontovi koji sadrže ispravna srpska/makedonska slova. Dobri primeri su operativni sistem GNU/Linuks (GNU/Linux), kancelarijski paket Libreofis (LibreOffice) pod Linuksom i veb-čitač Mozila Fajrfoks (Mozilla Firefox).

Evo primera za „privremeno” rešenje u veb tehnologijama. U osnovnoj verziji:

• <span lang="sr">бгдпт</span> daje бгдпт
• <span lang="ru">бгдпт</span> daje бгдпт

a polupisano ili iskošeno:

• <span lang="sr" style="font-style: italic">бгдпт</span> daje бгдпт
• <span lang="ru" style="font-style: italic">бгдпт</span> daje бгдпт.

Dakle, mora se koristiti atribut lang="sr", i svaka veb prezentacija na srpskom jeziku treba da ima <html lang="sr"> ili <html lang="sr-RS">. Sve druge oznake, ili neoznačavanje uopšte, čini prikaz srpske ćirilice uglavnom neispravnim.

Takođe, počevši od CSS-a 3, veb autori mogu da koriste font-feature-settings: 'locl';. Naravno, moderne porodice fontova kao sto su GNU FreeFont, DejaVu, Ubuntu ili Majkrosoftovi „C-” fontovi (Calibri, Cambria, Candara, Consolas, Constantia, Corbel) od Viste pa na dalje moraju se koristiti (takođe i Sitka od Windows-a 8.1).

Pored primera sa slovima б, г, д, п, т, rusko veliko polupisano Д identično je latiničkom slovu D, što je takođe neprihvatljivo za srpski i makedonski jezik, a pomalo se razlikuje i dizajn velikih polupisanih slova Б i Н.

 

Naposletku, otežano je i unošenje akcentovanih ćiriličkih slova, a u postojećoj bazi znakova u Unikodu nema dovoljno unapred definisanih ćiriličkih za ovu svrhu.

1. Filip Brčić.
   Ukratko o xml-u, Januar 2003.
   http://brcha.free.fr/documents/XMLtut/xmltut.pdf^{[mrtav link]}.
2. The Unicode Consortium.
   The Unicode Standard - Version 3.0.
   Addison-Wesley, http://www.unicode.org, 2000.
3. World Wide Web Consortium.
   Extensible markup language (xml) 1.1.
   Candidate recommendation, http://www.w3c.org/TR/xml11, 2002.
4. M. Davis D. Goldsmith.
   Utf-7 - a mail-safe transformation format of unicode.
   Experimental 1642, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc1642.txt, 1994.
5. M. Davis D. Goldsmith.
   Utf-7 - a mail-safe transformation format of unicode.
   Informational 2152, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2152.txt, 1997.
6. Ulrich Drepper.
   MANPAGE: Iconv(3) 2.2.5 - Perform character set conversion.
   Free Software Foundation, Inc., 2002.
7. Bojan Marinković <mr99007@alas.matf.bg.ac.yu>.
   Encoded archival description document type definition.
   2003.
8. K. Moore.
   Multipurpose internet mail extensions (mime) part three: Message header extensions for non-ascii text.
   Standards Track 2047, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2047.txt, 1996.
9. J. Postel N. Freed, J. Klensin.
   Multipurpose internet mail extensions (mime) part four: Registration procedures.
   Standards Track 2048, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2048.txt, 1996.
10. N. Borenstein N. Freed.
    Multipurpose internet mail extensions (mime) part five: Conformance criteria and examples.
    Standards Track 2049, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2049.txt, 1996.
11. N. Borenstein N. Freed.
    Multipurpose internet mail extensions (mime) part one: Format of internet message bodies.
    Standards Track 2045, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2045.txt, 1996.
12. N. Borenstein N. Freed.
    Multipurpose internet mail extensions (mime) part two: Media types.
    Standards Track 2046, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2046.txt, 1996.
13. F. Yergeau P. Hoffman.
    Utf-16, an encoding of iso 10646.
    Informational 2781, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2781.txt, 2000.
14. F. Yergeau.
    Utf-8, a trensformation format of unicode and iso 10646.
    Informational 2044, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2044.txt, 1996.
15. F. Yergeau.
    Utf-8, a transformation format of iso 10646.
    Standards Track 2279, Internet Engineering Task Force, http://www.ietf.org/rfc/rfc2279.txt, 1998.

• DecodeUnicode - Unicode WIKI, 50.000 gifs

 

Unikod na Wikimedijinoj ostavi

• Tipometar — ćirilice na poklon