maanantai 30. syyskuuta 2024

Unicode ja ä-kirjain, kaksi vaihtoehtoa

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.

5 kommenttia:

  1. Mac OS -käyttöjärjestelmän (oletus)tiedostojärjestelmä normalisoi tarkkeelliset merkit erotettuiksi eli Unicoden decomposition-normalisoinniksi. Olen huomannut tämän, kun olen siirtänyt tiedostoja Mac OS:n ja Linuxin välillä. Tiedostonnimet tulevat Macista takaisin muutettuina, decomposition-muotoisina.

    VastaaPoista
  2. Mac OS:n tiedostojärjestelmässä tiedostonnimet ovat siis aina Unicoden decomposition-tilassa, eli ilmiö toteutuu alemmalla tasolla kuin sovellukset.

    VastaaPoista
  3. Jostain syystä Macissä Wordillä tallentamani tiedostonimi ääkkösillä näkyy yhden merkin kirjaimina (composition) muissa koneissa.
    Mikähän idea Macissa muuten on suosia decomposition-formaattia? Luulisi, ettei siitä ole kuin haittaa.

    VastaaPoista
    Vastaukset
    1. Yleisesti tiedon normalisoinnin etu on se, että tiedetään, missä muodossa tieto on tallennettu. Se voi auttaa tiedon hakemista.

      Tarkkeellisten merkkien normalisoinnissa purkaminen osiin voi auttaa siinä, että hakuvaiheessa tarkkeita ei tarvitse huomioida: hakulauseessa pelkkä "a" löytää myös "a" + mitkä hyvänsä tarkkeet. On siis helppoa löytää ns. peruskirjain "a" ja olla huomioimatta mahdolliset yhdistyvät tarkkeet, koska ne ovat tietyllä Unicoden alueella. Sen sijaan edellisen kaltainen haku on teknisesti vähän hankalampaa, jos kaikki erilaiset tarkkeet (áàåäã...) voivat olla samassa merkissä.

      Poista
    2. Mielenkiintoinen selitys, mutta kaksiteräinen miekka, koska se haittaa eniten niitä, jotka natiivisti käyttävät tarkkeellisia merkkejä. Jos haen sanoja, joissa esiintyy ä-kirjain, en halua mukaan a-kirjaimen sanoja. Onko haku sitten helpompi koodata, jos tarkemerkit on tallennettu erikseen ja haun vertailussa pitää hypätä niiden yli? Hmm.

      Poista