La Absoluta Minimumo Kiun Ĉiu Programisto Absolute, Pozitive Devas Scii Pri Unikodo kaj Signaroj (Neniuj Ekskuzoj!)

From The Joel on Software Translation Project

Jump to: navigation, search

de Joel SPOLSKY
merkredon, la 8-an de oktobro, 2003
Originala artikolo The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Tradukita de Russ WILLIAMS
Redaktita de Brion VIBBER

Contents

Enkonduko

Ĉu vi iam scivolis pri tiu mistera etikedo Content-Type? Vi scias, tiu kiun vi devas uzi en HTML kaj pri kiu vi neniam certe scias kio ĝi devas esti?

Ĉu vi iam ricevis retpoŝton de viaj amikoj en Bulgario kun la temo "???? ?????? ??? ????"?

Mi konsterniĝis pri kiom da programistoj ne tre certe komprenas la misteran mondon de signaroj, kodoprezentoj, Unikodo, ktp. Antaŭ kelkaj jaroj, beta-testanto por FogBUGZ scivolis ĉu ĝi povas toleri retpoŝton alvenantan japane. Ĉu la japana? Ĉu estas retpoŝto japana? Mi tute ne sciis. Kiam mi rigardis la komercan ActiveX-stirilon kiun ni uzis por sintaksanalizi MIME-retpoŝtmesaĝojn, ni trovis ke ĝi precize misagadis pri signaroj, do ni efektive bezonis verki heroan kodon por malfuŝi la miskonverton kaj rekonverti korekte. Kiam mi rigardis alian komercan bibliotekon, ĝi ankaŭ havis tute fuŝitan signokodorealigon. Mi poŝtis kun la verkisto de tiu softvaro, kaj li pensis ke eble ili "ne povas fari ion pri ĝi." Kiel multaj programistoj, li nur deziris ke la problemo malaperus iel.

Sed ĝi ne malaperos. Kiam mi malkovris ke la populara ttt-programilo PHP havas preskaŭ tutan senscion pri signokodaferoj, senzorge uzante 8 bitojn por signoj, kaj malebligante verki bonajn internaciajn ttt-aplikaĵojn, mi pensis sufiĉe!

Do mi bezonas anonci: se vi estas programisto laborante en 2003 kaj vi ne scias la fundamentojn pri signoj, signaroj, kodoprezentoj, kaj Unikodo, kaj mi kaptos vin, mi punos vin per igi vin senŝeligi cepojn dum 6 monatoj en submarŝipo. Mi ĵuras, mi punos.

Kaj unu alia aĵo:

NE ESTAS TRE MALFACILE.

Per ĉi tiu artikolo mi sciigos vin pri precise kiun ĉiu laboranta programisto devas scii. Tiu rubo pri "ordinara teksto = ascii = signoj havas 8 bitojn" ne nur malpravas, ĝi senespere malpravas, kaj se vi ankoraŭ kodas tiel, vi estas apenaŭ pli bona ol kuracisto kiu ne kredas je mikroboj. Bonvolu ne skribi alian linion de kodo ĝis vi legos tute ĉi tiun artikolon.

Antaŭ mi komencos, mi devas averti vin ke se vi estas unu de tiuj malkutimaj homoj kiu scias pri internaciigo, vi opinios ke mia tuta diskutado estas iomete trosimpligita. Fakte, mi nur provas klarigi la fundamentojn por ke ĉiu povu kompreni kio okazas kaj povu verki kodon kiu havas esperon funkcii kun tekston en iu lingvo krom la parto de la angla kiu ne havas vortojn kromsignitajn. Kaj mi devas averti vin ke signotrakti estas nur eta parto de krei softvaron kiu funkcias internacie, sed mi povas skribi pri nur unu afero ope, do hodiaŭ estas signaroj.

Historia Perspektivo

La plej facila metodo por kompreni ĉi tiujn aferojn estas iri kronologie.

Vi probable kredas ke mi babilos pri tre arkaikaj signaroj kiel EBCDIC nun. Nu, ne. EBCDIC ne koncernas vian vivon. Ni ne bezonas retroiri tiel foren tra tempo.

