UTF-8

Овај чланак можда захтева чишћење и/или прерађивање како би се задовољили стандарди квалитета Википедије. Проблем: уклапање потпунијег и тачнијег садржаја, уклањање сувишног и неодговарајућег текста, додавање референци и слична уређивања. Ако сте у могућности, побољшајте овај чланак. (јануар 2012) (детаљније о уклањању овог шаблона обавештења)

Овај чланак садржи списак литературе (штампане изворе и/или веб-сајтове) коришћене за његову израду, али његови извори нису најјаснији зато што има премало извора који су унети у сам текст. Молимо вас да побољшате овај чланак тако што ћете додати још извора у сам текст (редних референци). (детаљније о уклањању овог шаблона обавештења)

UTF-8 варијанта је најзгоднија за кодирање већински латиничног текста. Дато је и кратко упутство за коришћење те варијанте у Microsoft Word-у, Netscape Composer-у и текстуалном едитору Kate. У тексту су такође препоручени стандардни Unicode фонтови који омогућавају лаку преносивост текста са рачунара на рачунар или за објављивање текста на Интернет.

Први рачунари су били прављени претежно за енглеско говорно подручје и имали су подршку само за енглески алфабет, за бројеве, заграде и још по неки контролни карактер, што је чинило укупно 128 могућих слова (у 7 бита). То је био тзв. ASCII или US-ASCII стандард.^[1]

1968. године је скуп карактера проширен на 256 (8 бита), а „горњих“ 128 карактера је било коришћено за додатне карактере. Из неке навике је и овај проширени ASCII називан ASCII, тако да ту често долази до забуне. Да би постојала подршка за више језика, смишљане су тзв. кодне стране (Code Page) које дефинишу понашање тог додатног скупа слова. Основна кодна страна на персоналним рачунарима (PC437) у том горњем сету карактера дефинише разне графичке карактере за цртање текстуалних прозора и слично. Касније је развијено још пуно кодних страна које подржавају одређене језике. Тако постоје Latin1 (ISO-8859-1) за латинична писма Западне Европе (Француска, Немачка, Шпанија, ...), Latin2 (ISO-8859-2) и Windows-1250 за латинична писма Источне Европе (српска латиница и сл.), ISO-8859-5, KOI8-R и Windows-1251 за ћирилицу, итд. Основни проблем са кодним странама је то што се међусобно искључују, тј. цео документ мора да буде написан истим писмом. То углавном није проблем реализовати, али ако би било потребно помешати два писма, као на пример у неком туристичком водичу где заједно постоји и текст на српском, на енглеском и на француском, наилази се на проблем. Због тога се дошло до идеје да се направи јединствени запис за све језике - Јуникод (Unicode) (united - уједињен, заједнички; code - код, запис).

Постоји више верзија Unicode-а. Базична верзија је двобајтни формат записа до 2¹⁶ = 65536 карактера. Њен назив је UCS-2 зато што користи два октета, односно два бајта. Са тих 65536 карактера решен је проблем записа скоро свих постојећих писама (укључујући чак и нека измишљена, као на пример клингонско писмо). Овај тип Unicode-а се назива Plain UCS-2 или UTF-16.

Сада се јавља проблем алокације простора за Unicode поруку на медијуму који се користи. Ако је реч о неком документу на диску, он ће да заузима дупло више простора него конвенционалан документ јер ће се сваки карактер записивати са два бајта уместо само са једним. Ако је реч о преносу података преко рачунарске мреже, биће потребно пренети дупло више података, па ће самим тим и пренос да траје дупло више (односно да кошта дупло више). Поставља се питање да ли је то сувише велика цена за универзално писмо и да ли постоји неки начин да се тај проблем превазиђе и избегне. Као решење увек стоји могућност да се записује неком одговарајућом кодном страницом и троши бајт по карактеру, ако није неопходно коришћење више писама у истом документу (што се ретко дешава). Друго решење је коришћење тзв. трансформационих шеме за погоднији запис и пренос података коришћењем Unicode-а.

Прво је развијена Unicode трансформациона шема са основном јединицом од 8 бита (UTF-8). Помоћу ње се карактер записује у једном, два или три бајта, у зависности од тога о ком је карактеру реч. Ова трансформациона шема је превасходно згодна за употребу у језицима који користе латиницу. О UTF-8 ће бити више речи у поглављу Укратко о UTF-8.

