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 !
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 !
Vastaukset
Vanhimmat
Ei vielä vastauksia
Aloittaja odottaa vastauksia. Kerro oma näkemyksesi ensimmäisenä.