[Raksts] Unicode

[Vilx-]

Šis raksts ar autora atļauju ir tulkots no angļu valodas. Es neesmu tā autors, es tikai to iztulkoju, kā nu labi mācēju. Oriģināls šeit: http://www.joelonsoftware.com/articles/Unicode.html

 

Daži termini, kurus es mēģināju pārtulkot:

 

Rakstzīmju kopa - Character set

Kodu lappuse - code page

Koda punkts - code point

Unikoda Baitu Secības Zīme - Unicode Byte Order Mark vai BoM.

 

 

Absolūtais minimums, ko katram izstrādātājam pilnīgi noteikti obligāti ir jāzin par Unikodu un rakstzīmju kopām!

 

Esi kādreiz domājis par to mistisko Content-Type tagu? Zini, to, kuru Tev vajag likt HTML, bet par kuru nekad nevar īsti saprast, kam tur jābūt?

 

Esi kādreiz saņēmis e-pastu no saviem draugiem Krievijā ar subjekta tekstu "???? ?????? ??? ????"?

 

Esmu vīlies atklājot, tieši cik daudz izstrādātāji nav īsti lietas kursā par noslēpumaino pasauli, kurā dzīvo rakstzīmju kopas, kodējumi, Unikods, un visa tā padarīšana. Pirms pāris gadiem beta testētājs FogBugz programmai painteresējās, vai sistēma var saņemt e-pastus japāņu valodā. Japāņu? E-pasti ir arī japāņu valodā? Nekad nebūtu iedomājies! Kad es paskatījos tuvāk uz komerciālo ActiveX kontroli, kuru mēs izmantojām MIME e-pastu parsēšanai, mēs atklājām, ka tā dara tieši nepareizo lietu ar rakstzīmju kopām, kā rezultātā mums vajadzēja uzrakstīt varonīgu kodu, kurš atveidoja atpakaļ nepareizos pārveidojumus, un tad pārveidoja tekstu pareizi. Kad es paskatījos uz vēl citu komerciālu bibliotēku, tai arī bija pilnīgi nestrādājoša rakstzīmju kopu apstrāde. Es sazinājos ar šīs bibliotēkas izstrādātāju, un viņš domāja, ka viņi "tur jau neko nevar padarīt". Kā daudzi programmētāji, viņš vēlējās, kaut tas viss vienkārši atrisinātos pats no sevis kaut kā.

 

Bet tas tā nenotiks. Kad es atklāju, ka populārajā web izstrādes rīkā PHP rakstzīmju kopas ir praktiski ignorētas, akli izmantojot 8 bitus simboliem, padarot gandrīz neiespējamu labu starptautisku web aplikāciju izstrādi, es nodomāju - pietiek vienreiz!

 

Tāpēc man tagad ir paziņojums: ja Tu esi programmētājs, kurš strādā 2003. gadā; Tu nezini pamatus rakstzīmju kopām, kodējumiem un Unikodam; un es Tevi noķeršu - es Tevi sodīšu liekot mizot sīpolus 6 mēnešus no vietas zemūdenē. Goda vārds!

 

Un vēl viena lieta:

 

TAS NEMAZ NAV TIK GRŪTI

 

Šajā rakstiņā es Tev izstāstīšu visu, ko katram strādājošam programmētājam vajadzētu zināt. Viss tas, ka "plain text = ascii = simbols 8 biti" ir ne tikai nepareizi, tas ir bezcerīgi nepareizi, un ja Tu vēl programmē šādā veidā, tad Tu neesi īpaši labāks par dakteri, kurš netic baciļiem. Lūdzu neraksti vairs ne rindiņu koda, pirms neesi izlasījis šo rakstiņu.

 

