1 Johdanto

Kun tietojärjestelmä suunnitellaan globaaliksi, tehdään kansainvälistämisvaiheessa järjestelmän arkkitehtuurista sellainen, ettei eri kieliä ja kulttuureita varten tarvita lokalisointivaiheessa koodimuutoksia. Tähän tavoitteeseen pääseminen esimerkiksi yksinkertaisen työasemalla ajettavan sovellusohjelman tai pienen staattisen WWW‑sivuston (World Wide Web) tapauksessa ei ole vaikeaa, vaikka vaatiikin tarkkuutta ja suunnitelmallisuutta.

Järjestelmän koon ja vaadittavien lokalisointivaihtoehtojen määrän kasvaessa käy tavoite yleispätevän koodin tuottamiseksi taloudellisesti kannattamattomaksi ja koodiin tehdään poikkeuksia. Yksittäisen maan lainsäädännön vaatiman pakollisen lakitekstin tai varoituksen esittäminen tai poikkeavan kävijästatistiikan kerääminen tietyn maan tarpeisiin voi olla tällainen poikkeus. Globaalin järjestelmän tavoitteena voi olla myös täysin eri sisällön esittäminen eri kohderyhmille. Alueelliseen markkinointiin, mainostamiseen ja kampanjointiin tarkoitetut lokalisoinnit voivat vaatia kielen kääntämisen ja käyttöliittymän muun sopeuttamisen lisäksi omia toiminnallisia osioita järjestelmään. Näiden poikkeavien osioiden kokoaminen ja yleistäminen suunnitteluvaiheessa liian pitkälle voi johtaa ajan ja rahan hukkaan heittämiseen.

Toisaalta poikkeustapausten määrän kasvaessa voidaan harkita tapauksien yleistämistä taas kansainvälistetyksi ohjelmakoodiksi (järjestelmän seuraavassa versiossa). Poikkeavista tapauksista tulee tällöin lokalisointitapauksia, jotka toteutetaan pelkkiä lokalisointiasetuksia vaihtamalla. Järjestelmää kansainvälistetään iteratiivisesti.

Globaalin verkkojärjestelmän koodissa kansainvälistetään

· kieli / tekstin esittämismuoto

· sivulla esitettävien kuvien valinta

· sivun rakenne

· merkkijonojen järjestäminen

· palveluiden kohdistaminen rajatulle käyttäjäryhmälle

· päivämäärien, ajan, valuuttojen ja numeroiden sekä esimerkiksi henkilötunnuksen, osoitteiden ja puhelinnumeroiden esittäminen.

Vastaavasti lokalisointi mahdollistetaan

· maakohtaisesti

· kielikohtaisesti

· maa/kieli-yhdistelmäkohtaisesti

· maantieteellisen alueen mukaan rajatusti.

Kun WWW-palvelu tarjoaa kirjautuneelle tietyn maan kansalaiselle ja tiettyä kieltä puhuvalle käyttäjälle lokalisoituja palveluita, voidaan toisaalta todeta, että lokalisointi on osa palvelun personointia. Palvelu voi personoitua tietenkin myös käyttäjän muiden ominaisuuksien mukaan.

Tässä lopputyössä keskitytään globaalin verkkojärjestelmän kansainvälistämiseen ja lokalisointiin. Verkkojärjestelmällä tarkoitetaan järjestelmää, jonka käyttöliittymä esitetään WWW-sivuina internetissä. Tässä lopputyössä oletetaan, että järjestelmä kommunikoi käyttäjän kanssa HTTP-protokollalla (HyperText Transfer Protocol), jolla välitetään HTML-sivuja (HyperText Markup Language) selaimelle. Sivut voisivat olla myös esimerkiksi WAP-protokollalla (Wireless Application Protocol) siirrettäviä XHTML-sivuja (Extensible HyperText Markup Language), mutta koska HTML on internetissä eniten käytetty, lopputyössä keskitytään HTML-toteutuksiin.

Lopputyössä oletetaan, että verkkojärjestelmä tarjoaa dynaamista sisältöä ja kommunikoi selaimen lisäksi myös muiden viestintärajapintojen kanssa (esimerkiksi sähköposti ja tekstiviestit), joten suurin osa lopputyössä esiteltävistä ominaisuuksista ja ongelmista esiintyy vain sovelluspalvelimissa, vaikka useita lopputyön kohtia voi soveltaa suoraan web-palvelimienkin yhteydessä. Verkkojärjestelmään halutaan liittää usein myös tietokanta, jonka kanssa kommunikoiminen onnistuu sovelluspalvelimella.

Koska verkkojärjestelmän tulee olla globaali, pyrkii lopputyö tarkastelemaan kansainvälistämisominaisuuksia, joita tarvitaan toteutettaessa järjestelmää, joka on lokalisoitavissa kaikille maailman kielille ja kulttuureille. Koska työ on rajattu kansainvälistämiseen ja lokalisointiin, työssä ei yritetä kertoa verkkojärjestelmien perusteista. Työn lukijan tulee hallita perustiedot WWW-sivujen tekemisestä ja protokollista, joiden avulla verkkojärjestelmät kommunikoivat.

Lopputyön lukuihin on valittu aiheita, ongelmia ja ratkaisuja, joita kirjoittaja on kohdannut työskennellessään globaalien verkkojärjestelmien kanssa.

Luvussa 2 tutustutaan merkkeihin ja merkistöihin sekä niiden koodaamiseen. Kirjoitettava kieli on suurin ja eniten ongelmia aiheuttava lokalisoitava piirre, joten luku pyrkii antamaan ongelmatilanteiden selvittämisessä tarvittavat tavu- ja bittitason tiedot.

Luku 3 on jaettu kahteen osaan. Ensimmäisessä käydään läpi merkistömuunnoksia ja toisessa merkkijonojen vertailuun ja järjestämiseen liittyviä seikkoja. Selaimen ja palvelimen välisessä liikenteessä tapahtuvien muunnosten esittelyn yhteydessä sivutaan myös HTTP- ja HTML-määrittelyiden heikkouksia, jotka liittyvät siirrettävän tiedon merkistön määrittelyyn.

Luku 4 käsittelee selaimen ja palvelimen vuorovaikutuksen ja käyttäjäinteraktion seurauksena tapahtuvaa lokaalin valintaa. Luvussa 5 tarkastellaan lokalisoidun sisällön tallentamista ja esityskerroksen kansainvälistämistä.

Luku 6 esittelee kuvitteellisen järjestelmän, johon on koottu tyypillisimpiä todellisissa verkkojärjestelmissä olevia kansainvälistämiseen ja lokalisointiin liittyviä ominaisuuksia.

2 Merkistöt

Järjestelmän kansainvälistäminen ja lokalisointi vaikuttaa järjestelmän arkkitehtuuriin, rajapintojen suunnitteluun, käyttöliittymän suunnitteluun ja tietokantaan. Merkit ja merkistöt ovat läsnä miltei kaikissa lokalisoitavissa piirteissä ja perusedellytyksenä järjestelmien kansainvälistämiselle.

Tämä luku esittelee merkistöjen historiaa ja käyttötarkoituksia sekä verkkojärjestelmien käyttämiä merkistöjä ja tekstin koodaamista (encoding). Luku käsittelee myös tilanteita, joissa tarvitaan muunnoksia verkkojärjestelmän merkistöjen välillä. Lisäksi tutustutaan merkistöjen vertailuun.

2.1 Merkistöjen kehitys

Nykyaikaiset tietojärjestelmät käsittelevät tietoa kahdeksanbittisinä (8-bit) tavuina (byte). Järjestelmän muistissa olevat luvut, joiden on tarkoitus edustaa kirjoitettua tekstiä, on määritelty merkeiksi siten, että jokaista lukua vastaa yksi kirjain tai muu merkki (esim. 65 = A, 66 = B, 67 = C, jne.). Yksi merkki voi viedä tilaa yhden tai useamman tavun. Merkin käsite on selvä useimmissa kirjoitusjärjestelmissä. Isot ja pienet kirjaimet ovat erillisiä merkkejä, samoin kaikki välimerkit. Merkin käsitteeseen ei liity sen ulkonäkö (glyyfi), joka voi olla hyvinkin erilainen eri kirjasimilla.

Seuraavissa alakohdissa käsitellään nykyisten internetin verkkojärjestelmien kannalta oleellisia merkistöjä. Merkistöjen historiasta löytyy laajalti käytettyjä merkistöjä, jotka ovat kuitenkin olleet sellaisia, että niiden vaikutus ei näy enää nykyinternetissä. Lisäksi tämän lopputyön merkistöesittely painottuu länsimaissa käytettyihin merkistöihin.

2.1.1 ASCII ja ISO-646

Ensimmäiset merkistöt määriteltiin Yhdysvalloissa ja niillä saattoi tavallisesti kirjoittaa vain amerikanenglannin kirjaimia. Esimerkiksi suomen kielen skandinaavisia merkkejä niissä ei ollut. Yksi varhaisimmista ja laajimmalle levinneistä merkistöistä on vuonna 1968 julkaistu vieläkin laajalti käytössä oleva ASCII (American Standard Code for Information Interchange, standardoitiin nimellä ANSI X3.4), joka käyttää tiedon tallentamiseen seitsemää bittiä, joilla voidaan esittää 128 eri merkkiä. Kahdeksas bitti oli tarkoitettu virheenkorjaukseen. Kun jokainen iso ja pieni kirjain vie oman koodipaikkansa, samoin kuin välimerkit ja erilaiset kontrollimerkit, tähän merkistöön eivät mahdu edes tavallisimmat eurooppalaisten kielten merkit. [Czyb1998a]

Taulukko 1 esittää koodipisteet ASCII-merkistössä, jota kutsutaan myös 7-bittiseksi US‑ASCII-merkistöksi.

Taulukko 1 - ASCII merkistö [Czyb1998a]

Merkistön alkupuolella (taulukossa kaksi ensimmäistä riviä, joilla ei ole numerointia) ovat kontrollimerkit, joille ei ole visuaalista esitystä. Kontrollimerkkejä on käytetty kursorin ohjaamiseen, joten nykyaikana esimerkiksi HTML-sivujen koodissa [HTML401] nämä merkit tulkitaan vain välilyönneiksi.

Yhdysvaltojen ulkopuoliset standardoijat alkoivat määritellä kansallisia variaatioita 7-bittisestä US‑ASCII-merkistöstä sijoittamalla harvemmin ihmiskielissä tarvittujen merkkien tilalle kansallisia merkkejä. ASCII ja sen kansalliset variantit standardoitiin ISO‑646-standardiksi vuonna 1972.

Taulukko 2 - ISO-646-DE [Czyb1998a]

Taulukko 2 esittää saksan kielelle tarkoitetun ISO‑646‑DE-standardin mukaisen merkistön. Tilanteeseen sopiva merkistö valittiin terminaaliasetuksilla, joten esimerkiksi ISO‑646‑DE-merkistön päälle unohtuessa C-ohjelmoija sai ruudulleen

æ*argvÆ1Å='Ø0'å

odottamansa ohjelmakoodin {*argv[1]='\0'} sijaan.

2.1.2 ISO-8859-merkistöperhe

Merkistöjen kehittelyä jatkettiin Euroopassa. Koodaus laajennettiin käyttämään kahdeksaa bittiä, jolloin voitiin esittää 256 merkkiä. Tämäkään ei riittänyt kovin pitkälle, joten eri kielialueille tehtiin omat standardinsa. Ensimmäiset neljä laajennettua eurooppalaista merkistöä standardoitiin 1985. [Czyb1998b]

Merkistöjen eroista johtuu, että katseltaessa tekstitiedostoa, joka on tallennettu eri merkistöllä, osa merkeistä korvautuu toisilla ja tällöin tekstiä voi olla vaikea tai mahdoton ymmärtää. Tiedostoja voidaan muuntaa toisiin merkistöihin, mutta tällöin osa merkeistä voi hävitä, jos kohdemerkistössä ei ole käytössä samoja merkkejä kuin alkuperäisessä tekstissä. Kaikki ISO-8859-merkistöt ovat kuitenkin yhteensopivia ASCII-merkistön kanssa, joten esimerkiksi kirjaimet A - Z pysyvät samoina.

ISO-8859 on ryhmä ISO-standardointielimen määrittelemiä merkistöjä. Merkistöjen numerointi on juokseva, mutta se ei viittaa merkistöjen paremmuuteen tai laajuuteen. Merkistön koko nimi sisältää standardin nimen, juoksevan numeron ja hyväksymisvuoden, esimerkiksi: ISO/IEC 8859-15:1999.

ISO-8859-merkistöperheen historiaa:

· Länsi-Euroopalle kehitettiin ISO-8859-1 eli latin1, joka sisältää lähes kaikki länsieurooppalaisten kielten merkit. Siitä kuitenkin puuttuvat esimerkiksi suomessa lainasanoissa käytettävät Š ja Ž, ranskan Œ ja Ÿ ja katalaanin Ŀ. Tämä merkistö on usein oletuksena verkkojärjestelmissä (esimerkiksi [HTTP11], jos muuta ei ole määritelty).

· Itä-Euroopalle tehtiin ISO-8859-2 eli latin2. Tuetut kielet ovat: tšekki, unkari, romania, puola, kroatia, slovakki, sloveeni, serbia (latinalaisin aakkosin). Merkistössä saksan ja suomen tarvitsemat merkit, ”äöüß”, sijoitettiin samoihin paikkoihin kuin latin1:ssä, joten yhteensopivuus säilyi.

· Etelä-Euroopalle tehtiin ISO-8859-3 eli latin3, jolla kirjoitetaan yleisesti esperantoa sekä maltaa, aiemmin myös turkkia. Tämä merkistö on paljolti jäänyt pois käytöstä.

· Pohjois-Eurooppaan tehtiin ISO-8859-4 eli latin4, jolla voi kirjoittaa viroa, latviaa, liettuaa ja grönlantia.

· Kyrilliselle aakkostolle tehtiin ISO-8859-5, jolla voi kirjoittaa bulgariaa, venäjää, valkovenäjää, makedoniaa, serbiaa (kyrillisin aakkosin) sekä ukrainaa ennen vuoden 1990 oikeinkirjoituksen uudistusta. Tämä merkistö ei ole kuitenkaan saavuttanut merkittävää suosiota ja käytetympiä merkistöjä ovat KOI-8 muunnelmat [RFC1489] ja Windows-koodisivu 1251 (valmistajien omista merkistöistä vielä alakohdassa 2.1.3).

· Arabian kielelle kehitettiin ISO-8859-6, joka sisältää vain arabian perusaakkoston, eli sillä ei voi kirjoittaa persiaa tai urdua vaikka nämä käyttävätkin pääosin samoja kirjaimia kuin arabia.

· Kreikan kielelle (nykykreikka) kehitettiin ISO-8859-7.

· Heprean kielelle kehitettiin ISO-8859-8 (sisältää vain konsonanttimerkit).

· ISO-8859-9 eli latin5 on lähes sama kuin latin1, mutta tässä islannin merkit ”ðýþ” on korvattu turkkilaisilla kirjaimilla.

· ISO-8859-10 eli latin6 on uudelleenjärjestelty latin4, johon on otettu myös edellä mainitut islannin kirjaimet. Sitä voi käyttää Baltian kielten lisäksi joidenkin saamen kielten ja grönlannin kirjoittamiseen.

· ISO-8859-11 on tarkoitettu thain kirjoittamiseen.

· ISO-8859-12 on hylätty ehdotus, joka lopulta korvattiin ISO-8859-14:lla.

· ISO-8859-13 eli latin7 on parannettu balttilainen merkistö.

· ISO-8859-14 eli latin8 lisää loput gaelin ja Walesin kielten tarvitsemat kirjaimet latin1:een, jotta sillä voisi kirjoittaa kaikkia kelttiläisiä kieliä.

· ISO-8859-15 eli latin9 tai latin0 on muunneltu versio ISO‑8859‑1‑merkistöstä, josta on poistettu muutamia merkkejä ja niiden tilalle on laitettu pois jääneet ranskan ja suomen kielen kirjaimet. Valuuttamerkki ¤ on korvattu euron merkillä €.

· Uusin ISO-8859-16 on alun perin tehty romanian kielen oikeinkirjoitukseen, mutta soveltuu myös moniin Etelä- ja Itä-Euroopan kieliin ja sisältää lisäksi euron symbolin. Tällä merkistöllä voidaan kirjoittaa myös suomea, saksaa ja ranskaa, koska merkistöstä on tiputettu pois useita symboleja ja korvattu niitä kirjaimilla.

Uusia ehdotelmia ISO-8859-perheeseen ei ole enää käsittelyssä. Unicoden (käsitellään tarkemmin alakohdassa 2.2.1) toivotaan korvaavan hiljalleen muut merkistöt.

2.1.3 Valmistajien omat merkistöt

1980‑luvun alkupuolella länsimaiset järjestelmien valmistajat määrittelivät omia merkistöjään, koska US‑ASCII ja ISO‑646-merkistöt eivät riittäneet käytännön tarpeisiin ja koska standardoituja laajempia merkistöjä vielä odotettiin. Tuon ajan merkistöperinne on jäänyt elämään esimerkiksi Microsoftin DOS‑ ja Windows-merkistöperheiden sekä Applen Macintosh-merkistöjen muodossa myös tämän päivän Internetiin. Verkossa vastaantulevista valmistajien omista merkistöistä voidaan mainita ”macintosh” (saksa, ranska ja italia), ”windows-1252” (sisältää ISO‑8859‑1-merkistön), ”windows-1250” (esimerkiksi tšekki, slovenia, kroatia ja serbia), ”windows-1251” (venäjä, serbia ja makedonia) ja ”windows-850” (ranska ja saksa). [W3C2002]

2.1.4 Aasialaiset merkistöt

Aasialaiset teollisuusyritykset ja valtiot ovat perinteisesti standardoineet merkistöjä, jotka on tarkoitettu tietyn kielen tai tiettyjen kielten tukemiseen. Esimerkiksi japanissa on standardoitu yksitavuinen JIS X 0201, kaksitavuinen JIS X 208 ja näitä edelleen laajempi JIS X 0212‑1990. Merkistöjen samaan dokumenttiin koodaamiseksi kehitettiin Shift JIS. [JISX0201]

Thain virallinen merkistö on TIS 620 [TIS620]. Venäjänkielisillä sivuilla käytetään ISO‑8859‑5-standardin ja Microsoftin (Windows‑1251) merkistöjen lisäksi 8-bittistä KOI8‑R-merkistöä [RFC1489].

Taiwanin ja Hong Kongin virallinen merkistö on Big5 [RFC1922], joka määrittelee samalla myös merkistön koodauksen. Big5 ja sen Big5‑HKSCS-laajennus [HKSCS] on tarkoitettu perinteisen kiinan kielen (Traditional Chinese) prosessointiin ja tallentamiseen.

Yksinkertaistetun kiinan (Simplified Chinese) merkistönä on toiminut GB 2312. Tätä on laajentanut muuttuvamittainen (variable length) GBK-koodaus, jolla mukaan on saatu myös perinteisen kiinan merkkejä GB 13000 ‑merkistöstä. GB 13000 ‑standardi on kiinalainen versio ISO/IEC 10646 ‑standardista (esitellään kohdassa 2.2).

Vuonna 2000 julkaistiin GB 18030 ‑merkistö [Sche2001]. Merkistö on tarkoitettu Unicoden 3.0‑version kanssa yhteensovittamiseen ja merkistön tukeminen on nykyään vaatimuksena kiinalaisilla ohjelmistomarkkinoilla (enemmän alakohdassa 2.2.2).

Etenkin yksinkertaistetun kiinan, japanin ja korean kielen merkistöjä koodataan myös ISO/IEC 2022 ‑standardin [ISO2022] esittämällä tavalla. Koodaus määrittelee tavan vaihtaa merkistöä keskellä tekstiä, jolloin samaan asiakirjaan tai tekstivirtaan saadaan kerralla useampia merkistöjä. Paljon käytettyjä koodauksia ovat ISO‑2022‑JP ja EUC-JP (Extended Unix Code [EUC]), jotka koodaavat japanin kielen merkistöjä yhteen tavuvirtaan, sekä ISO‑2022‑KR ja EUC-KR, jotka tekevät saman koreankielisille koodauksille.

2.2 Unicode ja ISO/IEC 10646

Unicode Inc. kertoo sivuillaan [Unic2004a] Unicoden olevan koodattu merkistö, jonka määrittelyyn osallistuvat suurimmat pääosin yhdysvaltalaiset tietotekniikka-alan yritykset. Unicode on suorassa yhteydessä ISO/IEC 10646 -standardiin [ISO10646], jota kutsutaan myös nimellä ”Universal Multiple-Octet Coded Character Set” (UCS). Määrityksistä vastaavat komiteat pitävät standardit keskenään yhdenmukaisina. Kun toisen standardiin määritellään lisäyksiä, toinen laajentaa standardiaan samalla tavoin. Unicoden versio 4.0 vastaa jokaiselta koodipisteeltään ISO/IEC 10646:2003 -standardia. Versiot ovat jo laajalti tuettuja. Esimerkiksi Javan 1.5‑versio tukee Unicoden 4.0-versiota. [Java2005]

Unicoden siirtoon tarkoitetut koodausmuodot UTF‑8 ja UTF‑16 on määritelty liitteenä ISO/IEC 10646 -standardissa, jonka oma nelioktettinen siirtomuoto UCS‑4 vastaa koodipisteiltään suoraan Unicoden UTF‑32‑siirtomuotoa. Standardin UCS‑2-siirtomuoto ei vastaa suoraan Unicoden UTF‑16-siirtomuotoa, vaikka yhteys Unicoden koodipisteavaruuteen onkin olemassa. Koodipisteistä ja siirtomuodoista kerrotaan enemmän seuraavissa alakohdissa.

Koska Unicoden ja ISO/IEC 10646 ‑standardien ero on verkkojärjestelmän toteutuksen näkökulmasta lähinnä organisaatioihin liittyvä, keskitytään seuraavassa vain Unicoden ominaisuuksiin.

2.2.1 Koodipisteet

Unicode määrittelee yksikäsitteiset lukuarvot eli koodipisteet (code point) kaikille merkeille, joita esiintyy nykyään kirjoitetuissa kielissä. Mukaan mahtuvat esimerkiksi kaikki eurooppalaiset kielet, Lähi-idän oikealta vasemmalle kirjoitettavat kielet sekä suuri joukko aasialaisia kieliä. [Unic2004a]

Kullekin merkille on määritelty vain yksi koodipiste, joten esimerkiksi A-kirjain ei eroa koodipisteeltään, olipa se osana mitä kieltä tahansa. Lisäksi koodipisteet on määritelty erilaisille välimerkeille, treemoille (diaeresis), matemaattisille ja teknisille symboleille, nuolille, jne. Lisäämällä perusmerkin koodipisteen perään jonkin treeman koodipiste, saadaan perusmerkki ja treema yhdistettyä. Esimerkiksi yhdistämällä aaltoviiva (”~”) n-kirjaimeen, saadaan ñ-kirjain. Tarvittaessa treemoja voidaan yhdistää useampiakin yhteen perusmerkkiin.