Pratempe, kiam Unikso kreiĝis kaj K&R verkis la programlingvon C, ĉiu simplegis. EBCDIC estis eliranta. La nuraj gravaj signoj estis agrablaj malkromsignitaj anglaj literoj, kaj ni havis kodon por ili, ASCII, kiu povis reprezenti ĉiun signon uzante nombron inter 32 kaj 127. Spaceto estis 32, la litero "A" estis 65, ktp. Ĉi tiu sidis oportune en 7 bitoj. La plejmulto da komputiloj tiam uzis 8-bitajn bajtojn, do vi ne nur povis memori ĉiun eblan ASCII-signon, sed ankaŭ vi havis tutan biton disponeblan, kiun, se vi lertis, vi povas uzi por via propraj ruzemaj celoj: la stultuloj ĉe WordStar efektive ŝaltis la altan biton por indiki la finan literon en vorto, kondamnante WordStar al angla teksto nur. Kodoj sub 32 estis nomitaj malpreseblaj kaj uzitaj por sakri. Nur ŝerce! Ili uziĝis kiel stirsignoj, ekzemple 7, kiu igis vian komputilon pepi, kaj 12, kiu igis la paperfolion nunan flugi el la presilo kaj novan eniri.

Kaj ĉio bonegas, se vi parolis la anglan.

Ĉar bajtoj havas sufiĉan spacon por ok bitoj, multaj homoj ekpensis, "ho, ni povas uzi la kodojn 128-255 por niajn proprajn celojn." La problemo estis, ke multaj homoj havis ĉi tiun ideon samtempe, kaj ili havis iliajn proprajn ideojn pri kio devas iri kien en la spaco de 128 ĝis 255. La komputilo IBM-PC havis ion kiu fine konatiĝis kiel la signaro OEM, kiu provizis kelkajn signojn kromsignitajn por lingvoj eŭropaj kaj multajn linisignojn... horizontalajn liniojn, vertikalajn liniojn, horizontalajn liniojn kun etaj pendaĵoj pendantaj de la dekstra flanko, ktp, kaj vi povis uzi ĉi tiujn linisignojn por verki agrablajn skatolojn kaj liniojn sur la ekranon, kiujn vi ankoraŭ povas vidi sur la antikva 8088-komputilo ĉe via puragistejo. Fakte kiam homoj komencis aĉeti komputilojn ekster Usono, ĉiaj OEM-signaroj kreiĝis, kaj ĉiuj uzis la plej altaj 128 signoj por iliaj propraj celoj. Ekzemple iuj komputiloj vidigas la signokodon 128 kiel é, sed Israelaj komputiloj vidigas ĝin kiel la literon hebrean Gimel (), do kiam Usonanoj sendis iliajn résumojn al Israelo, ili alvenas kiel rsumoj. Multkaze, ekzemple la rusa, estis multaj malsamaj ideoj pri kiel uzi la 128 altajn signojn, do vi ne eĉ povis fidende interŝanĝi rusajn dokumentojn.

Fine ĉi tiu OEM-bruego normiĝis de ANSI. En la ANSI-normo, ĉiu akordis kion fari sub 128, kio estis pli-malpli ASCII, sed estis multaj malsamaj metodoj por trakti la signojn de 128 supren, depende de kie vi loĝis. Ĉi tiuj malsamaj sistemoj nomiĝis kodpaĝoj. Ekzemple en Israelo DOS uzis kodpaĝon nomitan 862, kaj Grekio uzis 737. Ili samis sub 128 sed malsamis de 128 supren, kie ĉiuj strangaj literoj loĝis. La naciaj versioj de MS-DOS havis dekojn da ĉi tiuj kodpaĝoj, traktante ĉiun de la angla ĝis la islanda, kaj ili eĉ havis kelkajn "multlingvajn" kodpaĝojn kiuj povis fari Esperanton kaj la galegan je la sama komputilo! Ha! Sed havi, ekzemple, la hebrean kaj la grekan je la sama komputilo estis tuta maleblo, krom se vi verkis vian propran laŭmendan programon kiu vidigis ĉiun uzante rastruman grafikon, ĉar la hebrea kaj la greka bezonis malsamajn kodpaĝojn kun malsimilaj interpretoj de la altaj nombroj.

Dume, en Azio, eĉ pli frenezaĵoj okazadis por trakti la fakton ke aziaj alfabetoj havas milojn da literoj, kiuj neniam sidus en 8 bitojn. Ĉi tio kutime solviĝis per la ĥaosa sistemo nomita DBCS, la "double byte character set" (duopa-bajta signaro), en kiu iuj literoj memoriĝis en unu bajto kaj aliaj bezonis du. Facilis antaŭiri en ĉeno, sed preskaŭ maleblis retroiri. Programistoj devas ne uzi s++ kaj s-- por antaŭiri kaj retroiri, sed anstataŭe uzi funkciojn kiel AnsiNext kaj AnsiPrev de Vindozo, kiuj sciis kiel trakti la tutan ĥaoson.