Pirms es sāku, man vajadzētu pabrīdināt, ka ja Tu esi viens no tiem retajiem cilvēkiem, kurš kaut ko saprot no internacionalizācijas, tad Tev viss šis stāsts šķitās mazliet par daudz novienkāršots. Es vienkārši šeit gribu pastāstīt pašu minimumu, lai visi varētu saprast kas notiek, un viņiem būtu vismaz neliela cerība veiksmīgi strādāt ar tekstu kādā citā valodā izņemot to angļu daļu, kura neiekļauj vārdus ar diakritiskajām zīmēm. Un man vajag arī brīdināt, ka simbolu apstrāde ir tikai viena mazmazītiņa daļiņa no visa tā, kas ir nepieciešams, lai izveidotu programmu, kura strādā starptautiski, bet diemžēl es varu vienlaicīgi rakstīt tikai par vienu lietu, tāpēc šodien tās ir rakstzīmju kopas.

 

Vēsturiska perspektīva

 

Vieglākais veids, kā visu šito saprast ir hronoloģiskā secībā.

 

Tu droši vien domā, ka es sākšu runāt par ļoti vecām rakstzīmju kopām kā EBCDIC. Īstenībā nē. EBCDIC nav nozīmīgs Tavā dzīvē. Tik tālu atpakaļ mums arī nav jāatgriežas.

 

Vecajās labajās dienās, ka Unix taisni tika izgudrots, un K&R rakstīja C programmēšanas valodu, viss bija ļoti vienkārši. EBCDIC teica savas ardievas. Vienīgie simboli, kuriem bija nozīme, bija vecie labie angļu burti bez diakritiskajām zīmēm, un mums priekš tiem bija labs kods vārdā ASCII, kurš spēja reprezentēt katru simbolu ar skaitli no 32 līdz 127. Atstarpe bija 32, A bija 65, u.t.t. To visu varēja ērti saglabāt 7 bitos. Lielākā daļa datoru tolaik jau lietoja 8-bitu baitus, kā rezultātā bija iespējams ne tikai saglabāt jebkuru ASCII simbolu, bet pat palika viens bits pāri, kuru, ja Tu biji viltīgs, varēja izmanto saviem nelietīgajiem nolūkiem. Piemēram, neaptēstie ļautiņi WordStarā to izmantoja, lai apzīmētu pēdējo burtu vārdā, rezultātā piespriežot WordStaram atbalstu tikai angļu tekstiem. Skaitļus mazākus par 32 sauc par nedrukājamiem un tos izmantoja, lai lamātos. Labi jau labi, patiesībā tie bija kontroles simboli. Piemēram 7, kurš piespieda datoru pīkstēt, vai arī 12, kurš lika printerim izspļaut lapu un ņemt nākamo.

 

 

 

Un viss bija labi, pieņemot, ka Tu runāji angļu valodā.

 

Tā kā baitā ir vietas veseliem 8 bitiem, daudziem cilvēkiem ienāca prātā doma, ka "hei, mēs taču varam izmantot kodus no 128 līdz 255 saviem mērķiem!" Problēma bija tur, ka šī ideja vienlaicīgi dzima daudziem cilvēkiem, un katram bija savs priekšstats par to, kam kur vajadzētu atrasties vietiņā no 128 līdz 255. IBM-PC bija kaut kas, ko sauca par OEM rakstzīmju kopu, kura piedāvāja dažus eiropiešu burtus ar diakritiskajām zīmēm un kaudzi ar līniju zīmējamajiem simboliem. Horizontālas strīpiņas, vertikālas strīpiņas, horizontālas strīpiņas ar mazām ļipiņām, kas atkarājās labajā pusē, u.t.t. Šos simbolus varēja izmantot lai zīmētu seksīgas strīpiņas un rāmīšus, kurus joprojām var redzēt uz veciem datoriem teksta režīmā. Patiesībā, tiklīdz PC sāka pirkt ārpus Amerikas, tika saveidotas visvisādas OEM rakstzīmju kopas, kura katra izmantoja augšējās 128 vērtības saviem mērķiem. Piemēram, uz dažiem datoriem 130 parādītu simbolu é, bet datoros, kuri tika pārdoti Izraēlā, tas bija Ivrita ג, tāpēc kad amerikāņi sūtīja savus résumé uz Izraēlu, tie pienāca kā rגsumג. Daudzos gadījumos, kā piemēram Krievijā, arī bija daudzas idejas, kā aizpildīt augšējos 128 simbolus, tāpēc nebija pat iespējams drošā veidā apmainīties ar dokumentiem krievu valodā.

 

 