Један део Mail Transfer Agent-а, као и званични стандард за Интернет пошту (IETF: STD 11, RFC 822) подржава само 7-битне маил поруке. MIME стандарди (RFC 2045, RFC 2046, RFC 2047, RFC 2048 и RFC 2049) омогућавају пренос вишебитних речи преко Интернет маил-а, користећи Base64 и Quoted Printable начине кодирања, међутим, они нису прављени за пренос Unicode-а него за пренос било каквих фајлова и нису били оптимална решења. Због тога је касније развијена 7-битна трансформациона шема UTF-7. Ту се карактер записује у једном или у неколико бајтова, слично као и у UTF-8. Основна разлика је у томе што UTF-7 користи само Base64 карактере који без проблема могу да се преносе путем електронске поште. За такву намену се показало да је UTF-7 оптималнији запис него UTF-8 када се кодира са Base64 или са Quoted Printable алгоритмима кодирања.

Постоји и новији Unicode стандард под називом UCS-4 који користи 4 бајта за запис 2³¹ = 2147483648 карактера подељених у тзв. равни. Прва два бајта дефинишу раван, тако да има 2¹⁵ = 32768 равни. Друга два бајта дефинишу карактер унутар равни, тако да има 2¹⁶ = 65536 карактера по равни. Тај новији формат је више направљен као план за будућност него као реална опција, пошто још увек ни један карактер није алоциран у новодобијени простор, односно сви за сада дефинисани карактери (цео UCS-2) се налазе у равни 0 или основној вишејезичкој равни (Basic Multilingual Plane, BMP). Међутим, пошто је UCS-4 нови стандард за Unicode, треба и њега имати у виду. Да би се UCS-4 транспарентно увео у употребу редефинисани су формати записа UTF-7, UTF-8, UTF-16 и UTF-32. То је учињено тако да сваки карактер из UCS-2 има исту репрезентацију у UTF-7 и UTF-8 као и раније. UTF-16 је у неку руку синоним за UCS-2 и садржи више од два бајта само у случају да се кодира неки карактер ван "Основне језичке равни" (BMP), који за сада не постоје. За више информација, погледајте табелу Шема кодирања UCS-4 у UTF-8. UTF-32 је у ствари начин записа UCS-4 у коме се користе сва четири бајта. Због тога што виши и нижи бајт (или два бајта) могу да се запишу у меморију на два начина, постоје још по две подваријанте UTF-16 и UTF-32 које се разликују по редоследу бајтова. То су UTF-16BE (big endian) и UTF-16LE (little endian) и UTF-32BE и UTF-32LE. Ово није уведено да би се увела додатна забуна и збрка, него зато што различите архитектуре рачунара различито чувају податке.

Такође бих желео да напоменем да постоје две организације које дефинишу два стандарда за Unicode. Један формат је развијен од стране тзв. The Unicode Consortium под називом The Unicode Standard. Други стандард је развила Међународна организација за стандардизацију - International Organization for Standardization, под називом ISO/IEC 10646. Та два стандарда су скоро идентична и разликују се по питању тзв. Хан унификације (представљање јапанских, кинеских и корејских знакова једним јединственим скупом знакова), око додатних карактера за дефинисање акцената, а од скоро и у томе што Unicode Consortium није још подржао UCS-4 стандард. Међутим, за нашу употребу слободно можемо да сматрамо да су потпуно идентични. Међународна организација која дефинише стандарде за Интернет - Internet Engineering Task Force, IETF је у својим стандардима, тзв. "захтевима за коментарима" (Request for Comments, RFC), у којима је дефинисано све што постоји на Интернету, прихватила UTF-7 (RFC 1642 и RFC 2152), UTF-8 (RFC 2044 и RFC 2279) и UTF-16 (RFC 2781), чиме су они и "званично" ушли у употребу на Интернету, тј. свуда. У најновијим стандардима IETF је изоставио Unicode Consortium и користи само верзију ISO 10646, што значи да је званично призната верзија ISO 10646.

У HTML језику за опис веб страница се јављају још два начина за кодирање Unicode карактера. Ови начини троше много више простора него оригинални Unicode запис и намењени су за коришћење унутар неке од кодних страница за убацивање понеког карактера из неке друге кодне странице. Један начин је запис окталних вредности UTF-8 бајтова. Записује се тако што се прво запише карактер \, па онда октална вредност бајта. Ако тај карактер у UTF-8 кодирању садржи више бајтова, сваки бајт се записује на исти начин. Тако на пример карактер Ф чији је UCS-2 код U+0424 (U+ означава да је реч о Unicode карактеру), а UTF-8 запис 0xD0 0xA4 има свој HTML октални запис као \320\244, пошто је 0xD0 = 0320(октални) = 208(децимални) и 0xA4 = 0244 = 164.