Sed ankoraŭ, la plejmulto da homoj pretendis ke bajto estis signo kaj signo estis 8 bitoj kaj dum vi neniam sendis ĉenon el iu komputilo al alia, aŭ parolis pli ol unu lingvo, ĝi ĉiam pli-malpli funkcius. Sed kompreneble, kiam la interreto okazis, ekkutimis sendi ĉenojn el iu komputilo al alia, kaj la tuta ĥaoso disfalegis. Bonŝance, Unikodo inventiĝis.

Unikodo

Unikodo estis kuraĝa peno por krei unuopan signaron kiu enhavis ĉiun bonsencan skribsistemon sur la planedo kaj iujn ludajn lingvojn kiel la klingona, ankaŭ. Iuj miskredas ke Unikodo estas simple 16-bita kodo kaj ĉiu signo uzas 16 bitojn kaj do estas 65536 eblaj signoj. Ĉi tio ne fakte pravas. Ĝi estas la plej ofta mito pri Unikodo, do se vi kredis tion, ne ĉagreniĝu.

Fakte, Unikodo havas alian metodo por pensi pri signoj, kaj vi devas kompreni la Unikodan metodon por pensi pri aĵoj aŭ nenio sencos.

Ĝis nun, ni supozis ke signo ĵetiĝas al iuj bitoj kiujn vi povas memori je disko aŭ memoro:

A -> 0100 0001

Unikodo ĵetas literon al iu nomita kodono (aŭ signonumero), kiu estas ankoraŭ nur teoria koncepto. Kiel tiu kodono reprezentiĝas je memoro aŭ disko estas tuta alia rakonto.

Laŭ Unikodo, la litero A estas platona idealo. Ĝi simple ŝvebas en ĉielo:

A

Ĉi tiu platona A malsamas ol B, kaj malsamas ol a, sed samas ol A kaj A kaj A. La ideo ke A je la tiparo Times New Roman (Tajmzo Nova Roma) estas la sama signo kiel la A je la tiparo Helvetica (Helvetika), sed estas malsama ol la minuskla litero a, ne ŝajnas tre disputebla, sed por iuj lingvoj nur decidi kio litero estas povas krei disputon. Ĉu la germana litero ß reala litero, aŭ nur ornama metodo por skribi ss? Se la formo de la litero ŝanĝiĝas ĉe la vortfino, ĉu tio estas malsama litero? La hebrea diras jes, la araba diras ne. Ĉiuokaze, la lertaj homoj ĉe la Unikodokonsorcio deĉifradis ĉi tion dum jardeko, kun multa politikega debato, kaj vi ne devas zorgi pri ĝi. Ili jam deduktis ĉiun.

Ĉiu platona litero en ĉiu alfabeto akiras magian nombron de la Unikodokonsorcio kiu skribiĝas tiel: U+0645. Ĉi tiu magia nombro nomiĝas kodono. La U+ signifas "Unikodo" kaj la numeroj estas deksesumaj. U+FEC9 estas la araba litero Ain. La angla litero A estas U+0041. Vi povas trovi ĉiujn uzante la ilon charmap je Vindoza 2000/XP aŭ vizitante la Unikodoretpaĝaron.

Ne estas reala limo pri la nombro da literoj kiu Unikodo povas difini kaj fakte ili iris preter 65536 do ne ĉiu unikoda litero povas premiĝi en du bajtojn, sed tio estis mito ĉiuokaze.

Nu, supozu ke ni havas ĉelon:

Saluton

kiu laŭ Unikodo akordas al ĉi tiujn sep kodonojn:

U+0053 U+0061 U+006C U+0075 U+0074 U+006F U+006E.

Nur kodonaro. Nombroj, reale. Ni ankoraŭ ne parolis pri kiel memori ĉi tiun je memoro aŭ reprezenti ĝin en retpoŝtmesaĝo.

Kodoprezentoj

Nun envenas kodoprezentoj.

La plej frua ideo pri Unikoda kodoprezento, kiu kaŭzis la miton pri la du bajtoj, estis, hej, simple memoru tiujn nombrojn en po du bajtojn. Do Saluton iĝas

00 53 00 61 00 6C 00 75 00 74 00 6F 00 6E

Ĉu ne? Ne tiel rapide! Ĉu ĝi ankaŭ povas esti:

53 00 61 00 6C 00 75 00 74 00 6F 00 6E 00