Koodipisteitä merkitään heksadesimaalinumeroilla, joiden eteen on lisätty ”U+”. Esimerkiksi ison A-kirjaimen koodipiste on U+0041 ja euron merkin U+20AC.

Osasta merkkejä on olemassa valmiiksi yhdistetty versio. Esimerkiksi suomen kielessä esiintyvät Ä ja Ö löytyvät yksittäisinä koodipisteinään ensimmäisen 256 koodipisteen joukosta. Vanhan ISO‑8859‑1‑standardin kanssa yhteensopivuuden säilyttämiseksi Unicoden ensimmäiset koodipisteet vastaavatkin suoraan vanhan standardin koodipisteitä. Tämän lisäksi koodistoon on lisätty myös muita yhteensopivuuden takaavia alueita, jotta integrointi olemassa oleviin järjestelmiin sujuisi kitkattomammin.

Unicode määrittelee myös tekstin siirtomuotoja (Unicode transformation format, UTF), jotka esitellään alakohdassa 2.2.3, sekä vertailu- ja järjestämisalgoritmeja (collation), joita käsitellään enemmän alakohdassa 3.2.4. Lisäksi Unicode määrittelee kaksisuuntaisen (bi-directional) tekstin esittämiseen algoritmin, jota tarvitaan oikealta vasemmalle kirjoitettavien kielien näyttämiseksi selaimessa. Kaksisuuntaisesta tekstistä HTML-kielessä kerrotaan enemmän sivujen esittämiseen keskittyneen luvun alakohdassa 5.3.5.

2.2.2 Basic multilingual plane (BMP) ja supplementary characters

Unicode suunniteltiin alun perin 16-bittiseksi merkkikoodaukseksi, johon esimerkiksi Java-kielen char-perustietotyypin määrittelyssä nojauduttiin suoraan. Pian kuitenkin huomattiin, että 16 bitin mahdollistama 65536 koodipistettä on liian vähän maapallon kaikkien kielten merkkien osoittamiseen ja Unicode-standardia laajennettiin siten, että noin miljoonan merkin osoittaminen tuli mahdolliseksi. [LiOk2004]

Suurin osa maailmalla yleisesti käytössä olevista merkeistä on koodattuna ensimmäisen 65536 koodipisteen avulla. Näiden koodipisteiden joukkoa kutsutaan nimellä basic multilingual plane, joka lyhennetään BMP. Noin 6300 BMP-alueella olevaa ja 870000 BMP-alueen ulkopuolella olevaa koodipistettä on varattu tulevaisuuden merkistölaajennuksiin. ISO/IEC 10646 -standardin UCS‑2 vastaa Unicoden BMP-alueen koodipisteitä. [Unic2004a]

BMP-alueen 16 bitin rajan yli menevät merkit on nimetty englannin kielen termillä supplementary characters. Unicoden versio 2.0 esitteli tämän uuden käsitteen, mutta vasta versio 3.1 sisälsi ensimmäiset käsitteen määrittelemät merkit koodipisteineen. Laajennusosalle on todellinen tarve esimerkiksi Kiinan valtionhallinnon sovelluksissa, jotta kielessä harvemmin esiintyvät nimet saadaan esitettyä oikein. Unicoden versio 3.1 oli päivitys, jolla standardiin lisättiin kiinalaisen GB 18030-standardin merkit. Merkkejä on noin 69000. Kiina vaatii lakisääteisesti tuen GB18030-koodipisteille kaikkiin Kiinassa julkaistaviin sovelluksiin [Sche2001]. Laajennusosan ollessa käytössä voidaan viitata koodipisteisiin U+0000…U+10FFFF. Unicode 4.0 on käyttänyt 96 382 koodipistettä, joten tilaa laajennuksille on vielä olemassa. [LiOk2004]

Unicode-standardissa on varattu koodipisteitä myös yksityiskäyttöön. Järjestelmien ja sovellusten toimittajat voivat käyttää kyseisiä koodipisteitä toteutuksissaan sisäisesti. Unicode-standardi takaa, että yksityiskäyttöön tarkoitettuja koodipisteitä ei tulevaisuuden versioissakaan määritellä yleiseen käyttöön. BMP‑alueelta löytyy 6400 koodipisteen yksityinen alue ja sen ulkopuolelta 131068 koodipisteen alue. [Unic2004a]

2.2.3 Siirtomuodot

Koodipisteiden siirtomuodon ymmärtäminen on tärkeää verkkojärjestelmän merkistöongelmien selvitystyössä. Kun verkkoliikenteessä tai verkkojärjestelmän sivulla esiintyvän tekstin epäillään olevan jotain muuta kuin sen pitäisi olla, on tärkeää ymmärtää eri merkistöjen siirtomuotojen tavurakenne. Tässä alakohdassa esitellään [Unic2004b] mukaisien siirtomuotojen ominaisuuksia ja tavurakenteita.

Unicode-standardi tukee kolmea siirtomuotoa (Unicode transformation format): UTF‑32, UTF‑16 ja UTF‑8. Siirtomuodoilla pystytään koodaamaan alueet U+0000…U+D7FF ja U+E000…U+10FFFF, joiden väliin jäävä alue on tarkoitettu UTF‑16-muodon toteuttamiseen. Väliin jäävää aluetta nimitetään surrogaattialueeksi (surrogate range).

Siirtomuodot soveltuvat eri tarkoituksiin. Ensimmäisenä esiteltävä UTF‑32 on rakenteeltaan staattinen ja soveltuu siksi esimerkiksi suoraan muistiviittaamiseen, joka on operaationa erittäin nopea. Toisena esiteltävä UTF‑16 on kompromissi rakenteen staattisuuden ja tilantarpeen väliltä. UTF-16 toimii usein järjestelmien sisäisenä koodauksena, koska sen 16 bitin rakenne ei vaadi yhtä paljon muistia kuin UTF-32-koodaus. Yksi syy UTF‑16‑koodauksen olemassa oloon on myös se, että vanhojen 16‑bittisten järjestelmien muuntaminen käyttämään Unicodea onnistuu helpoiten UTF‑16-koodauksen avulla. Lopuksi esiteltävä UTF‑8 sopii parhaiten Internetin tiedonsiirtoon. HTTP‑protokollassa ja HTML‑kielessä usein esiintyvät US‑ASCII ja ISO‑8859‑1-merkit, jotka löytyvät Unicoden koodipisteiden alkupäästä, siirtyvät yhdellä ja kahdella tavulla.

UTF‑32 siirtää koodipisteiden numeroarvoja vastaavia nelitavuisia lukuja. Surrogaattialueen arvot ovat laittomia. ISO/IEC 10646 -standardin UCS‑4‑koodaus on ollut virallisesti synonyymi UTF-32-koodaukselle Unicoden versiosta 4.0 alkaen. Koodipisteen arvon sijoittuminen UTF‑32-sanoihin on esitettynä taulukossa 3.

Taulukko 3 - UTF-32-koodaus

Unicode‑koodipisteen bitit

(ja koodipistealueet)

1. sana

2. sana

0000zzzz yyyyyyyy xxxxxxxx

(U+0800…U+D7FF

ja U+E000…U+10FFFF)

00000000 0000zzzz

yyyyyyyy xxxxxxxx

UTF‑16-koodaus esittää alueiden U+0000…U+D7FF ja U+E000…U+FFFF koodipisteet suoraan koodipistettä vastaavalla sanan (word, 16 bittiä) mittaisella bittijonolla. UTF‑16‑koodaukselle varattua koodialuetta U+D800…U+DFFF käytetään, kun halutaan osoittaa koodipisteisiin, jotka ovat suurempia kuin U+FFFF. Alue on jaettu kahteen osaan, joiden nimet ovat high-surrogates range (U+D800…U+DBFF, ylempi surrogaattialue) ja low-surrogates range (U+DC00…U+DFFF, alempi surrogaattialue). Kummallakin alueella voidaan esittää 1024 eri arvoa, joten alueet yhdistämällä voidaan osoittaa 2²⁰ eri arvoon. Jos tähän lasketaan vielä mukaan surrogaattialueen ulkopuoliset merkit, saadaan koodipisteitä tarkalleen 1 112 064 merkille. Koodipisteen arvon sijoittuminen UTF‑16-sanoihin on esitettynä taulukossa 4.

Taulukko 4 - UTF-16-koodaus, jossa wwww = uuuuu - 1

Unicode‑koodipisteen bitit

(ja koodipistealueet)

1. sana

2. sana

xxxxxxxxxxxxxxxx

(U+0000…U+D7FF

ja U+E000…U+FFFF)

xxxxxxxxxxxxxxxx

000uuuuuyyyyyyxxxxxxxxxx

(U+10000…U+10FFFF)

110110wwwwyyyyyy

110111xxxxxxxxxx

Erona tavalliseen koodinvaihtomerkintään (escaping) UTF‑16-koodauksen surrogaateissa on se, että surrogaattialueen yksittäisiä sanoja ei käytetä alueen ulkopuolisten merkkien koodaamiseen. Jos UTF‑16-tietovirrasta otetaan yksi sana sattumanvaraisesti, voidaan siitä heti sanoa, onko se surrogaatti. Jos sana on surrogaatti, voidaan kuudenneksi eniten merkitsevän bitin perusteella todeta, onko kyseessä ylemmän vai alemman surrogaattialueen sana.

Koska Java API 1.5‑versio tukee Unicoden 4.0‑versiota, on alkuperäinen char-tyypin merkitys muuttunut. Aiemmin char-tyyppinen muuttuja viittasi suoraan Unicoden BMP-alueen koodipisteeseen, mutta nykyään char viittaa UTF‑16-koodatun koodipisteen sanaan tai surrogaattisanoihin. Tämän lisäksi API-kirjastoja on jouduttu päivittämään esimerkiksi merkkijonon oikean pituuden selvittämisen mahdollistamiseksi [Java2005].

UTF‑8-koodaus on suunniteltu Internetin US‑ASCII-merkistön yleisyys mielessä. Koodaus siirtää Unicoden koodipisteavaruuden alussa olevat 128 koodipistearvoa sellaisenaan yhdessä tavussa. Tavun eniten merkitsevä bitti on aina nolla. Muut koodipisteet esitetään 2‑4 tavulla, joista jokaisen eniten merkitsevä bitti on aina ykkönen. Jos ensimmäisen tavun bittijono alkaa ”110”, on koodipiste esitetty kahdella tavulla. Jos jono alkaa ”1110”, on esitys kolmitavuinen. Jonon alkaessa ”11110”, koodipiste on esitetty neljällä tavulla. Monitavuisten esityksien muut tavut alkavat aina biteillä ”10”. Koodipisteen arvon sijoittuminen jäljelle jääviin bitteihin näkyy taulukossa 5 eri koodipistealueiden tapauksissa. Surrogaattialueeseen viittaaminen on laitonta.

Taulukko 5 - UTF-8-koodaus

Unicode‑koodipisteen bitit (ja koodipistealueet)	1. tavu	2. tavu	3. tavu	4. tavu
00000000 0xxxxxxx (U+0000…U+007F)	0xxxxxxx
00000yyy yyxxxxxx (U+0100…U+07FF)	110yyyyy	10xxxxxx
zzzzyyyy yyxxxxxx (U+0800…U+D7FF ja U+E000…U+FFFF)	1110zzzz	10yyyyyy	10xxxxxx
000uuuuu zzzzyyyy yyxxxxxx (U+10000…U+10FFFF)	11110uuu	10uuzzzz	10yyyyyy	10xxxxxx

UTF‑8-koodauksesta on olemassa versio nimeltä Modified UTF-8. Java Virtual Machine sekä Javan java.io.DataInput ja DataOutput-rajapinnat käyttävät tätä muunneltua versiota [LiOk2004]. Erona standardinmukaiseen koodaukseen on ennen UTF‑8-koodauksen muodostamista tapahtuva BMP-alueen ulkopuolisten koodipisteiden esittäminen surrogaatteina. Tämän seurauksena Modified UTF‑8 tarvitsee maksimissaan kuusi tavua tilaa yhtä U+FFFF‑koodin ylittävää koodipistettä kohti. Lisäksi U+0000 esitetään aidosta UTF‑8‑koodauksesta poiketen tavuparina 0xC0 0x80.

2.2.4 Siirtomuotojen tavujärjestys

Unicode määrittelee siirtomuotojen tavurakenteille myös vaihtoehtoisia tavujärjestyksiä [Unic2004b]. UTF‑8-koodaus voi olla vain yhdessä järjestyksessä, mutta UTF‑16‑ ja UTF‑32-koodaukset voidaan järjestää joko little-endian‑ tai big-endian-muotoon. Muodoista ensimmäinen tarkoittaa järjestystä, jossa koodipistettä (tai surrogaattia) edustavan UTF‑16-sanan tai UTF‑32-kaksoissanan (double word, 32 bittiä) vähiten merkitsevä tavu kirjoitetaan ensimmäisenä ja eniten merkitsevä jälkimmäisenä. Muodoista jälkimmäinen kirjoittaa tavut päinvastaisessa järjestyksessä. Käsitteenä little-endian tarkoittaa [Lexi2005] määritelmän mukaan ”little-end-first” ja big-endian tulkitaan ”big-end-first”.

Siirtomuodon ja tavujärjestyksen voi ilmaista tavumerkinnällä, jota Unicode-standardissa kutsutaan nimellä byte order mark (BOM). BOM-tavut kirjoitetaan UTF-koodatun tietovirran alkuun. Tavuista esimerkiksi tekstieditorit voivat päätellä, missä koodauksessa teksti on tallennettuna. UTF‑8-koodauksen tunnistamiseen ei periaatteessa ja useassa tapauksessa edes käytännössä tarvita BOM-tavua, mutta sellainen on kuitenkin olemassa. Taulukko 6 esittää tavut eri koodauksille. Jos BOM-tavuja ei ole tavuvirran alussa, oletetaan koodauksen olevan big-endian-muodossa.

Taulukko 6 - UTF byte order mark

UTF-koodaus ja haluttu tavujärjestys	BOM-tavut (byte order mark)
UTF-8	EF BB BF
UTF-16 big-endian	FE FF
UTF-16 little-endian	FF FE
UTF-32 big-endian	00 00 FE FF
UTF-32 little-endian	FF FE 00 00

2.2.5 Unicode-kritiikki

Länsimaalaisesta näkökulmasta verkkojärjestelmän toteuttaminen Unicode-standardin mukaisesti tuntuu luontevalta. Etenkin itäisessä Aasiassa suhtaudutaan Unicodeen kuitenkin kriittisemmin, koska standardin heikot puolet tulevat herkemmin siellä esille. [Topp2001]

Unicoden kiinan, japanin, vietnamin ja korean kielen Han-merkkien yhdenmukaistamista (Han Unification) kritisoidaan paljon. Unicodessa on yhdistetty viimeksi Han-dynastian aikaan samanlaisessa ulkoasussa esiintyneet merkit (han characters) nyt samoiksi, vaikka eri kielissä merkkien ulkoasut poikkeavatkin toisistaan paljon. Yhdistäminen on tehty, koska Unicoden ideaan kuuluu, että koodipisteet edustavat abstrakteja merkkejä eivätkä niiden glyyfejä. Väärinkäsityksiä syntyy, kun tekstiä esittävälle sovellukselle (esimerkiksi selain) ei kerrota, mistä kielestä on kyse, tai kun esittävä sovellus ei muuten osaa piirtää abstraktia merkkiä oikein kielelle, jota merkillä on yritetty esittää. Perinteisesti Aasialaiset merkistöt ovat tarkoitettu vain tietyn kielen esittämiseen, joten erillistä piirtämistä ohjaavaa kielen määrittelyä ei ole tarvittu.

Osa Han-merkkien yhdenmukaistamisen vastustuksesta on kulttuurista lähtevää. Ajatellaan, että Unicode yhdistää merkkien lisäksi kielet. Itäisen Aasian kulttuureissa kirjoitusjärjestelmän ulkoasun suhde kulttuuriin ja kieleen on huomattavasti tiiviimpi kuin länsimaissa.

Ongelmia aiheuttaa Unicode-merkistön staattisuus. Merkistöön ei voi lisätä ”lennosta” uusia merkkejä, joita tarvittaisiin esimerkiksi uusien japanilaisten henkilöiden nimien esittämiseen. Ratkaisuna on Unicoden yksityisten koodialueiden (private use area) käyttö, joka vaatii kuitenkin järjestelmien välistä jatkuvaa synkronointia, jos tarkoitukseen varattuja koodipisteitä halutaan käyttää yli järjestelmärajojen.

Myös indeksointi ja järjestäminen aiheuttavat ongelmia Han-merkkien yhteydessä ja lisäksi arabian kielen kaksisuuntaisuuden (tähän palataan alakohdassa 5.3.5) koetaan sisältävän heikkouksia.

Aasialaisiksi kilpailijoiksi Unicodelle luetellaan Giga Character Set (GCS), TRON ja UTF-2000, jotka kaikki lähestyvät merkistön rakentamista Han-merkkien näkökulmasta.

2.3 Tekstiviestit

Matkapuhelinaikakaudella verkkojärjestelmät rakennetaan usein lähettämään ja vastaanottamaan tekstiviestejä. Tekstiviesteillä lähetettävät tervehdykset tai salasanamuistutukset voivat kuulua uuden käyttäjän rekisteröintiprosessiin tai niitä voidaan käyttää verkkojärjestelmän tarjoamien matkapuhelimien soittoäänien tai operaattorilogojen ostamiseen. Matkapuhelimissa on oma ETSI GSM 03.38 -standardissa [GSM0338] esitetty perusmerkistönsä (7-bit GSM default alphabet) ja jos sen merkit eivät riitä, voidaan viesti lähettää UCS-2 merkeillä (esiteltiin kohdassa 2.2). Perusmerkistö ja UCS-2 ovat yleisesti tuettuja ja lisäksi puhelinvalmistajat ja verkot tukevat suurta joukkoa merkistöjä kansallisiin tarpeisiin. Usein esimerkiksi osaa ISO-8859-merkistöperheestä tuetaan. Globaalia järjestelmää rakennettaessa kannattaakin harkita, halutaanko merkistövalinta tehdä operaattorista ja puhelinmallista riippuvaiseksi, jolloin viestiin saadaan enemmän merkkejä, mutta valintaan tarvitaan tietenkin tieto kaikista operaattoreiden ja puhelinmallien tukemista merkistöistä. Toinen äärivaihtoehto on käyttää vain standardin perusmerkistöä ja UCS-2:ta, jolloin merkistönvalinnasta tulee suoraviivaista ja merkistöt ovat tuettuja. Usein joudutaan toteuttamaan näiden välimuoto.

Taulukko 7 - ETSI GSM 03.38 perusmerkistö

Perusmerkistö ilman koodinvaihtomerkillä saatavia merkkejä on esitetty taulukossa 7. Merkistö on alakohdassa 2.1.1 esitellyn US-ASCII-merkistön muunnos, jossa osa kontrollimerkeistä on korvattu esimerkiksi skandinaavisilla merkeillä ja kreikan aakkosilla. Viestin lähettämiseen tarkoitetut ohjelmointirajapinnat saattavat tukea merkistömuunnoksen tekemistä, mutta rajapinnan käyttäjän tulee olla kuitenkin tietoinen, mitä merkkejä ei voi lähettää käytettävän merkistön rajallisuudesta johtuen.

Tekstiviestissä on rajoitettu määrä tilaa merkeille: Viesti tallennetaan 1120 bitillä. 7‑bittisen perusmerkistön käyttöön verrattuna (1120 / 7 = 160 merkkiä) tilaa jää alle puolet käytettäessä 16‑bittisiä UCS-2 merkkejä (1120 / 16 = 70 merkkiä), joten perusmerkistön käyttö on perusteltua jo pelkästään loppukäyttäjälle syntyvien kulujenkin takia. Viestiin mahtuvien merkkien määrän laskeminen perusmerkistön ja UCS-2:n tapauksessa on muuten suoraviivaista, mutta perusmerkistöstä löytyy myös koodinvaihtomerkki (0x1B, “ESCAPE TO EXTENSION TABLE”), jonka jälkeen tuleva tavu käsitetäänkin eri merkiksi kuin muussa tapauksessa. Koodinvaihtomerkin takia perusmerkistöllä kirjoitetun viestin pituuden selvittämiseksi onkin koko viesti käytävä läpi tavu kerrallaan. Muut tuettavat merkistöt (esim. ISO-8859-merkistöperhe) ovat usein 8-bittisiä.

Verkkojärjestelmän toteuttaja joutuu harvoin konstruoimaan tekstiviestiä itse. Viestin lähetykseen voidaan käyttää jotakin valmista rajapintaa, mutta viestin pituuden laskenta joudutaan kuitenkin toteuttamaan toisinaan esimerkiksi käyttöliittymätason tarpeisiin. UCS-2:n ja GSM perusmerkistön välinen tarkka yhteys on esitetty Unicoden sivuilla.

Jos järjestelmässä on valmiiksi tiedossa, että käytettävä merkistö sisältää esimerkiksi vain tietyn kielen merkit, voidaan viestin lähetys merkkien laskemisineen toteuttaa nojautuen ETSI-standardin perusmerkistön mukaan. Toisaalta nykyaikaiset verkkojärjestelmät tehdään käyttämään mielellään UCS-merkkejä, joten tarvittavan merkistön selvittämiseksi kannattaakin käyttää yleispätevää tapaa, jossa viesti käydään joka tapauksessa merkki kerrallaan läpi laskien merkkien määrä, laskien mahdolliset koodinvaihtomerkkiä tarvitsevat merkit ja tunnistetaan tilanne, jossa perusmerkistö ei riitä ja UCS-2:n käyttö on ainoa vaihtoehto. Tarvittaessa tällä tavoin rakennettu tapa voidaan laajentaa tukemaan myös muiden merkistöjen sopivuutta tekstiviestin lähettämiseen.

Tekstiviestien lisäksi matkapuhelimissa lähetetään tekstiä kuvaviestien mukana. Tekstin merkistö valitaan puhelinvalmistajan määrittelemän merkistön mukaan. Tässä lopputyössä asiaa ei tarkistella lähemmin.

2.4 Tekstin koodaus

Tässä kohdassa esitetään tapauksia, joissa merkistö joudutaan esittämään tavallisesta poikkeavassa tavumuodossa johtuen sovellusalueen rajoitteista. Lopuksi käsitellään ZIP-pakkauksen tiedostonnimiin liittyviä ongelmia, jotka johtuvat puutteellisesta tekstinkoodauksen määrittelystä.

2.4.1 Internationalized Resource Identifier, IRI