Други начин записа Unicode карактера у HTML-у је путем децималне вредности њиховог UCS-2 кода. Записује се тако што се прво запишу карактери &#, па онда децимална вредност UCS-2 кода и на крају карактер ;. Тако би се, на пример, горепоменути карактер Ф са UCS-2 кодом U+0424 записао у HTML децималном запису као Ф, пошто је 0x0424 = 02044 = 1060.

UTF-8 је замишљен као формат који највише одговара латиничном тексту. То је веома погодно за коришћење у изворном коду програма или у разноразним маркуп језицима (HTML, XML, \LaTeX, ...) јер су стандардне команде тих програмских/маркуп језика увек ASCII, а текст који се користи може да буде и ASCII и UTF-8. На тај начин се не омета рад програмског компајлера или парсера маркуп језика, а омогућава се коришћење вишејезичке подршке.

У UTF-8 се карактер записује у облику једног бајта ако у свом запису садржи само најнижих 7 бита, односно, ако је реч о ASCII карактеру (види поглавље Развој електронског записа текста). Уколико карактер у свом Unicode запису садржи само најнижих 11 бита, у UTF-8 се записује у облику два бајта. И на крају, ако карактер садржи свих 16 бита, записује се у облику три бајта. У табели 1 је дата шема како се UCS-4 трансформише у UTF-8. Табела је дата за пун, четворобајтни Unicode, а ако је реч о двобајтном Unicode-у, тј. о UCS-2, треба гледати само прва три реда у табели. Детаљнији опис алгоритма за трансформацију може се наћи у RFC 2279.

UTF-8 није оптималан начин записа за кинески и јапански текст јер уместо да се користе два бајта по карактеру, за такав текст би било коришћено чак три бајта по карактеру, али то и није толико важно за нас. За ћирилични текст је, са друге стране, свеједно да ли се користи чисти UNICODE или UTF-8, пошто се сваки ћирилични карактер записује у облику два бајта и у једном и у другом формату. За нас је ипак оптималнији UTF-8 јер постоји могућност писања и ћирилицом и латиницом, па ако у ћирилици већ не може да се избегне употреба два бајта, у латиници се скоро сви карактери записују само са једним бајтом (осим šđčćž).

Да би се користио Unicode у припреми докумената, потребно је имати одговарајуће фонтове који га (барем делимично) подржавају. Од фонтова доступних на Windows-у, Unicode сигурно подржавају Arial, Times New Roman, Helvetica, Verdana и Courier New фонтови, а такође су инсталирани на свим Windows платформама, тако да би генерално требало да се користи неки од тих фонтова. Фонтови типа TimesCirilica или YULTimes могу да прикажу наше карактере, али су далеко од Unicode-а и у преносу фајла са једног на други рачунар у електронском облику постоји велика шанса да тај фајл неће бити лепо читљив на другом рачунару, тако да би требало да се такви нестандардни фонтови избегавају колико год је то могуће.

На LINUX-у и осталим UNIX-има се у самом називу фонта види да ли подржава уницоде или не, пошто последњи део назива фонта представља character set фонта. Ако ту пише iso10646, то значи да је фонт Unicode компатибилан. Међутим, и овде бих ради преносивости докумената, препоручио да се користе стандардни (Adobe) фонтови, као што су Times (-adobe-times-*-iso10646-1), Utopia (-adobe-utopia-*-iso10646-1), Helvetica (-adobe-helvetica-*-iso10646-1), Courier (-adobe-courier-*-iso10646-1).

Светски трендови развоја база података иду ка увођењу Unicode-а, као стандардни начин записа података и XML-а, као стандарни језик за пренос и презентацију тих података.

Већина база података већ дуже време подржава Unicode. Добар део апликација за рад са базама користе XML за презентовање и пренос података, зато што се показало да је XML једноставан језик за програмирање, за који већ постоји пуно парсер-а и зато што се показало да је XML довољно флексибилан да може да пренесе било какав тип података на сличан начин. Да би се програми међусобно "разумели" развијени су разни стандарди за опис података користећи XML (као што је на пример Encoded Archival Description стандард).

То увођење XML-а као главног језика за подршку базама података је још више учврстило позицију Unicode-а, пошто се XML фајлови стандардно пишу у UTF-8 или UTF-16. Занимљива је и та чињеница да је Microsoft, који се углавном противи свим стандардима и труди се да дефинише своје, прихватио XML и користи га где год може. Цела .NET технологија је XML базирана. Због тога може да се очекује да ће у будућности бити само више XML-а и више Unicode-а и да је битно што раније се оријентисати ка њима.

У табели 2 су излистани скоро сви карактери који се код нас користе, са својим UCS-2 кодом, UTF-8 записом и са HTML окталним и децималним записима (за више информација погледајте поглавље 2).