Nu, teknike, jes, mi kredas ke ĝi povus, kaj fakte fruaj realigantoj volis povi memori ilian unikodajn kodonojn per metodoj pezfina aŭ pezkomenca, kiun ajn ilia ĉeforgano traktis plej rapide, kaj ho, estis vespero kaj estis mateno kaj jam estis du metodoj por memori Unikodon. Do la homoj deviĝis inventi la strangan konvencion de meti FE FF antaŭ ĉiu unikoda ĉeno; ĉi tio nomiĝas Unikoda Bajtordomarko kaj se vi interŝanĝas viajn altajn kaj subajn bajtojn ĝi aspektos kiel FF FE kaj legantoj de via ĉeno scios ke ili devas interŝanĝi ĉiujn bajtparojn. Uf. Ne ĉiu unikoda ĉeno en la reala mondo havas bajtordomarkon.

Iom da tempo, tio ŝajnis sufiĉe bona, sed programistoj plendis. "Rigardu ĉiujn nulojn!" ili diris, ĉar ili estis Usonanoj kaj ili rigardis anglan tekston kiu malofte uzis kodonojn super U+00FF. Ankaŭ ili estis liberalaj idealismaj hipioj en Kalifornio (probable samideanoj ankaŭ!) kiuj volis konservi (rikanu!). Se ili estus Teksasaj milionuloj, ili ne plendus pri la malŝparo de valoraj bajtoj. Sed tiuj folaj Kalifornio-senspinuloj ne povis toleri la ideon duobligi la memoron bezonitan por ĉenoj, kaj ĉiuokaze, jam ekzistis ekstere tro da damnaj dokumentoj uzantaj multajn ANSI- kaj DBCS-signarojn kaj kiu konvertos ĉiujn? Mi? Tial, la plejmulto da homoj decidis ignori Unikodon dum kelkaj jaroj kaj dume aferoj plimalboniĝis.

Tiel inventiĝis la brila koncepto UTF-8. UTF-8 estis alia sistemo por reprezenti vian ĉenon de unikodaj kodonoj, tiuj magiaj U+nombroj, en memoro per 8-bit-bajtoj. Laŭ UTF-8, ĉiu kodono el 0-127 memoriĝas en unuopa bajto. Nur kodonoj de 128 supren bezonas 2, 3, fakte ĝis 6 bajtojn.

How UTF-8 works

Ĉi tio havas la lertan kromefikon ke angla teksto aspektas precize same per UTF-8 kiel per ASCII, tial Usonanoj ne eĉ rimarkas ion malĝustan. Nur la cetero de la mondo devas laboregi kaj salti tra ringegojn! Ekzemple, Saluton, kiu estis U+0053 U+0061 U+006C U+0075 U+0074 U+006F U+006E, memoriĝis kiel 53 61 6C 75 74 6F 6E, kiu, jen!, estas la sama kiel ASCII, kaj ANSI, kaj ĉiu OEM-signaro sur la planedo. Nun, se vi estas tiel aŭdaca kiel uzi literojn kromsignitajn aŭ literojn grekajn aŭ literojn klingonajn, vi devos uzi kelkajn bajtojn por memori unuopan kodonon, sed la Usonanoj neniam rimarkos. (UTF-8 ankaŭ plaĉas ĉar nesciaj malnovaj ĉentraktanta kodo kiu volas uzi unuopan 0-bajton kiel la nul-finilo ne stumpigos ĉenojn.)

Ĝis nun mi diris al vi tri metodoj por kodoprezenti Unikodon. La tradiciaj metodoj "memoru-ĝin-en-du-bajtoj" nomiĝas UCS-2 (ĉar ĝi havas du bajtojn) aŭ UTF-16 (ĉar ĝi havas 16 bitojn), kaj vi ankoraŭ bezonas deĉifri ĉu ĝi estas pezkomenca UCS-2 aŭ pezfina UCS-2. Kaj estas la populara nova UTF-8-normo kiu plaĉas ankaŭ ĉar ĝi funkcias bone se vi havas la feliĉan koincidon de angla teksto kaj cerbmortaj programoj kiuj nescias ke estas io krom ASCII.