Internationalized Resource Identifier [IRI] on perinteisesti internetissä käytettyjen URI-elementtien [RFC2396] täydennys. IRI muodostuu UCS-pohjaisesta merkkijonosta, jolle on määritetty yhteys (mapping) URI:iin. Yli 7-bittiset merkit saadaan muunnoksella muotoon, jossa ne voidaan siirtää turvallisesti 7-bittisyyttä vaativiin paikkoihin.

Yhteys IRI:stä URI:ksi muodostetaan muuntamalla IRI ensin UTF-8 muotoon (siirtomuodot esiteltiin alakohdassa 2.2.3), jolloin esimerkiksi linkin

http://localhost/Päivitä.do

Ä-kirjaimet vievät kaksi tavua:

http://localhost/PÃ¤ivitÃ¤.do

Yllä oleva on UTF-8-koodauksen ilmentymä, kun tavut tulkitaan ISO-8859-1-merkistössä, jotta saadaan jonkinlainen esitys, jota ei tarvitse esittää pelkkänä heksadesimaalilukusarjana.

Tämän jälkeen linkkiin käytetään normaalia URI-elementtien koodinvaihtomerkintää (escaping)

http://localhost/P%C3%A4ivit%C3%A4.do

jolla jokainen koodipisteen arvoltaan yli 127 oleva merkki koodataan koodipisteen heksadesimaaliarvolla, jota edeltää prosenttimerkki.

Nykyään selaimet tukevat myös automaattista IRI-muunnosta. Jos esimerkin linkki valitaan HTML-sivulta, päästään suoraan oikeaan osoitteeseen käytettäessä vaikkapa Internet Explorer 6.0 tai Mozilla Firefox 1.0.4 -selaimia.

Kun linkeissä käytetään ASCII-merkistön ulkopuolisia merkkejä, tulee HTML-sivun tekijä kuitenkin tallentaa sivun sisältö muodossa, joka esitellään myös palvelimelle esimerkiksi palvelinkohtaisilla merkistöasetuksilla, ja palvelimen tulee lähettää sivun sisältö selaimelle samassa muodossa kuin sivu esitellään selaimelle HTTP‑protokollan otsikoilla (merkistöjä määrittelevistä HTTP-otsikoista enemmän alakohdissa 3.1.4 ja 3.1.5). Jos selaimelle kerrotaan, että sivu on esimerkiksi ISO‑8859‑1‑koodattu ja sivun linkit ovat UTF‑8‑tavuina HTML‑tiedostossa, lähettää selain käyttäjän klikkaamat linkit muodossa, jossa linkin UTF‑8‑tavut on virheellisesti tulkittu ISO‑8859‑1-tavuiksi ja tämän jälkeen linkki on koodattu IRI‑muunnoksella. Linkki on ikään kuin koodattu kaksi kertaa käyttäen UTF‑8‑muunnosta kuten taulukon 8 (sivu 23) ensimmäiseltä ja toiselta riviltä käy ilmi. Internet Explorerissa ominaisuus näkyy asetuksena, joka näkyy kuvassa 1.

Kuva 1 - Internet Explorer 6.0 -selaimen asetuksissa näkyvä IRI-tuki

Jos ominaisuuden kytkee pois päältä, lähtee esimerkin linkki kuitenkin oikeassa muodossa, jos selaimelle kerrotaan sivun olevan UTF-8-koodattu. Jos sivun esitellään olevan ISO‑8859‑1‑koodattu, selain lähettää sivulla todellisuudessa olevat UTF‑8‑tavut sellaisenaan eteenpäin.

Taulukko 8 esittää tulokset kahdella eri selaimella, kun vaihdetaan selaimelle kerrottua HTML-sivun merkistöä ja kytketään muunnos-ominaisuus päälle tai pois Internet Explorerissa. Mozilla Firefox ‑selaimesta Internet Explorer eroaa myös näyttämällä linkissä olevat Ä-kirjaimet ja muut merkit selaimen osoitevalintakentässä IRI‑koodaamattomassa muodossa. Tämä voi helpottaa ongelmatilanteen huomaamista, koska osoitevalintakentästä näkee, millaisena selain on tulkinnut linkin ilman koodauksia.

Taulukko 8 - Esimerkki URL‑koodauksesta eri olosuhteissa

Selain	Sivun merkistö	HTTP‑viesti vai käyttöliittymä	Muunnos päällä		Polku
Firefox 1.0.4	ISO-8859-1	HTTP	on	/P%C3%83%C2%A4ivit%C3%83%C2%A4.do
IE 6.0	ISO-8859-1	HTTP	on	/P%C3%83%C2%A4ivit%C3%83%C2%A4.do
IE 6.0	ISO-8859-1	HTTP	ei	/PÃ¤ivitÃ¤.do
IE 6.0	ISO-8859-1	käyttöliittymä	on	/PÃ¤ivitÃ¤.do
IE 6.0	ISO-8859-1	käyttöliittymä	ei	/PÃ¤ivitÃ¤.do
Firefox 1.0.4	UTF-8	HTTP	on	/P%C3%A4ivit%C3%A4.do
IE 6.0	UTF-8	HTTP	on	/P%C3%A4ivit%C3%A4.do
IE 6.0	UTF-8	HTTP	ei	/P%C3%A4ivit%C3%A4.do
IE 6.0	UTF-8	käyttöliittymä	on	/Päivitä.do
IE 6.0	UTF-8	käyttöliittymä	ei	/Päivitä.do

Vaikka aluksi viitattu IRI‑sivu antaa ymmärtää, että IRI on UTF‑8‑koodaukseen pohjautuvana monessa paikassa jo valmiiksi toimiva (esimerkiksi HTML 4.0), kannattaa edellä esitetyn vertailun tulosten takia ASCII‑merkistön ulkopuolisia merkkejä edelleen välttää linkeissä ja viittauksissa. Tämä ei johdu IRI-koodauksen toimimattomuudesta vaan siitä, että viittauksien ollessa ASCII-pohjaisia sivun yleinen muuntaminen merkistöstä toiseen on helpompaa ja selkeämpää, koska sivulle mahdollisesti kovakoodattuja linkkejä ei jouduta muuttamaan. Jos kuitenkin esimerkiksi käyttäjän antama hakusana joudutaan lähettämään HTTP GET ‑kutsussa, tulee pitää huoli siitä, että HTML-sivu on UTF‑8‑muodossa, jolloin Internet Explorerin selainasetuksen tapaiset asiat eivät pääse vaikuttamaan lopputulokseen. HTTP POST ‑kutsun käyttäminen haussa rikkoisi HTML-spesifikaation mainitsemaa idempotent‑suositusta [HTML401] kohdassa 17.13.1. Suosituksen mukaan lomake, jonka prosessoinnilla ei ole havaittavaa pysyvää vaikutusta, tulee lähettää palvelimelle HTTP GET -kutsulla. Tällä tavoin toteutettuna esimerkiksi hakutulos voidaan varastoida palvelimelle talteen odottamaan vastaavaa uutta hakua.

2.4.2 HTML-entiteetti

HTML-entiteetti (HTML entity) on rakenne, joka viittaa merkkiin. Rakennetta, joka on muotoa

&#xxxx;

käytetään, kun HTML-sivulle halutaan koodata merkki, joka ei kuulu HTML-koodin sisältävän tiedoston merkistökoodaukseen. Koodauksen xxxx on desimaaliluku, joka HTML 4.0 ‑määrityksen [HTML401] luvun 24 mukaisesti osoittaa UCS‑2-koodipisteeseen eli Unicoden BMP-alueelle.

Suurelle joukolle koodipisteitä on annettu lisäksi sanallinen muoto

&<entity>;

joten esimerkiksi Ñ‑kirjain voidaan esittää muodoissa

Ñ ja Ñ

2.4.3 ZIP-pakkaus ja kansainväliset tiedostonnimet

Internetissä suurempia tietomääriä liikutellaan mielellään pakatussa muodossa siirtoajan pienentämiseksi. Esimerkiksi HTTP 1.1 tukee kutsun ja vastauksen sisällön pakkaamista ([HTTP11] kohta 3.5).

Pakkaamista käytetään myös usean tiedoston kokoamiseen yhdeksi tiedostoksi, jolloin tiedostonnimet on koodattava pakettiin mukaan. Esimerkiksi useiden verkkojärjestelmien alustana olevan Javan JAR-koodikirjastot perustuvat suosittuun ZIP-pakkaukseen [ZIP], jonka käytön mahdollistava API on ollut Javassa versiosta 1.1 lähtien. [Java2005]

Ongelmaksi ZIP-pakkaamisessa muodostuu kuitenkin tiedostonnimien merkistökoodaus. ZIP-spesifikaatio ei määrittele käytettävää merkistöä, joten käytännöksi on muodostunut, että tiedostonnimet koodataan käyttöjärjestelmän tai ajoalustan merkistöllä. Jos käyttöjärjestelmänä on esimerkiksi Windows, ZIP-pakkauksen merkistö on joko CP437 (Windows Code Page 437) tai CP1252 (Windows Code Page 1252). Merkistöjä kutsutaan myös nimillä DOSLatinUS ja WinLatin1 [Czyb1998c].

Javan JAR-koodikirjastojen tapauksessa Sun ratkaisi merkistöongelman tallentamalla tiedostonnimet ZIP-pakettiin aina UTF‑8-koodauksella, jotta yhteensopivuus yli alustarajojen pystyttiin takaamaan ja koko Unicode-merkistö pystyttiin käyttämään tiedostonnimissä. Valitettavasti ratkaisu kuitenkin kirjoitettiin Java API ‑kirjaston yleiskäyttöisen java.util.zip-paketin luokkiin siten, että ohjelmoija ei voi halutessaan määritellä mitään muuta merkistökoodausta. Tästä syystä java.util.zip-paketin luokat ovatkin olleet käyttökelvottomia yleisien kansainvälisiä merkkejä sisältävien tiedostonnimien käsittelyyn. Kummalliseksi tilanteen tekee kuitenkin se, että vaikka ongelma on raportoitu Sunille jo vuonna 1999, sen evaluointi on tehty vasta vuonna 2005 ja korjausta odotellaan vieläkin.

Ongelman kuvaus ja historia löytyy Sun Developer Network -sivuston osoitteesta http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244499.

Kansainvälisen verkkojärjestelmän toteutuksessa ZIP-pakkauksen voi toteuttaa käyttämällä kolmansien osapuolien komponentteja. Esimerkiksi org.apache.commons.compress‑paketti tarjoaa mahdollisuuden tiedostonnimien merkistökoodauksen määrittelyyn [Jaka2005].

3 Merkistöoperaatiot

Tämä luku käsittelee tavallisimpia operaatioita, joita tarvitaan verkkojärjestelmien kansainvälistämisessä. Kohta 3.1 esittelee merkistömuunnokset ja kohta 3.2 merkkijonojen vertailun.

3.1 Merkistömuunnokset verkkojärjestelmässä

Koska merkistöt sisältävät hyvinkin erilaisia merkkejä, eivät muunnokset merkistöjen välillä onnistu aina ilman merkkien hukkaamista, sisällön uudelleen muotoilemista tai muita kompromisseja. Tavallisesti ohjelmakoodia kirjoitettaessa ja merkkijonoja käsiteltäessä ei tarvitse miettiä, mitä merkistöä ohjelmointikieli tai alla oleva käyttöjärjestelmä käyttää. Ohjelmointikielien tehtävänä on tarjota teksti mielellään abstraktina käsitteenä ohjelmoijalle, joka käsittelee tekstiä merkki kerrallaan sen sijaan, että hän joutuisi pohtimaan kunkin merkin käyttämiä tavumääriä, tavujärjestyksiä ja bittien sijoittelua tavun sisällä.

Järjestelmän toteuttajan kontrolloimia merkistömuutoksia tarvitaan tyypillisesti tiedostoja luettaessa ja tallennettaessa, sähköpostia tai tekstiviestejä lähetettäessä tai vastaanotettaessa tai kommunikoitaessa muussa rajapinnassa, joka on ohjelmointiympäristön näkökulmasta yhteydessä ulkopuoliseen maailmaan. Muunnos saatetaan määritellä ohjelmointi- tai viestintäalustan asetuksissa tai muunnoksen tekemiseksi voidaan tehdä myös tilanteeseen sopivaa ohjelmakoodia. Tietokantamigraatio, jossa vanhan tietokantarakenteen tietosisältö siirretään hallitusti uuteen tietokantarakenteeseen, voi vaatia myös merkistömuunnoksia ja lisäksi alakohdassa 3.2.6 mainittua merkkijonoindeksien kehittämistä.

3.1.1 Ohjelmointirajapinnat

Tavallisesti merkistön pääsee määrittelemään nykyaikaisissa ohjelmointikielissä, kun kommunikoidaan jonkin ulkopuolisen tietovirran (stream) kanssa.

Esimerkiksi Javan API on antanut jo versiosta 1.1 alkaen rakentajan [Java2005]

public InputStreamReader(InputStream in, String charsetName) throws UnsupportedEncodingException

jolla tietovirtaa voidaan tulkita valitun merkistön mukaan. Vastaavasti tietovirtaan kirjoitettaessa voidaan käyttää OutputStreamWriter-luokan sopivia rakentajia. Tuntemattoman merkistön nimi aiheuttaa poikkeuksen. Version 1.4 jälkeen on tullut myös käyttöön Charset-luokan instansseja parametrina käyttävä rajapinta, joka määrittää merkistön korkeammalla tasolla kuin pelkkänä merkistön nimenä. Rakentajassa voidaan käyttää myös CharsetDecoder-luokan instansseja, jolloin tavuvirta voidaan tulkita täysin räätälöidyllä tavalla merkistöksi ja päinvastoin.

Microsoftin .NET puolestaan määrittelee tietovirtojen luomiseksi vastaavanlaisia rakentajia StreamReader-luokalle. Rakentajat osaavat myös Unicoden siirtomuodon automaattisen tunnistamisen (UTF-8, UTF-16LE, UTF-16BE):

public StreamReader(Stream stream, Encoding encoding, bool detectEncodingFromByteOrderMarks);

Kansainvälistämisen kannalta oleelliset .NET-nimiavaruudet [Micr2005c] ovat System.Globalization, System.Resources ja System.Text.

Yksittäisten merkkijonojen luominen tavuista onnistuu Javalla käyttäen String-luokan kuormitettuja rakentajia ja tietyn merkistön mukaiset tavut saadaan getBytes-metodilla [Java2005]:

public String(byte[] bytes, String charsetName) throws UnsupportedEncodingException

public byte[] getBytes(String charsetName)

throws UnsupportedEncodingException

.NET muuntaa merkkijonoja Encoding-luokkaa apuna käyttäen. Esimerkiksi merkkijonon UTF-8 tavut saadaan generoitua seuraavasti alkuperäisen merkkijonon ollessa muuttujassa unicodeString:

UTF8Encoding utf8 = new UTF8Encoding();

Byte[] encodedBytes = utf8.GetBytes(unicodeString);

Microsoftin vanhempaa teknologiaa edustava ASP ei itsessään sisällä merkistömuunnoksiin tarvittavia välineitä. Muunnokset on tehty ulkopuolisilla komponenteilla.

3.1.2 Muunnos suppeampaan merkistöön

On tilanteita, joissa joudutaan tekemään muunnos laajemmasta merkistöstä suppeampaan. Tällöin hukataan harkitusti osa merkeistä, korvataan osa merkeistä toisilla tai muokataan koko sisältö suppeammalle merkistölle sopivammaksi. Muunnoksessa käytetään joko ohjelmointialustan valmiiksi tuntemia merkistöjä tai sitten toteutetaan oma algoritmi, joka suorittaa koodauksen muuntamisen.

Vaikka oltaisiin toteuttamassa globaalia verkkojärjestelmää, jossa järjestelmän merkistö on valittu kaikkien käyttäjien tarpeisiin, joudutaan vielä nykyäänkin harkitsemaan, olisiko sähköposti syytä muuntaa Unicode-merkistöstä käyttäjän kielen merkistöön, joka on esimerkiksi vain 8‑bittinen, mutta ollut perinteisesti käytössä kieltä lähetettäessä. Perinteisiä sähköpostimerkistöjä ovat olleet esimerkiksi ISO-8859-perheen merkistöt (Euroopassa), GB2312 (Chinese Simplified) ja windows-1256 (arabiankielisissä maissa). Sähköpostiohjelmista lähes kaikki tukevat kyllä UTF-8-merkistöä, mutta joskus esimerkiksi ohjelmien oletusasetukset estävät postin oikean tulkinnan. Jos kuitenkin tehdään oletus, että globaalin verkkojärjestelmän kaikki käyttäjät voivat ottaa Unicodea vastaan ja lukea sitä sujuvasti, joudutaan muunnoksia tekemään viimeistään silloin, kun järjestelmän tulisi puolestaan ottaa vastaan ja tulkita käyttäjältä tullutta sähköpostia.

Vastaan otetun sähköpostin tulkinnassa nojataan tietenkin postin Content‑Type-otsikoihin ja tätä tietoa voidaan käyttää myös postiin vastattaessa. Jos tietoa ei ole käytössä, voidaan käyttää kielelle tyypillistä sähköpostimerkistöä, joka on taulukoituna järjestelmän saataville. Merkistönvalintaperusteena voidaan käyttää käyttäjän valitsemaa lokaalia (luku 4).

Muunnos suppeampaan merkistöön voi tulla vastaan myös tiedostoon tallennuksessa, jos tiedostoa aiotaan käyttää toisaalla järjestelmässä, joka ei ymmärrä laajempaa merkistöä.

Muunnoksen voi toteuttaa esimerkiksi Java API ‑metodeilla, jotka esiteltiin alakohdassa 3.1.1:

String str = ”Help Öö, mitä tää tekee, 疑难解答”;

byte[] chineseSimplified = str.getBytes("GB2312");

httpServletResponseWriter.println(new String(chineseSimplified));

Muunnos Java-kielen sisäisestä UCS-2 koodauksesta tapahtuu onnistuneesti GB2312-muotoon yksinkertaistetun kiinan kielen merkkien (Chinese Simplified) ja ASCII-merkkien tapauksessa, mutta muuttujan str skandinaaviset merkit (”äöå”) korvautuvat kysymysmerkeillä:

Help ??, mit? t?? tekee, 疑难解答

Vastaavasti muunnos Pohjoismaille sopivaan ISO-8859-15-muotoon toteutetaan samalle merkkijonolle seuraavasti:

byte[] scandinavian = str.getBytes("ISO-8859-15");

httpServletResponseWriter.println(new String(scandinavian));

Tulokseksi saadaan merkkijono, jossa kiinankieliset merkit on korvattu kysymysmerkeillä:

Help Öö, mitä tää tekee, ????

Kysymysmerkkien ilmestyminen on Java API:n oletustoiminnallisuus String-luokassa. Jos on tiedossa, että muunnettavien merkkijonojen ei pitäisi sisältää muuntokelvottomia merkkejä järjestelmän normaalissa toiminnassa, ei oletustoiminnallisuutta tarvitse alkaa muuttamaan. Jos kuitenkin halutaan tehdä esimerkiksi ASCII-merkistöön muunnos, jossa skandinaaviset merkit korvataan niitä vastaavilla pisteettömillä kirjaimilla (”äöå”=>”aoa”) luettavuuden säilyttämiseksi, voidaan korvaaminen suorittaa ennen muunnosta.

Versiosta 1.4 lähtien mukana ollut CharsetEncoder-luokka [Java2005] antaa mahdollisuuden monipuolisempaan koodausvirhetilanteiden käsittelyyn ja omien koodauksien luomiseen. Vastaavat luokat löytyvät myös Microsoftin .NET:stä.

Tekstiviestien lähetyksessä käytettävä perusmerkistö ETSI / GSM 03.38 (esitelty kohdassa 2.3) ei ole tavallisesti ohjelmointialustojen tuntema, joten muunnoksen joutuu toteuttamaan itse tai muunnoksen tekemiseksi käytetään valmiiksi toteutettuja kirjastoja.

3.1.3 Muunnos laajempaan merkistöön

Muunnos laajempaan merkistöön on suoraviivainen ohjelmointialustojen tuntemien merkistöjen tapauksessa ja omien koodauksien ohjelmoiminen on myös mahdollista, kuten edellisessä alakohdassa jo todettiin. Esimerkiksi ASCII muuttuu aina ISO‑8859‑perheen merkistöiksi, jotka puolestaan muuttuvat aina Unicode-merkistöiksi, jotka taas voidaan koodata useammalla tavalla. Näitä muutoksia voidaan tarvita kaikissa ohjelmointialustan rajapinnoissa sekä esimerkiksi tietokantamigraatioissa.

3.1.4 Muunnos HTML-lomakkeen lähettämisen yhteydessä

Lähetettäessä HTML-lomaketta (FORM) selain joutuu mahdollisesti tekemään sisällölle joitain muunnoksia ja ainakin valitsemaan lähetyksessä käytettävän merkistön.

HTTP-kutsussa voidaan määritellä käytetty merkistö entiteettiotsikon (entity-header) Content-Type mukana ([HTTP11], kohta 14.7). Esimerkiksi:

Content-Type: application/x-www-form-urlencoded;charset=UTF-8

[HTML401] kohta 17.13.4 määrittelee lomakkeen lähettämiseen (FORM submission) kaksi mahdollista Content-Type-arvoa:

· application/x-www-form-urlencoded

· multipart/form-data

Arvo määritellään HTML-kielen FORM-tunnisteen (tag) enctype-attribuutilla ([HTML401], kohta 17.3) ja jokaisen selaimen tulee tukea molempia arvoja. Merkistön määrittelyyn käytettävästä osuudesta ei mainita mitään. Arvoista ensimmäisen todetaan olevan ”tehoton” siirtämään tekstiä, joka sisältää merkkejä ASCII-merkistön ulkopuolelta. Jälkimmäisen todetaan noudattavan sääntöjä, jotka on määritelty RFC 2045 -spesifikaation [RFC2045] mukaisesti MIME-tietovirroille.

Jokaisella multipart/form‑data‑osalla voi olla oma RFC 2045 -spesifikaation mukainen Content‑Type‑entiteettiotsikko, joka määrittää sisällön luonteen ja merkistön. Esimerkiksi:

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

Lukiessa HTML:n INPUT-tunnisteen määrittelyä [HTML401] kohdasta 17.4 voi todeta, että mahdollisuutta otsikon asettamiseen ei HTML:ssä kuitenkaan ole. Löytyy vain accept-attribuutti, joka on tarkoitettu sallittujen MIME-tyyppien määrittelemiseen tiedoston lähettämisessä. Vanhempi [RFC2070] vuodelta 1997 ehdottaa INPUT ja TEXTAREA‑tunnisteille ACCEPT‑CHARSET‑attribuuttia, jonka tarkoitus olisi ohjata selainta rajaamaan kenttiin syötettäviä merkkejä. Jo viitatusta vuoden 1999 HTML 4.01 määrittelystä tätä attribuuttia ei kuitenkaan löydy.

