Minimumi absolut që çdo zhvillues softueri, pa dyshim duhet të dijë për Unicode dhe Bashkësitë e Karaktereve (S'do justifikime!)

Artikullin origjinal në gjuhën angleze mund ta gjeni në joelonsoftware.com

A të ka shkuar ndonjëherë mendja për atë etiketën misterioze Content-Type ose tipi i përmbajtjes? A e din, ajo që duhet ta vendosësh në HTML dhe kurrë nuk e din sigurt çfarë duhet të jetë?

A të ka ndodh të marrësh ndonjë email nga ndonjë shok në Bullgari me subjektin “???? ?????? ??? ????”?

Jam shqetësuar kur kam zbuluar se sa shumë zhvillues softueri nuk janë të përditësuar për botën misterioze të bashkësive të karaktereve, kodimeve, Unicode, e të gjithë këto gjëra. Para disa vitesh, një testues beta për FogBUGZ po pyeste nëse mund të trajtonte email-et hyrëse në gjuhën japoneze. Japonisht? A kanë email në Japonisht? S'kisha ide. Kur e shikova nga afër kontrollin komercial ActiveX që përdornim për të analizuar mesazhet MIME email, zbuluam se po bëhej pikërisht gabimi me bashësitë apo setet e karaktereve, kështu që na duhej të shkruanim një kod heroik për të zhbërë konvertimin e gabuar që kishte bërë dhe ta bënim atë saktë. Kur e shqyrtova një bibliotekë tjetër komerciale, ajo gjithashtu kishte një implementim totalisht të gabuar të kodimit të karaktereve. Korrespondova me zhvilluesin e asaj pakete dhe mendonte se “nuk mund të bënim asgjë për këtë”. Si shumë programerë , ai thjesht shpresonte që kjo të kalonte disi.

Por nuk do të kalojë. Kur zbulova që një nga tools(mjetet) më të njohura për zhvillimin e ueb-it - PHP, pothuajse nuk kishte dijeni për çështjet e kodimit të karaktereve, duke përdorur pa kuptim 8 bit për karaktere, duke e bërë praktikisht të pamundur zhvillimin e aplikacioneve të mira ndërkombëtare për ueb, mendova se mjaft është mjaft.

Kështu që kam një njoftim për të bërë: nëse je një programer që punon në vitin 2003 dhe nuk i di bazat e karaktereve, bashkësive të karaktereve, kodimeve dhe Unicode, dhe të arrish të bësh këtë gabim, do të të dënoj duke të bërë që të qërosh qepë për 6 muaj në një nëndetëse. Të betohem që do e bëj.

Dhe një gjë tjetër:

NUK ËSHTË EDHE AQ E VËSHTIRË.

Në këtë artikull do të të shpjegoj saktësisht çfarë duhet të dijë çdo programer që punon. Të gjitha ato gjëra për “tekst të thjeshtë = ASCII = karakteret janë 8 bit” jo vetëm që janë të gabuara, por janë dëshpërimisht të gabuara, dhe nëse akoma po programon në atë mënyrë, nuk je më mirë se një mjek që nuk beson në mikrobe. Ju lutem mos shkruani asnjë rresht tjetër kodi derisa të përfundoni këtë artikull.

Para se të filloj, duhet të të paralajmëroj se nëse je një nga ata njerëz të rrallë që di për ndërkombëtarizimin, do të të duket se i gjithë diskutimi im është pak i thjeshtuar. Në të vërtetë, po përpiqem të vendos një standard minimal këtu që të gjithë të mund të kuptojnë se çfarë po ndodh dhe të mund të shkruajnë kod që ka një shans për të punuar me tekst në çdo gjuhë tjetër përveç nën-grupit të anglishtes që nuk përfshin fjalë me thekse. Dhe duhet të të paralajmëroj se trajtimi i karaktereve është vetëm një pjesë e vogël e asaj që duhet për të krijuar softuer që funksionon ndërkombëtarisht, por mund të shkruaj vetëm për një gjë njëherësh, kështu që sot do të flas për setet e karaktereve.

Një perspektivë historike

Mënyra më e lehtë për ta kuptuar këtë gjë është duke ndjekur rrjedhën kronologjike.

Ndoshta mendon se do të flas për sete shumë të vjetra karakteresh si EBCDIC.Po, nuk do e bëj. EBCDIC nuk është e rëndësishme për jetën tënde. Nuk kemi nevojë të shkojmë aq larg në kohë.

Në ditët e vjetra të teknologjisë, kur Unix po shpikej dhe K&R po shkruanin librin "The C Programming Language", gjithçka ishte shumë e thjeshtë. EBCDIC po dilte nga përdorimi. Të vetmet karaktere që kishin rëndësi ishin shkronjat e thjeshta të paaksentuara të anglishtes, dhe kishim një kod për to që quhej ASCII, i cili mund të përfaqësonte çdo karakter duke përdorur një numër midis 32 dhe 127. Hapësira ishte 32, shkronja “A” ishte 65, etj. Kjo mund të ruhej lehtësisht në 7 bit. Shumica e kompjuterëve në atë kohë përdornin byte 8-bitesh, kështu që jo vetëm që mund të ruaje çdo karakter të mundshëm ASCII, por kishe një bit të tërë të lirë, të cilin, nëse ishe "i ligë", mund ta përdorje për qëllime "të liga": njerëzit te WordStar ndezën bit-in e lartë për të treguar shkronjën e fundit në një fjalë, duke dënuar WordStar me tekst vetëm në anglisht. Kodet nën 32 quheshin të paprintueshme dhe përdoren për sharje. Po bëj shaka. Ato përdoren për karaktere kontrolli, si 7, që bënte kompjuterin të bënte bip, dhe 12, që bënte faqen aktuale të letrës të fluturonte nga printeri dhe një faqe e re të furnizohej.

Dhe gjithçka ishte mirë, por duke supozuar që ishe një folës i anglishtes .

Pasi bytet kanë hapësirë për deri në tetë bit, shumë njerëz filluan të mendojnë: “po, mund të përdorim kodet 128-255 për qëllimet tona.” Problemi ishte se shumë njerëz kishin këtë ide në të njëjtën kohë, dhe secili kishte idetë e veta për çfarë duhet të vendosej ku, në hapësirën nga 128 deri në 255. IBM-PC kishte diçka që u bë e njohur si seti i karaktereve OEM, që ofronte disa karaktere të aksentuara për gjuhët evropiane dhe një grumbull karakteresh për vizatimin e vijave... vijëzime horizontale, vertikale, vijëzime horizontale me ca bishta të vegjël që dilnin nga e djathta, etj., dhe mund t’i përdorje këto karaktere për të krijuar kuti dhe vijëzime të këndshme në ekran, të cilat ende mund t’i shohësh në kompjuterin 8088 te pastruesi i thatë. Në fakt, sapo njerëzit filluan të blejnë PC jashtë Amerikës, u krijuan lloj-lloj sete OEM karakteresh, të cilat përdorën karakteret e sipërme të 128 për qëllime të ndryshme. Për shembull, në disa PC, kodi i karakterit 130 shfaqej si é, por në kompjuterët e shitur në Izrael ishte shkronja hebraike Gimel (ג), kështu që kur amerikanët dërgonin rezymetë e tyre në Izrael, ato mbërrinin si rגsumגs. Në shumë raste, si në gjuhën ruse, kishte shumë ide të ndryshme për çfarë të bëhej me karakteret e sipërme të 128, kështu që nuk mund të ndaje dokumente ruse me besueshmeri.

Më në fund, OEM falas për të gjithë,u kodifikua në standardin ANSI. Në standardin ANSI, të gjithë ranë dakord se çfarë duhej bërë nën 128, që ishte pothuajse e njëjtë me ASCII, por kishte shumë mënyra të ndryshme për të trajtuar karakteret nga 128 e më lart, në varësi të vendit ku jetoje. Këto sisteme të ndryshme quheshin "faqe kodesh". Për shembull, në Izrael, DOS përdorte një faqe kodi të quajtur 862, ndërsa përdoruesit grekë përdornin 737. Ishin të njëjtat nën 128, por të ndryshme nga 128 e lart, ku ndodheshin të gjitha shkronjat e çuditshme. Versionet kombëtare të MS-DOS kishin dhjetëra faqe kodimi, duke trajtuar gjithçka, nga anglishtja deri te islandishtja, dhe madje kishin disa faqe kodimi "multilingual" që mund të bënin Esperanto dhe Galiçianisht në të njëjtin kompjuter! Wow! Por të bëje, për shembull, hebraisht dhe greqisht në të njëjtin kompjuter ishte një pamundësi e plotë përveç nëse shkruaje programin tënd personal që shfaqte gjithçka duke përdorur grafikë të vizatuar, sepse hebraishtja dhe greqishtja kërkonin faqe kodimi të ndryshme me interpretime të ndryshme të numrave të lartë.

Ndërkohë, në Azi, po ndodhnin gjëra edhe më të çmendura për të marrë parasysh faktin që alfabetet aziatike kanë mijëra shkronja, të cilat nuk do të futeshin kurrë në 8 bit. Kjo zakonisht zgjidhej nga sistemi i çrregullt i quajtur DBCS, “seti i karaktereve me dy byte”, ku disa shkronja ruheshin në një byte dhe të tjerat merrnin dy. Ishte e lehtë të ecesh përpara në një varg, por thuajse e pamundur të ecesh prapa. Programuesit këshilloheshin të mos përdornin s++ dhe s-- për të ecur përpara dhe prapa, por në vend të kësaj të thërrisnin funksione si AnsiNext dhe AnsiPrev të Windows që dinin si të trajtonin gjithë këtë rrëmujë.

Por gjithsesi, shumica e njerëzve thjesht pretendonin se një byte ishte një karakter dhe një karakter ishte 8 bit dhe për sa kohë që nuk e lëvizje një varg nga një kompjuter te një tjetër, ose nuk flisje më shumë se një gjuhë, do të funksiononte gjithmonë. Por natyrisht, sapo ndodhi Interneti, u bë shumë e zakonshme të lëvizje vargje nga një kompjuter te një tjetër, dhe gjithë rrëmuja u shemb. Për fat të mirë, Unicode ishte shpikur.

Unicode

Unicode ishte një përpjekje guximtare për të krijuar një grup karakteresh të vetëm që përfshinte çdo sistem shkrimi të arsyeshëm në planet dhe disa të shpikur, si për shembull Klingon. Disa njerëz kanë keqkuptimin se Unicode është thjesht një kod 16-bitësh ku çdo karakter zë 16 bit dhe si rrjedhojë ka 65,536 karaktere të mundshme. Kjo nuk është e vërtetë. Ky është miti më i zakonshëm për Unicode, kështu që nëse e keni menduar këtë, mos u ndjeni keq.

Në fakt, Unicode ka një mënyrë tjetër të të menduarit për karakteret, dhe duhet të kuptoni këtë mënyrë të mendimit të Unicode, përndryshe asgjë nuk do të ketë kuptim.

Deri më tani, kemi supozuar se një shkronjë lidhet me disa bita që mund t’i ruani në disk ose në memorje/kujtesë:

A -> 0100 0001

Në Unicode, një shkronjë lidhet me diçka që quhet kod i pikës, e cila është ende thjesht një koncept teorik. Si përfaqësohet kjo pikë kodi në kujtesë ose në disk është një çështje krejt tjetër.

Në Unicode, shkronja A është një ideal platonik. Ajo qëndron lart, në qiell:

A

Kjo A platonike është e ndryshme nga B, dhe e ndryshme nga a, por e njëjtë me A dhe A dhe A. Ideja që A në fontin Times New Roman është karakteri njëjtë si A në fontin Helvetica, por e ndryshme nga “a” me shkronja të vogla, nuk duket e diskutueshme. Megjithatë, në disa gjuhë, thjesht përcaktimi se çfarë është një shkronjë mund të jetë çështje debati. A është shkronja gjermane ß një shkronjë e vërtetë apo thjesht një mënyrë e bukur për të shkruar ss? Nëse forma e një shkronje ndryshon në fund të një fjale, a është ajo një shkronjë tjetër? Hebraishtja thotë po, arabishtja thotë jo. Gjithsesi, njerëzit e mençur në Unicode kanë qenë duke e zgjidhur këtë për dekadën e fundit, të shoqëruar nga shumë debate politike, dhe ju nuk keni pse të shqetësoheni për këtë. Ata e kanë zgjidhur gjithçka tashmë.

Çdo shkronjë platonike në çdo alfabet i caktohet një numër magjik nga Unicode, i cili shkruhet kështu: U+0639. Ky numër magjik quhet kod i pikës. Shkronjat U+ nënkuptojnë “Unicode” dhe numrat janë në formë heksadecimale. U+0639 është shkronja arabe Ain. Shkronja angleze A do të ishte U+0041. Mund t’i gjeni të gjitha duke përdorur veglën charmap në Windows 2000/XP ose duke vizituar faqen e internetit të Unicode.

Nuk ka kufi të vërtetë për numrin e shkronjave që Unicode mund të përcaktojë dhe në fakt ata kanë kaluar përtej 65,536, kështu që jo çdo shkronjë Unicode mund të përmblidhet vërtet në dy byte, por ky ishte një mit gjithsesi.

Le të themi se kemi një varg:

Hello

i cili, në Unicode, korrespondon me këto pesë pika kodi:

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

Thjesht një grumbull pikash kodi. Numra, vërtet. Ende nuk kemi thënë asgjë për mënyrën se si ta ruajmë këtë në memorje ose ta përfaqësojmë me mesazh emaili.

Enkodimet

Këtu hyjnë në lojë enkodimet.

Ideja e hershme për enkodimin Unicode, e cila çoi në mitin për dy bytet, ishte: “hej, le t’i ruajmë këta numra në dy byte secili”. Kështu që Hello bëhet:

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

E drejtë? Jo kaq shpejt! A nuk mund të jetë gjithashtu:

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

Në fakt, teknikisht, po, mendoj se mund të jetë, dhe në fakt, zbatuesit e hershëm donin të ishin në gjendje t’i ruanin pikat e tyre të kodit Unicode në modalitetin high-endian ose low-endian, cilido të ishte më i shpejtë për CPU-në e tyre të veçantë, dhe kështu u krijua konventa e çuditshme e vendosjes së një FE FF në fillim të çdo vargu Unicode; kjo quhet Unicode Byte Order Mark dhe nëse jeni duke ndërruar bajtet tuaja të larta dhe të ulëta, kjo do të duket si FF FE dhe personi që lexon vargun tuaj do ta dijë që duhet të ndërrojë çdo bajt tjetër. Sa lehtë! Jo çdo varg Unicode ka një byte order mark në fillim.

Për një farë kohe dukej sikur kjo mund të ishte e mjaftueshme, por programerët filluan të ankoheshin. “Shihni të gjitha këto zero!” thoshin ata, sepse ishin amerikanë dhe shihnin tekst anglisht i cili rrallë përdorte pika kodi mbi U+00FF. Gjithashtu, ata ishin liberalë në Kaliforni që donin të kursenin (me përçmim). Nëse do të ishin teksanë, nuk do t’u kishte bërë përshtypje dyfishimi i hapësirës së ruajtjes për vargjet. Por ata qyqarët nga Kalifornia nuk mund ta duronin idenë e dyfishimit të hapësirës që merrte për ruajtjen e vargjeve, dhe gjithsesi, kishte tashmë gjithë ato dokumente të mallkuara që përdornin karaktere të ndryshme ANSI dhe DBCS, dhe kush do t’i konvertonte të gjitha? Unë? Për këtë arsye të vetme shumica e njerëzve vendosën ta injoronin Unicode për disa vite, dhe ndërkohë gjërat u përkeqësuan.

Kështu u shpik koncepti briliant i UTF-8. UTF-8 ishte një tjetër sistem për ruajtjen e vargut tuaj të pikave të kodit Unicode, ato numra magjikë U+, në kujtesë duke përdorur byte 8-bitësh. Në UTF-8, çdo pikë kodi nga 0-127 ruhet në një bajt të vetëm. Vetëm pikat e kodit nga 128 e sipër ruhen duke përdorur 2, 3, madje deri në 6 byte.

Si funksionon UTF-8

Kjo ka efektin e till që teksti anglisht duket saktësisht njësoj në UTF-8 si në ASCII, kështu që amerikanët nuk vënë re asgjë të gabuar. Vetëm pjesa tjetër e botës duhet të kapërcejë pengesa. Konkretisht, Hello, e cila ishte U+0048 U+0065 U+006C U+006C U+006F, do të ruhet si 48 65 6C 6C 6F, që, ja! është e njëjtë me mënyrën se si ruhej në ASCII, dhe ANSI, dhe çdo grup karakteresh OEM në planet. Tani, nëse guxoni të përdorni shkronja me theks apo shkronja greke apo shkronja Klingon, do t'ju duhet të përdorni disa byte për të ruajtur një pikë të vetme kodi, por amerikanët nuk do ta vënë re. (UTF-8 ka gjithashtu cilësinë e këndshme që programet e vjetra të përpunimit të vargjeve që duan të përdorin një bajt 0 si null-terminator nuk do të shkurtojnë vargjet).

Deri tani, ju kam përmendur tre mënyra për të koduar Unicode. Mënyrat tradicionale për ta ruajtur në dy byte quhen UCS-2 (sepse ka dy byte) ose UTF-16 (sepse ka 16 bit), dhe ju duhet ende të kuptoni nëse është UCS-2 me bajtin e lartë në fillim (high-endian) apo me bajtin e ulët në fillim (low-endian). Po ashtu ekziston standardi i njohur UTF-8, i cili ka përparësinë që punon në mënyrë të respektueshme edhe nëse përputhni tekstin anglez dhe programet që janë të padijshme për çfarëdo që është më shumë se ASCII.

Në fakt, ekzistojnë një sërë mënyrash të tjera për të koduar Unicode. Ekziston diçka e quajtur UTF-7, e cila është e ngjashme me UTF-8, por garanton që biti i lartë të jetë gjithmonë zero, në mënyrë që nëse duhet të kaloni Unicode përmes një sistemi emaili me rregulla shumë të rrepta, ku mendohet se 7 bit janë më se të mjaftueshme, ai mund të kalojë pa u prekur. Ekziston edhe UCS-4, që ruan çdo pikë kodi në 4 byte, dhe kjo ka përparësinë që çdo pikë kodi mund të ruhet në të njëjtin numër bytesh, por, çuditërisht, edhe teksanët(texans) nuk do të ishin aq të guximshëm sa të harxhonin kaq shumë memorie.

Dhe tani që po mendoni për gjërat në terma të shkronjave ideale platonike që përfaqësohen nga pikët e kodit Unicode, ato pikë kodi Unicode mund të kodohen në çdo skemë të vjetër kodimi gjithashtu! Për shembull, mund të kodoni vargun Unicode për “Hello” (U+0048 U+0065 U+006C U+006C U+006F) në ASCII, ose kodimin e vjetër OEM grek, ose kodimin ANSI hebraik, ose në cilëndo nga disa qindra kodime të shpikura deri tani, me një kusht: disa nga shkronjat mund të mos shfaqen! Nëse nuk ekziston një ekuivalencë për pikën e kodit Unicode që po përpiqeni ta përfaqësoni në kodimin që po përdorni, zakonisht merrni një pikëpyetje të vogël: ? ose, nëse jeni me të vërtetë të zotë, një kuti. Çfarë morët ju? ->

Ekzistojnë qindra kodime tradicionale të cilat mund të ruajnë disa pika kodi saktësisht dhe të ndryshojnë të gjitha të tjerat në pikëpyetje. Disa kodime popullore për tekstin anglisht janë Windows-1252 (standardi Windows 9x për gjuhët e Evropës Perëndimore) dhe ISO-8859-1, aka Latin-1 (gjithashtu i dobishëm për çdo gjuhë të Evropës Perëndimore). Por përpiquni të ruani shkronja ruse ose hebraike në këto kodime dhe do të merrni një mori pikëpyetjesh. UTF-7, 8, 16, dhe 32 kanë të gjitha përparësinë që mund të ruajnë çdo pikë kodi saktësisht.

Fakti Më i Rëndësishëm për Kodimet

Nëse harroni gjithçka që ju shpjegova deri tani, ju lutem mbani mend një fakt jashtëzakonisht të rëndësishëm. Nuk ka kuptim të keni një varg pa e ditur se çfarë kodimi përdor. Nuk mund të futeni më kokëposhtë dhe të pretendoni se “teksti i thjeshtë” është ASCII.

Nuk Ekziston Diçka e Tilla si Tekst i Thjeshtë.

Nëse keni një varg, në kujtesë, në një skedar, apo në një mesazh emaili, duhet të dini se çfarë kodimi përdor, përndryshe nuk mund ta interpretoni ose ta shfaqni saktë për përdoruesit.

Gati çdo problem i “faqja ime e internetit duket si shkronja të çrregullta” ose “ajo nuk mund të lexojë emailat e mi kur përdor thekse” vjen nga një programues naiv që nuk e kuptoi faktin e thjeshtë se nëse nuk më thoni nëse një varg është i koduar duke përdorur UTF-8 ose ASCII ose ISO 8859-1 (Latin-1) ose Windows 1252 (Evropa Perëndimore), ju thjesht nuk mund ta shfaqni saktë ose të kuptoni se ku përfundon. Ekzistojnë mbi njëqind kodime dhe mbi pikën e kodit 127, të gjitha bastet janë të hapura.

Si e ruajmë këtë informacion për kodimin që përdor një varg? Epo, ka mënyra standarde për ta bërë këtë. Për një mesazh emaili, ju pritet të keni një varg në titullin e formës

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

Për një faqe interneti, ideja origjinale ishte që serveri i internetit të kthente një titull të ngjashëm Content-Type http së bashku me vetë faqen e internetit — jo brenda HTML-it vetë, por si një nga titujt e përgjigjes që dërgohen përpara se faqja HTML të shfaqet.

Kjo krijon probleme. Supozoni se keni një server të madh interneti me shumë site dhe qindra faqe të kontribuara nga shumë njerëz në shumë gjuhë të ndryshme dhe të gjitha duke përdorur cilindo kodim që kopja e tyre e Microsoft FrontPage e gjeti të arsyeshme për të gjeneruar. Vetë serveri i internetit nuk do të dinte me të vërtetë se çfarë kodimi ishte shkruar çdo skedar, kështu që nuk mund të dërgonte titullin Content-Type.

Do të ishte e përshtatshme nëse mund ta vendosnit Content-Type të skedarit HTML pikërisht në vetë skedarin HTML, duke përdorur një lloj etikete të veçantë. Sigurisht që kjo i çmend puristët... si mund ta lexoni skedarin HTML derisa të dini se çfarë kodimi ka?! Për fat të mirë, pothuajse çdo kodim që përdoret zakonisht bën të njëjtën gjë me shkronjat midis 32 dhe 127, kështu që gjithmonë mund të arrini deri këtu në faqen HTML pa filluar të përdorni shkronja të çuditshme:

html Copy code

Çfarë bëjnë shfletuesit e internetit nëse nuk gjejnë asnjë Content-Type, qoftë në titujt http ose në etiketën "meta"? Internet Explorer në fakt bën diçka mjaft interesante: ai përpiqet të hamendësojë, bazuar në frekuencën me të cilën shfaqen byte të ndryshëm në tekstin tipik në kodime të ndryshme të gjuhëve të ndryshme, se çfarë gjuhe dhe kodimi është përdorur. Sepse kodet e ndryshme të vjetra me 8 bit priren të vendosin shkronjat e tyre kombëtare në diapazone të ndryshme midis 128 dhe 255, dhe sepse çdo gjuhë njerëzore ka një histogram karakteristik të përdorimit të shkronjave, kjo në fakt ka mundësi të funksionojë.

Është vërtet e çuditshme, por duket se funksionon mjaftueshëm shpesh që autorët e thjeshtë të faqeve të internetit, të cilët nuk e dinin kurrë që u nevojitej një titull Content-Type, e shikojnë faqen e tyre në një shfletues interneti dhe ajo duket në rregull, deri në një moment kur shkruajnë diçka që nuk përputhet plotësisht me shpërndarjen e frekuencës së shkronjave të gjuhës së tyre amtare, dhe Internet Explorer vendos që është koreane dhe e shfaq si të tillë, duke provuar, mendoj unë, se ligji i Postel-it për të qenë “konservator në atë që emeton dhe liberal në atë që pranon” nuk është aspak një parim i mirë inxhinierik. Gjithsesi, çfarë bën lexuesi i shkretë i kësaj faqeje interneti, e cila është shkruar në bullgarisht por duket koreane (dhe jo edhe ndonjë koreane koherente)? Ai përdor menunë View | Encoding dhe provon një sërë kodimesh të ndryshme (ka të paktën një duzinë për gjuhët e Evropës Lindore) derisa imazhi të bëhet më i qartë. Nëse e di të bëjë këtë, gjë që shumica e njerëzve nuk e dinë.

Për versionin më të fundit të CityDesk, softuerit për menaxhimin e faqeve të internetit të publikuar nga kompania ime, vendosëm që të bënim gjithçka brenda në UCS-2 (dy byte) Unicode, që është ajo që përdorin Visual Basic, COM dhe Windows NT/2000/XP si llojin e tyre vendas të vargjeve. Në kodin C++, thjesht shpallim vargje si wchar_t (shkronjë e gjerë) në vend të char dhe përdorim funksionet wcs në vend të funksioneve str (për shembull, wcscat dhe wcslen në vend të strcat dhe strlen). Për të krijuar një varg të literalit UCS-2 në kodin C, thjesht vendosni një L përpara si kështu: L"Hello".

Kur CityDesk publikon faqen e internetit, e konverton atë në kodimin UTF-8, i cili është mbështetur mirë nga shfletuesit e internetit për shumë vite. Kjo është mënyra se si janë koduar të gjitha 29 versionet gjuhësore të "Joel on Software" dhe nuk kam dëgjuar ende asnjë person që të ketë pasur ndonjë problem në shikimin e tyre.

Ky artikull po bëhet mjaft i gjatë dhe nuk mund të mbuloj gjithçka që ka për të ditur për kodimet e karaktereve dhe Unicode, por shpresoj që, nëse keni lexuar deri këtu, dini mjaftueshëm për t'u rikthyer në programim, duke përdorur antibiotikë në vend të shushunjave dhe magjive, një detyrë të cilën tani po ju lë ta kryeni vetë.