Beigu beigās viss šitais bardaks ar OEM rakstzīmju kopām tika kodificēts ANSI standartā. ANSI standartā visi vienojās par to, ko darīt ar apakšējiem 128 simboliem (kas bija puslīdz tas pats, kas ASCII), bet eksistēja daudzi un dažādi veidi, kā interpretēt augšējās 128 vērtības, kuri bija atkarīgi no ģeogrāfiskās dislokācijas. Šīs dažādās sistēmas sauca par kodu lappusēm. Tā, piemēramm, Izraēlā DOS lietoja kodu lappusi vārdā 862, bet Grieķu lietotāji izmantoja 737. Visas kodu lappuses sakrita zem 128, bet atšķīrās virs 128, kur atradās visi jocīgie simboli. Nacionālās MS-DOS versijas izmantoja dučiem dažādu kodu lappušu, kur bija viss no angļu līdz islandiešu alfabētiem, un bija pat "daudzvalodu" kodu lappuses, kuras ļāva lietot esperanto un galīciešu simbolus uz viena datora. WOW! Bet dabūt, piemēram, ivritu un grieķu valodas bija praktiski neiespējami, ja vien Tu neuzrakstīji pats savu programmu, kura simbolus rādīja grafiskajā režīmā ar rastra attēliem, jo grieķu valodai un ivritam vajadzēja katrai savu kodu lappusi, ar citu interpretāciju augšējiem simboliem.

 

Tajā pat laikā Āzijā notika daudz trakākas lietas, lai tiktu galā ar to, ka viņiem alfabētos mēdz būt pāris tūkstoši simbolu, kuri nekad nesatilps 8 bitos. To parasti risināja ar ķēpīgo DBCS (Doble Byte Character Set - divu baitu rakstzīmju kopa), kurā daži simboli tika glabāti vienā baitā, kamēr citiem vajadzēja divus. Bija samērā vienkārši pārvietoties stringā uz priekšu, bet gandrīz neiespējami - uz atpakaļu. Programmētāji tika mudināti neizmantot s++ un s--, lai pārvietotos starp simboliem, bet tā vietā izsaukt Windows funkcijas AnsiNext un AnsiPrev, kuras prata tikt galā ar visu to nebūšanu.

 

Tomēr lielākā daļa cilvēku vienkārši izlikās, ka 1 simbols = 1 baits, un kamēr nevajadzēja tekstu pārvietot no viena datora uz otru, vai arī kamēr Tu nerunāji vairāk kā vienā valodā, viss pārsvarā strādāja. Protams, tiklīdz notika Internets, tā teksta pārvietošana no viena datora uz otru kļuva pavisam ikdienišķa parādība, un visa samudžinātā konstrukcija sabruka. Par laimi, bija izgudrots Unikods.

 

Unikods

 

Unikods bija drosmīgs mēģinājums izveidot universālu kodēšanas sistēmu, kura iekļāva visas puslīdz nopietnās rakstības sistēmas uz šīs planētas, un arī dažas izdomātas (piem. Klingonu alfabēts). Daži cilvēki dzīvo ar maldīgu priekšstatu, ka Unikods ir vienkārši 16-bitu kodēšanas sistēma, un tāpēc var saturēt tikai 65536 simbolus. Patiesībā, tā nav. Tas ir vispopulārākais mīts par Unikodu, tāpēc nejūties slikti, ja arī Tu tā domāji.

 

Patiesībā, Unikodam ir pavisam cita pieeja, kā domāt par simboliem, un Tev būs jāsaprot Unikoda domu gājiens, citādi neko nesapratīsi.

 

