> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/fi/syvalliset-artikkelit/51-unicode-utf-8-and-multilingual-text-an-introduction.md).

# Unicode, UTF-8 ja monikielinen teksti: johdanto

## Unicode ja OpenType: Merkit ja glyfit

Nykyaikaiset TeX-moottorit, eli XeTeX ja LuaTeX, ovat kehittyneet Knuthin alkuperäisestä TeX-moottorista suurelta osin tarpeesta pysyä teknologisen kehityksen tahdissa, erityisesti Unicodea (tekstiä varten) ja OpenTypea (fontteja varten) koskevan kehityksen mukana. Nykyään pakettien, kuten [fontspec](https://ctan.org/pkg/fontspec?lang=en) ja [unicode-mathiin](https://ctan.org/pkg/unicode-math?lang=en), LaTeX-käyttäjät voivat käyttää OpenType-fonttien tarjoamia erittäin kehittyneitä ladontamahdollisuuksia – mukaan lukien edistynyt monikielinen ladonta ja OpenTypeen perustuva matemaattinen ladonta ([Microsoftin uranuurtama](https://blogs.msdn.microsoft.com/murrays)).

Kuitenkin, jotta OpenType-fonttien käytöstä XeTeXin/LuaTeXin kanssa saisi kaiken irti, voi olla hyödyllistä perehtyä useisiin taustakäsitteisiin ja -aiheisiin — erityisesti vianmääritystä varten tai jotta tie avautuisi edistyneempään ja monimutkaisempaan työskentelyyn. Voit esimerkiksi lukea, että XeTeX- ja LuaTeX-moottorit käyttävät “UTF-8-syötettä” tai että ne ovat “Unicode-tietoisia”, ja OpenType-fontteja koskeva lisälukeminen saattaa käsitellä tai mainita aiheita kuten “Unicode-koodaus”, OpenType-fonttien “fonttiominaisuudet”, “glyfit”, “glyfitunnisteet”, “glyfien nimet” ja niin edelleen. Tavoitteenamme on antaa johdatus näihin termeihin ja aiheisiin sekä hahmotella perusrakenne, joka näyttää, miten ne liittyvät toisiinsa ja joka toivottavasti tukee jatkotyötä tai ongelmanratkaisua.

Käsiteltävät aiheet jakautuvat melko selvästi kahteen pääalueeseen: *Unicode* joka käytännössä kuuluu tekstin/merkkien ja tekstikoodauksen maailmaan ja *OpenType* jonka maailma on fonttien ja glyfien maailmaa; mutta tietenkin nämä kaksi maailmaa ovat yhteydessä toisiinsa ja niiden välillä on jonkin verran päällekkäisyyttä, jopa tässä ensimmäisessä artikkelissa.

### Mitä aiheita aiomme käsitellä?

Tämän artikkelin pääpaino on eräissä Unicodeen liittyvissä aiheissa: aluksi käsitellään sitä, mitä tarkoitetaan ”merkillä”, ja sen jälkeen esitellään kirjoitusjärjestelmiä/kieliä, Unicode-koodausta ja UTF-8:aa — sekä esimerkki monikielisten tekstitiedostojen käsittelystä. Seuraava artikkeli rakentuu tämän tekstin varaan ja käsittelee OpenType-fonttiteknologiaan liittyviä taustakäsitteitä. On selvää, että blogikirjoituksen puitteissa ei ole mahdollista yrittää tehdä ”syväluotausta” kaikkiin niihin alueisiin, joista toivomme voivamme keskustella: nimenomaisena tavoitteenamme on antaa kokonaiskehys, joka näyttää, miten muutamat keskeiset käsitteet liittyvät toisiinsa ja toimivat yhdessä. Aloitamme peruskäsitteestä: *merkkiä*.

## Merkki: perusrakennuspalikka

Keskeinen ajatus/käsite, joka on keskustelujemme (ja Unicodeen liittyvän keskustelun) ytimessä, on sanan ”merkki” merkitys: se on yksi niistä sanoista, joiden merkitys usein ”oletetaan” päivittäisessä työssä ja keskusteluissa. Unicodea, ladontaa ja fonttiteknologioita tarkasteltaessa meidän on kuitenkin oltava hieman täsmällisempiä ja määriteltävä, mitä ”merkki” tarkoittaa. Esimerkiksi meille saattaa tuntua aivan luonnolliselta ajatella **a** ja *a* eri ”merkkeinä”: ’lihavoitu a’ ja ’kursivoitu a’. Mutta ei: ne ovat vain saman perusmerkin eri visuaalisia esitystapoja, jolle Unicode antaa virallisen nimen [LATIN SMALL LETTER A](http://unicode.org/charts/PDF/U0000.pdf).

Unicode [määrittelee merkin](http://www.unicode.org/glossary/#character) näin:

> “Kirjoitetun kielen pienin semanttista arvoa sisältävä osa; viittaa abstraktiin merkitykseen ja/tai muotoon, ei tiettyyn ulkoasuun...”

joka tekee selkeän eron merkin tietyn *ulkoasuun* ja sen *merkityksen*.

Merkkiä voi ajatella kielen perusyksikkönä tai rakennuspalikkana, tai tarkemmin sanottuna, kirjoitusjärjestelmän *kirjoitusjärjestelmälle*—aihe, jota käsittelemme alla. Se, miltä merkki itse asiassa näyttää tietyllä fontilla esitettynä, ei ole olennaista Unicodeen kuuluvan merkin määritelmässä: vain *merkityksen* on tässä todella olennaista: merkin *rooli ja tarkoitus* kunkin merkin osana rakennuspalikoiden joukkoa, joista kirjoitusjärjestelmät/kielet lopulta rakentuvat.

### Kirjoitusjärjestelmä ja kieli

Kaksi tärkeää käsitettä on syytä mainita lyhyesti: *kirjoitusjärjestelmät* ja *kielissä*. Unicode-verkkosivusto tarjoaa hyödyllisen [kirjoitusjärjestelmän määritelmän](https://www.unicode.org/standard/supported.html):

> “Unicode-standardi koodaa kirjoitusjärjestelmiä eikä kieliä. Kun useamman kuin yhden kielen kirjoitusjärjestelmät jakavat historiallisesti sukua olevia graafisia symboleja sisältäviä merkistöjä, kaikkien näiden graafisten symbolien yhdistelmää käsitellään koodauksessa yhtenä merkkien kokoelmana ja se tunnistetaan yhdeksi kirjoitusjärjestelmäksi.”

Käyttäen  [Wikipedia-esimerkkiä](https://en.wikipedia.org/wiki/Script_\(Unicode\)), latinalainen kirjoitusjärjestelmä koostuu tietystä [merkkien kokoelmasta](http://unicode.org/charts/) joita käytetään useissa kielissä: englannissa, ranskassa, saksassa, italiassa ja niin edelleen. Tietenkään kaikkia latinalaiseen kirjoitusjärjestelmään määriteltyjä merkkejä eivät käytä kaikki siihen perustuvat kielet — esimerkiksi englannin aakkostossa ei ole niitä aksentillisia merkkejä, joita esiintyy muissa eurooppalaisissa kielissä, kuten ranskassa tai saksassa.

### OpenType-fontit: kirjoitusjärjestelmät ja kielet

Tässä vaiheessa siirrymme Unicode-maailmasta OpenType-fontteihin, koska kirjoitusjärjestelmän ja kielen käsitteet ovat erittäin tärkeässä roolissa myös OpenType-fonttiteknologiassa.

Joukko kieliä, jotka käyttävät samaa [kirjoitusjärjestelmälle](http://www.unicode.org/glossary/#script) voi kullakin olla erilaiset typografiset perinteet, kun kyseisen kielen tekstin näyttämisestä (ladonnasta) on kyse. Hyvä esimerkki on turkin kieli ja [pisteettömän i:n käyttäytyminen](https://en.wikipedia.org/wiki/Dotted_and_dotless_I) (katso kyseisen sivun huomautukset ligatuureista). Kirjoitusjärjestelmiin ja kieliin liittyvät typografiset ”säännöt” on rakennettu OpenType-fonttien toiminnallisuuteen niin sanottujen script- ja language *tunnisteita* tunnisteiden avulla, joita käytetään määrittämään säännöt, joiden tulisi koskea tiettyjä kirjoitusjärjestelmä/kieli-yhdistelmiä. Luonnollisesti kunkin OpenType-fontin tukemien kirjoitusjärjestelmien/kielten joukko vaihtelee fontin tekijöiden valintojen ja fontin käyttötarkoituksen mukaan. Kehittynyt ladontaohjelmisto, kuten XeTeX tai LuaTeX, voi hyödyntää näitä sääntöjä (jotka on rakennettu OpenType-fontteihin) sallimalla käyttäjien soveltaa niitä valikoivasti syötetyn tekstin ladonnassa, kun tekstiä ladotaan tietyllä kielellä — esimerkiksi käyttämällä LaTeX- [fontspec-pakettia](https://ctan.org/pkg/fontspec?lang=en).

#### Kurkistus OpenType-fontin sisään: kirjoitusjärjestelmät/kielet

Selvennyksen vuoksi tässä on kuvakaappaus, jossa näkyy ilmainen [Scheherazade OpenType -fontti](http://software.sil.org/scheherazade/download/) avattuna myös ilmaisen [Microsoft VOLT](https://www.microsoft.com/en-us/Typography/volt.aspx) -fontinmuokkausohjelmiston sisällä. Tässä kuvassa voit nähdä Scheherazadeen sisäänrakennetut kirjoitusjärjestelmät, kielet ja typografiset ominaisuudet — VOLTin avulla voit lisätä Scheherazadeen lisäominaisuuksia ja toiminnallisuutta, mutta se menee täysin tämän artikkelin aihepiirin ulkopuolelle!

![Scheherazade OpenType -fontti (TrueType-variantti) avattuna Microsoft VOLTissa](/files/c0344e2fe874424a4f63a7511e3d87a90f7e380b)

Tästä kuvakaappauksesta näet, että Scheherazade tukee arabian ja latinan kirjoitusjärjestelmiä ja tarjoaa lisäerityistukea useille arabian kirjoitusjärjestelmää käyttäville kielille — käyttämällä niin sanottuja OpenType-ominaisuuksia, jotka on lueteltu yllä olevassa vihreäreunaisessa laatikossa. Emme mene näiden ominaisuuksien yksityiskohtiin, mutta viesti tässä on se, että korkealaatuisissa OpenType-fonteissa on paljon älykkyyttä sisäänrakennettuna, valmiina ladontaohjelmiston käyttöön, joka osaa hyödyntää fontteihin rakennettuja typografisia sääntöjä.

Kiinnostunut lukija voi selata OpenType-tunnisterekisteriä nähdäkseen [kirjoitusjärjestelmätunnisteet](https://www.microsoft.com/typography/otspec/scripttags.htm) ja [kielitunnisteet](https://www.microsoft.com/typography/developers/opentype/languagetags.aspx) jotka ovat tällä hetkellä käytössä OpenType-määrityksessä.

### Takaisin merkkeihin: eri merkkiroolit

Kirjoitusjärjestelmän (tai kielen) peruselementit muodostavat merkit eivät kaikki toimi samassa roolissa. Esimerkiksi useimmissa kielissä on merkkejä *välimerkkejä*, merkkejä numeerisille *numeroille* sekä merkkejä, joita pidämme *kirjaimina* aakkosten kirjaimina, joilla joissakin kirjoitusjärjestelmissä on myös suura- ja pienaakkosmuodot. Merkin käsite on varsin laaja, ja Unicode-standardi sisältää erikoismerkkejä, joita *ei ole suunniteltu näytettäviksi* mutta joiden tehtävänä on ”ohjata tekstin tulkintaa tai näyttämistä”. Esimerkiksi ladottaessasi arabialaista tekstiä saatat haluta pakottaa tiettyjen merkkien liittämiskäyttäytymisen tai estää sen; Unicode-standardi tarjoaa tähän erityisiä ohjausmerkkejä: niin sanotut [ZERO WIDTH JOINER](https://en.wikipedia.org/wiki/Zero-width_joiner) ja [ZERO WIDTH NON-JOINER](https://en.wikipedia.org/wiki/Zero-width_non-joiner). Nuo merkit eivät ole tarkoitettu näytettäviksi, ja ohjelmisto ”imee” ne itseensä käsitellessään tekstiä tuottaakseen niille tarkoitetut visuaaliset vaikutukset.

Kaikille Unicode-standardissa määritellyille merkeille annetaan joukko ominaisuuksia, jotka käytännössä kuvaavat kunkin merkin roolia ja tarkoitusta Unicode-koodauksessa — merkkien nimet, kuten LATIN SMALL LETTER A, ovat vain yksi osa merkin ominaisuusluetteloa. Nämä ominaisuudet kuvataan kokonaisuudessaan [Unicode Character Database (UCD)](http://www.unicode.org/reports/tr44/) ja niitä käytetään laajalti tietokonepohjaisissa tekstinkäsittelytoiminnoissa, kuten haussa, lajittelussa, oikeinkirjoituksen tarkistuksessa ja niin edelleen. Unicode-merkkien ominaisuuksia luettelevat datatiedostot ovat myös [ladattavissa](http://www.unicode.org/Public/UCD/latest/).

Kullekin merkille annetuista ominaisuuksista tärkein keskustelumme kannalta on *numeerinen tunniste* jonka sen Unicode-koodaus määrittää; siirrymme siihen nyt.

### Merkit: numerot ja koodaukset

On itsestään selvää, että tietokoneet ja muut digitaaliset laitteet tallentavat ja käsittelevät numeerista dataa: miten tämä siis liittyy tekstiin? Kun kirjoitat tekstiä tietokoneen näppäimistöllä tai napauttelet mobiililaitteen näyttöä, näppäinpainalluksesi muunnetaan numeroiksi, jotka edustavat kirjoittamaasi merkkijonoa.

Jossakin vaiheessa saatat haluta siirtää tuon tekstin (numerojoukon) sähköpostissa, tekstiviestissä tai verkkoviestinnän kautta, kuten twiitissä tai sosiaalisen median julkaisuissa. On selvää, että laitteen, jolla kirjoitit tekstin, ja vastaanottajan käyttämien laitteiden on jotenkin sovittava siitä, mitkä numerot edustavat mitäkin merkkejä. Muuten tekstisi ei ehkä näy oikein vastaanottajan laitteessa.

Jotta nykyinen globaali viestintä toimisi, lähettävien ja vastaanottavien laitteiden on sovittava jostakin ”yhteisesti sovitusta käytännöstä”, jossa tietty numerosarja edustaa tiettyä merkkijoukkoa. Tätä käytäntöä kutsutaan *koodaus*: joukko numeroita, joita käytetään tietyn merkkijoukon esittämiseen, ja Unicode-koodaus on nykyään *de facto* maailmanlaajuinen standardi.

## Unicode: bitit ja tavut tekstin tallentamiseen

Unicode on valtava standardi, joka kattaa paljon, paljon enemmän kuin pelkän tekstikoodauksen, mutta tässä keskitymme vain sen tarjoamaan koodaukseen.

#### Bitit, tavut ja kuinka monta merkkiä?

Mainitsimme, että laitteet tallentavat ja esittävät tekstiä numeroina — tarkemmin sanottuna merkit tallennetaan kokonaislukuina. Ymmärtääksemme, mitä tämä merkitsee Unicode-koodaukselle, meidän on tehtävä *erittäin* lyhyt, *erittäin* perustason kertaus siitä, miten tietokoneet tallentavat kokonaislukuja (emme aio syventyä tietojenkäsittelytieteeseen).

Jos lyhennämme hyvin pitkän tarinan: nykyiset pöytäkoneet ja käsilaitteet tallentavat kokonaislukuja erillisissä ”paloissa”, jotka voivat olla 1, 2, 4 tai 8 tavua pitkiä. Kukin näistä tallennusyksiköistä voi tallentaa kokonaislukuja enintään tiettyyn positiiviseen arvoon saakka sen mukaan, kuinka monta bittiä kuhunkin tallennusyksikköön sisältyy:

* 1 tavu (8 bittiä): suurin positiivinen kokonaisluku on 255;
* 2 tavua (16 bittiä): suurin positiivinen kokonaisluku on 65535;
* 4 tavua (32 bittiä): suurin positiivinen kokonaisluku on 4,294,967,295;
* 8 tavua (64 bittiä): suurin positiivinen kokonaisluku on 18,446,744,073,709,551,615.

Käytännössä Unicode-standardi käyttää numeroita alueella 0–1,114,111 kaikkien maailman merkkien koodaamiseen, ja tuloksena on, että koko alueen koodaamiseen tarvitaan vain 21 bittiä. Tämä nähdään siitä, että n bittiä sisältävät tallennusyksiköt voivat esittää minkä tahansa positiivisen kokonaisluvun nollasta enimmäisarvoon $$2^n -1$$; näin ollen:

* 20 bitillä tallennettava enimmäisarvo on $$2^{20} -1 = 1,048,575$$ (liian pieni);
* 21 bitillä tallennettava enimmäisarvo on $$2^{21} -1 = 2,097,151$$ (riittävän suuri).

Olemme todenneet, että tietokoneet tallentavat dataa (numeroita) 1, 2, 4 (tai 8) tavun yksiköissä, joten kuinka suuri tallennusyksikön on oltava, jos meidän täytyy tallentaa arvoja Unicode-maksimiarvoon 1,114,111 saakka? On selvää, että tavun kokoinen tallennusyksikkö voi sisältää enintään arvon 255 ja 2 tavua voi tallentaa 65535: kumpikaan ei riitä Unicodeen koodatun merkkialueen koko laajuudelle. Seuraava käytettävissä oleva vaihtoehto on 4 tavun kokoiset tallennusyksiköt, joihin voidaan tallentaa kokonaislukuja enintään arvoon 4,294,967,295 saakka, mikä on paljon enemmän kuin todella tarvitsisimme. Jos siis valitsisimme tallennusyksiköksi 4 tavua, meillä olisi varmasti enemmän kuin tarpeeksi tilaa kaikkien Unicode-arvojen tallentamiseen, ja kukin merkki tallennettaisiin kokonaislukuna, joka vaatii 4 tavua (32 bittiä). Kuitenkin 4 tavun käyttäminen kaiken tallentamiseen on tilan kannalta hyvin tuhlaavaa, koska jopa suurimmat Unicode-arvot tarvitsevat enintään 21 bittiä — mikä, jos tallennettaisiin 32 bitillä, tarkoittaisi, että 32 bitistä 11 ei koskaan käytettäisi.

**Huomaa**: Vaikka Unicode-alue ulottuu arvosta 0 arvoon 1,114,111, kaikkia tuon alueen arvoja ei itse asiassa käytetä: teknisistä syistä joitakin arvoja pidetään virheellisinä Unicode-merkkeinä käytettäviksi.

### Mikä sitten on UTF-8?

Jos luet XeTeXistä tai LuaTeXistä, kohtaat lähes varmasti selityksiä, joissa todetaan, että nämä TeX-moottorit lukevat tekstiä ja LaTeX-syötetiedostoja “UTF-8-muodossa”. Mitä siis on “UTF-8-muoto” ja miten se liittyy Unicodeen? Unicode-termeillä kukin sen 1,114,112 arvosta (alueella 0–1,114,111), joita käytetään maailman merkkien koodaamiseen, kutsutaan [koodipisteeksi](http://www.unicode.org/glossary/#code_point).

Olemme nähneet, että *teoriassa*meidän olisi tallennettava kaikki Unicode-koodattu tekstimme 4 tavua merkkiä kohden, jotta Unicode-koodipisteiden koko alue saataisiin esitettyä. Käytännössä kuitenkin jotkut varsin nerokkaat ihmiset keksivät yksinkertaisen tavan esittää yksi Unicode-numero (koodipiste) *sarjalla* pienempien numeroiden sarjana, joista kukin niistä tallennetaan yhteen tavuun: prosessi, joka *muuntaa* yhden (suuremman) kokonaisluvun pienempien, tavun kokoisten arvojen sarjaksi. Tämän muunnoksen vuoksi tekstitiedostomme merkit eivät enää ole kukin yhden numeerisen arvon esittämiä: jokaisesta merkistä tulee *monitavuinen sarja*—tekstitiedostossa mikä tahansa 1–4 (peräkkäistä) tavua voi edustaa yhtä yksittäistä Unicode-merkkiä (eli sen koodipistearvoa).

UTF on lyhenne sanoista *Unicode-muunnosmuoto* ja avainsana tässä on *muunnos*. Pohjimmiltaan UTF-8:a voi ajatella ”reseptinä” tai algoritmina, joka muuntaa yhden Unicode-koodipisteen arvon 1–4 tavun kokoisten palasten sarjaksi. Unicode-koodipisteen arvon kasvaessa kasvaa myös niiden yksittäisten tavujen määrä, joita tarvitaan sen esittämiseen UTF-8-muodossa.

UTF-8:n luomiselle on teknisiä ja historiallisia syitä, ja UTF-8:n keksimisen tausta on [tallennettu kiehtovaan sähköpostiviestiin vuodelta 2003](https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), jossa sähköpostin alkuosassa on rivi:

> “Se ei pidä paikkaansa. UTF-8 suunniteltiin silmieni edessä eräänä yönä syyskuussa 1992 New Jerseyn dinerissä pöytätabletille.”

#### Esimerkki: arabian kirjain ل

Käytetään esimerkkinä arabian kirjainta ل (Unicode-nimi ARABIC LETTER LAM), jolle on annettu Unicode-koodipistearvo 1604 (desimaali) tai 0644 (heksadesimaali): sen esitys UTF-8:ssa on *kaksitavuinen* sekvenssi D9 84 (heksadesimaalisena) eli desimaaleina 217 132. Kun UTF-8:aa käytetään tekstin tallennusmuotona, sen sijaan että tekstitiedosto sisältäisi yhden luvun 1604 esittämään ل-kirjainta, se muunnetaan kahdeksi tavun kokoiseksi arvoksi: 217 ja 132 — merkki ل tallennetaan *kaksitavuisena sarjana*. Lukijat, jotka haluavat tutkia UTF-8-algoritmia tarkemmin, löytävät perusteellisen selityksen ja C-koodin minun [henkilökohtaisessa blogisivustossa](http://www.readytext.co.uk/?p=1284).

Kun ohjelmisto (esim. XeTeX tai LuaTeX) lukee UTF-8-muotoista tekstiä, sen on määritettävä kyseisessä tiedostossa olevan kunkin merkin Unicode-arvo, joten se käyttää algoritmia *kääntää* UTF-8-muunnosprosessin purkamiseen. Tällä ”käänteisalgoritmilla” nämä kaksi tavua (217 ja 132) yhdistetään uudelleen kokonaisluvuksi 1604, joka voidaan sitten tunnistaa arabian kirjaimen ل Unicode-koodipistearvoksi.

Lopuksi siis UTF-8 on todella vain välimuotoinen datamuoto, jota käytetään Unicode-koodatun tekstin tallentamiseen ja siirtämiseen.

**Huomaa**: Jotkin järjestelmät valitsevat käyttää/tallentaa tekstiä 32 bittiä merkkiä kohden; tätä kutsutaan [UTF-32](https://en.wikipedia.org/wiki/UTF-32)—on myös [UTF-16](https://en.wikipedia.org/wiki/UTF-16) mutta UTF-8 on yleisin tapa tallentaa Unicode-koodattua tekstiä.

## Monikieliset TeX-tiedostot: XeTeX ja LuaTeX

Sekä XeTeX että LuaTeX pystyvät hyvin kehittyneeseen monikieliseen ladontaan, vaikka niiden mekanismit tämän saavuttamiseksi ovat varsin erilaisia ja heijastavat kummankin moottorin suunnittelu- ja kehitysfilosofiaa. Emme mene tähän syvällisesti, vaan toteamme vain, että XeTeX-moottori sisältää ohjelmakomponentteja (sisäänrakennettuina sen suoritettavaan tiedostoon), joita ei ole LuaTeXissä — merkittävimpänä ohjelmisto prosessiin nimeltä *OpenType-muotoilu* (esim. kirjaston kautta nimeltä [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)).

LuaTeX puolestaan omaksuu erilaisen lähestymistavan: sen sijaan että toimintoja rakennettaisiin suoraan varsinaiseen TeX-moottoriin, LuaTeX tarjoaa erittäin rikkaan kokoelman komentoja (TeX-primitiivejä) ja erittäin tehokkaan [Lua-pohjaisen sovellusrajapinnan](/latex/fi/syvalliset-artikkelit/07-an-introduction-to-luatex-part-1-what-is-it-and-what-makes-it-so-different.md) jonka kautta kehittäjät voivat rakentaa yhtä kehittyneitä ratkaisuja monikieliseen ladontaan. Vaikka LuaTeXin filosofia saattaa merkitä lisätyötä LaTeX-pakettien kehittäjille, se tarjoaa paljon lisäjoustavuutta, koska ratkaisut eivät ole ”kovakoodattuja” varsinaiseen LuaTeX-moottoriin itseensä, vaan ne rakennetaan TeX- ja Lua-koodista — tai C/C++:lla kirjoitetuista liitännäisistä.

**Sivuhuomautus**Lukijoita, jotka haluavat tutustua tarkemmin OpenType-muotoilun kiehtovaan mutta monimutkaiseen maailmaan, saattaa kiinnostaa lukea erinomaisesta avoimen lähdekoodin kirjastosta nimeltä [HarfBuzz](https://www.freedesktop.org/wiki/Software/HarfBuzz/)—jota käyttävät monet sovellukset, kuten Firefox, Chrome ja LibreOffice, ja tietenkin myös XeTeX. Tämän artikkelin kirjoittaja on käyttänyt HarfBuzzia luodakseen [LuaTeX-liitännäisiä arabian ladontaan](http://www.readytext.co.uk/?p=3186).

Nykyään on tavallista (esim. sosiaalisessa mediassa) siirtää tekstiä, joka sisältää useiden kielten merkkejä, ja useaa kieltä sisältävää tekstiä tallentava UTF-8-tekstitiedosto voi helposti sisältää merkkejä, joiden esitys UTF-8:ssa on 1, 2, 3 tai 4 tavua pitkä. Käytännössä UTF-8-tekstitiedosto on siis vain yksittäisten tavujen virta, mutta jokainen todellinen merkki tuossa tiedostossa voi olla mikä tahansa 1–4 tavua pitkä: yksittäisistä merkeistä on tullut *monitavuisiksi sarjoiksi*.

Tutkiaksemme tarkemmin joitakin monikielisen tekstin (ladonnan) työskentelyn keskeisiä piirteitä käytämme esimerkkinä arabian kirjoitusjärjestelmää, koska arabia antaa meille mahdollisuuden käsitellä useita käsitteitä.

#### Sivuhuomautus: arabian kirjoitusjärjestelmä

Se [arabian kirjoitusjärjestelmä](https://en.wikipedia.org/wiki/Arabic_script) kirjoitetaan kursiivisella tyylillä, jota luetaan ja kirjoitetaan oikealta vasemmalle. Jokainen arabian kirjain voi mahdollisesti saada yhden neljästä eri muodosta sen mukaan:

* onko se esitetty yksittäisenä, erillisenä (isolated) merkkinä (ei liitettynä mihinkään muuhun);
* onko se sanan sisällä — sanan alussa, keskellä tai lopussa: niistä käytetään nimitystä *alkumuodot*, *keskimuodot* ja *final* vastaavasti.

Jokaisella arabian kirjoitusjärjestelmän merkillä on oma liitossääntöjen joukkonsa, ja sen muoto/ulkoasu voi muuttua tai olla muuttumatta, kun sillä on toinen merkki vasemmalla, oikealla tai vasemmalla ja oikealla. Lukijat, jotka haluavat tutkia tätä tarkemmin, voivat löytää [täydellinen luettelo Wikipediassa](https://en.wikipedia.org/wiki/Template:Arabic_alphabet_shapes/joining).

#### Esimerkki: arabian- ja englanninkielistä tekstiä UTF-8:ssa

Oletetaan, että luomme UTF-8-tekstitiedoston, joka sisältää yhden rivin englannin- ja arabiankielistä tekstiä: This is العَرَبِيَّة text!

Tämä tekstirivi sisältää 3 välilyöntiä, 11 englanninkielistä (latinalaisen kirjoitusjärjestelmän) merkkiä ja 12 arabian merkkiä (vaikka se ei ehkä olekaan heti ilmeistä). Kun se tallennetaan UTF-8-tekstitiedostona, se vie 38 tavua tallennustilaa, mikä johtuu seuraavista:

* **latinalainen kirjoitusjärjestelmä**: välilyönnit plus englanninkielinen teksti: 14 ✕ 1 tavun merkkiä = 14 tavua;
* **arabian kirjoitusjärjestelmä**: 12 arabian merkkiä ✕ 2 tavua per merkki = 24 tavua.

Yhteensä 14 + 24 = 38 tavua.

#### Tarkemmin tarkastellen

Jos tallennamme esimerkkitekstimme UTF-8-tiedostoon nimeltä `arabic.txt` ja avaamme sen heksadesimaalieditorissa, voimme tutkia sitä nähdäksemme sen sisältämät todelliset tavut. Seuraavaa selostettua kuvakaappausta tutkimalla näet, että arabian teksti on tallennettu 2 tavua merkkiä kohden:

![UTF-8-tekstitiedosto, joka sisältää englannin- ja arabiankielistä tekstiä, avattuna heksadesimaalieditorissa.](/files/e27ed9c7cb004dda8b660f97ee51a898b1c737c3)

UTF-8-tekstitiedosto, joka sisältää englannin- ja arabiankielistä tekstiä, avattuna heksadesimaalieditorissa. Näet selvästi, että latinalaisen kirjoitusjärjestelmän merkit vaativat yhden tavun, mutta arabian kirjoitusjärjestelmän merkit tallennetaan käyttäen kahta tavua merkkiä kohden.

Tästä kuvakaappauksesta voi tehdä pari havaintoa:

* arabian teksti on tallennettu vasemmalta oikealle etenevänä sarjana ja merkit ovat arabian kirjainten ja vokaalien raakoja, muotoilemattomia (erillisiä) versioita;
* latinalaisen kirjoitusjärjestelmän “This is ” -osan jälkeen ei ole mitään lisätietoa, joka kertoisi tätä tiedostoa lukevalle ohjelmistolle, että seuraava merkki on arabian kirjoitusjärjestelmästä.

Jos ladot monikielistä dokumenttia (esim. englannin- ja arabiankielistä), XeTeXin tai LuaTeXin on syötetekstitiedoston (tavujonon) lukemisen/käsittelyn aikana kyettävä havaitsemaan kunkin merkin alku ja loppu sekä lukea oikea määrä tavuja, joita tarvitaan UTF-8-muunnoksen purkamiseen ja vastaavan Unicode-koodipisteen muodostamiseen. Juuri UTF-8-algoritmi mahdollistaa tämän ohjelmistolle: se tunnistaa kunkin yksittäisen merkin ensimmäisen tavun ja sen, kuinka monta tavua on luettava vastaavan Unicode-koodipisteen laskemiseksi. UTF-8 on helppokäyttöinen, mutta todella oivaltava.

#### Looginen järjestys, näyttöjärjestys ja OpenType-muotoilu

Jos katsot tarkkaan yllä olevaa arabiaa (العَرَبِيَّة), voi olla vaikea nähdä, että tekstitiedostomme todella sisältää 12 yksittäistä arabian merkkiä — varsinkin jos arabian kirjoitusjärjestelmä ei ole sinulle tuttu! Jos kuitenkin lasket huolellisesti yllä olevan kuvakaappauksen oikealla puolella näkyvät arabian merkit, huomaat, että niitä on yhteensä 12.

Monimutkaisia kirjoitusjärjestelmiä käyttävissä kielissä, kuten arabiassa, se, mitä tekstitiedostomme *tallentaa* ja mitä sinä *näet näytöllä* ovat näkyvästi *erittäin* todella erilaisia! Se, mitä näet katsellessasi kyseistä tekstiä esimerkiksi selaimessa, on (käytetystä fontista riippuen):

![Kuva ladotusta arabian tekstistä](/files/8e079eae9c25428d2d073d76130d3bc701a29c2a)

Mutta kuten yllä oleva kuvakaappaus osoittaa, UTF-8-tekstitiedosto sisältää todellisuudessa tämän:

![Kuva ladontaa vailla olevasta arabian tekstistä (erilliset merkit)](/files/6ce3fe4bbb00320daa9d220a3f7ecb040f23c48a)

Vaikka et tuntisikaan arabian kirjoitusjärjestelmän kursiivista luonnetta, voit selvästi nähdä, että ”jotakin” on tapahtunut, kun tekstitiedostossa olevat arabian merkit on siirretty ladontaan ja/tai näytölle esitettäväksi (glyfeinä). Jos olet tottunut käyttämään TeX/LaTeXia yksinkertaisen kirjoitusjärjestelmän kielissä, esimerkiksi latinalaispohjaisissa kielissä, tämä voi olla varsin hämmentävää!

Tässä on käynnissä joitakin tärkeitä käsitteitä, koska Unicode-tekstitiedostot tallentavat… no, tekstiä (Unicodea), ja ladonta- ja näyttöjärjestelmät käyttävät fontteja ja glyfejä (OpenType):

* tekstitiedosto tallensi arabian merkit vasemmalta oikealle etenevässä järjestyksessä, mutta arabia luetaan/näytetään oikealta vasemmalle: tekstitiedostot tallentavat tekstin niin sanottuun *loogiseen järjestykseen*;
* tekstitiedosto sisältää yksittäisiä merkkejä, jotka näyttävät hyvin erilaisilta kuin näytöllä esitetty todellinen ulkoasu: tekstitiedosto sisältää arabian merkit niiden erillisinä, toisiinsa liittämättöminä muotoina.

#### Mitä tapahtuu?

Tekstitiedostossa arabia tallennetaan vasemmalta oikealle etenevänä erillisten muotojen merkkisarjana: jos mietit asiaa, tekstitiedosto tallentaa arabiatekstin siinä järjestyksessä, *jossa se kirjoitettiin* (m-kirjain *loogiseen järjestykseen*). Vasta kun kyseinen teksti käsitellään näyttöä varten tai ladotaan, se näytetään oikeassa lukujärjestyksessä, jota usein kutsutaan *visuaaliseksi järjestykseksi* tai *näyttöjärjestykseksi*; lisäksi arabian merkkien erilliset muodot *muotoillaan* niiden typografisesti oikeiksi näyttöversioiksi. Yksi tapa ajatella tätä on, että yksinkertaisen tekstitiedoston on tallennettava teksti (Unicode-merkit) mahdollisimman perusmuodossaan: raakoina, muotoilemattomina, yksittäisinä tekstimerkkeinä — järjestelmäohjelmiston tehtävä on tuottaa nämä merkit näytettäväksi käyttöjärjestelmän, fonttien ja näyttölaitteessa käytettävissä olevan ladonta-/renderöintiohjelmiston perusteella.

Kun kyseisen tiedoston arabiateksti ladotaan/näytetään, se käy läpi prosessin nimeltä *shaping*. Yksittäiset arabian merkit muunnetaan muotoilluiksi glyfeiksi, jotka edustavat oikein kunkin merkin variantin arabian kirjoitusjärjestelmän liitossääntöjen mukaisesti. Lisäksi korkealaatuinen ladontaohjelmisto (hyviä OpenType-fontteja käyttäen) lisää jatkokäsittelyä soveltamalla lisätypografista hienostuneisuutta prosessin nimeltä *OpenType-muotoilu*—prosessi, joka kattaa laajan valikoiman typografisia toimintoja, joihin voi sisältyä:

* useiden yksittäisten glyyfin korvaaminen yhdellä monimutkaisella ligatuuriglyyfillä (hyvin yleistä arabiassa), tai
* sijoittelutoimintoja, jotka esimerkiksi säätävät arabian vokaalien sijaintia sen mukaan, minkä glyyfin ylä- tai alapuolella ne sijaitsevat.

![Kuva, joka näyttää arabian tekstin muutoksen, kun se ladotaan](/files/9b89941f7ab6701298377ec2878b9c7408d185e7)

Loogisen järjestyksen ja visuaalisen (näyttö)järjestyksen välinen ero. Tässä kuvassa näet, että tekstitiedostoon tallennetut arabian merkit järjestetään uudelleen ja muotoillaan, kun ne näytetään tai ladotaan.

Edistyneiden OpenType-fonttien suunnittelijat ja tekijät käyttävät huomattavan paljon aikaa ja asiantuntemusta tarjotakseen fonteihinsa sisäänrakennetut kehittyneet typografiset ominaisuudet.

Käytössä olevan arabian tekstin muotoilun voi kytkeä pois käyttämällä erinomaista, ilmaista, [BabelPad](http://www.babelstone.co.uk/Software/BabelPad.html) Unicode-tekstieditorin (vain Windows), jonka avulla voit poistaa muotoilun käytöstä nähdäksesi raakat, yksittäiset, yhteen liittämättömät (muotoilemattomat) merkit, joita tekstitiedostossa todella on—katso tämän yhdistetyn kuvakaappauksen alapuolisko:

![Kuva, joka näyttää BabelPad-tekstieditorin kyvyn kytkeä OpenType-muotoilu pois päältä](/files/56979c00f2a73ec6fffe0753308ae97a82bcd25f)

BabelPad Unicode -tekstieditorin käyttäminen OpenType-muotoilun kytkemiseen päälle (yläkuva) tai pois päältä (alakuva). OpenType-muotoilun poistaminen käytöstä tekee arabian tekstin muokkaamisesta paljon helpompaa.

Loogisen järjestyksen ja näyttöjärjestyksen käsitteet yhdessä muotoiluprosessien kanssa voivat olla varsin hämmentäviä, kun ne kohtaa ensimmäistä kertaa monikielisten tekstitiedostojen, joissa on monimutkaisia kirjoitusjärjestelmiä kuten arabia, muokkauksen tai ladonnan yhteydessä: toivottavasti yllä oleva on auttanut välttämään jonkin verran alkusekaannusta.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/latex/fi/syvalliset-artikkelit/51-unicode-utf-8-and-multilingual-text-an-introduction.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.