Vere estas multaj aliaj metodoj por kodoprezenti Unikodon. Estas io nomita UTF-7, kiu estas tre simila ol UTF-8 sed garantias ke la alta bito ĉiam estos nulo, do se vi devas sendi Unikodon tra iu totalisma policoŝtata retpoŝtsistemo kiu insistas ke 7 bitoj certe sufiĉas, dankon, ĝi ankoraŭ povas tratordiĝi nemutilite. Estas UCS-4, kiu memoras ĉiun kodonon per 4 bajtoj, kiu plaĉas ĉar ĉiu unuopa kodono memoriĝas en la sama nombro da bajtoj, sed, nu, eĉ la Teksasanoj ne estus tiel aŭdacaj, kiel malŝpari tiom da memoro.

Kaj fakte nun vi pensadas pri aferoj rilate al platonidealaj literoj kiuj reprezentiĝas per unikodaj kodonoj, tiuj unikodaj kodonoj povas kodoprezentiĝi per iu ajn antikva kodoprezentosistemo, ankaŭ! Ekzemple, vi povus kodoprezenti la unikodan ĉenon Saluton (U+0053 U+0061 U+006C U+0075 U+0074 U+006F U+006E) per ASCII, aŭ la malnova OEM-greka kodoprezento, aŭ la ANSI-hebrea kodoprezento, aŭ iu ajn el la kelkaj centoj da kodoprezentoj kiuj inventiĝis ĝis nun, krom por unu ruzo: iuj literoj eble ne aperas! Se ne estas ekvivalento de la unikoda kodono kiun vi provas reprezenti en la kodoprezento per kiu vi provas reprezenti ĝin, vi kutime ricevas malgrandan demandosignon: ? or, se vi estas tre bona, skatolon. Kiun vi ricevis? -> �

Estas centoj da tradiciaj kodoprezentoj kiuj povas nur memori iom da kodonoj korekte kaj ŝanĝas ĉiujn aliajn kodonojn al demandosignojn. Iuj popularaj kodoprezentoj de angla teksto estas Vindozo-1252 (la Vindozo-9x normo por lingvoj okcidenteŭropaj) kaj ISO-8859-1, ankaŭ nomita Latin-1 (ankaŭ utila por ĉiu lingvo okcidenteŭropa). Sed provu memori rusajn aŭ hebreajn literojn per ĉi tiuj kodoprezentoj kaj vi ricevos multajn demandosignojn. UTF-7, 8, 16, kaj 32 ĉiuj plaĉas ĉar ili povas memori ĉiun kodonon korekte.

La Unuopa Plej Grava Fakto Pri Kodoprezentoj

Se vi tute forgesos ĉiun kiun mi ĵus klarigis, bonvolu memori unu gravegan fakton. Sensencas havi ĉenon sen scio pri kiun kodoprezenton ĝi uzas. Vi ne plu povas kovri viajn okulojn kaj pretendi ke "ordinara" teksto estas ASCII.

Ne Ekzistas Ordinara Teksto.

Se vi havas ĉenon, en memoro, en dosiero, aŭ en retpoŝtmesaĝo, vi devas scii en kiu kodoprezento ĝi estas aŭ vi ne povas interpreti ĝin aŭ vidigi ĝin al uzantoj korekte.

Preskaŭ ĉiu stulta problemo pri "mia retpaĝaro aspektas kiel rubo" aŭ "ŝi ne povas legi miajn retpoŝtojn kiam mi uzas kromsignojn" rezultas de unu naiva programisto kiu ne komprenis la simplan fakton ke, se vi ne diras ĉu iu specifa ĉeno kodoprezentiĝas per UTF-8 aŭ ASCII aŭ ISO-8859-1 aŭ Vindozo-1252, vi simple ne povas vidigi ĝin korekte aŭ eĉ decidi kie ĝi finas. Estas pli ol cent kodoprezentoj, kaj super kodono 127, ĉiu malcertegas.

Kiel ni konservu ĉi tiun informon pri kiun kodoprezenton ĉeno uzas? Nu, estas normaj metodoj por fari ĉi tiun. Por retpoŝtmesaĝo, vi havu ĉenon en la ĉapo kiel

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

Por retpaĝo, la originala ideo estis ke la ttt-servilo resendas similan http-ĉapon Content-Type kun la retpaĝo mem — ne en la HTML mem, sed kiel unu el la respondĉapoj kiuj sendiĝas antaŭ la HTML-paĝo.

Ĉi tio kaŭzas problemojn. Supozu ke vi havas grandan ttt-servilon kun multaj retpaĝaroj kaj centoj da paĝoj donitaj de multaj homoj en multaj malsamaj lingvoj kaj ĉiuj uzantaj kiun ajn kodoprezenton taŭgis laŭ ilia kopio de Microsoft FrontPage. La ttt-servilo mem ne certe scius en kiu kodoprezento ĉiu dosiero estas skribita, do ĝi ne povus sendi la ĉapon Content-Type.