Līdz šim mēs esam pieņēmuši, ka katrs simbols ir piekārtots kādai bitu čupiņai, ko var saglabāt uz diska vai atmiņā.

 

A -> 0100 0001

 

Unikodā katrs simbols atbilst koda punktam, kas joprojām ir tikai teorētisks koncepts. Kā to saglabāt uz diska vai atmiņā ir pavisam cits stāsts.

 

Unikodā burts A ir platonisks ideāls. Tas vienkārši peld debesīs:

 

A

 

Šis platoniskais A ir atšķirīgs no B, un atšķirīgs no a, bet tas ir tas pats, kas A un A un A. Ideja, ka A Times New Roman fontā ir tas pats simbols, kas A Helvetica fontā, bet atšķirīgs no "a" (mazais burts), pirmajā brīdī neliekas īpaši pretrunīga, taču dažās valodās izdomāt tik vien kas tad īsti ir burts var radīt kontroversiju. Vai vācu burts ß ir īsts burts, vai arī vienkārši cits veids, kā pierakstīt ss? Ja burts maina izskatu vārda beigās, vai tas ir cits burts? Ivrits saka jā, Arābi saka nē. Jebkurā gadījumā, gudri ļaudis Unikoda konsorcijā par šīm lietām domā jau vairāk kā desmit gadus, kopā ar lielām politiskām debatēm, un Tev par to nav jāuztraucas. Viņi to jau ir izdomājuši.

 

Katram platoniskajam burtam katrā alfabētā Unikoda konsorcij ir piešķīris maģisku skaitli, kurš izskatās šitā: U+0639. Šis maģiskais skaitlis ir koda punkts. U+ nozīme Unikodu, un cipari ir heksadecimāli. U+0639 ir arābu burts Ain. Angļu burts A būtu U+0041. Tos visus var apskatīt ar charmap programmu Windows vidē, vai arī apmeklējot Unikoda weblapu.

 

Nav nekādu reālu ierobežojumu, cik simbolu Unikods var nodefinēt, un patiesībā viņi jau sen ir pārsnieguši 65536 simbolu robežu, tā kā ne katrs Unikoda simbols var tik iespiests 2 baitos, bet tas jau tik un tā bija mīts.

 

OK, pieņemsim, ka mums ir strings:

 

Hello

 

Unikodā tas atbilst šiem pieciem koda punktiem:

 

U+0048 U+0065 U+006C U+006C U+006F

 

Vienkārši bariņš ar koda punktiem. Skaitļiem, patiesībā. Mēs vēl neko neesam runājuši par to, kā to visu saglabāt uz diska vai nosūtīt e-pastā.

 

Kodējumi

 

Šajā vietā lomu sāk spēlēt kodējumi.

 

Pirmā ideja Unikoda kodējumiem (no kā arī nācis mīts par 2 baitiem) bija - hei, glabāsim šos skaitļus katru divos baitos. Tātad, Hello kļūst par

 

00 48 00 65 00 6C 00 6C 00 6F

 

Pareizi? Vai tomēr nē? Vai tas nevarētu būt arī

 

48 00 65 00 6C 00 6C 00 6F 00 ?

 

Nu, tehniski jau jā, laikam varētu būt gan, un patiesībā agrīnie implementētāji arī gribēja saglabāt savus Unikoda koda punktus high-endian vai low-endian režīmos, kuros nu viņu CPU spēja ātrāk strādāt. Un nepaguva ne aci pamirkšķināt, kad jau bija izdomātas divas sistēmas, kā glabāt Unikodu. Tā nu cilvēkiem nācas izdomāt dīvainas tradīcijas glabāt FE FF katra Unikoda stringa sākumā. To sauc par Unikoda Baitu Secības Zīmi, un, ja Tu samaini augšējo un apakšējo baitu vietām, tad tā izskatās kā FF FE, un cilvēki var zināt, ka jāmaina vietām katri divi baiti. Uff. Ne katram Unikoda stringam savvaļā ir šī zīme.

 