FORM-tunnisteen määrittelystä sen sijaan löytyy accept-charset-attribuutti, jolla voidaan esitellä selaimelle merkistöt, jotka palvelin hyväksyy juuri kyseessä olevaa lomaketta vastaan otettaessa ([HTML401], kohta 17.3). Samassa yhteydessä todetaan, että oletusarvon ”UNKNOWN” tapauksessa selain saa käyttää lomakkeen koodaamisessa merkistöä, jota käytettiin sivun vastaanottamisessa.

Jos attribuutin toimintaa kokeillaan käytännössä, saadaan tämän hetken tavallisimmilla selaimilla jonkin verran toisistaan eroavia tuloksia. Muodostetaan seuraavanlainen HTML-sivu:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>

<head>

</head>

<body>

</form>

</body>

</html>

Kun sivu avataan selaimeen, asettaa selain sivun merkistöksi ISO-8859-1:n ja näyttää lomakkeen ainoassa kentässä arvon ”Usernameääää” oikein. Lomakkeen koodissa on asetettu accept-charset=”utf-8”‑attribuutilla merkistö, jota selaimen tulisi hyödyntää kentän lähetyksessä. Kun lomake lähetetään, nähdään verkkoliikennettä tarkkailemalla, että Internet Explorer 6.0 luo HTTP-kutsun, jonka sisältö on:

POST /forum/Main.do HTTP/1.0

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,

Accept-Language: fi

Content-Type: multipart/form-data; boundary=---------------------------7d52c439170ffc

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Host: 192.168.0.100

Content-Length: 157

Connection: Keep-Alive

Pragma: no-cache

-----------------------------7d532431170ffc

Content-Disposition: form-data; name="userName"

Usernameääää

-----------------------------7d532431170ffc--

Vastaavasti Mozilla Firefox 1.0.4 luo kutsun:

POST /forum/Main.do HTTP/1.1

Host: 192.168.0.100

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fi-FI; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: fi,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: UTF-8,*

Keep-Alive: 300

Connection: keep-alive

Content-Type: multipart/form-data; boundary=---------------------------974127529778

Content-Length: 157

-----------------------------974127529778

Content-Disposition: form-data; name="userName"

UsernameÃ¤Ã¤Ã¤Ã¤

-----------------------------974127529778—

Todetaan kutsuista kokeilun kannalta oleelliset seikat:

1. Kumpikaan selaimista ei lisää MIME-osiin Content‑Disposition-otsikon jälkeen Content-Type-otsikkoa, jolla voisi määritellä merkistön, eikä kumpikaan selaimista kerro eksplisiittisesti käytettyä merkistöä missään muuallakaan.

2. Internet Explorer koodaa sisällön ISO-8859-1:llä.

3. Mozilla Firefox koodaa sisällön UTF-8:lla.

4. Mozilla Firefox ‑selaimen HTTP:n Accept-Charset-otsikko ei ole kokeilun kannalta oleellinen, koska kyse ei ole lomakkeen accept‑charset‑attribuutista; tulos oli sama vaihtamalla selaimen oletusmerkistöä.

Seikan 1. toteaa monien muiden tapaan esimerkiksi Mike Brown sivuillaan [Brow2001] esitellessään eri tapoja lähettää XML‑rakenteita HTTP-kutsuissa. Hän sanoo, että selaimet jättävät asettamatta sisällön tyypin, koska se on vakiintunut tapa eikä mistään standardista johtuva käytäntö.

Seikasta 2. voi todeta, että Internet Explorer ei valitse lähetysmerkistöä lomakkeen accept-charset-attribuutin perusteella ja seikasta 3., että Mozilla Firefox valitsee. Tämä oletus vahvistuu käännettäessä HTML-koodissa mainitut merkistöt toisin päin (dokumentin merkistöksi UTF-8 ja lomakkeen merkistöksi ISO-8859-1).

Jos lomakkeen kenttään annetaan kiinan kielen merkkejä, lähettävät molemmat selaimet kentän arvon samalla tavoin. Koodaus on UTF-8. Samoin käy myös, jos lomakkeella on kaksi eri kenttää, joista toiseen laitetaan skandinaavisia merkkejä ja toiseen kiinan kielen merkkejä. Lomakkeen accept‑charset=”utf‑8” attribuuttia tulkitaankin siis Internet Explorerin tapauksessa muodossa accept‑charset=”utf‑8, iso‑8859‑1”. Tämä ei ole välttämättä mikään ihme, koska [HTML401] 14.2 määrittelee Accept‑Charset-otsikosta: Jos otsikossa ei ole erityismerkkiä ”*”, tulee kaikille mainitsemattomille merkistöille ISO-8859-merkistöä lukuun ottamatta laatuarvoksi q=0. ISO‑8859‑1‑merkistö saa oletusarvon q=1, jos ei erikseen muuta mainita.

Internet Explorer pyrkii ilmeisesti valitsemaan sallituista merkistövaihtoehdoista tiiviimmän ja tässä tapauksessa se on implisiittisesti sallittu ISO-8859-1-merkistö.

Mozilla Firefox ei näytä tätä implisiittistä ISO-8859-1-määritystä ottavan huomioon. Kokeeksi voidaan kuitenkin määritellä

accept‑charset=”utf‑8, iso‑8859‑1;q=0”

joka siis ei toivo palvelimelle lähetettävän ISO-8859-1 koodausta. Tämän seurauksena, yllättävää kyllä, molemmat selaimet lähettävät arvon ”Usernameääää” ts. ISO‑8859‑1‑koodatun arvon. Vaikuttaisi siltä, että laatuarvoa q=0 ei huomioitaisi ollenkaan.

Jos lomakkeen accept-charset-otsikkoa ei aseteta ja HTML-dokumentin merkistöksi asetetaan UTF‑8, lähtee molempien selainten tapauksessa kaikilla sisältöyhdistelmillä (ASCII, skandinaaviset merkit ja kiinan kielen merkit) lomake myös UTF‑8‑koodauksessa. Kun HTML‑dokumentin merkistöksi valitaan ISO‑8859‑1, molemmat selaimet toimivat jälleen ennakoitavasti samalla tavoin ja lomake on ISO‑8859‑1 merkistön mukainen. Jos tämän suppean merkistön ollessa voimassa päätetäänkin kirjoittaa lomakkeen kenttään esimerkiksi kiinankielisiä merkkejä, muuntaa selain nämä merkit HTML-entiteetiksi (HTML entity, alakohta 2.4.2):

Lomakkeen kentän arvo:

Username疑难解答

HTTP POST -viestiin muunnettu arvo:

Username疑难解答

HTTP-viestiin tulee sama muunnettu arvo, jos käyttäjä syöttääkin merkit (kaikki tai osan merkeistä) lomakkeen kenttään valmiiksi käsin muunnettuna:

Username疑难解答

Tämän ei pitäisi aiheuttaa ongelmia käytännön tilanteessa, jos kyseessä on ihmiskieltä käsittelevä verkkojärjestelmä, mutta ominaisuudesta tulee olla tietoinen, jos on tarkoitus lähettää esimerkiksi HTML-entiteettejä ja -skriptiä sellaisenaan. Selaimen tekemä implisiittinen muunnos rikkoo alkuperäisen tiedon palautuskelvottomaksi.

Joka tapauksessa on tärkeää, että verkkojärjestelmää toteutettaessa ei oleteta, että esimerkiksi ISO‑8859‑1-koodatulla sivulla olevalta lomakkeelta tulee palvelimelle vain ISO‑8859‑1-merkistön merkkejä. Koska selaimet voivat koodata sivun merkistön ulkopuoliset merkit HTML‑entiteettejä käyttäen, voi joukossa olla mitä tahansa Unicode-merkistön merkkejä. Jos asianmukainen entiteettikoodauksen purkaminen jätetään toteuttamatta, voi esimerkiksi tietokantaan saakka joutua oikeelliselta näyttäviä ASCII‑merkkejä, jotka muodostavatkin todellisuudessa HTML-entiteetejä. Tällöin tietokantahaut ja järjestämisoperaatiot tuottavat täysin vääriä tuloksia.

Koska selaimet eivät liitä multipart/form-data-lomakkeenkaan tapauksessa kenttiin tai koko HTTP-viestiin mitään tietoa käytetyistä merkistöistä ja koska merkistö voi vaihdella tietosisällöstä sekä selainversioista ja -valmistajista riippuen, kannattaa tämän hetken selaintoteutuksille tarjota lomakkeet ilman merkistömäärityksiä ja HTML-sivun merkistöksi kannattaa määritellä palvelinpään olettama merkistö, joka valitaan mielellään UTF‑8‑koodaukseksi [Dürs2004].

Tulevaisuudessa XHTML 2.0 ‑määrityksen sisältämä XForms ratkaisee lomakkeen lähetyksen merkistöongelmat määrittelemällä siirtomerkistöksi Unicoden ja rakenteeksi XML:n, joten lomakkeen sisällön tulkitsemisessa tarvittava tieto on aina varmasti tiedon mukana. [XForms]

Koska selaimien ja palvelimien kehitys kulkee käytännössä toisiinsa sidottuna ja siksi kehitystä hidastaen, joudutaan XForm-rakenteita vielä kuitenkin odottamaan.

3.1.5 Muunnos HTML-lomaketta vastaanotettaessa

Jos merkistömääritys puuttuu, pitää palvelimen tehdä jokin oletus HTML-lomakkeen merkistöstä. Palvelimet kuten Microsoftin IIS / ASP.NET tai J2EE-pohjaiset IBM:n WebSphere ja BEA:n Weblogic antavat määritellä oletusmerkistön, jota käytetään kutsun sisällön tulkinnassa.

ASP.NET-verkkosovelluksen asetustiedostoissa voidaan antaa oletuksia kansainvälistämiseen liittyville attribuuteille. Asetukset on esitelty dokumentaatiossa seuraavasti [Micr2005b]:

<globalization

requestEncoding="any valid encoding string"

responseEncoding="any valid encoding string"

fileEncoding="any valid encoding string"

culture="any valid culture string"

uiCulture="any valid culture string"/>

Attribuutin requestEncoding selitys sanoo, että attribuutti määrittelee oletetun koodauksen kaikkien kutsujen HTTP POST -datalle (posted data) ja URI‑koodatuille muuttujille (the query string). Jos kutsussa on mukana Accept‑Charset-attribuutti, se kumoaa requestEncoding‑attribuutin asettaman arvon.

Tämä on ilmeisesti jonkinlainen arvaus, koska Accept‑Charset-otsikonhan on tarkoitus määritellä selaimelle mieluisimmat merkistöt, eikä selaimen lähettämän lomakkeen merkistöä. Lisäksi testattaessa selaimella (esim. Mozilla Firefox 1.0.4), joka lähettää otsikon, jäi requestEncoding-attribuutilla määritelty oletus kuitenkin voimaan. Jos hyväntahtoisesti olettaa, että selityksen Accept-Charset viittaa attribuuttiin lomakkeella, jolle on asetettu

enctype="multipart/form-data" accept-charset="utf-8"

on selityksessä enemmän järkeä, vaikkakin oletus jää edelleen voimaan selaimien tuen puuttuessa attribuutille kuten kohdassa 3.1.4 huomattiin. Tämä toivottavasti korjataan tai määritellään toisin seuraaviin versioihin.

J2EE-pohjaiset sovelluspalvelimet ottavat samankaltaisia määrittelyjä vastaan. Esimerkiksi WebSphere tarjoaa kuvassa 2 esitettyjä vaihtoehtoja.

Kuva 2 - WebSphere-sovelluspalvelimen tekemät merkistömuunnokset [IBM2005]

HTTP-kutsun käsittelyssä WebSphere‑palvelin käyttää merkistöä, joka valitaan käyttäen seuraavista ehdoista ensimmäisenä toteutuvaa [IBM2005]:

1. Jos löytyy Javan system property client.encoding.override (vastaa ASP.NET-asetuksia requestEncoding ja responseEncoding), käytetään sitä.

2. Jos selaimen kutsussa on toimitettu lomakkeen merkistö, käytetään sitä. Kuten alakohdassa 3.1.4 todettiin, toteutuu tämä harvoin, jos ollenkaan.

3. Jos selaimen kutsussa on toimitettu Accept-Language otsikko, etsitään sen suositteleman kielen perusteella encoding.properties-tiedostosta kielelle oletusmerkistö ja käytetään sitä. Tämän käyttäminen on tosin ristiriidassa otsikon oikean käyttötarkoituksen kanssa samaan tapaan kuin edellä esitelty Accept-Charset‑otsikon käyttö ASP.NET-alustan tapauksessa.

4. Jos löytyy Javan system property default.client.encoding, käytetään sitä.

5. Valitaan HTML:n oletusmerkistö eli ISO‑8859‑1.

WebSphere 5.0:n tapauksessa määritykset 1. ja 3. ovat oletuksena pois päältä, jotta sovelluspalvelimen oletustoiminta olisi yhteensopiva muiden J2EE-sovelluspalvelimien kanssa.

Sovelluspalvelimien yleisten asetusten lisäksi HTML-lomakkeen merkistön selvittämiseen löytyy myös ohjelmakirjastoja, joita käyttämällä sovelluksen toteuttaja voi vaikuttaa merkistön selvittämiseen. JavaServer Pages Standard Tag Library (JSTL) esittelee lomakkeen vastaanotossa käytettävän <fmt:requestEncoding>-tunnisteen (tag), joka osaa hakea palvelimen istunnosta (session) tiedon merkistöstä, jota on käytetty HTML-sivulla, joka esitteli lomakkeen selaimelle. Palvelinpäähän luodaan siis kirjanpito kulloinkin käytössä olevasta merkistöstä. [Java2005]

3.2 Merkkijonojen vertailu ja järjestäminen

Vertailulla tarkoitetaan tietotekniikassa prosessia tai algoritmia, jolla kirjoitetulle informaatiolle saadaan määritettyä järjestys vakioidulla tavalla. Englanninkielisessä tekstissä käytetään termiä collation (tutkiminen), joka ei suoraan suomennettuna liity vertailuun. Yleiskielen ”aakkostaminen” on lähellä vertailua, mutta tietotekniikassa joudutaan järjestämään myös esimerkiksi numeroita ja erikoismerkkejä (esimerkiksi kysymysmerkki, piste, sulkeet). Vertailtava teksti voi olla kielen yleisiä sanoja tai erisnimiä. Vertailua tarvitaan lähes kaikkialla tietojärjestelmien käyttöliittymissä ja tietokannoissa, missä teksti joudutaan esittämään käyttäjän ymmärtämässä ja käyttäjälle intuitiivisessa järjestyksessä.

Vertailu toimii osana järjestämisalgoritmia (sorting algorithm) määrittäen kahden järjestettävän alkion osittaisen järjestyksen (partial order), jonka mukaan päätetään, tulisiko alkioiden paikat vaihtaa keskenään järjestyksen saavuttamiseksi.

Tässä kohdassa esitellään järjestelmän kansainvälistämisen vaikutusta merkkijonojen vertailuun ja järjestämiseen. Kohdan teksti perustuu pääosin lähteisiin [WORD2005] ja [UTS10].

3.2.1 Kielen, kulttuurin ja käyttötarkoituksen vaikutus järjestämiseen

Järjestäminen ihmiselle intuitiiviseen muotoon ei ole suoraviivaista. Haluttu järjestys voi riippua kielestä, maasta, kulttuurista ja jopa järjestystuloksen käyttötarkoituksesta.

Taulukko 9 - Esimerkkejä erilaisista vertailuista [UTS10]

Kielen määräämä järjestys		Käyttötarkoituksen mukainen järjestys		Teknisen merkityksen mukainen järjestäminen
Ruotsi	Saksa	Sanakirja	Puhelinluettelo	Java-luokat ensin	Java-metodit ensin
z < ö	ö < z	öf < of	of < öf	A < a	a < A

Taulukko 9 listaa esimerkkejä erilaisista vertailuista. Ensimmäisenä esitetään kielelle ominaisen järjestämistavan vaikutus (linguistic tailoring). Toisena esimerkkinä on järjestettävän tekstin käyttötapaan liittyvä eroavaisuus: nimien järjestäminen puhelinluetteloon eroaa useissa kulttuureissa siitä järjestyksestä, jota käytetään sanakirjoissa tai henkilöluetteloissa. Taulukon kolmantena esimerkkinä on tekniseen tarkoitukseen räätälöity järjestäminen, jossa Java-koodissa esiintyvien luokkien ja metodien nimien halutaan listata samaan listaan. Java-koodin luokan nimet kirjoitetaan tyypillisesti isolla alkukirjaimella ja metodin nimet pienellä alkukirjaimella.

Kielet, joiden kirjoitusjärjestelmissä käytetään suuria ja pieniä kirjaimia, jättävät huomiotta kirjainkoon ellei se ole ainoa sanojen erottelutapa. Tavallisesti nämä kielet käsittelevät samalla tavoin myös treemoja (diaeresis), joten esimerkiksi saksan kielessä Ä- ja Ã-kirjain järjestetään A-kirjaimen jälkeen ennen B-kirjainta.

Taulukko 10 - Aksenttien järjestäminen ranskan kielessä [UTS10]

Normaali aksenttien järjestys	Ranskan kielen aksenttien järjestys
cote < coté < côte < côté	cote < côte < coté < côté

Poikkeuksen tavalliseen treemojen järjestämiseen tekee ranskan kieli, jonka aksentit vaikuttavat enemmän sanan lopussa kuin alussa. Taulukosta 10 nähdään, kuinka esimerkiksi côte-sana tulee ranskankielisessä järjestyksessä ennen coté-sanaa.

Erikielisten sanastojen järjestäminen poikkeaa toisistaan myös merkkitasolla. Esimerkiksi saksan kielen Ä-kirjain (”A umlaut”) voidaan käsitellä järjestämisen yhteydessä A- ja E-kirjaimien yhdistelmäksi (”AE”) tai A-kirjaimeksi, johon on vain lisätty treema. AE-tulkinnan seurauksena Ä-kirjaimella alkavat sanat järjestetään AE-alkuisten sanojen jälkeen ja jos Ä tulkitaan treemalliseksi A-kirjaimeksi, järjestetään se heti A-kirjaimen jälkeen. Suomen ja ruotsin kielissä Ä-kirjainta käsitellään aakkoston yhtenä kirjaimena ja järjestyksessä Ä tulee vasta Z-kirjaimen jälkeen.

Vertailtavan alkion merkkitasolla voi muodostaa myös digrafia (digraph, kahden merkin yhdistelmä, etenkin sellainen, joka tarkoittaa yhtä äännettä eli kaksoiskirjainta). Esimerkiksi slovakin kielessä ch järjestetään heti C-kirjaimen jälkeen yksittäisen kirjaimen tapaan.

Itä-Aasian kielissä käytettävät merkit voidaan järjestää joko merkin glyyfin mukaan tai foneettisesti. Glyyfin mukaan järjestäminen tehdään sanakirjaan muusta järjestämisestä poikkeavalla tavalla.

3.2.2 Numeerinen ja aakkosellinen järjestäminen

Vertailu- ja järjestämisalgoritmin toteuttamisen kannalta yksinkertaisimpiin järjestämisongelmiin kuuluu numeerinen järjestäminen (numerical sorting), jossa luvut järjestetään luvun suuruuden mukaan. Lukujen ja numeroiden järjestämisen lisäksi numeerinen järjestäminen soveltuu minkä tahansa tietojärjestelmään syötetyn asian järjestämiseen. Ainoa vaatimus on se, että kullekin järjestettävälle alkiolle voidaan määritellä numeerinen arvo, jota verrata. Esimerkiksi ASCII-merkistön (2.1.1) tai muun koodatun merkistön määrittelemä järjestys voi toimia numeerisena järjestysperusteena. Tällöin kuitenkin esimerkiksi isot ja pienet kirjaimet järjestyvät erikseen (ensin pienet kirjaimet a - z ja sitten isot kirjaimet A - Z, tai toisin päin), joten järjestystapa ei sovellu useinkaan suoraan kielen järjestämiseen. Jos järjestettävät merkit on koodattu muistiin siten, että yksittäisen merkin tavumäärä voi vaihdella, ei numeerinen järjestäminen toimi, koska järjestettävää tietoa käsitellään tavuina eikä merkkeinä.

Aakkosellinen järjestäminen (alphabetical sorting) on kehittyneempi versio numeerisesta järjestämisestä. Edellisessä alakohdassa esitellyt kielelliset vaatimukset otetaan huomioon, joten esimerkiksi saksankielisessä aakkosellisessa järjestämisessä Ä-kirjain tulee A- ja B-kirjaimien väliin.

Numeerinen ja aakkosellinen järjestäminen ei toimi mielekkäällä tavalla, jos järjestettävät merkkijonot sisältävät numeroita. Esimerkiksi ”156,1”-merkkijono tulee numeerisesti järjestettynä ennen merkkijonoa ”36,2”.

3.2.3 Ideogrammien järjestäminen

Tässä alakohdassa esitellään tavallisimmat ideogrammien järjestämistavat. Teksti perustuu lähteeseen [ORAC2005].

Kiinan ja japanin kielissä käytettävien ideogrammien (ideograph) järjestämissäännöt perustuvat perinteeseen, jossa ideogrammista tunnistetaan ensin sen perusmuoto (radical). Perusmuotoon lisätään 0-n komponenttia (component). Perusmuoto ja komponentit koostuvat vaihtelevasta määrästä siveltimen vetoja (stroke).

Ideogrammit voidaan järjestää perusmuotojen siveltimen vetojen määrän mukaan, jonka jälkeen saman perusmuodon ideogrammit järjestetään vielä keskenään koko ideogrammin siveltimen vetojen määrän mukaisesti. Kuvan 3 esimerkissä on käytetty tätä järjestämistapaa.

Kuva 3 - Ideogrammien järjestäminen perusmuodon mukaan [ORAC2005]

Koska osa perusmuodoista piirretään samalla määrällä siveltimen vetoja, määrää perinne näille perusmuodoille keskinäisen järjestyksen. Järjestystä käytetään useimmissa kiinankielisissä sanakirjoissa, vaikka tapa ei ole välttämättä intuitiivinen kiinaa puhuvallekaan.

Kuva 4 - Ideogrammien järjestäminen siveltimen vetojen määrän mukaan [ORAC2005]

Kuvan 4 esimerkissä ideogrammit on järjestetty vetojen kokonaismäärän mukaan edellä esitetyn tavan sijaan. Tämä järjestämistapa, jossa ideogrammit järjestetään ensisijaisesti siveltimen vetojen määrän mukaan ja toissijaisesti perusmuodon siveltimen vetojen määrän mukaan, on yleisemmin käytössä intuitiivisuutensa vuoksi.

Koska molemmat järjestämistavat perustuvat siveltimen vetojen määrään, eroaa perinteisen ja yksinkertaistetun kiinan (Traditional ja Simplified Chinese) järjestykset toisistaan merkittävästi.

