Unicode-merkkijärjestelmään siirtymisen piti poistaa suomalaisten ääkkösongelmat, samoin kuin kaikkien muidenkin maailman merkkijärjestelmien ongelmat. Vasta äskettäin havahduin huomaamaan, ettei asia olekaan ihan niin yksinkertainen.
Pienen ä-kirjaimen koodi on 228, sama kuin vanhassa ISO Latin 8859-järjestelmässä eli heksana 0xE4 (Unicode-järjestelmässä U+00E4). UTF-8 -koodauksella merkki on 0xC3 0xA4.
Äskettäin löysin arkistolevyltäni pdf- ja m4a-tiedostoja, joiden ä-kirjain olikin koodattu kahtena erillisenä merkkinä: ensin pikku-a ja sitten Unicode-merkki U+0308 (kymmenjärjestelmässä 776) eli yläpisteet. Pieni ä muodostetaan siis a-kirjaimesta ja piirtämällä sen päälle kaksi pistettä (\0308), aivan kuin käsin tekstatessa.
Yllättävää kyllä, molemmat ovat standardinmukaisia tapoja ä-kirjaimen esittämiseen. Meillä on siis kaksi eri koodinumeroa ä-kirjaimelle.
Windows peittää asian hyvin. Tiedostolistauksesta on mahdoton havaita eroa aidon ä:n ja a+pisteet -kirjainten välillä.
Merkkipohjaisessa ikkunassa ero näkyy kuitenkin selvästi, sillä se ei tue Unicodea.
![]() |
Ä-kirjaimet näkyvät väärin. |
Ilmeisesti kaikki nykyiset sovellukset tukevat Unicodea, koska graafisen käyttöliittymän kautta erikoiset ä:t eivät ole aiheuttaneet mitään ongelmia. Huomasin ne vasta Python-koodauksessa, kun ohjelma kaatui virheeseen. Pythonin sisällä ä:t eivät silloinkaan olleet ongelma.
Merkkejä voi tarkastella Excelissä.
![]() |
Unicode-palauttaa merkin koodinumeron. |
Solussa C2 on sana "näyttäjät" kahden merkin ä-kirjaimella (tässä sama leikepöydän kautta Liitä pelkkä teksti siirrettynä: näyttäjät), solussa C7 tavallisella yhden merkin kirjaimella. Molemmat näyttävät samoilta, mutta kun sana puretaan kirjaimiksi (=MID($C$2;D1;1)) havaitaan, että toinen kirjain on a ja kolmas näkyy tyhjänä. Alla vastaavat Unicode-arvot 97 (a) ja yläpisteet (776). Sama toistuu jokaisen ä-kirjaimen kohdalla.
Näppäimistöltä itse kirjoitettu sanat "näyttäjät" näkyy tavallisilla ä-kirjaimilla (228). Myös merkkijonon pituus (=LEN()) antaa eri tulokset, sillä se laskee ä:n kahtena merkkinä.
Erikoista kyllä, Excelin vertailufunktio =IF näkee merkkijonot samoina:
![]() |
Eri pituiset merkkijonot ovatkin samoja? |
Tässä on kyllä ihmettelemistä: miten kaksi merkkijonoa voivat olla samoja, vaikka toisen pituus on 12 ja toisen 9 merkkiä? Ilmeisesti osa Excelin funktioista tunnistaa yläpisteiden käytön ja osa ei.
Kuvan funktiot ovat englanninkielisiä, koska vaihdoin tarkoituksella Excelin englanninkieliseksi. Sama ero näkyy kuitenkin myös suomenkielisissä funktioissa.
Eron voi havaita myös muissa sovelluksissa. Wordissä osa fonteista käsittelee yläpisteitä oikein, osa ei. Vanha Arial perusmuodossa näkyy oikein:
![]() |
Arial näkyy oikein. |
Arial Black sekä monet eksoottisemmat fontit, jopa Windowsin mukana tulevat, näyttävät erilliset yläpisteet väärin:
![]() |
Arial Black näkyy väärin. |
On vaikea ymmärtää, miksi standardiin on otettu tällainen mahdollisuus. Vähintäänkin voisi todeta, että kaksiosaiset kirjaimet merkeille, joilla on oma koodinsa, ovat kiellettyjä. Nyt tarjolla on erikoinen sudenkuoppa, joka hämmentää siihen putoavia käyttäjiä.
Pythonissa on Unicode-merkkien käsittelyyn unicodedata.normalize(form, unistr), joka sekä normalisoi (normal form C, canonical composition) että laajentaa (normal form D, canonical decomposition) kahdesta osasta koostuvia merkkejä. Tämä ei tosiaan ole pelkän ä-kirjaimen eikä suomalaisten ongelma.
Pythonissa form voi saada neljä eri arvoa: NFC, NFD, NKFC ja NKFD. Yhden merkin ä-kirjaimiin päästään kutsumalla esim. teksti=unicodedata.normalize('NFC', teksti).
Itselleni on arvoitus, mitkä sovellukset tuottavat tiedostonimiin kahden merkin ääkkösiä. Pdf-tiedostot olivat ilmeisesti peräisin Macistä ja Adoben taitto-ohjelmasta, mutta äänitiedoston tuottanutta ohjelmaa en pystynyt jäljittämään. Vinkit ovat tervetulleita.