Kādu laiku šķita, ka viss varētu būt labi, bet programmētāji sāka sūdzēties - "Paskat uz visām tām nullēm!" viņi teica, jo bija amerikāņi un skatījās uz angļu tekstu, kurā reti ir kāds koda punkts virs U+00FF. Plus, viņi bija no Kalifornijas. Ja viņi būtu no Teksasas, viņiem nebūt problēmu ar divreiz vairāk baitiem. Bet nē, tiem nīkuļiem bija absolūti nepieņemama ideja, ka stringiem paredzēto vietu vajadzētu dubultot, un arī bija ellīgi daudz vecu dokumentu ANSI un DBCS kodējumos, un kurš gan tos visus pārveidos? Moi? Šī iemesla dēļ lielākā daļa cilvēku izvēlējās ignorēt Unikodu vēl uz pāris gadiem, bet pa to laiku kļuva tikai ļaunāk.

 

Tāpēc tika izgudrots ģeniālais UTF-8 koncepts. UTF-8 bija vēl viena sistēma kā glabāt Unikoda koda punktus, tos maģiskos U+ skaitļus, atmiņā, izmantojot 8-bitu baitus. UTF-8 katrs koda punkts no 0 līdz 127 tiek glabāts vienā baitā. Tikai koda punkts 128 un lielāki tiek glabāti 2, 3, un patiesībā līdz pat 6 baitos.

 

 

Tam ir jauks blakusefekts, ka angļu teksts izskatās tieši tāpat iekš UTF-8, kā iekš ASCII, tāpēc amerikāņi pat nepamana, ka kaut kas ir mainījies. Tikai atlikušajai pasaules daļai ir jāmokās. Konkrētāk, Hello, kurš bija U+0048 U+0065 U+006C U+006C U+006F, tiks glabāts kā 48 65 6C 6C 6F, kas, pavei, ir tieši tāpat, kā ASCII, ANSI un visāss OEM rakstzīmju kopās. Ja Tu savukārt gribēsi izmanto grieķu vai klingonu burtus, Tev nāksies izmantot vairākus baitus katram koda punktam, bet amerikāņi to pat nepamanīs. (UTF-8 arī ir jauka īpašība, ka veci stringu apstrādes kodi, kuri grib izmantot 0 kā beigu simbolu, neapgriezīs stringa galu).

 

Pagaidām es esmu pastāstījis trīs veidus, kā glabāt Unikodu. Tradicionālā glabāsim-divos-baitos metode tiek saukta par UCS-2 (jo tai ir 2 baiti), vai UTF-16 (jo tai ir 16 biti), un vēl ir jāizdomā, vai tā ir high-endian UCS-2 vai low-endian UCS-2. Vispēdīgi ir arī jaunā un populārā UTF-8 sistēma, kurai piemīt jaukā īpašība, ka tā strādā tīri labi arī ja ir tas gods izmantot angļu tekstu un trulas programmas, kurām nav ne nojausmas par to, ka eksistē arī kaut kas cits bez ASCII.

 

Ir arī citi veidi, kā glabāt Unikodu. Piemēram, eksistē tāda lieta kā UTF-7, kas ir ļoti līdzīga UTF-8, tikai garantē ka augšējais bits vienmēr ir 0, lai tekstu varētu nemainītu izspiest cauri dažādām drakoniskām e-pastu sistēmām, kuras uzskata, ka 7 bit ir pavisam pietiekoši, paldies. Ir arī UCS-4, kas glabā katru koda punktu 4 baitos, bet, tētīt, pat teksasieši nebūtu tik pārdroši, lai TĀ izniekotu atmiņu.

 