Järjestäminen voidaan tehdä myös foneettisen muodon mukaan. Fonetiikkaan perustuva järjestys toimii hyvin, jos järjestettäväksi tule ideogrammeja, joiden lausumistapa riippuu asiayhteydestä. Lausumismuotoja kutsutaan sanoilla pinyin (yksinkertaistettu kiina) ja bopomofo (perinteinen kiina). Yksittäisellä pinyinillä voi olla myös viisi erilaista lausumisäänen korkeudella erotettavaa muotoa. Ideogrammit, joilla on sama pinyin ja sama äänen korkeus, järjestetään keskenään siveltimen vetojen määrän mukaan. Kuvan 5 esimerkissä on esitettynä foneettisesti järjestettyjä ideogrammeja. Suluissa olevat kirjaimet kuvaavat lausumismuotoa (pinyin) ja numerot lausumisäänen korkeutta.

Kuva 5 - Ideogrammien järjestäminen lausumismuodon mukaan [ORAC2005]

3.2.4 Unicode ja monitasoinen vertaileminen

Kansainvälistä tietoa käsittelevässä järjestelmässä vertailu ja järjestäminen tehdään käyttäjän kulttuurin ja järjestelmän käyttötapauksien vaatimilla tavoilla. Järjestelmässä saatetaan joutua järjestämään myös sanoja tai nimiä, jotka ovat lähtöisin toisistaan poikkeavista kielistä. Joskus joudutaan päättämään järjestys sanoille, jotka perustuvat toisistaan täysin poikkeaviin merkistöihin.

Unicode, joka esiteltiin edellisen luvun kohdassa 2.2, määrittelee yleisen Unicode-merkkijonojen vertailualgoritmistandardin, Unicode Collation Algorithm (UCA). Algoritmia voi käyttää kaikenkielisten merkkijonojen järjestämiseen ja standardi esittelee järjestämiseen käytettävän oletusjärjestyksen taulukon, Default Unicode Collation Element Table (DUCET), johon tehdään poikkeuksia eri kielten ja kulttuurien tarpeiden mukaan. Unicoden sivustolta on saatavissa laaja joukko poikkeustaulukoita eri kielien oikean järjestämisen aikaansaamiseksi.

Vertailun mahdollistamiseksi standardi määrittelee merkeille normeeratut muodot [UTS15], joissa esimerkiksi yksittäisellä koodipisteellä esitettävä Ä-kirjain puretaan perusmerkiksi A ja treemaksi ¨ (pisteet A-kirjaimen päällä).

3.2.5 Järjestäminen ohjelmointikielissä

Yleensä ohjelmointikielet tarjoavat tavan vertailla merkkijonoja keskenään. Jos ei toisin määritellä, vertailu on aina numeeriseen järjestämiseen perustuvaa. Ohjelmakirjastot voivat tarjota metodeita esimerkiksi kirjainkoon huomiotta jättämiseen (ignore case) ja omien sovelluksen käyttötapaukseen räätälöityjen vertailujen tekeminen ei ole tavallisesti vaikeaa.

Globaalin verkkojärjestelmän toteuttamisessa saatetaan kuitenkin tarvita kaikkia edellisissä alakohdissa esiteltyjä järjestämistapoja, joten onneksi Unicoden järjestämisalgoritmi (UCA) on toteutettu jo esimerkiksi Javaan ja .NET-alustaan.

Esimerkiksi Javan Collator-luokan perivä RuleBasedCollator tuntee kielellisiä ja kansallisia järjestyksiä.

RuleBasedCollator da_DKCollator = (RuleBasedCollator) Collator.getInstance(new Locale("da", "DK", ""));

määrittelee tanskalaisen tavan järjestää.

Määritelty vertailija voidaan antaa parametriksi esimerkiksi tanskankielisiä nimiä järjestämisessä:

Arrays.sort(stringArrayOfDanishNames, DKCollator);

RuleBasedCollator-luokalle voidaan antaa myös täysin itse rakennettu vertailusäännöstö. [Java2005]

3.2.6 Järjestäminen tietokannoissa

Tietokantajärjestelmät järjestävät hakutuloksia SQL-kielen [WIKI2005] avainsanoilla ”ORDER BY”. Se, kuinka paljon käytettävään järjestämistapaan voi vaikuttaa, vaihtelee suuresti. Esimerkiksi vapaasti saatavilla olevat MySQL 4.0 (www.mysql.com) tai PostgreSQL 8.0 (www.postgresql.org) tarjoavat vain mahdollisuuden käynnistää tietokantajärjestelmä valitun merkistön vaikutuksen alaisena, jolloin järjestäminen tapahtuu merkistön merkkien koodien numeroiden mukaisesti. Poikkeuskoodia saksan kielen järjestämissäännöille löytyy kuitenkin MySQL-tietokannasta. Järjestäessä sisäiseen toteutukseen on tehty muunnokset:

· ä -> ae

· ö -> oe

· ü -> ue

· ß -> ss

Lisäksi sanoista riisutaan aksentit ja kirjaimet muunnetaan isoiksi vertailussa. Järjestelmiä kehitetään tietenkin jatkuvasti, joten niiden suosion myötä kansainvälistämiseen ja lokalisointiin soveltuvia piirteitä tulee varmasti lisää.

Versiosta 4.1 lähtien MySQL ja kaupallisista tietokantajärjestelmistä esimerkiksi DB2 8.2 (www.ibm.com), SQL Server 2000 [Micr2005a] ja Oracle 9i [ORAC2005] tukevat jo huomattavasti paremmin lokalisoitua järjestämistä. Kuten esimerkkinä edellä käytetty PostgreSQL 8.0, nämä tietokantajärjestelmät voivat periä käytettävän järjestämistavan käyttöjärjestelmästä, tapa voidaan määritellä erikseen tietokantajärjestelmää asennettaessa tai tapa voidaan määritellä erikseen uutta tietokantaa luotaessa. Lisäksi järjestämistavan voi määritellä usein erikseen taululle tai yksittäiselle sarakkeelle ja järjestämistavan voi määritellä myös yksittäisen haun yhteydessä.

SQL Server 2000 antaa mahdollisuuden määritellä järjestämistavan useissa konteksteissa avainsanalla ”COLLATE” [Micr2005a]. Järjestämisen voi määritellä esimerkiksi ALTER TABLE ‑komennolle tai haun tulokselle:

SELECT Name FROM Customers ORDER BY Name COLLATE SQL_Danish_Pref_Cp1_CI_AS

Oracle 9i, kuten myöhemmätkin versiot, noudattaa omaa tapaansa määritellä järjestäminen ympäristömuuttujilla ja NLSSORT-funktion avulla. Esimerkiksi tavallinen numeeriseen järjestämiseen perustuva haku (binary sort) voisi antaa viisi taulusta löytyvää riviä seuraavasti:

ALTER SESSION SET NLS_SORT=BINARY;

SELECT product_name

FROM product

ORDER BY product_name;

PRODUCT_NAME

============

Antenne

Lcd

aerial

Ähre

ächzen

Saksan kielen järjestämiseen perustuva Antenne-sanan jälkeen tulevia sanoja hakeva lause palauttaisi vain yhden rivin:

ALTER SESSION SET NLS_SORT=GERMAN;

SELECT product_name

FROM product

WHERE NLSSORT(product_name) >

NLSSORT(‘Antenne’)

ORDER BY product_name;

PRODUCT_NAME

============

Lcd

3.2.7 Vertailutavan valinta

Koska ihminen voi kokea järjestämisen hyvinkin yksilöllisesti, tulee vertailutavan valinnassa olla tarkkana. On tilanteita, joissa kieli tai kulttuuri sanelee vertailutavan, ja tilanteita, joissa kulttuurin sisällä käyttötapaus vaikuttaa valintaan (esimerkiksi kohdassa 3.2 mainittu puhelinluettelon järjestäminen). Vaikka käyttäjä voikin haluta järjestää esimerkiksi henkilöihin kohdistuneiden hakujen tuloksia hetken mielijohteesta joko suku- tai etunimen mukaan, ei yksittäisten merkkijonojen vertailu kielen tai kulttuurin sisällä kuitenkaan vaihtele siten, että käyttäjälle jouduttaisiin tarjoamaan personoituja vertailualgoritmeja.

Lisäksi kannattaa kiinnittää huomiota siihen, että järjestelmän eri tasoilla olevat vertailutavat ovat toistensa kanssa yhteneviä. Jos vertailu tehdään tietokannassa vain käyttäjän kielen perusteella ja käyttöliittymätasolla vertailu perustuu käyttäjän kielen lisäksi myös johonkin muuhun kriteeriin, voi käyttäjä saada käyttötapauksittain erilaisia tuloksia.

4 Lokaalin valinta

Globaalin verkkojärjestelmän tulisi palvella käyttäjää hänen ymmärtämällään kielellä ja tarjota käyttäjälle palveluita, joita hän pystyy maassaan hyödyntämään teknologian ja lakien sallimissa puitteissa.

Toisinaan järjestelmää määriteltäessä tehdään oletuksia, jotka rajoittavat turhaan käyttäjän vapautta valita hänen ymmärtämänsä kieli. Käyttäjä voi esimerkiksi joutua kertomaan asuinmaansa järjestelmään rekisteröitymisen yhteydessä, jotta järjestelmän sisältö voidaan personoida mainostamaan oikeita tuotteita, mutta tämän lisäksi järjestelmä suostuu esittämään sisällön vain rekisteröitymismaan kielellä tai kielillä. Tällöin esimerkiksi suomessa asuva ulkomaalainen saa palvelua vain suomeksi ja ruotsiksi ja järjestelmä on hänen kannaltaan käyttökelvoton. Toisaalta on ymmärrettävää, että sisältö, joka on vahvasti maakohtaista, käännetään mahdollisimman rajatulle määrälle kieliä. Tämän ei kuitenkaan tarvitse välttämättä estää muunmaalaisen sisällön selailua, jos sivusto vain esittää maakohtaisuuden selkeästi.

4.1 Lokaali ohjelmakoodissa

Lokaalilla (substantiivi) tarkoitetaan kokoelmaa sääntöjä ja muuta tietoa, joiden perusteella yksittäinen lokalisointitapaus voidaan identifioida. Lokaalin avaimena voi toimia esimerkiksi kielen ja maan tai maanosan yhdistelmä, jota voidaan tarkentaa esimerkiksi poliittisella tai kulttuurillisella tunnisteella. ”Locale-sensitive”‑operaation eteneminen tai lopputulos riippuu määritellystä tai kontekstissa vallitsevasta lokaalista.

Java API:ssa Locale-luokan [Java2005] rakentajalle on mahdollisuus antaa ensimmäisenä tunnisteena kielitunnus, toisena maatunnus ja kolmantena variantti. Tunnukset voivat olla mitä tahansa merkkijonoja, mutta luokka tunnistaa ISO‑639‑standardin mukaiset kaksikirjaimiset kielitunnukset [ISO639] ja ISO‑3166‑standardin mukaiset kaksikirjaimiset maatunnukset [ISO3166]. Tunnistettujen tunnusten perusteella on saatavilla lisätietoa lokaalista. Luokka tuntee myös vakioita suurelle joukolle kieliä.

Esimerkiksi

Locale.ITALIAN.getISOCountries()

antaa arvon ”IT” ja

new Locale(”sv”, ”FI”)

luo lokaalin, joka edustaa suomenruotsia. Variantti on toimittaja‑ tai selainkohtainen tunniste, joka tarkentaa lokaalia. Luokan dokumentaatiossa annetaan esimerkiksi

new Locale(”es”, ”ES”, ”Traditional_WIN”)

joka voisi toimia lokaalina, jolla ilmaistaan Windows-ympäristöissä järjestämisoperaatioille (collation, 3.2), että teksti halutaan aakkostaa traditionaalisen espanjankielisen tavan mukaisesti. Variantissa olevalla alaviivalla (”_”) erotellaan variantissa itsessään olevat tarkennukset (esimerkissä yleisen traditionaalisuuden lisäksi määritellään vielä käyttöjärjestelmäksi Windows).

.NET‑alustalla System.Globalization.CultureInfo-luokka [Micr2005c] edustaa lokaalia. Luokan kuvauksen mukaan kulttuurien (lokaalien) nimet muodostetaan tavalla, jonka esittelee [RFC1766]. Kuten Java API:n Locale-luokankin tapauksessa, RFC 1766:n kieli- ja maatunnukset pohjautuvat ISO‑639 ja ISO‑3166-standardeihin ([ISO639] ja [ISO3166]). Tämä ei silti takaa yhteensopivuutta alustojen kesken, koska standardit muuttuvat (esimerkiksi uusia maita syntyy) ja alustojen toimittajat päivittävät toteutuksiaan muuttuneiden standardien perässä. Tästä syystä esimerkiksi järjestelmiä integroitaessa onkin syytä aina tarkistaa tunnusten yhteensopivuus ja muodostaa esimerkiksi versioriippuvaiset yhteensopivuustaulukot. Lisäksi RFC 1766 kertoo, että lokaali, ja siksi myös .NET-alustan CultureInfo-luokka, määritellään muodostamalla merkkijono, jossa on miinusmerkillä (”-”) eroteltuja kaksi- tai kolmikirjaimisia kielitunnisteita. RFC-tekstissä lokaali on ”language tag”, mutta .NET soveltaakin RFC‑määritystä koko ”kulttuurin” identifioimiseen Edellisen esimerkin traditionaalinen espanjan kieli rakennettaisiin seuraavasti:

new CultureInfo(”es-ES-Traditional-Win”)

4.2 Valinta-algoritmit

Koska verkkojärjestelmät eivät milloinkaan voi tukea kaikkia mahdollisia lokaaleja, käytetään järjestelmien tai järjestelmien osien lokalisoinnissa valinta-algoritmia, jonka toteutus eroaa eri alustoilla periaatteen ollessa kuitenkin sama.

Jos pyydettyä lokalisoitua resurssia ei ole suoraan saatavilla, pyrkii algoritmin toteutus palauttamaan ”mahdollisimman hyvin” pyyntöä vastaavan resurssin. Käytännössä tämä tarkoittaa kohdassa 4.1 esiteltyjen luokkien rakentajien parametrien rakenteiden hyödyntämistä. Esimerkiksi Java-koodi [Java2005]

ResourceBundle errorMessageBundle = ResourceBundle.getBundle(

“ErrorMessages”, new Locale(“en”, “GB”));

pyrkii palauttamaan virheilmoituskokoelman, joka on lokalisoitu englantia puhuvalle britille. Jos kokoelmaa ei löydy, toteutus palauttaa yleisen englanninkielisen kokoelman, joka voidaan palauttaa myös esimerkiksi Yhdysvalloissa (”en_US”) ja Australiassa (”en_AU”) puhuttua englantia pyydettäessä. Jos yleistä englanninkielistä kokoelmaakaan ei löydy, palautetaan yleinen kielineutraali kokoelma, jonka sisältö kirjoitetaan usein tosin englannin kielellä. Jos yleistä kielineutraalia kokoelmaa ei löydy, heitetään poikkeus. ResourceBundle-luokat ovat siis keskenään hierarkkisesti ketjutettuja. Hierarkia muodostuu automaattisesti taustalla olevien resurssitiedostojen ja -luokkien nimien perusteella. Nimet voisivat olla esimerkin tapauksessa seuraavia:

· ErrorMessages.properties

· ErrorMessages_en.properties

· ErrorMessages_en_GB.class

· ErrorMessages_en_US.properties

· ErrorMessages_en_AU.class

ResourceBundle-tyyppisen palautetun kokoelman metodit getObject ja getString palauttavat lokalisoituja olioita. Metodille annetaan parametriksi halutun olion tai merkkijonon avain.

Esimerkiksi australialaiselle lokalisoitua virheilmoitusta väärästä salasanasta voitaisiin tavoitella kutsumalla:

String incorrectPassowrdMessage =

errorMessageBundle.getString(”loginPasswordIncorrect”);

Jos errorMessageBundle-kokoelmasta ei löydy annetulla avaimella palautettavaa oliota, käyttää kutsuttu metodi kokoelmien hierarkiaa hyväkseen edellä esitellyn getBundle-metodin tapaan.

Javan abstrakti ResourceBundle-luokka on helppo periä esimerkiksi tietokantaa hyödyntävän kansainvälistämisen toteuttamiseksi.

.NET-alustan ResourceManager-luokka toteuttaa taakseen vastaavanlaisen hierarkian ja valinta-algoritmista käytetään nimitystä ”resource fallback”.

4.3 Oletuskieli

Käyttäjän saapuessa sivustolle on järjestelmän tehtävä jokin arvaus käyttäjän ymmärtämästä kielestä. Vaikka länsimaalaisen ja varsinkin pohjoismaalaisen näkökulmasta englannin kieli voisi tuntua hyvältä ja kaikille käyvältä vaihtoehdolta, ei tämä ole globaalina ratkaisuna toimiva. Englannin kieli ei ole globaalisti ymmärretty ja lisäksi sen valta-aseman tunnustaminen ei kaikissa kulttuureissa ole itsestäänselvyys.

Jos globaalille järjestelmälle rekisteröidään useita internet-osoitteita, joilla on eri maapäätteet (www.domain.fi, www.domain.se, www.domain.de, jne.), tehdään yleensä arvauksia URL:n maapäätteen perusteella. Oletuskieleksi valitaan maan yleisin tai ainoa virallinen kieli. Jos maan kielet ovat kuitenkin lähes tasavahvoja tai on syytä odottaa liian vahvojen oletusten tekemisen johtavan esimerkiksi maan poliittisen tilanteen takia negatiiviseen palautteeseen, on syytä tarjota kilpaileville kielille tasavahva aloitustilanne, jossa aloituskielen valitsee käyttäjä (esimerkiksi www.domain.nl).

Käyttäjän internet-osoitteen perusteella tapahtuva oletuskielenvalinta on mahdollista, mutta koska käyttäjän sijainti Internetin osoiteavaruudessa ei kerro nykyään välttämättä mitään käyttäjästä, on internet-osoitteen käyttäminen lähes aina huono vaihtoehto.

4.4 HTTP:n kielivalintamekanismi

HTTP-protokollan RFC 2616 ([HTTP11], ”14.4 Accept-Language”) tarjoaa kielivalintamekanismin, jossa selain voi lähettää listan käyttäjän ymmärtämistä kielistä palvelimelle HTTP-otsikossa (HTTP header) Accept‑Language. Listaan merkitään kullekin kielelle myös laatuluvut väliltä 0-1, joilla kuvataan kielen kelpaavuutta. Jos palvelimelta löytyy pyydetystä sivusta erikielisiä versioita, voi palvelin käyttää kutsussa vastaanotettua tietoa sivun valinnassa tai lokalisoinnissa.

RFC määrittelee otsikon rakenteeksi:

Accept-Language = "Accept-Language" ":"

1#( language-range [ ";" "q" "=" qvalue ] )

language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

Ja esimerkkinä otsikosta annetaan:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Esimerkki tulkitaan: ”Haluan sisällön ensisijaisesti tanskankielisenä, mutta myös englannin kieli kelpaa; etenkin brittienglanti”.

Lisäksi palvelimen on syytä soveltaa sisällön valinnassa lokaalin valinta-algoritmia (esiteltiin kohdassa 4.2), jos selaimen lähettämien otsikoiden perusteella ei suoraan löydy sisältöä.

HTTP:n kielivalintamekanismi on hyvä oletuslokalisointi, mutta ikävä kyllä joskus sivustojen toteuttajat sortuvat pitämään sitä ainoana vaihtoehtona. Jukka Korpelan sivulla ”Miksi linkit?” [Korp2000] annetaan esimerkkinä osoite http://www.debian.org/ [Debi2005], joka käyttää HTTP:n kielivalintamekanismia Debian-sivuston lokalisointiin. Kielivalinta toimii ja lisäksi käyttäjälle on annettu mahdollisuus vaihtaa sisällön kieltä sivun alalaidassa olevilla kielilinkeillä ja tässä kohtaa on jäänyt toteutus miettimättä loppuun asti: linkitkin toimivat ja käyttäjä voi vaihtaa selaimensa kielivalintamekanismin vastaisesti esimerkiksi suomen kielen tilalle englannin kielen, mutta kun käyttäjä klikkaa ”News”-sivulta siirtymisen esimerkiksi ”Documentation”-sivulle, hän saa taas selaimen ehdottaman suomenkielisen ”Käyttöohjeet”-sivun. Myöhemmin tässä luvussa käsiteltävä ”valinnan tallentaminen” (kohdassa 4.6) on jäänyt ilmeisesti toteuttamatta. Tosin Korpela ei näytä tulkitsevan tilannetta tällä tavoin vaan sanoo:

”Selvintä on ehkä todeta, että tämä on kuitenkin poikkeustapaus, joka käyttäjän pitää hoitaa esim. selaimensa kielipreferenssejä tilapäisesti muuttamalla, ja että yleensä linkkien on syytä olla geneerisiä jos mahdollista.”

Tällainen tulkinta ei voi johtaa tavalliselle verkon selaajalle käyttökelpoisiin sivustoihin ja lisäksi linkeissä olisi hyvä olla ainakin URL-parametrina lokalisointivalinta esimerkiksi kirjanmerkkien käyttöä ajatellen.

Debian-sivusto saattaa olla toteutettu käyttäen esimerkiksi Apachin AddLanguage direktiiviä (ainakin palvelin esittelee itsensä Linuxiksi, jossa ajetaan Apachen palvelinta PHP‑tuella). Direktiivillä Apachin web-palvelimelle voi määritellä, missä muodossa web-sivun tiedoston nimi on tietynkielisellä sisällöllä. Palvelin lähettää tämän perusteella automaattisesti oman Accept‑Language-otsikkonsa selaimelle ja tietoa käytetään myös ”content negotiation”-tilanteessa. [Apac2005]

Tässä lopputyössä ei mennä syvemmälle web-palvelimien toimintoihin, vaan käsitellään globaalin verkkojärjestelmän toteuttamista sovelluspalvelimilla, joiden ominaisuuksien pitäisi riittää kansainvälistämis- ja lokalisointiratkaisujen toteuttamiseen.

Kuva 6 - HTTP:n kielivalintamekanismin asetukset Internet Explorer 6.0 -selaimessa

Toinen äärilaita on tietenkin HTTP:n tarjoaman mekanismin hyödyntämättä jättäminen. On täysin perusteltua kysyä, ovatko käyttäjät tietoisia selaimensa kielivalintamekanismista ja siitä, mikä heidän selaimensa asetus milloinkin on. Kuinka moni Internet Explorer -selaimen käyttäjä tuntee kuvan 6 asetukset, jotka vaikuttavat edellä mainittuun Debian-sivuston lokalisointiin? Onko käyttäjällä edes mahdollisuutta tai kiinnostusta vaikuttaa asetukseen, jos käytettävä kone selaimineen on esimerkiksi julkisessa tilassa yleisesti käytössä oleva kirjaston tarjoama työasema?

