Unicode, BOM, KDE: kate/kwrite

Unicode, BOM, KDE: kate/kwrite

tuo BOM:han on virallisesti "byte-order mark", jonka unicode-koodi on U FEFF.

Jos itse olisin suunnitellut kwriten ja katen, niin olisin toiminut näin:

JOS teksti tallennetaan unicode:na (esim. UTF-8 tai UTF16LE, UTF16BE, UTF32LE, UTF32BE), niin tekstinkäsittelyohjelman tulisi toimia näin:

tarkistetaan tiedostopääte (esim: ".txt").

Jos tiedostopäätettä ei ole, silloin EI tallenneta BOM -merkkiä (koska valitettavasti BOM -merkki tiedoston alussa on epäyhteensopiva linuxissa käytetyn skriptimekanismin kanssa, esim bash, perl tms. skriptithän alkavat siten, että 1. rivi alkaa näin:

#!

).

Jos tiedostopääte on, sitä verrataan kahteen listaan, jotka toimitetaan oletuksena linuxjakelun mukana, mutta joita root -tunnuksella voi muokata systeeminlaajuisesti ja kukin käyttäjä lisäksi vain omaan toimintaansa vaikuttavia vastaavia listoja, siis yhteensä 4 listaa 2 tiedostossa:

1a. systemwide "BOM: Yes" -lista
1b. systemwide "BOM: No" -lista

2a. per-user "BOM: Yes" -lista
2b. per-user "BOM: No" -lista

Nuo sitten käydään järjestyksessä 2->1 läpi, ja lopetetaan heti, kun löytyy osuma.

jos missään noista 2 tiedostosta ei löydy osumaa, samat tiedostot käydään uudelleen läpi, mutta vasta nyt käydään läpi tällainen rivi:

default=1

TAI

default=0.

(toki, tehokkuuden parantamiseksi nuo "default" -rivit voidaan cachettaa muuttujiin muistiin, niin niitä fyysisiä tiedostoja ei tarvitse silloin lukea 2 kertaa/tiedosto).

ja noiden tiedostojen muu sisältö voisi olla tällainen:

txt=1
doc=1
pl=0

Ideana siis, että jos tiedostopääte on txt tai doc, niin tallennetaan BOM -merkki toedoston alkuun, jos taas tiedostopääte on pl, niin ei tallenneta. Ja jos noista 2 tiedostosta ei löydy käytettyä tiedostopäätettä (mutta sellaista siis käytettiin), niin silloin tuo default -rivi määrää, käytetäänkö BOM -merkkiä (1) vai ei käytetä (0).

Valitettavasti kwriten ja katen koodaajat eivät ole tällaista toteuttaneet, vaan ovat ottaneet sen linjan, etti koskaan tallenneta BOM -merkkiä tiedoston alkuun.

UTF8:ssahan tavujärjestys on aina sama, joten tavujärjestyksen määrittämiseksi BOM -merkkiä tarvitaan vain UTF-16 ja UTF32 -koodauksissa.

MUTTA: ongelma tuleekin tästä: JOS tekstitiedostossa ei ola alussa BOM -merkkiä, niin ainakin Suomessa (ja monessa muussakin maassa) on syytä olettaa, että merkkivalikoima ja koodaus on windows-1252, ja esim tŝekeissä windows-1250, EIKÄ mikään unicode -versio.

Jos kopioit esim. suomenkielisen windowsin (ainakin win98) notepadilla tehdyn tekstitiedoston linuxiin, niin koodaus on windows-1252.
Joissakin windowsin uudemmissa versioissa saattaa voida valita, tallennetaanko 8 vai 16 -bitin merkkikoodauksella. Jos valitsee 8, niin tilanne on sama kuin win98:ssa (siis windows-1252).

Jos valitsee 16, niin tilanne on melkein sama, kuin UTF-16, sillä erotuksella, että merkkivalikoiman U 0000 - U FFFF ulkopuolella olevia merkkejä ei voi windowsissa käsitellä ollenkaan (jollei nyt sitten Vistan myötä ole tullut tukea tuohonkin).

Koska on täysin mahdollista (ja joskus hyvinkin asiallista) kopioida tekstitiedostoja windows -koneelta linuxkoneelle, niin miksi pitää ehdoin tahdoin synnyttää tilanne, jossa tekstitiedostoissa on eri koodaustapoja (windows-1252 tai unicode UTF-8), mutta sitä ei voi automaattisesti päätellä mitenkään, kumpaa on käytetty!

Jos kwrite ja kate yms. linuxohjelmat toimisivat, kuetn yllä on kuvattu, ongelmaa ei olisi:

Jos tiedoston alussa ei ole mitään määrettä merkkivalikoimasta, oletetaan sen olevan windows-1252.

Jos taas alussa on BOM -merkki, niin se kertoo, että merkkivalikoima on unicode, ja se, miten tuo BOM on tiedoston alkuun koodattu, kertoo senkin, mitä tallennus/pakkaustapaa (UTF8, UTF16LE, UTF16BE, UTF32LE, UTF32BE) on ko. tiedostossa käytetty.

Nykytilanteessa tekstinkäsittelyohjelmalla käyttäjä joutuu kärsimään mahdollisesti väärin tulkitusta merkkivalikoimasta/koodaustavasta tiedostoa avattaessa. (Suomessa ilmiö näkyy useimmiten väärin olevina ä ja ö -kirjaimina).

Omatekoisissa ohjelmissa paras keino on ilmeisesti tämä:

1. Etsitään tiedoston alusta BOM -merkkiä, jos se löytyy, asia on sillä selvä.

2. jos ei löydy, niin joudutaan käymään koko tiedosto läpi, ja tutkimaan, että kun löytyy tavuja, joiden arvo on >= 128, tutkitaan, muodostavatko ne poikkeuksetta luvallisen UTF8 -sekvenssin; jos kyllä, oletetaan UTF-8 -koodaus, jos ei, oletetaan windows-1252 -koodaus.

Tämä tapa johtaa usein oikeaan tulkintaan, mutta 100% takuuta asiasta ei voi antaa.


MUTTA:

tuo BOM:han on merkki, ja paitsi tavujärjestysmerkkinä, niin se voidaan tulkita myös näin: "zero-width nonbreaking space".

Saako katessa ja kwritessä jotenkin näppäiltyä tuollaisen zero-width nonbreaking space:n, ja tuottaisiko sellainen BOM -merkin tiedoston alkuun, jos näppäilisi tuon 1. merkkinä uuteen tiedostoon ja tallentaisi sen ?

Tekisi siis aina käsin sen, minkä kwriten ja katen ohjelmoijat jättivät tekemättä?

Eli: näppäilyohjetta BOM -merkille peliin, kiitos !