Patiesībā, ja Tu tagad domā par simboliem kā platoniskiem ideāliem, kuri ir reprezentēti ar Unikoda kodu punktiem, tad vispār jau tos var saglabāt arī visādās vecās kodēšanas sistēmās. Piemēram, Unikoda stringu Hello (U+0048 U+0065 U+006C U+006C U+006F) varētu kodēt ASCII, vai grieķu OEM, vai ivrita ANSI, vai vēl pāris simtos citu kodēšanas sistēmu, kas tik tālu ir izgudrotas, ar vienu BET: daži simboli varētu neparādīties! Ja Unikoda koda punktam nav ekvivalenta kodēšanas sistēmā, kurā Tu to mēģini saglabāt, tad Tu parasti dabon jautājuma zīmīti: ? Vai arī, ja Tev patiesi paveicas, mazu kvadrātiņu!

 

Eksistē simtiem tradicionālu kodēšanas sistēmu, kuras spēj saglabāt tikai daļu no Unikoda koda punktiem, un pārvērš visu pārējo jautājuma zīmēs. Dažas populāras sistēmas ir Windows-1252 (Windows 9x standarts Rietumeiropas valodām) un ISO-8859-1 jeb Latin-1 (arī lietderīgs lielai daļai Rietumeiropas valodu). Bet pamēģini saglabāt krievu vai ivrita burtus, un Tu iegūsi bariņu ar jautājuma zīmēm. UTF 7, 8, 16 un 32 piemīt jaukā īpašība, ka tie spēj korekti saglabāt jebkuru koda punktu.

 

Vissvarīgākais fakts par kodējumiem

 

Ja arī Tu pilnībā aizmirsti visu, ko es nupat stāstīju, atceries vismaz vienu lietu - nav jēgas stringam, ja Tu nezini, kādā kodējumā tas ir. Tu vairs nevari iebāzt savu galvu smiltīs un izlikties, ka "plain" teksts ir ASCII.

 

Tāda lieta kā "plain" teksts neeksistē!

 

Ja Tev ir strings atmiņā, failā vai e-pastā, Tev vajag zināt, kāds kodējums tam ir, citādi Tu to nevarēsi korekti apstrādāt un parādīt lietotājiem.

 

Praktiski visas muļķīgās "mana weblapa izskatās nesakarīga" vai "viņa nevar izlasīt manus e-pastus, kad es izmantoju diakritiskās zīmes" beigu beigās nonāk pie viena naiva programmētājiņa, kurš nesaprata vienkāršo faktu, ka ja Tu man nepasaki, vai strings ir kodēts ar UTF-8, ASCII, ISO 8859-1 (Latin 1) vai Windows 1252 (Western European), tad šo stringu vienkārši nav iespējams korekti parādīt, vai pat saprast, kur tas beidzas. Eksistē vairāk kā simts dažādu kodējumu, un virs 127 vairs nevar būt ne par ko drošs.

 

Kā gan saglabāt šo informācju par stringiem? Nu, eksistē standarta veidi, kā to izdarīt. E-pasta sūtījumam headeros vajadzētu būt

 

Content-Type: text/plain; charset="UTF-8"

 

Weblapām ideja bija tāda, ka webserverim vajadzētu atgriezt līdzīgu Content-Type HTTP headeri kopā ar pašu weblapu. Ne jau pašā HTML, bet kā vienu no HTTP atbiles headeriem.

 

Tas gan izraisa problēmas. Iedomāsimies, ka mums ir milzīgs webserveris ar daudziem jo daudziem websaitiem, kurā katrā ir neskaitāmas weblapas, kuras radījuši daudzi dažādi cilvēki dažādās valodās izmantojot kādu nu vien kodējumu viņu Front Page kopija izdomāja par piemērotāko. Webserveris pats nemaz nezinās, kādā kodējumā katrs fails ir, tāpēc nevarēs nosūtīt šo headeri.

 

Būtu, protams, jauki, ja šo informāciju varētu iekļaut pašā HTML, izmantojot kādu nebūt īpašu tagu. Protams, tas padarīja puritāņus trakus. Kā gan Tu vari nolasīt HTML failu, ja Tu nezini, kādā kodējumā tas ir?! Par laimi gandrīzi visi kodējumi dara vienu un to pašu ar simboliem no 32 līdz 127, tāpēc parasti var tikt vismaz šitik tālu weblapā, neizmantojot jocīgus simbolus:

 

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

 