4.5 Käyttäjän tekemä kielivalinta

Koska sivun oletuskielen valinta ei edellisissä kohdassa kuvatuista syistä ole aina triviaalia, tulee käyttäjälle antaa mahdollisuus kielen vaihtamiseen. Lisäksi tarjolla olevat erikieliset sisällöt voivat paikata toisiaan, jos käyttäjä ei ymmärrä kaikkea sivuston sisällöstä. Vaikka kieli olisi käyttäjän äidinkieli, voivat jotkut tiettyyn alaan liittyvät termit olla tuttuja paremmin tuttuja englanniksi (useinhan näin on tietotekniikan alalla). Tietenkin sisältö voi olla (vaikkapa tilapäisesti) jollakin kielellä niin heikkolaatuista, että käyttäjä haluaa varmistaa ymmärtäneensä asian oikein käyttämällä toista kieltä.

Kielivalintamahdollisuus tulisi asetella käyttöliittymässä paikkaan, josta jokainen voi sen löytää riippumatta siitä, minkä kielistä muu sivulla näytettävä sisältö on. Sivun yläreuna on hyvä paikka, koska käytännössä kaikki käyttäjät aloittavat sivun tutkiskelun yläreunasta varsinkin perustavanlaatuisten toimintojen kuten kielivalinnan tai vaikkapa sivuston sisäisten hakutoimintojen kiinnostaessa. Jos sivun asettelussa on päädytty muutenkin jonkinlaiseen ylämarginaaliin, jossa on esimerkiksi palvelun logo ja nimi, ei kielivalinnan lisääminen ylämarginaaliin vie lisätilaa varsinaiselta sisällöltä paljoakaan.

Jukka Korpelan sivulla ”Linkkien sijoittaminen” [Korp2000] mainittu verkon indeksointirobottien hämääntyminen ei varmastikaan nykyään ole ongelma, mutta hän tarjoaa ratkaisuksi toteutusta, jossa kielen valinta kirjoitetaan HTML-koodin loppuun DIV-tunnisteiden ympäröimänä ja tyylisääntöjen avulla valinta kuitenkin sijoitetaan absoluuttisesti sivun oikeaan ylänurkkaan:

#langlinks { position: absolute; top:0.5em; right:0;

text-align: right;

font-family: "Lucida Console", "Courier New", Courier, monospace;

font-size:110% }

h1 { margin-top : 1em; font-size: 125%; }

Sijoittelutyylisääntöä tukematon selain näyttää linkit sivun lopussa ja sääntöä soveltava selain näyttää linkit sivun oikeassa yläkulmassa.

Käyttöliittymän kielivalinta tulisi olla mielellään sellainen, että vaihtoehtoisen kielen nimi kirjoitettuna kielellä itsellään olisi suoraan näkyvissä. Jos sivulla käytettävä merkistö on suppea ja merkistö ei tue kaikkien kielivaihtoehtojen nimien merkkejä, voidaan kielivaihtoehdot esittää kuvina, joissa teksti on kirjoitettuna. Samaa ratkaisua voidaan käyttää, jos on oletettavaa, että käyttäjien selaimissa tai järjestelmissä ei ole kaikkia kielivalintojen kielien fontteja, vaikka sivu muuten olisikin esimerkiksi Unicode-merkistöllä toteutettu. Kun kielivaihtoehtoja on runsaasti, voi kielivalinnan sijoittaminen sivun alareunaan olla hyvä vaihtoehto kuten Debian-sivuston tapauksessa oli tehty. Jos kielet sen sijaan ladotaan vain esimerkiksi alasvetovalikkoon, jää oletuskieltä osaamattoman ainoaksi toivoksi se, että valikko on sijoitettu hänen kannaltaan johdonmukaisesti ja sivun yleinen ilme on tarpeeksi selkeä, jotta käyttäjä uskaltaa tai viitsii ryhtyä kokeilemaan toivon mukaan ainoaa esimerkiksi sivun ylämarginaalissa olevaa alasvetovalikkoa.

Toisinaan verkkosivujen kielivalinnoissa käytettävät maiden liput on syytä jättää käyttämättä, kun tavoitellaan poliittista riippumattomuutta. Korpela on kirjoittanut tästä hieman provokatiivisella otsikolla ”Flag as a symbol of language - stupidity or insult?” [Korp2003]. Asian alleviivaaminen ei tosin ole lainkaan paha asia ja hetken asiaa mietittyään kukin sisällöntoimittaja ja verkkosivujen suunnittelija jättää liput suosiolla rauhaan niiden sisältämien arvolatausten vuoksi. Varovaisuuteen on syytä varsinkin, jos verkkosivujen tulisi palvella globaalisti kauppaa tekevän yrityksen tarpeita.

Kielivalinnan toteuttamiseen on käytetty myös ponnahdusikkunoita (popup window), jotka sisältävät varsinaiset kielivaihtoehdot. Kuten erilaisten ”popup blocker” ‑ominaisuuksien kirjo nykyselaimissa osoittaa, tulisi ponnahdusikkunoiden käyttöä kuitenkin välttää, koska ne eivät välttämättä tue nykykäsitystä ”selattavasta verkosta”. Mainittakoon kuitenkin, että tämä lienee makuasia ja ainakin tämän lopputyön ulkopuolista asiaa.

4.6 Kielivalinnan ja muun lokalisoinnin tallentaminen

Kun käyttäjä saapuu sivustolle, tehdään oletukset käyttäjälle tarjottavien sivujen kielestä ja muusta lokalisoinnista HTTP-kutsun perusteella. Selkeän käyttökokemuksen aikaansaamiseksi lokalisoinnin tulisi muuttua tämän jälkeen vain silloin, kun käyttäjä itse valitsee jonkin toisen lokaalin. Käytännössä tämä johtaa tilanhallintaan, jossa oletukseksi valittu tai käyttäjän valitsema lokaali täytyy tallentaa jonnekin. Palvelimet hallitsevat toki sessiomuuttujien käsittelyn, mutta jos sivustoa käytetään referenssinä ja ihmiset haluavat linkkejä suoraan tiettyihin sivuihin ja luonnollisestikin tietyllä kielellä, on URL-polussa tai -parametreissa oltava näkyvillä käytetty lokalisointi ja tietenkin muukin sisällön identifioiva tieto.

Jos käyttäjä on joutunut kirjautumaan järjestelmään, on luontevaa tietenkin tallentaa lokaali käyttäjätietojen yhteyteen.

5 Sisällön lokalisointi

Tässä luvussa käsitellään lokalisoitavan sisällön tallentamista, sisällön eri tyyppejä ja lokalisoidun sisällön esittämiseen liittyviä seikkoja.

5.1 Sisällön säilytyspaikat

Järjestelmän suunnitteluvaiheessa arvioidaan kansanvälistettävän sisällön määrä, laatu sekä päivityksen tarve. Varastoitava WWW-järjestelmän sisältö koostuu pääasiassa muotoilusta (HTML / WML), leipätekstistä ja kuvista. Järjestelmä voi käsitellä myös animaatiotiedostoja (esim. Flash) tai matkapuhelimien soittoääni- ja logotiedostoja. Koska sisällön lokalisoidun säilytyksen näkökulmasta tiedostot voidaan kuitenkin käsitellä samassa kategoriassa kuin kuvatiedostot, rinnastetaan ne tässä lopputyössä kuvatiedostoihin.

Parhaassa tapauksessa sisällöstä joudutaan lokalisoimaan vain leipäteksti ja esityksen muotoilu kuvineen voidaan pitää staattisena. Toista äärilaitaa edustaa tilanne, jossa kaikki kolme sisällön osaa joudutaan lokalisoimaan, jolloin sisällön tietovarastolle asetetaan huomattavasti enemmän vaatimuksia.

Jos sisältöä ei ole tarkoitus lokalisoida monelle kielelle tai lokaalille eikä sisältöä ole tarkoitus päivittää muutoin kuin virheiden korjaamiseksi, voi tekstin staattinen kirjoittaminen suoraan esityskerrokseen (esimerkiksi JSP‑koodiin tai pelkkään HTML‑koodiin) olla riittävä ratkaisu. Tällöin olisi myös toivottavaa, että esityskerros ei sisältäisi paljoa dynamiikkaa, jota mahdollisessa ylläpitovaiheessa jouduttaisiin muuttamaan jokaiseen lokalisoituun versioon. Ratkaisu on toimiva erityisesti silloin, kun sisällöntoimittaja on eri kuin esityskerroksen dynamiikan toimittaja.

Kuva 7 - Lokalisoitujen HTML-tiedostojen hakemistohierarkia

Jos kullekin lokaalille päädytään tekemään oma sivunsa, kannattaa HTML- tai JSP-tiedostojen tallentaminen levyjärjestelmään tehdä hakemistorakenteeseen, jonka hierarkia myötäilee järjestelmän lokaalien hierarkiaa. Kuvan 7 mukainen hierarkia mahdollistaa tiedostojen lokalisoinnin englannin-, suomen- ja ruotsinkielisille sivuille. Lisäksi hierarkia sisältää tietyille maille (Australia, Iso-Britannia ja Suomi) räätälöidyt versiot sivuista. Maahakemistot ovat kielihakemistojen alla. Jos tietystä maasta tulevalle tietyn kielen puhujalle löytyy maakohtainen hakemisto, haetaan tiedostot sieltä. Muutoin käytetään vain kielikohtaista hakemistoa. Jos edes kielelle ei löydy omaa hakemistoa, tiedosto luetaan hakemistorakenteen juuresta. Hakemiston valinnassa noudatetaan siis kohdassa 4.2 esiteltyä valinta-algoritmia.

Esityskerroksia rakennettaessa käytetään usein tekniikoita, joilla esityskerros jaetaan paloihin. Nämä palat voivat olla uudelleenkäytettäviä tai ne edustavat vähintäänkin sivun osia siten, että varsinainen sisältö jää omaan palaansa ja mahdollinen dynamiikka omiin paloihinsa. Tekniikat antavat tavallisesti mahdollisuuden myös sisältötekstin tallentamiseen ja lokalisoimiseen siten, että eri versiot tekstistä sijaitsevat resurssitiedostoissa tai tietokannassa. Sisällöntoimittajan ollessa eri kuin esitysdynamiikan toimittaja voi olla selkeintä, ettei paloittelematonta sisältöä yritetä yleistää dynaamisiksi uudelleenkäytettäviksi paloiksi, koska tällöin sisällöntoimittajalla ei ole enää mahdollisuutta muokata sisältöä suoraan. Dynaamisen toteutuksen tapauksessa dynamiikan toimittaja joutuu tekemään muokkaamisen sisällöntoimittajan ohjeiden mukaan, jolloin toimittajien roolit sekoittuvat ja tehtäväjaosta tulee epäselvä. Jos voidaan olla kohtuullisen varmoja, että sisällön istuttaminen esityskerrokseen joudutaan tekemään vain kerran tai päivityksen tekemisestä päästään eri osapuolten kesken yhteisymmärrykseen, on resurssitiedostojen käyttö kuitenkin ratkaisuna selkeä ja sitä suositaan jo pelkästään yhdelle kielelle käännettävien järjestelmien toteuttamisessa laajennettavuuden takia, vaikka käytännössä joudutaankin tekemään ylimääräistä työtä tekstin irrottamiseksi muotoilusta ja muusta sisällöstä.

Suuren ja varsin dynaamisen järjestelmänkin tapauksessa saatetaan käyttää staattista suoraa esityskerrokseen kirjoittamista, jos kyse on esimerkiksi väliaikaisesta kampanjasta tai poikkeuksellisesta sisällöstä, joka vaatii täysin omat asettelunsa ja joka kiinnitetään muuhun ratkaisuun vain tilapäisesti. Näin vältytään olemassa olevan runkoratkaisun laajentamiselta väkisin väliaikaisen sisällön tarpeiden tyydyttämiseksi.

Jos järjestelmän sisältöä on paljon tai jos järjestelmän sisältöä on tarkoitus päivittää usein ja mielellään siten, että järjestelmää ei jouduta ajamaan hetkeksikään alas, voi tietokanta olla sisältötekstille oikea sijoituspaikka. Lisäksi suureen järjestelmään voi kuulua klusterissa olevia useita palvelimia, joilla kaikilla tulee olla sama sisältö. Tällöin viimeistään sisällöntoimittajalle tulee olla rakennettuna omat sisällönhallintavälineet, jollei valmiita sisällönhallintavälineitä jo muuten ole käytössä.

Kuvatiedostot ovat staattista sisältöä, joten myös niiden lokalisoitujen versioiden tallentaminen kannattaa tehdä hakemistorakenteeseen, jonka hierarkia myötäilee järjestelmän lokaalien hierarkiaa. Ylläpidosta tulee helpompaa ja alakohdassa 5.3.2 esiteltävän valinta-algoritmin toteuttaminen helpottuu.

5.2 Tekstisisällön tallentaminen

Tyypillinen ongelma luotaessa kansainvälistä sisältöä on epävarmuus sisällön tallentumisesta oikeaan muotoon. Seuraavassa käsitellään sisällön tallentumista tiedostoihin ja tietokantoihin.

5.2.1 Tiedostot

Lokalisoitua tekstiä sisältävät tiedostot voivat olla esimerkiksi HTML- tai JSP-tiedostoja tai esimerkiksi Javan lokalisointimerkkijonoja sisältäviä property-tiedostoja.

Esimerkiksi Windows 2000 -käyttöjärjestelmän Wordpad-ohjelma avaa ja tallentaa kyllä UTF-8-muodossa (Unicoden siirtomuoto, alakohta 2.2.3) olevia tiedostoja, mutta avaamisen jälkeen tallentaessa (muokattuna tai ei) tiedosto menettää Unicode-merkkinsä, mikäli tallennetaan suoraan ”Save” valitsematta uutta tallennusmuotoa. Wordpad-ohjelma antaa mahdollisuuden valita uudeksi tallennusmuodoksi ”Unicode”, joka tarkemmin tiedoston tavuja tarkasteltaessa paljastuu UTF‑16LE-muotoiseksi. Tämän muodon tiedosto ei hukkaa merkkejä enää uudestaan avattaessa ja tallennettaessa.

Notepad-ohjelma osaa avata ja tallentaa UTF‑8-tiedostoja (ohjelmassa ”UTF-8”) sekä UTF‑16LE/BE-tiedostoja (ohjelmassa ”Unicode” ja ”Unicode big endian”). Kuten Notepad-ohjelman ohje sanoo, kannattaa ohjelmassa käytettäväksi fontiksi valita jokin Unicode-merkkejä tukeva fontti kuten ”MS Sans Serif”, muutoin esimerkiksi kiinan- tai arabiankielinen teksti näkyy vain laatikkoina.

Yhteisenä hyvänä piirteenä ohjelmien tallentamista tavuista voidaan todeta, että tiedostojen alkuun tallentuvat Unicoden Byte Order Mark -tavut (BOM, alakohta 2.2.4). Vaikka BOM-tavujen avulla ohjelmat voivatkin todeta tiedostossa käytettävän koodauksen, ei tavuja hyödynnetä kaikissa ohjelmissa, editoreissa ja ohjelmointikielien kirjastoissa. Esimerkiksi suositun Eclipse Platform -kehitysympäristön [Ecli2005] tekstieditori ymmärtää UTF‑8‑koodatut tiedostot, kun asetuksissa kertoo käytettävän koodauksen, mutta BOM-tavuja editori ei ymmärrä, vaan esittää ne näkyvinä merkkeinä (esim. UTF‑8 BOM‑tavut näkyvät yhtenä pisteenä). Tämänkaltainen piirre korjataan tosin varmasti uudempiin versioihin.

Javassa ISO‑8859‑1‑merkistön ulkopuolella olevat merkit syötetään lähdekoodi- ja property-tiedostoihin käyttämällä koodinvaihtomerkintää (escaping) ”\uxxxx” [Java2005], jossa x-kirjaimet ovat merkin Unicoden koodipisteen arvo heksadesimaalina. Javan J2SE SDK -paketin mukana tuleva ”native2ascii”-ohjelma [Java2005] hoitaa koodauksen parametrina määritellystä merkistöstä ”\uxxxx”-muotoon, mutta BOM-tavut jäävät ymmärtämättä myös tältä ohjelmalta, joten kannattaa varmistua, ettei tiedoston luonnissa käytettävä ohjelma ole asettanut tiedoston alkuun BOM-tavuja.

5.2.2 Tietokanta

Tietokantojen tapauksessa tallentumismuoto on tietokantajärjestelmästä riippuvainen ja oleellisinta onkin, että tietokantajärjestelmän ja myös käytettävien tietokanta-ajureiden merkistömääritykset ja mahdolliset muunnosmääritykset on valittu sopivasti. Kannattaa selvittää, missä muodossa kantaan syötettävä tieto on ja missä muodossa kanta suostuu tiedon hyväksymään, jotta tallentamisen yhteydessä ei pääse tapahtumaan esimerkiksi tekstin korruptoitumista. Sama pätee tietenkin myös tietokantaan kohdistuviin hakuoperaatioihin.

5.3 Esityskerros

Verkkojärjestelmän esityskerros generoi tavalla tai toisella HTML-koodia. Sivun sisältö on varastoitu joko tietokantaan tai tiedostoihin, jotka sisältävät joko pelkkää leipätekstiä tai jopa kaiken muotoilun. Jälkimmäisessä tapauksessa HTML on jo valmiiksi generoitua, mutta muissa tapauksissa esitys rakennetaan dynaamisesti sivua kutsuttaessa.

5.3.1 Leipätekstin valinta ja sijoittaminen

Dynaamista sivua rakennettaessa on tavallista, että muotoilematon leipäteksti haetaan HTML-koodin joukkoon lokalisointiin tarkoitetuilla kutsuilla kuten ”getMessage” tai ”message”, joille annetaan parametriksi haettavan leipätekstin osan avain (key).

Esimerkiksi Sunin JavaServer Pages Standard Library (JSTL) toteutusta käytetään seuraavasti:

<fmt:message key="my.msg.key">

<fmt:param value="Matti"/>

</fmt:message>

Käytettävä lokaali voidaan asettaa fmt:setLocale-tunnisteilla (tag) tai koodissa ServletResponse-luokan setLocale-metodilla. Jos lokaalia ei erikseen määritellä joko HTML-kielen tunnisteella tai sovelluksen kontekstiparametreilla, oletustoteutus käyttää HTTP-kutsun Accept-Language-otsikkoa (header) parhaansa mukaan kohdassa 4.4 esitellyn kielivalintamekanismin mukaisesti. Lokalisoidun tekstin esittävä fmt:message-tunniste on toteutettu ResourceBundle-luokan avulla (luokan toimintaa esiteltiin kohdassa 4.2 yleisen valinta-algoritmin yhteydessä).

Esimerkissä haetaan leipätekstiä avaimella ”my.msg.key” ja tekstin joukossa olevat korvattavat kohdat määritellään fmt:param-tunnisteen mukaisesti. Jos lokaali olisi ”fi” ja avain osoittaisi tekstiin ”Tervetuloa keskustelupalstallemme, {0}!”, evaluoituisi sivulle teksti ”Tervetuloa keskustelupalstallemme, Matti!”.

Avoimeen lähdekoodin perustuva Java-pohjainen kehys Struts puolestaan tarjoaa seuraavan JSP-tunnisteen:

<bean:message key=”my.msg.key” arg0=”Matti”/>

Tälle tunnisteelle voidaan antaa eksplisiittisesti argumentiksi myös lokaali, joka on varastoituna java bean -olioon. [Stru2005]

Microsoftin ASP.NET-arkkitehtuurissa resurssitiedostoissa oleviin viesteihin päästään käsiksi System.Globalization.ResourceManager-luokan [Micr2005c] metodilla GetString:

<%=locRM.GetString("my.msg.key")%>

Esimerkin resurssimanageri locRM voidaan luoda:

locRM= new ResourceManager("LocProject.strings", typeof(WebForm1).Assembly);

5.3.2 Kuvat

Jos sivujen lokalisoinnissa on päädytty lokaalien hierarkiaa myötäilevään hakemistorakenteeseen (kohta 5.1, kuva 7), jossa kukin lokalisoitu sivusto sijaitsee, on luontevaa sijoittaa myös kuvat samaan hakemistoon HTML-sivujen kanssa. Tällöin kuvaan osoittavalle HTML‑kielen <img>‑tunnisteelle annetaan attribuutiksi vain suhteellinen polku kuvaan, jota ei tarvitse muuttaa eri kieliversioihin.

Vaikka sivut rakennettaisiinkin dynaamisesti ja teksti sivuille haettaisiin edellisessä alakohdassa (5.3.1) esitellyillä valintamekanismeilla, kannattaa kuvat edelleen sijoittaa lokaalihierarkiaa myötäilevään hakemistorakenteeseen. Kuvapolun valinta voidaan automatisoida esimerkiksi JSP-koodin itse toteutetuksi tunnisteeksi (custom tag) tai ASP.NET‑alustan web control ‑elementiksi. Valintamekanismit, jotka esiteltiin tekstin valintaan, löytyvät useista alustoista suoraan myös kuvaresurssien valintaan.

Kuvatiedostot ovat yleensä verkkojärjestelmien suurimpia tiedostoja. Kun kuvamateriaali lokalisoidaan, kasvaa tiedostojen määrä vielä moninkertaiseksi. Jotta verkkojärjestelmän toiminnan sujuvuus voidaan taata, kannattaa kuvat sijoittaa omalle palvelimelleen tai niille kannattaa ottaa käyttöön täysin oma verkon osa, jotta niiden lataaminen ei kuormita sovelluspalvelinta ja sen käyttämää verkkoa.

5.3.3 Päivämäärät, valuutat ja numerot

Päivämäärien, tietyssä valuutassa ilmaistujen rahasummien ja pelkkien numeroiden esitysmuodot vaihtelevat kulttuureittain. Esimerkiksi pelkkä englannin kieli ei vielä määrittele, miten päivämäärä ja kellonaika tulisi esittää amerikkalaiselle, englantilaiselle ja australialaiselle. Taulukossa 11 on esitettynä esimerkit päivämääristä ja kellonajoista.

Taulukko 11 - Esimerkki päivämääristä ja kellonajoista englanninkielisissä maissa

Lokaali	Päivämäärä ja kellonaika
en-US (amerikkalainen)	Tuesday, October 18, 2005 7:02:40 PM
en-GB (englantilainen)	18 October 2005 19:02:40 o'clock
en-AU (australialainen)	Tuesday, 18 October 2005 07:02:40 PM

Java API ja .NET-alusta tukevat näiden kansallisten piirteiden mukaista esittelyn muotoilua. Esimerkiksi päivämäärän ja kellonajan muotoilu Javalla [Java2005] onnistuu seuraavalla koodilla:

DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL, new Locale(s, s2));

String formattedDateTime = df.format(new Date());

5.3.4 Leipätekstin kielen lohkojen merkintä