Oportunus se vi povus enmeti la Content-Type de la HTML-dosiero rekte en la HTML-dosiero mem, uzante ian specialan etikedon. Kompreneble, ĉi tio frenezigis puristojn... kiel vi povas legi la HTML-dosieron ĝis vi scias en kiu kodoprezento ĝi estas?! Bonŝance, preskaŭ ĉiu kodoprezento kutima faras same kun signojn inter 32 kaj 127, do vi povas ĉiam atingi ĉi tien sur la HTML-paĝo sen ekuzi strangajn literojn:

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

Sed tiu meta-etikedo vere devas veni unue en la <head> parto ĉar kiam la foliumilo vidas ĉi tiun etikedon ĝi ĉesos sintaksanalizi la paĝon kaj rekomencos post reinterpreti la tutan paĝon uzante la kodoreprezenton kiun vi specifis.

Kion faras foliumiloj se ili ne trovas iun Content-Type, nek en la http-ĉapoj nek en la meta-etikedo? Microsoft Internet Explorer efektive faras ion tre interesan: ĝi provas konjekti, per la ofteco de kiu diversaj bajtoj aperas en tipa teksto en tipaj kodoprezentoj de diversaj lingvoj, kiu lingvo kaj kodoprezento uziĝis. Ĉar la diversaj malnovaj 8-bit-kodopaĝoj emis meti iliajn naciajn literojn en malsamajn intervalojn de 128 ĝis 255, kaj ĉar ĉiu homa lingvo havas malsaman distribuadon de literuzado, ĉi tio fakte havas esperon por funkcii. Estas vere stranga, sed ĝi ŝajnas funkcii sufiĉe ofte ke naivaj retpaĝverkistoj kiuj neniam sciis ke ili bezonis ĉapon Content-Type rigardas ilian paĝon per foliumilo kaj ĝi aspektas bone, ĝis unu tago, kiam ili skribas ion kio ne precize konformas al la liter-ofteco-distribuado de ilia denaska lingvo, kaj Microsoft Internet Explorer decidas ke ĝi estas korea kaj vidigas ĝin tiel, pruvante, mi kredas, ke la citaĵo de Larry WALL pri "estu strikta pri kiun vi elsendas kaj tolerema pri kiun vi akceptas" estas tre sincere ne bona inĝeniera principo. Ĉiuokaze, kion faras la povra leganto de ĉi tiu retpaĝaro, kiu skribiĝis en la bulgara sed aspektas kiel la korea (kaj ne eĉ kohera korea)? Li uzas la menuon View|Encoding kaj provas multajn malsamajn kodoprezentojn (estas almenaŭ dek por lingvoj orienteŭropaj) ĝis la bildo pliklariĝas. Se li sciis fari tiun, kiun la plejparto da homoj ne scias.

Por la plej lastatempa versio de CityDesk, la retpaĝaro-direktado-softvaro publikita de mia kompanio, ni decidis fari ĉion interne per Unikodo UCS-2 (du bajtoj), kio estas uzita de Visual Basic, COM, kaj Vindozo NT/2000/XP kiel ilia denaska ĉenotipo. En C++ kodo ni simple deklaras ĉenojn kiel wchar_t ("wide character", longa kodono) anstataŭ char kaj uzas la funkciojn wcs anstataŭ la funkciojn str (ekzemple wcscat kaj wcslen anstataŭ strcat kaj strlen). Por krei literalan UCS-2-ĉenon en C-kodo vi simple metu L antaŭ gin ĉi tiel: L"Saluton".

Kiam CityDesk publikigas la retpaĝon, ĝi ŝanĝas ĝin al UTF-8-kodoprezento, kiu funkcias bone je foliumiloj dum multaj jaroj. Tio estas la metodo per kio 30 lingvaj versioj de Joel on Software kodoprezentiĝas kaj mi ne jam aŭdis unuopan homon kiu havis iun problemon vidi ilin.

Ĉi tiu artikolo tre longiĝas, kaj mi ne povas inkludi ĉiun sciindan pri kodoprezentoj kaj Unikodo, sed mi esperas ke se vi legis ĝis ĉi tie, vi scias sufiĉe bone ke vi devas reveni al programi, uzante antibiotikojn anstataŭ hirudojn kaj sorĉojn, tasko por kiu mi nun vin adiaŭos.

Personal tools