Bet šim meta tagam patiesi vajag būt pašam pirmajam tagam iekš <head>, jo tiklīdz browseris to ieraudzīs, viņš pārstās apstrādāt lapu un sāks visu no sākuma, izmantojot norādīto kodējumu.

 

Ko gan browseri dara, kad viņi neatrod Content-Type nedz headeros, nedz iekš <head>? Internet Explorer patiesībā dara kautko pavisam interesantu: tas mēģina uzminēt, balstoties uz dažādu baitu biežumu tipiskajos valodu kodējumos, kāda valoda un kodējums ir izmantoti. Tā kā dažādās 8-bitu kodu lappuses parasti lika īpatnējos simbolus starp 128 un 255, un tā kā katrai cilvēku valodai ir cita raksturīgā histogramma ar burtu biežumu, tas pat var nostrādāt. Jokaini, bet izskatās, ka tas patiesi nostrādā gana bieži, lai naivi web lapu veidotāji, kuri nekad nav zinājuši, ka viņiem vajag Content-Type headeri, varētu paskatīties uz savu radījumu un secināt, ka izskatās OK. Līdz kādu dienu viņi ieraksta kaut ko, kas gluži neatbilst standarta burtu biežuma sadalījumam, un Internet Explorer izdomā, ka šī lapa ir korejiešu valodā, un attiecīgi parāda. Un ko gan dara nabaga šīs weblapas apmeklētājs, kura bija rakstīta bulgāru valodā, bet izskatās pēc korejiešu, un pat ne sakarīga korejiešu? Viņš, protams, ķeras pie View -> Encoding un izmēģina dažādus kodējumus (ir vismaz ducis kodējumu Austrumeiropas valodām), līdz lapa sāk izskatīties labāk. Pieņemot, ka viņš to vispār prot darīt, ko lielākā daļa cilvēku nemaz neprot.

 

Pēdējā CityDesk versijā (manas kompānijas izstrādā websaitu menedžēšanas programma) mēs izlēmām visu iekšienē darīt UCS-2 kodējumā, kas ir Visual Basic, COM un Windows NT/2000/XP dzimtais stringu kodējums. C++ kodā mēs vienkārši stringus taisam kā wchar_t ("wide char") char vietā, un izmantojam wcs funkcijas str funkciju vietā (piemēram, wcscat un wcslen strcat un strlen vietā). Lai izveidotu UCS-2 stringu C kodā vajag vienkārši uzrakstīt L burtu tam priekšā: L"Hello".

 

Kad CityDesk publicē weblapu, tas to pārveido par UTF-8, kuru visi browseri labi atbalsta jau daudzus gadus. Tas arī ir veids, kā visas 29 valodu Joel on Software versijas ir kodētas, un es vēl neesmu dzirdējis nevienu personu, kura sūdzētos, ka ir problēmas to apskatīt.

 

Šis raksts ir kļuvis samērā garš, un es nevaru šeit aprakstīt pilnīgi visu, ko var uzzināt par Unikodu un kodējumiem. Taču es ceru, ka ja Tu esi izlasījis šitik tālu, tad vismaz spēsi doties atpakaļ pie programmēšanas izmantojot antibiotikas burvestību un dēļu vietā.

Labots Janvāris 4, 2010 - Vilx-

[Devil_Inside]

Raksta sākums bija daudzsološs, bet beigas galīgi garām.

Kodējums neaprobežojas tikai ar webu.

[Vilx-]

Kā jau teicu - es tikai pārtulkoju. Pie tam - kur ir teikts, ka tas aprobežojas tikai ar webu?

[(...)]

Jau sākas flūdošana , piekrītu d_l teiktajam, ka jāslēdz uzreiz, a to riebjās lasīt neapmierinātos.

[Vilx-]

Es vēl mazliet tomēr pakarāšos pie cerības stariņa par prātīgiem komentāriem. Bet, nu, ja panesīsies sviests, tad slēgšu, protams.