Tekstissä käytettävä kieli vaikuttaa tekstin ladontaan ja ulkoasuun. Esimerkiksi ranskan kielen ladonnassa lauseen loppuun tulevan huutomerkin tai kysymysmerkin eteen tulee välilyönti, mutta jos tällainen lauseen loppu joutuu lähelle ladonnan tekemää automaattista rivinvaihtoa, ei huuto- tai kysymysmerkki kuitenkaan saa tippua seuraavalle riville ilman lauseen viimeistä sanaa. Ongelman voi kiertää käyttämällä HTML-kielen sitovaa välilyöntiä   (non-breaking space, [HTML401], kohta 9.3.2), joka kieltää selaimen ladontaa erottamasta ympärillä olevia sanoja toisistaan. Jos sisältö kuitenkin tulee lähteestä, jossa ei tunneta sitovaa välilyöntiä, on tekstiä käsiteltävä ennen kuin se soveltuu ranskankieliselle sivulle. Muita ladontaan vaikuttavia kielikohtaisia tekijöitä ovat tavutus ja sanojen tilankäyttö lauseen eri kohdissa. Myös lainausmerkkien ulkonäkö vaihtelee kielen mukaan. Kaikki nämä seikat voidaan kirjoittaa sisältönä (valitaan vain erilainen merkki lainausmerkille ja huolehditaan sitovista välilyönneistä), mutta jos tavoitteeksi asetetaan sisällön lopulliselle esittämiselle muitakin tapoja kuin visuaalinen esitys, kuten puhesynteesin tai automatisoidun kielenkääntämisen käyttö, pitää sisältöön liittää metatietoa, joka kertoo jotakin sisällön kielestä. Myös hakukoneet voivat hyödyntää kielitietoa.

Edellä todettujen syiden lisäksi W3 Consortium mainitsee sivullaan [HTML401] luvussa 8, että kielen lohkojen merkintää tarvitaan myös glyyfien valinnassa. Unicodessa merkit on yhtenäistetty siten, ettei kielieroa oteta huomioon merkkien koodien tasolla, vaikka merkeistä käytetään eri kielissä osittain erilaisia muotoja. Esimerkiksi CJK-merkkien (Chinese-Japanese-Korean) esittämisessä selaimien tulisi valita oikea esitysasu Unicode-merkille riippuen siitä, onko kyseessä kiinan, japanin vai korean kieli.

Jukka Korpela ottaa sivullaan ”Ongelmia kielimerkkauksen käytössä” [Korp2002] esimerkiksi Unicode merkin 40869, jonka glyyfi vaihtuu Microsoft Explorer 6.0 ja Mozilla Firefox 1.0.4 selaimilla kokeiltaessa. Kuva 8 esittää glyyfien eron.

Kuva 8 - Unicode merkin 40869 glyyfit eri kielillä [Korp2002]

HTML-koodissa useimpien elementtien kieli voidaan ilmaistaan lang-attribuutilla ([HTML401], luku 8), jonka arvo on ISO-639-1-kielikoodi [ISO639]. Esimerkiksi koko HTML-dokumentti merkitään ranskankieliseksi seuraavasti:

XML-elementeille vastaava määrittely tapahtuu xml:lang-attribuutilla ja XHTML 1.0 ‑spesifikaation liite HTML Compatibility Guidelines [XHTML1] suosittelee käytettäväksi molempia määritteitä yhteensopivuuden saavuttamiseksi, vaikka HTML-koodin lang-attribuutti onkin poistettu jo kokonaan XHTML 1.1 ‑määrittelystä ([XHTML11], ”A. Changes from XHTML 1.0 Strict”).

Ylemmän tason elementin kielimääritys periytyy alemman tason elementeille. Esimerkiksi yksittäinen taulu voidaan määritellä eri kielelle verrattuna muuhun HTML-dokumenttiin. Jos tekstin kieli vaihtuu, mutta uudelle kielelle ei ole omaa HTML-elementtiä, voidaan vaihtuneelle kielelle luoda oma lohkonsa uudella elementillä. Jos kyse on yksittäisestä sanasta tai muutamista peräkkäisistä sanoista, käytetään span-elementtiä, esimerkiksi:

XHTML 1.0 -spesifikaation <span lang="en">HTML Compatibility Guidelines</span>

Jos kyse on laajemmasta kokonaisuudesta, kuten peräkkäisistä kappaleista, käytetään div-elementtiä.

Myös Unicode-merkistö sisältää kielilohkojen merkitsemiseen tarkoitettuja merkkejä (U+E0000…U+E007F), jotka on otettu HTML-kielen merkistöön vain tukemaan tiettyjä Internet-protokollia. Koska merkit ovat mukana taaksepäin yhteensopivuuden saavuttamiseksi, niiden käyttöä ei suositella muualla. Esimerkiksi selaimien toteuttajia kehotetaan ohittamaan merkit. Sisällöntoimittajat voivat konvertoida merkit XML-elementeiksi sisällönmuokkaustilanteessa. [UTR20]

Kuten Korpelakin huomauttaa lopuksi sivullaan ”Muita erityiskysymyksiä” [Korp2002], HTML ja XML-dokumenttien alussa oleva esittely

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

ei viittaa dokumentin englanninkielisyyteen, vaan DTD-määrityksen kieleen, joka on englanti.

5.3.5 Kaksisuuntainen teksti (bi-directional text)

Vaikka edellisessä alakohdassa esitelty HTML-kielen lang-attribuutti vaikuttaakin esimerkiksi kiinan kielen tapauksessa tekstin ulkoasuun, ei attribuutti kuitenkaan määrittele tekstin ladontasuuntaa. [HTML401] esittelee kohdassa 8.2 dir-attribuutin tekstin ladontasuunnan määrittelemiseen ja erillisen <bdo>-elementin, jota voidaan käyttää, jos dir-attribuuttia ei voida lisätä mihinkään muuhun elementtiin.

Selaimet osaavat kyllä latoa oikein myös oikealta vasemmalle kirjoitettavia kieliä (esimerkiksi heprea ja arabia) päättelemällä ladontasuunnan suoraan käytetyistä merkeistä, mutta jos teksti sisältää lohkoja kielellä, jota ladotaan lohkon ulkopuolisen tekstin kanssa vastakkaiseen suuntaan, on lohkot merkittävä erikseen. Ilman merkintää kielen suunnan vaihtumisen rajalla olevat neutraalit merkit (esimerkiksi kysymysmerkit) voivat tulla esitetyksi väärässä paikassa, koska selain ei voi päätellä, kumpi rajalla olevista suunnista on merkitsevässä asemassa.

HTML-dokumenttien oletussuunta on ”vasemmalta oikealle”, joten oikealta vasemmalle kirjoitettavat osuudet tulee ympäröidä lohkoilla, joiden tunnisteet sisältävät kieliattribuutin lisäksi attribuutin dir, jonka arvoksi asetetaan rtl (right-to-left). Suunnan määräävä dir‑attribuutti periytyy samalla tavoin kuin kielen määräävä lang-attribuutti. Jos ylemmän lohkon tai koko HTML-dokumentin tekstin suunnaksi määrätään ”oikealta vasemmalle” <html dir=”rtl”>, voidaan suuntaan tehdä poikkeus asettamalla alemman tason HTML-elementtiin dir=ltr (left-to-right).

Ilman suuntaa määrittelevää attribuuttia selaimet esittävät esimerkiksi HTML-koodin

<body>

"Communities?" is

in Hebrew.

</body>

muuten oikein (edes span-elementtiä kielimäärityksineen ei tarvita), mutta kysymysmerkki tulee väärään päähän hepreankielistä sanaa:

"Communities?" is "?" in Hebrew.

Kun span-elementtiin lisätään oikea suunta heprean kielelle

saadaan esitys halutun näköiseksi:

"Communities?" is "?" in Hebrew.

Koodin ja tekstin muokkaamiseen tarkoitetut ohjelmat (esimerkiksi alakohdassa 5.2.1 mainitut Notepad, Wordpad ja Eclipse) esittävät ohjelma- ja HTML-koodin joukossa olevan oikealta vasemmalle ladottavan tekstin lopullisessa muodossaan. Vaikka muu HTML-koodi kirjoitetaankin ”normaalisti” vasemmalta oikealle, vaihtavat ohjelmat suunnan automaattisesti, kun koodin joukkoon kirjoitetaan esimerkiksi hepreankielisiä merkkejä.

Jos edellisen esimerkin lähdekoodia tarkastelee tavuesityksenä, käy ilmi, että hepreankielisen sitaatin merkit on tallennettu seuraavassa järjestyksessä:

ק ה י ל ו ת ?

Vaikka tekstin ladontasuunta muuttuu, teksti tallennetaan tiedostoon loogisessa lukujärjestyksessä.

5.3.6 Sivun merkistön asettaminen

Kansainvälisen järjestelmän toteuttamisessa paras vaihtoehto merkistöksi ja sen koodaukseksi on nykyään Unicode ja UTF-8 (esitelty kohdassa 2.2). Oleellista on kuitenkin ymmärtää, miksi ja mihin kaikkialle käytetty merkistö joudutaan määrittelemään.

Esitettävän sisällön ja lähdekoodin (esimerkiksi JSP tai ASP) tallennusmuoto (kohta 5.2) määritellään sovelluspalvelimelle asetuksin. Esimerkiksi alakohdassa 3.1.5 mainittu ASP.NET-alustan <globalization>-asetus sisältää lähdekooditiedostojen merkistökoodauksen määrittelevän <fileEncoding>‑tunnisteen (tag) ja JSP-koodissa taas on suositeltavaa määritellä pageEncoding-direktiivi, joka kertoo muodon, jossa JSP-sivu on tallennettu. Näiden asetusten avulla esimerkiksi dynaamisesti useasta palasta muodostettavat sivut saadaan rakennettua oikein, vaikka palojen tallennusmuodot palvelimella eroaisivatkin toisistaan. Jos myös oma ohjelmakoodi lukee sisältöä esimerkiksi tiedostosta, joudutaan tekemään muunnokset, joilla tallenne saadaan tulkituksi oikein. Muunnoksissa käytettävistä ohjelmointirajapinnoista kerrottiin enemmän alakohdassa 3.1.1.

Kun esitettävän sivun palojen tallennusmuodot ja palojen lukeminen on hallinnassa, määritellään palvelimelle asetuksilla tai ohjelmakoodilla koodaus, jonka muodossa palvelimen tulee lähettää sivu selaimelle. Useat palvelimet pystyvät tekemään muunnoksen lähettämisen yhteydessä. Esimerkiksi ASP.NET-alustan <globalization>-asetuslohko sisältää myös <responseEncoding>‑asetuksen, jolla määritellään lähetyksessä käytettävä koodaus.

Jotta selain tietäisi sivun esityksessä käytettävän merkistökoodauksen, HTTP-vastauksen Content-Type-otsikko ([HTTP11], kohta 14.17) tulee asettaa arvoon, jossa palvelin aikoo sivun selaimelle lähettää. HTTP-vastaukseen voidaan haluta esimerkiksi:

Content-Type: text/html; charset=UTF-8

Usein edellä mainittu tapa, jolla palvelimelle kerrotaan haluttu sivun lähettämisen koodaus, asettaa myös HTTP-vastauksen otsikon. Aina ei kuitenkaan ole näin ja vianselvitystilanteessa tästäkin seikasta on syytä olla tietoinen

HTTP-vastauksen otsikon lisäksi suositetaan toisinaan sitä, että sivun <head>‑lohkon <META http-equiv> ‑tunnisteilla kerrottaisiin vielä varmuudelta sivun esityksessä tarvittava merkistökoodaus ([HTML401], luku 5). Esimerkiksi:

Suuren sisältömäärän kanssa tämä on kuitenkin ylläpitonäkökulmasta ongelmallista. Jos sivun koodauksia halutaan jostain syystä vaihtaa, pitää myös <meta>‑tunnisteet vaihtaa. Jos sivut toisaalta rakennetaan dynaamisesti, voidaan <meta>-tunnisteet eristää omaan yleiseen palaan, joka monistetaan kaikille sivuille.

6 Toteutettava verkkojärjestelmä

Tämä luku esittelee kuvitteellisen järjestelmän, johon on koottu tyypillisimpiä todellisissa verkkojärjestelmissä olevia kansainvälistämiseen ja lokalisointiin liittyviä ominaisuuksia. Käyttötapauksissa ja toteutusratkaisuissa ei keskitytä käytettävyyteen tai tietoturvaan liittyviin kysymyksiin.

6.1 Yleinen kuvaus

Järjestelmä on uudistettu versio WWW-palvelusta, joka tarjoaa käyttäjilleen kansainvälisen keskustelufoorumin. Palveluun kirjautuneet käyttäjät luovat keskusteluaiheet ja osallistuvat mihin tahansa keskusteluun. Palvelun keskusteluita on mahdollista selailla ilman järjestelmään kirjautumista. Palveluun rekisteröitynyt käyttäjä voi kirjautua palveluun. Onnistuneen rekisteröitymisen jälkeen käyttäjän antamaan puhelinnumeroon tai sähköpostiosoitteeseen lähetetään rekisteröitymisen vahvistus.

Palvelun käyttäjät valitsevat kielen ja mahdollisen tarkemman lokalisoivan tekijän (maa, kielialue tai kulttuuri), jonka mukaan palvelun käyttöliittymä lokalisoituu tarvittaessa sekä ennen kirjautumista että kirjautumisen jälkeen. Oletuslokalisointi valitaan käyttäjän selaimen lähettämien tietojen perusteella. Lokalisointi vaikuttaa käyttöliittymän kieleen, tekstin ladontasuuntaan (vasemmalta oikealle tai oikealta vasemmalle), graafiseen ilmeeseen ja keskusteluaiheluettelon järjestämiseen. Kirjautuneiden käyttäjien tapauksessa järjestelmä tallentaa valitun lokaalin tietokantaansa.

Palveluun kirjautuneet käyttäjät voivat hakea palvelun muita käyttäjiä hakusanoilla, jotka ovat osa haettavan käyttäjän suku- tai etunimeä. Hakutulos esitetään hakevan käyttäjän lokaalin määräämässä järjestyksessä.

Järjestelmä on toteutettu käyttämään Unicode‑merkistöä. Järjestelmän vanhassa versiossa on käytetty kullekin kielelle perinteisesti ominaista merkistöä (esimerkiksi ISO‑8859‑perheen merkistöjä ja Big5‑merkistöä). Toisin sanoen vanhassa versiossa ei ole ollut mahdollista esittää erikielisiä keskusteluaiheita samassa luettelossa, vaan luettelo on voinut sisältää vain käyttäjän kulloinkin valitsemalla kielellä olevat aiheet. Käyttöliittymän lokalisointi on ollut sidottuna itse keskustelussa kulloinkin käytettävään kieleen, eikä välttämättä käyttäjän oman kulttuurin edellyttämällä tavalla.

6.2 Käyttötapaukset

Seuraavassa on kuvattu vain kansainvälistämisen ja lokalisoinnin kannalta oleelliset käyttötapaukset.

6.2.1 Sivuille saapuminen ja oletuslokalisointi

Saavuttaessa sivuille käyttäjällä ei ole aiempaa selainistuntoa (session). Sivu lokalisoituu käyttäjän valitseman internet-osoitteen URL-parametrien mukaan (esitelty kohdassa 4.6) tai parametrien puuttuessa selaimen HTTP-otsikon perusteella (kohta 4.4). Valittu sivu ei välttämättä ole etusivu, joten toteutuksessa on syytä varautua alustamaan istunto oletuslokalisointeineen jokaisen HTTP-kutsun yhteydessä. Jos kieltä ei voida päätellä minkään tekijän perusteella, oletuskieleksi valitaan tässä toteutuksessa englanti. Esimerkki järjestelmän englanninkielisestä etusivusta on kuvassa 9 .

Kuva 9 - Järjestelmän etusivu

Järjestelmälle varataan internet-osoite www.freechatforum.com. Jos järjestelmälle halutaan tulevaisuudessa varata myös maatunnuksiin päättyviä osoitteita on luontevaa, että järjestelmä tarjoaa URL-parametrien ja HTTP-otsikoiden puuttuessa etusivun kieleksi maan kansalaisten käyttämää kieltä. Jos maassa kuitenkin puhutaan useampia kieliä, joudutaan valitsemaan joko maan oletuskieli tai joudutaan tarjoamaan mahdollisuutta kielen valintaan ennen viralliselle etusivulle pääsyä kohdassa 4.3 esitellysti. Maatunnuksiin päättyvät internet-osoitteet eivät kuulu järjestelmän versioon, jota tämä lopputyö käsittelee.

Esimerkiksi suomenkieliselle etusivulle voisi päätyä seuraavilla internet-osoitteen valinnoilla:

· http://www.freechatforum.com?locale=fi-FI

· http://www.freechatforum.com (HTTP-kutsun otsikoissa (header) mukana ”Accept-Language: fi;q=1”)

Vaihtoehdoista ensimmäinen määrittelee lokaalin tarkasti ja se on voinut syntyä esimerkiksi käyttämällä selaimen kirjanmerkkejä (bookmark). Toisaalta kielivalinta ”?locale=en” ei vielä määrittelisi kuinka palvelussa käytettävät päivämäärät tulisi esittää, koska amerikkalainen, englantilainen ja australialainen esitystapa poikkeavat toisistaan (alakohta 5.3.1), joten tällöin joudutaan tekemään oletusvalintoja.

Useille kielille on luonteva spesifinen kulttuuri (specific culture, Microsoftin .NET-alustan termein), joka voidaan valita pelkän kielen eli ”neutraalin” kulttuurin (neutral culture) perusteella. Esimerkiksi .NET‑ ja Java-alustat valitsevat yhdysvaltalaisen kulttuurin englannin kielelle (”en-US”), jos pelkkä englannin kieli (”en”) on kulttuurin alkuperäisenä määritteenä. Päivämäärille ja kellonajoille saadaan ymmärrettävä oletusesitysmuoto, vaikka se ei olisikaan täysin oikea käyttäjän kannalta. Aina kielelle ei kuitenkaan ole alustan määrittelemää spesifistä kulttuuria. Poikkeustapauksia käsitellään tarkemmin alakohdassa 6.2.2.

Järjestelmän kaikkien sivujen merkistökoodaukseksi valitaan UTF-8 alakohdan 5.3.6 suosittelemalla tavalla, jotta kaikenkielisten keskustelujen otsikot voidaan esittää samanaikaisesti ruudulla.

HTML-koodissa on syytä käyttää lang-attribuutteja tunnisteille (tag), jotka rajaavat tietynkielistä sivun osuutta (kielimerkkausta käsiteltiin alakohdassa 5.3.4), jolloin selaimet valitsevat CJK-kielten glyyfit oikein. Teoriassa ranskan kielen kysymys- ja huutomerkit pysyvät myös tällöin kiinni lauseen viimeisessä sanassa, vaikka sanan jälkeen olisikin välilyönti kielen kirjoitusopin mukaisesti. Muilla kielillä irti kirjoitetun kysymysmerkin tulisi tipahtaa seuraavalle riville. Valitettavasti Internet Explorer 6.0 ja Mozilla Firefox 1.0.4 -selaimet eivät kokeilun perusteella tue viimeksi mainittua ominaisuutta. Internet Explorer pitää kysymysmerkin kiinni aina lauseen viimeisessä sanassa ja Mozilla Firefox tiputtaa kysymysmerkin seuraavalle riville.

6.2.2 Poikkeukset oletuslokalisointiin

Ainoa .NET-alustan (Microsoft .NET Framework 1.1) tuntema kieli, jolle alusta ei määritä neutraalia kulttuuria, on kiina. Neutraaleina kulttuureina toimivat kiinan tapauksessa merkittävästi toisistaan eroavat zh-CHS-lokaali (Chinese Simplified) ja zh-CHT (Chinese Traditional). Jälkimmäinen on pohjana Taiwanissa ja Hong Kongissa käytettävälle kiinan kielelle ja loput kulttuureista rakentuvat ensimmäisen varaan. Selaimet antavat kuitenkin usein mahdollisuuden valita kieleksi pelkän kiinan (ISO-639-1-koodi ”zh”, [ISO639]). Jos .NET valitaan toteutusalustaksi, tehdään kiinalle poikkeussivu, jolla tuetut kiinan kielen vaihtoehdot ovat valittavissa ennen etusivulle saapumista. Poikkeuksen toteuttaminen on nopeampaa kuin yleisen toteutuksen tekeminen.

Java-alustalla (versio 1.5.0) hindi on ainoa kieli, jolle ei ole neutraalia kulttuuria. Selaimen tarjotessa hindiä voidaan spesifiseksi kulttuuriksi valita poikkeuskoodilla suoraan lokaaleista löytyvä ”hi_IN”.

Jos aiemmin mainitut internet-osoitteiden maatunnukset otetaan jatkossa käyttöön, voidaan niiden perusteella tehdä oikean kiinan kielen valinta. Esimerkiksi jos maatunnus on ”.cn” (Kiinan tasavalta), valitaan zh-CN-lokaali (Chinese Simplified), tai maatunnuksen ollessa ”.tw” (Taiwan) valitaan zh-TW (Chinese Traditional). Tällöin kielivalintasivu joudutaan tekemään joka tapauksessa, jotta pelkän internet-osoitteen maatunnuksen ollessa saatavilla maassa puhutuista tasavahvoista kielistä ei jouduta valitsemaan oletusvaihtoehtoa (kohta 4.3).

6.2.3 Järjestelmän lokaalin valinta

Käyttäjä valitsee sivulla olevilla valitsimilla uuden kielen, jota on mahdollisesti tarkennettu esimerkiksi maan nimellä. Englannin kieli on esitetty englanniksi, suomen kieli suomeksi, arabian kieli arabiaksi, jne. Valitsimet on sijoitettu sivun ylämarginaaliin. Valintavaihtoehdot ovat näkyvillä ilman käyttäjän vuorovaikutusta, joten alkuperäisen sivun kieltä osaamaton voi helposti tunnistaa osaamansa kielen nimen sivulta, eikä joudu arvaamaan esimerkiksi mistä alasvetovalikosta kielivalinta löytyy (käyttäjän kielivalintaa käsiteltiin kohdassa 4.5).

Järjestelmän tuntemat valintavaihtoehdot mahtuvat yhdelle tai kahdelle riville riippuen selainikkunan leveydestä. Jos valintavaihtoehtojen määrä olisi suuri, jouduttaisiin vaihtoehtojen määrää rajoittamaan sivun asettelun ehdoilla. Tällöin vaihtoehdoiksi valittaisiin sivuston kannalta tärkeimmät kielet ja toteutettaisiin lisäksi erillinen valintasivu, jolta löytyisivät kaikki järjestelmän tuntemat vaihtoehdot.

Kuva 10 - Uuden lokaalin valinta

Esimerkiksi kuvassa 10 käyttäjä valitsee arabian kielen ja hän saa kuvan 11 esittämän sivun selaimeensa, jonka osoite sisältää lokaalin:

· http://www.freechatforum.com?locale=ar

Kuva 11 - Järjestelmään on valittu uudeksi kieleksi arabia

Uuden lokaalin valinnan jälkeen sivun sisältö päivittyy uuden lokaalin mukaisesti. Esimerkiksi päivämäärät ja sivun opasteet vaihtavat kieltä. Tarvittaessa ryhmittelyn suunta vaihdetaan koko sivulla oikealta vasemmalle. Jotta kuvassa 11 näkyvän suomenkielisen keskusteluotsikon kysymysmerkki pysyy otsikon oikeassa päässä, tulee jokaisen otsikon ympärille laittaa tekstin suunnan ja kielen määrittelevä tunniste (alakohta 5.3.5). Esimerkiksi:

<span dir="ltr" lang=”fi” xml:lang=”fi”>Mikä olympialaisissa meni pieleen?</span>

Käyttäjän tekemä valinta tallentuu palvelimen ylläpitämään selainistuntoon ja lisäksi valinnan seurauksena selaimelle lähetetty vastaus ohjataan URL-osoitteeseen, joka sisältää lokaalin parametrina. URL-parametrin avulla varmistetaan, että lokalisoidun sivun voi lisätä selaimen kirjanmerkkeihin (bookmark, kohta 4.6).

6.2.4 Rekisteröityminen

Käyttäjä valitsee sivulta rekisteröitymisen ja saa sivun, jolle hän syöttää nimensä, rekisteröinnissä luotavan käyttäjätunnuksen ja salasanan sekä halutessaan puhelinnumeron ja sähköpostiosoitteen. Lisäksi rekisteröitymissivulla valitaan rekisteröinnissä luotavalle käyttäjätunnukselle oletuslokaali, jonka oletusarvona on joko käyttäjän jo valitsema lokaali (6.2.3) tai järjestelmän valitsema oletuslokaali (6.2.1). Nimi‑, käyttäjätunnus- ja salasanakenttiin voi syöttää mitä tahansa Unicode-merkkejä. Jos käyttäjä on antanut rekisteröintilomakkeelle puhelinnumeron tai sähköpostiosoitteen, lähetetään hänelle rekisteröitymisestä vahvistus. Puhelinnumeroa ja sähköpostiosoitetta voidaan käyttää myös unohtuneen salasanan lähettämiseen, mutta salasanasta muistuttamista ei esitellä tässä määrittelyssä.

Alakohdassa 6.2.1 määriteltiin, että sivun esityksen koodaus on UTF‑8. Rekisteröintilomakkeen lähettämisen tulee tapahtua samassa muodossa, jotta käyttäjän nimi, käyttäjätunnus ja salasana tulevat järjestelmään oikein. Vallitsevan käytännön mukaisesti lomake lähetetään selaimesta koodauksessa, jossa sivu on käyttäjälle esitetty, joten lomakkeen esittelevä HTML-koodi ei tarvitse erillisiä lisämääritteitä (lomakkeen lähettämistä selaimelta palvelimelle käsiteltiin alakohdassa 3.1.4).

Lomakkeen kentät voivat tulla väärässä muodossa palvelimelle vain, jos käyttäjä valitsee selaimensa valikosta koodauksen, joka ei ole UTF‑8. Tällöin selaimen esittämä sivu on jo todennäköisesti visuaaliselta ilmeeltään rikki, joten käyttäjä ei välttämättä jatka rekisteröintiään. Tapaus voi kuulostaa harvinaiselta, mutta harvinaisimmistakin tapauksista voi kertyä paljon turhaa roskasisältöä käyttäjätietokantaan, kun kyseessä on globaali, paljon käytetty verkkojärjestelmä. Roskasisällön voi välttää sijoittamalla rekisteröintilomakkeeseen (ja tarvittaessa muihinkin järjestelmän lomakkeisiin) piilokentän, jonka arvon muodostavat merkit, joiden tiedetään korruptoituvan ongelmatapauksessa [YeDü1999].

Esimerkiksi UTF‑8‑koodauksessa selaimelle lähetetty sivu voi sisältää seuraavan piilokentän:

Jos selaimesta valitaan UTF‑8-koodauksen sijaan esimerkiksi Big5 kiinalaisten merkkien lähettämiseen, saa palvelin tavut

C3 B6 C3 A4 3F 3F

Vertaamalla saatua arvoa oikeaan, joka on

C3 B6 C3 A4 E2 82 AC

voi järjestelmä todeta euron merkin (”€”) olevan rikkoutunut ja palauttaa käyttäjälle virheilmoituksen, jossa pyydetään tarkistamaan selaimen merkistöihin liittyviä asetuksia.

Kun ilmoitus onnistuneesta rekisteröitymisestä lähetetään puhelimeen, ilmoitus koodataan mielellään ETSI GSM 03.38 ‑standardin esittelemällä matkapuhelimien perusmerkistöllä, joka esiteltiin kohdassa 2.3. Ilmoitukseen halutaan mukaan tervehdys, jossa käyttäjää puhutellaan nimellä, joten ilmoituksen pituus voi vaihdella. Esimerkiksi:

Tervetuloa keskustelufoorumillemme, Tuukka! --freechatforum.com

Jos ilmoitus tai puhutteluun käytetty nimi sisältää merkkejä perusmerkistön ulkopuolelta, koodataan viesti matkapuhelimien tukemaan UCS‑2-muotoon. Jotta rekisteröitymisilmoitus saadaan mahtumaan yhteen tekstiviestiin, on sisällöntoimittajalla oltava tiedossa puhuttelunimen maksimipituus ja valmiudet mitata viestin tilantarve eri kielten ja koodauksien tapauksissa.

Kun ilmoitus lähetetään rekisteröinnissä annettuun sähköpostiosoitteeseen, valitaan merkistö käyttäjän lokaalin mukaan. Tällöin vanhemmat postisovellukset esittävät sisällön ilman, että käyttäjä joutuu muuttamaan sovelluksensa asetuksia tai pahimmassa tapauksessa lukemaan rikkinäistä sisältöä (alakohta 3.1.2). Esimerkkejä lokaaleista ja niiden sähköpostimerkistöistä on esillä taulukossa 12.

Taulukko 12 - Esimerkkejä sähköpostin merkistökoodauksen valinnasta

Lokaali	Sähköpostimerkistö
en	US-ASCII
fi	ISO-8859-15
zh-CN	GB2312
zh-TW	Big5
ar	windows-1256

Tervehdyksessä käyttäjää puhutellaan jälleen nimeltä. Jos käyttäjän nimen merkit eivät ole edustettuina lokaalin mukaan valitussa merkistössä, lähetetään sähköposti UTF-8-koodattuna.

6.2.5 Kirjautuminen järjestelmään ja käyttäjälokaalin vaihtaminen

Kirjautumislomake lähetetään palvelimelle samalla tavalla kuin rekisteröinnin lomake. Onnistuneen kirjautumisen jälkeen sivu lokalisoituu käyttäjätietoihin liitetyn lokaalin perusteella. Jos käyttäjä vaihtaa kirjautumisen jälkeen lokaaliaan, tallentuu valinta alakohdassa 6.2.3 esitettyjen seikkojen lisäksi käyttäjätietoihin odottamaan seuraavaa kirjautumista.

6.2.6 Käyttäjähaku

Järjestelmään kirjautuneet käyttäjät voivat hakea muita palveluun rekisteröityneitä käyttäjiä etu- tai sukunimen osan perusteella. Jos haku osuu useampaan kuin yhteen käyttäjään, esitetään hakutulokset haun suorittaneen käyttäjän lokaalin määrittelemässä järjestyksessä. Tulos järjestetään ensisijaisesti sukunimen mukaan. Käyttäjällä on mahdollisuus selata järjestettyä hakutulosta kymmenen haetun käyttäjän sivuina, joita voi vaihtaa käyttöliittymässä olevilla selauslinkeillä.

Kuvan 12 tapauksessa englanninkielinen käyttäjä on kirjautunut järjestelmään ja päättänyt hakea suomenruotsalaista tuttavaansa, jonka etunimen hän on muistanut olevan Pekka. Sukunimestä hän ei ole ollut aivan varma, mutta mieleen on jäänyt, että sukunimi alkoi joko ”Ak..”, ”Åk..” tai ”Äk..”. Käyttäjä on asettanut hakuehdoksi sanan ”Pekka” ja luottanut englanninkielisenä siihen, että etsittävä sukunimi järjestetään listan alkupäähän, koska A-kirjain millä tahansa treemalla täydennettynä järjestetään aina esimerkiksi ennen B-kirjainta. Käyttäjä on löytänyt kuvassa 12 näkyvän käyttäjän, Pekka Åkerssonin.

Jos järjestelmä esittääkin hakutuloksen esimerkiksi suomalaisen järjestämistavan mukaisesti ilman että käyttäjälle kerrotaan sovelletusta järjestyksestä mitään, englanninkielinen käyttäjä saattaa olettaa, että Pekkaa ei löydy järjestelmästä. Eri kielien kulttuurien tapaa järjestää merkkijonoja käsiteltiin kohdassa 3.2.1.

Kuva 12 - Englanninkielinen käyttäjä on tehnyt käyttäjähaun

Jotta käyttäjähaku saadaan lokalisoitua erikielisille käyttäjille, tulee tietokannan käyttäjätaulu indeksoida jokaisen järjestelmän lokaalin mukaan. Haun suorittavan tietokantaproseduurin (stored procedure) tulee ottaa hakuparametriksi nimen osan lisäksi myös hakua suorittavan käyttäjän lokaali. Tietokannassa tapahtuvaa järjestämistä käsiteltiin kohdassa 3.2.6.

Hakutulos esitetään muiden käyttöliittymän osien tapaan lokalisoituna. Lokaalin mukaan tapahtuva järjestäminen on rajattu tietokantaan, joten mahdolliset erot tietokannan ja sovelluspalvelimen järjestämisalgoritmien välillä eivät tule näkyviin (kohta 3.2.7). Järjestelmää laajennettaessa on kuitenkin aina muistettava konfliktin mahdollisuus eri toimittajien (tässä tapauksessa tietokanta ja sovelluspalvelin) välillä.

7 Yhteenveto

Verkkojärjestelmien toteutuksessa käytettävät tekniikat ovat lähtöisin pääosin Yhdysvalloista ajalta, jolloin kansainvälistämisvaatimuksia ei määritellyt nykyisen laajuinen Internetin käyttäjäkunta. Erilaisia kansallisia ja valmistajakohtaisia merkistöjä on paljon ja niiden yhteensovittaminen on tuottanut ongelmia koko Internetin olemassaolon ajan. Lisäksi esimerkiksi HTML-lomakkeiden (forms) merkistömäärittely on puutteellinen siten, että väärinkäsityksiltä merkistön suhteen ei aina voida välttyä. Internetin protokollien oletusmerkistönä oleva ISO‑8859‑1 tulee korvautumaan vähitellen Unicode-merkistöllä, joka koodataan Internetissä mielellään UTF‑8-siirtomuotoon. Unicode-merkistön käytöllä vältytään paremmin tilanteilta, joissa merkistömuunnoksen vuoksi osa merkeistä hukataan. Merkistömuunnokset tulevat kuitenkin olemaan osa globaalien verkkojärjestelmien lähdekoodia vielä pitkän aikaa ja muunnoksia joudutaan tekemään myös integroiduttaessa muihin järjestelmiin.

Selaimien ja palvelimien suorittama kielivalintamekanismi on toimiva oikein käytettynä, mutta verkkojärjestelmän lokalisointia ei tule jättää pelkästään mekanismin varaan, koska mekanismin vaatimien käyttäjäasetuksien oikeellisuudesta ei ole aina takuita. Kielen valitsemiseksi on lisäksi syytä tarjota myös käyttöliittymätason ratkaisu, jolla käyttäjä voi valita haluamansa kielen. Sisällön lokalisointi suoritetaan tekstille, kuville, päivämäärille, valuutoille ja numeroiden esitysmuodoille. Lisäksi käyttöliittymän muotoilua joudutaan sovittamaan eri kielille ja kulttuureille sopivaksi. HTML ja ohjelmointikielten kirjastot tukevat lokalisointia hyvin, mutta niidenkin käytöstä löytyy väärinkäsityksien mahdollisuuksia.

Tässä lopputyössä käsitelty globaalin verkkojärjestelmän kansainvälistäminen ja lokalisointi ulotettiin käyttöliittymästä tietokantaan. Tarkoitus oli esitellä kansainvälistämisen vaikutusta järjestelmän kaikilla tasoilla. Samalla käsiteltiin eri tasoilla esiintyviä ongelmakohtia ja niiden ratkaisuja. Lopputyön aiheen rajaamisesta huolimatta käsiteltävää asiaa oli paljon ja useat aiheet pystyttiinkin esittelemään vain esimerkkien tasolla syvällisemmän käsittelyn sijaan. Paljon jouduttiin jättämään myös lukijan taustatietojen varaan esimerkiksi HTTP-protokollasta ja HTML-kielestä, joiden tuntemusta pidettiin esitietovaatimuksena lopputyön ymmärtämiselle.

Lähdeluettelo

[Apac2005]	The Apache Software Foundation Apache HTTP Server Version 2.0 Documentation Viitattu 16.10.2005 http://httpd.apache.org/docs/2.0/
[Brow2001]	Mike Brown, 02 Jan 2001 XML vs. HTTP: Issues affecting safe transport of XML over HTTP Viitattu 16.10.2005 http://skew.org/xml/misc/xml_vs_http/
[Czyb1998a]	Roman Czyborra's publications Good ole' ASCII Viitattu 14.10.2005 http://czyborra.com/charsets/iso646.html
[Czyb1998b]	Roman Czyborra's publications. The ISO 8859 Alphabet Soup Viitattu 14.10.2005 http://czyborra.com/charsets/iso8859.html
[Czyb1998c]	Roman Czyborra's publications. Codepage & Co. Viitattu 14.10.2005 http://czyborra.com/charsets/codepages.html
[Debi2005]	Software in the Public Interest, Inc. Debian Viitattu 16.10.2005 http://www.debian.org/
[Dürs2004]	Martin Dürst, The World Wide Web Consortium FAQ: Multilingual Forms, 2004-06-16 Viitattu 16.10.2005 http://www.w3.org/International/questions/qa-forms-utf-8
[Ecli2005]	Eclipse Foundation eclipse.org Viitattu 17.10.2005 http://www.eclipse.org
[EUC]	Wikipedia, the free encyclopedia Extended Unix Code Viitattu 14.10.2005 http://en.wikipedia.org/wiki/Extended_Unix_Code
[GSM0338]	ETSI - European Telecommunications Standards Institute Digital cellular telecommunications system (Phase 2+) (GSM); Alphabets and language-specific information (GSM 03.38) Viitattu 15.10.2005 http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=4690
[HKSCS]	Information Technology Services Department & Official Languages Agency Government of the Hong Kong Special Administrative Region, December 2001 Viitattu 15.10.2005 Hong Kong Supplementary Character Set - 2001 http://www.info.gov.hk/digital21/eng/hkscs/download/e_hkscs.pdf
[HTML401]	The World Wide Web Consortium HTML 4.01 Specification Viitattu 15.10.2005 http://www.w3.org/TR/html401/
[HTTP11]	The Internet Engineering Task Force Hypertext Transfer Protocol -- HTTP/1.1 Viitattu 15.10.2005 http://www.ietf.org/rfc/rfc2616.txt
[IBM2005]	IBM Developing J2EE Global Applications : Character Encoding Viitattu 16.10.2005 http://www-306.ibm.com/software/globalization/j2ee/encoding.jsp
[IRI]	The Internet Engineering Task Force Internationalized Resource Identifiers (IRIs) Viitattu 15.10.2005 http://www.ietf.org/rfc/rfc3987.txt
[ISO10646]	International Organization for Standardization Universal Multiple-Octet Coded Character Set (UCS), ISO/IEC 10646:2003 Viitattu 14.10.2005 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=39921
[ISO2022]	International Organization for Standardization Character code structure and extension techniques, ISO/IEC 2022:1994 Viitattu 14.10.2005 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=22747
[ISO3166]	International Organization for Standardization English country names and code elements Viitattu 16.10.2005 http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html
[ISO639]	Standards at the Library of Congress ISO 639.2, Codes for the Representation of Names of Languages Viitattu 16.10.2005 http://www.loc.gov/standards/iso639-2/englangn.html
[Jaka2005]	The Jakarta Project Commons Compress Viitattu 16.10.2005 http://jakarta.apache.org/commons/sandbox/compress/index.html
[Java2005]	Sun Microsystems, Inc. Java Technology Viitattu 14.10.2005 http://java.sun.com/
[JISX0201]	Japanese Industrial Standards Committee 7-bit and 8-bit coded character sets for information interchange JIS X 0201:1997, Japanese Standards Association, 1997
[Korp2000]	Jukka Korpela Tekniikoita monikielisiä Web-sivustoja varten Viitattu 16.10.2005 http://www.cs.tut.fi/~jkorpela/multi/
[Korp2002]	Jukka Korpela Kielimerkkaus: tekstin kielen ilmoittaminen merkkausjärjestelmissä Viitattu 16.10.2005 http://www.cs.tut.fi/~jkorpela/kielimerkkaus/
[Korp2003]	Jukka Korpela Flag as a symbol of language - stupidity or insult? Viitattu 16.10.2005 http://www.cs.tut.fi/~jkorpela/flags.html
[Lexi2005]	Lexico Publishing Group, LLC Dictionary.com Viitattu 25.10.2005 http://dictionary.reference.com
[LiOk2004]	Norbert Lindenberg and Masayoshi Okutsu, Sun Microsystems, May 2004 Article: Supplementary Characters in the Java Platform Viitattu 14.10.2005 http://java.sun.com/developer/technicalArticles/Intl/Supplementary/index.html
[Micr2005a]	Microsoft Corporation Transact-SQL Reference, SQL Collation Name Viitattu 16.10.2005 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ca-co_5ell.asp
[Micr2005b]	Microsoft Corporation .NET Framework General Reference, <globalization> Element Viitattu 16.10.2005 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfglobalizationsection.asp
[Micr2005c]	Microsoft Corporation Globalization and Localization Namespaces in Visual Studio Viitattu 16.10.2005 http://msdn.microsoft.com/library/en-us/vbcon/html/vxoriGlobalizationLocalizationNamespaces.asp?frame=true
[ORAC2005]	Oracle Corporation An Oracle Technical White Paper: Sorting Your Linguistic Data inside an Oracle Database, May 2005 Viitattu 24.10.2005 http://www.oracle.com/technology/tech/globalization/pdf/TWP_AppDev_Linguistic_Sorting_10gR2.pdf
[RFC1489]	The Internet Engineering Task Force Registration of a Cyrillic Character Set Viitattu 14.10.2005 http://www.ietf.org/rfc/rfc1489.txt
[RFC1766]	The Internet Engineering Task Force Tags for the Identification of Languages Viitattu 16.10.2005 http://www.ietf.org/rfc/rfc1766.txt
[RFC1922]	The Internet Engineering Task Force Chinese Character Encoding for Internet Messages Viitattu 15.10.2005 http://www.apps.ietf.org/rfc/rfc1922.html
[RFC2045]	The Internet Engineering Task Force Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies Viitattu 16.10.2005 http://www.ietf.org/rfc/rfc2045.txt
[RFC2070]	The Internet Engineering Task Force Internationalization of the Hypertext Markup Language Viitattu 16.10.2005 http://www.ietf.org/rfc/rfc2070.txt
[RFC2396]	The Internet Engineering Task Force Uniform Resource Identifiers (URI): Generic Syntax Viitattu 24.10.2005 http://www.ietf.org/rfc/rfc2396.txt
[Sche2001]	Markus Scherer, IBM Unicode Technology Group, IBM, 01 Feb 2001 Article: GB 18030: A mega-codepage Viitattu 14.10.2005 http://www-128.ibm.com/developerworks/library/u-china.html
[Stru2005]	The Apache Software Foundation Struts Bean Tags, message Viitattu 16.10.2005 http://struts.apache.org/userGuide/struts-bean.html#message
[TIS620]	National Electronics and Computer Technology Center Standard for Thai Character Codes For Computers, TIS 620 Viitattu 14.10.2005 http://www.nectec.or.th/it-standards/std620/std620.htm
[Topp2001]	Suzanne Topping, 01 May 2001 The secret life of Unicode: A peek at Unicode's soft underbelly Viitattu 15.10.2005 http://www-128.ibm.com/developerworks/unicode/library/u-secret.html?dwzone=unicode
[Unic2004a]	Unicode Consortium, Unicode, Inc The Unicode® Standard: A Technical Introduction Viitattu 14.10.2005 http://www.unicode.org/standard/principles.html
[Unic2004b]	Unicode Consortium, Unicode, Inc. The Unicode Standard 4.0: Chapter 3.9 Unicode Encoding Forms Viitattu 14.10.2005 http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf
[UTR20]	Martin Dürst ja Asmus Freytag, 13 June 2003 Unicode Technical Report #20, Unicode in XML and other Markup Languages Viitattu 25.10.2005 http://www.unicode.org/reports/tr20/
[UTS10]	Mark Davis & Ken Whistler, 2005-05-05 Unicode Technical Standard #10, Unicode Collation Algorithm Viitattu 14.10.2005 http://www.unicode.org/reports/tr10/
[UTS15]	Mark Davis & Martin Dürst, 2005-03-25 Unicode Technical Standard #15, Unicode Normalization Forms Viitattu 14.10.2005 http://www.unicode.org/reports/tr15/
[W3C2002]	The World Wide Web Consortium Most popular charsets Viitattu 14.10.2005 http://www.w3.org/International/O-charset-lang.html
[WIKI2005]	Wikipedia, the free encyclopedia SQL Viitattu 24.10.2005 http://en.wikipedia.org/wiki/SQL
[WORD2005]	WordIQ.com Definition of Collation Viitattu 26.10.2005 http://www.wordiq.com/definition/Collation
[XForms]	The World Wide Web Consortium XForms - The Next Generation of Web Forms Viitattu 16.10.2005 http://www.w3.org/MarkUp/Forms/
[XHTML1]	The World Wide Web Consortium XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) Viitattu 16.10.2005 http://www.w3.org/TR/xhtml1/
[XHTML11]	The World Wide Web Consortium XHTML™ 1.1 - Module-based XHTML Viitattu 16.10.2005 http://www.w3.org/TR/xhtml11/
[YeDü1999]	François Yergeau & Martin Dürst, 31 August 1999 Weaving the Multilingual Web - 15th International Unicode Conference Viitattu 16.10.2005 http://www.w3.org/Talks/1999/0830-tutorial-unicode-mjd/
[ZIP]	PKWARE, Inc. General Format of a ZIP file Viitattu 24.10.2005 ftp://ftp.uu.net/pub/archiving/zip/doc/appnote-970311-iz.zip