Merkistöistä

[JCSH]

Siirretään tämä keskustelu oikeaan paikkaan.

Edellisessä viestissäni jo kerroin, miksi unicoden pitäminen oletuksena ei ole hyvä asia. Se tekee ihan konkreettisia tietoturvariskejä ja on ongelmallinen myös käyttäjien tuottaman sisällön kanssa esimerkiksi foorumeilla ja vieraskirjoissa. Unicode on kyllä hyvä asia silloin, kun sitä tarvitaan, ja ilman unicodea moni asia olisi hankalampaa. Kuitenkin tuollainen kaikkien pakottaminen unicoden käyttäjiksi on vastenmielistä ja tuottaa enemmän ongelmia kuin ratkaisee niistä.

Ja ovathan ne tasapituiset merkistöt aina myös helpompia implementoida.

Kyllä se unicoden pitäminen oletuksena on todellakin hyvä asia. Oikeastaan se, että käytät internetin UGC:tä esimerkkinä asiasta, jossa se olisi huono juttu, on suht koomista, kerta tuo on mainio esimerkki tilanteesta, jossa unicode on aikalailla välttämätön. Koska 2/3 maapallon väestöstä käyttää jotain muita aakkosia kuin latinalaisia.
Unicode mahdollistaa sen, että tietojärjestelmät ovat yhteensopivia kaikkien maailman kielien kanssa.

 

[Timo 2]

Tyhmänä kysyn liittyikö nää merkistöt ja niiden yhteensopivuus jotenkin siihen ettei mikkisoftan julkaisemasta dos 4.0 lähdekoodista saada käyttistä koottua (complile)? Jotain tälläistä muistan lukeneeni ja joku joskus sanoi jotain (saattoi olla villi huhu) ettei jotain ikivanhaa ajuria voi lähettää sähköpostilla liitteenä kun kuulema hajoaa.

 

[Sompi]

Siirretään tämä keskustelu oikeaan paikkaan.



Kyllä se unicoden pitäminen oletuksena on todellakin hyvä asia. Oikeastaan se, että käytät internetin UGC:tä esimerkkinä asiasta, jossa se olisi huono juttu, on suht koomista, kerta tuo on mainio esimerkki tilanteesta, jossa unicode on aikalailla välttämätön. Koska 2/3 maapallon väestöstä käyttää jotain muita aakkosia kuin latinalaisia.
Unicode mahdollistaa sen, että tietojärjestelmät ovat yhteensopivia kaikkien maailman kielien kanssa.

Oletusmerkistön pitäisi olla jokin mahdollisimman yksinkertainen tasapituinen merkistö, sellainen joka riittää tarkoitukseen. Unicode on tietoturvariski ja myös yhteensopivuusongelma mm. niistä syistä, että unicode on hankalampi implementoida ja siitä on useampia versioita olemassa.

Et ole tainnut paljoa olla eri merkistöjen kanssa tekemisissä, jos pidät unicode-pakotusta jotenkin hyvänä asiana.

Yleensä suomenkielisillä sivuilla on tarkoituksenmukaista rajoittaa käyttäjien tuottama sisältö kirjainmerkeiltään sellaiseen osajoukkoon merkkejä, johon sattuu jo valmiiksi rajoittumaan mm. tasapituinen 8-bittinen merkistö ISO-8859-15. En näe mitään syytä käyttää unicodea noissa tapauksissa, koska silloin merkkien rajoitus vaatisi jonkin tehottoman ja bugiherkän tarkistuksen siitä, ettei käyttäjän tuottamassa sisällössä ole kiellettyjä merkkejä. Yksinkertaisesti voidaan vain määrittää, että käytetään merkistöä ISO-8859-15, jolloin merkkijoukko rajoittuu automaattisesti.

Tyhmänä kysyn liittyikö nää merkistöt ja niiden yhteensopivuus jotenkin siihen ettei mikkisoftan julkaisemasta dos 4.0 lähdekoodista saada käyttistä koottua (complile)? Jotain tälläistä muistan lukeneeni ja joku joskus sanoi jotain (saattoi olla villi huhu) ettei jotain ikivanhaa ajuria voi lähettää sähköpostilla liitteenä kun kuulema hajoaa.

Ei liity mitenkään mihinkään noista. Sähköpostin liitetiedostot base64-enkoodataan ja binääritiedostot tulevat kyllä ehjänä läpi.

Assemblerit ja C-kääntäjät käyttävät yleensä 7-bittistä ASCIIta 8-bittisenä esityksenä, joten ne ovat yhteensopivia myös yleisimmän unicoden esitystavan UTF-8:n kanssa. MS-DOSin lähdekoodit taitavat olla ihan normaalia 437-koodisivua.

 

[JCSH]

Oletusmerkistön pitäisi olla jokin mahdollisimman yksinkertainen tasapituinen merkistö, sellainen joka riittää tarkoitukseen. Unicode on tietoturvariski ja myös yhteensopivuusongelma mm. niistä syistä, että unicode on hankalampi implementoida ja siitä on useampia versioita olemassa.

Et ole tainnut paljoa olla eri merkistöjen kanssa tekemisissä, jos pidät unicode-pakotusta jotenkin hyvänä asiana.

Yleensä suomenkielisillä sivuilla on tarkoituksenmukaista rajoittaa käyttäjien tuottama sisältö kirjainmerkeiltään sellaiseen osajoukkoon merkkejä, johon sattuu jo valmiiksi rajoittumaan mm. tasapituinen 8-bittinen merkistö ISO-8859-15. En näe mitään syytä käyttää unicodea noissa tapauksissa, koska silloin merkkien rajoitus vaatisi jonkin tehottoman ja bugiherkän tarkistuksen siitä, ettei käyttäjän tuottamassa sisällössä ole kiellettyjä merkkejä. Yksinkertaisesti voidaan vain määrittää, että käytetään merkistöä ISO-8859-15, jolloin merkkijoukko rajoittuu automaattisesti.

Suomessa puhutaan muitakin kieliä kuin suomea. Lisäksi kukaan ei ala koodaamaan foorumisoftaa pelkästään Suomen markkinoille, vaan globaaleille markkinoille. Jolloin se 8-bittinen merkistö ei yksinkertaisesti riitä.

 

[pulatunnus]

Yleensä suomenkielisillä sivuilla on tarkoituksenmukaista rajoittaa käyttäjien tuottama sisältö kirjainmerkeiltään sellaiseen osajoukkoon merkkejä, johon sattuu jo valmiiksi rajoittumaan mm. tasapituinen 8-bittinen merkistö ISO-8859-15. En näe mitään syytä käyttää unicodea noissa tapauksissa, koska silloin merkkien rajoitus vaatisi jonkin tehottoman ja bugiherkän tarkistuksen siitä, ettei käyttäjän tuottamassa sisällössä ole kiellettyjä merkkejä. Yksinkertaisesti voidaan vain määrittää, että käytetään merkistöä ISO-8859-15, jolloin merkkijoukko rajoittuu automaattisesti.

Jos otat vastaan muiden tuottamaa sisältöä niin ehdottamasi merkistö ei kuullosta hyvältä, voi toki toki tukea vastaanotossa tuota, mutta tallenna ja edelleen jaa unicode merkistöllä.

Jos kässittely menetelmissäsi on merkistön, datan käsittelyn osalta tietoturvariskejä, niin joka tapauksessa joudut ne parsiin. joudut niitä kohteleen ns vihamielisinä aina.

8-bittinen merkistö ISO-8859-15 on taasen niin suppea että rajoittaa ilmaisua vaikka pysyttäisiin suomenkielisessä sisällössä ja ajatus tasolla on toki esimerkki alan kelleimista aajtusvirheistä, koodataan tämä nyt näin, asiakas ilmoitti että tänää heillä vain 8 bittisiä, tai vuosi sitten ALV prosentti ei tarvi desimaaleja, no koodaataan niin....

Yritän sanoa, asiakas kertoo että heidän sivusto on suomenkielinen, jo huomenna asiakas voi haluta kirjoittaa ihan suomenkieliselle sivulle merkkejä jotka ei ole siinä Latin merkistössä, ylihuomenna haluaa lisätä kielitarjontaa, tehdä sivuista monikielisen. Siis nämä ovat olleet vuosia, vuosikymmeniä oletuksia tulevasta.

Ja lukijat, että sisältö tuottavat ovat siirtyneet unicode merkistöön, joten valitsemalla jonkin latin merkistön joudut karsimaan sisältöä, ja pyytämään siihen luvan.

 

[Paapaa]

Unicode on ratkaissut käytännössä suurimman osan merkistöihin liittyvistä ongelmista. Sen käyttäminen sovelluksissa on helppoa, sille on moderneissa kielissä ja sovelluksissa suora tuki, eikä se ole tietoturvariski oikein käytettynä. Tietoturvanäkökulmat on hyvin dokumentoitu, eikä niiden noudattaminen ole mitään rakettitiedettä. Alla Unicoden ja OWASP:n dokumentaatiota Unicoden turvallisesta käyttämisestä ja lista tärkeimmistä huomioitavista asioista:

UTR #36: Unicode Security Considerations

UTS #39: Unicode Security Mechanisms

Input Validation - OWASP Cheat Sheet Series

Website with the collection of all the cheat sheets of the project.

cheatsheetseries.owasp.org

Jos ohjelmoijalla menee sormi suuhun Unicoden kanssa, on syy ennen kaikkea epäpätevässä ohjelmoijassa joka yrittää tehdä asiat kuten ne tehtiin 80-luvulla, ei teknologiassa. Ei omasta kyvyttömyydestä kannata syyttää aina uutta teknologiaa. Ei merkistöjen kohdalla, eikä muutoinkaan.

Ei ole ihme, että Unicode on syrjäyttänyt suuressa osassa sovelluskohteita vanhat puutteelliset merkistöt jotka aiheuttivat jatkuvia ongelmia.

 

[Hyrava]

Unicode on ratkaissut käytännössä suurimman osan merkistöihin liittyvistä ongelmista. Sen käyttäminen sovelluksissa on helppoa, sille on moderneissa kielissä ja sovelluksissa suora tuki, eikä se ole tietoturvariski oikein käytettynä. Tietoturvanäkökulmat on hyvin dokumentoitu, eikä niiden noudattaminen ole mitään rakettitiedettä. Alla Unicoden ja OWASP:n dokumentaatiota Unicoden turvallisesta käyttämisestä ja lista tärkeimmistä huomioitavista asioista:

UTR #36: Unicode Security Considerations

UTS #39: Unicode Security Mechanisms

Input Validation - OWASP Cheat Sheet Series

Website with the collection of all the cheat sheets of the project.

cheatsheetseries.owasp.org

Jos ohjelmoijalla menee sormi suuhun Unicoden kanssa, on syy ennen kaikkea epäpätevässä ohjelmoijassa joka yrittää tehdä asiat kuten ne tehtiin 80-luvulla, ei teknologiassa. Ei omasta kyvyttömyydestä kannata syyttää aina uutta teknologiaa. Ei merkistöjen kohdalla, eikä muutoinkaan.

Ei ole ihme, että Unicode on syrjäyttänyt suuressa osassa sovelluskohteita vanhat puutteelliset merkistöt jotka aiheuttivat jatkuvia ongelmia.

Ei voi olla enempää samaa mieltä, Unicode on kyllä helpottanut elämää aika pirusti.

Itse aina sillointällöin joudun tekemisiin kaikenlaisten ihme-merkistöjen kanssa (pääosin harrastusten parissa) ja kyllä sitä aina toivoo että voi kun tämäkin ohjelma/laite/järjestelmä ymmärtäisi unicodea. Yleensä kun jostain wanhan härvelin käyttämästä merkistöstä ei ole mitään dokumentaatiota niin joutuu arpapelillä lähtemään ihmettelemään. Hauskimpia on ne, jotka eivät käytä mitään "standardi"-merkistöä vaan jonkun sulautetun härvelin valmistaja on keksinyt ihan oman merkistönsä joka on lähellä montaa yleistä merkistöä mutta ei aivan, välillä löytyy vielä kuukausienkin päästä joku yksittäinen merkki joka onkin jotain ihan muuta mitä on ajatellut mutta on niin harvinainen ettei tullut mieleen testailun ja ihmettelyn lomassa.

 

[jad]

Unicode on kyllä helpottanut valtavasti elämää kaikenlaisten merkistöongelmien suhteen, mutta edelleen tulee vastaan hauskoja yllätyksiä. Esimerkiksi pari kuukautta sitten jouduin ihmettelemään kun MS Sharepointissa ääkkösiä sisältävät kansionimet "korruptoituivat" joillain käyttäjillä. Jossakin välissä käyttäjän nimetessä kansion uudelleen, päätti Sharepoint, että ä kirjain ei ollutkaan ä (U+00E4), vaan ä (U+0061 + U+0308)

 

[salojan]

Oletusmerkistön pitäisi olla jokin mahdollisimman yksinkertainen tasapituinen merkistö, sellainen joka riittää tarkoitukseen. Unicode on tietoturvariski ja myös yhteensopivuusongelma mm. niistä syistä, että unicode on hankalampi implementoida ja siitä on useampia versioita olemassa.

Ehkä siitä on useita versioita ihan syystä, ja yksi on juuri tuo tasapituus? UTF-32:llahan saat tasapituisen merkistön.

 

[Sompi]

Unicode on ratkaissut käytännössä suurimman osan merkistöihin liittyvistä ongelmista. Sen käyttäminen sovelluksissa on helppoa, sille on moderneissa kielissä ja sovelluksissa suora tuki, eikä se ole tietoturvariski oikein käytettynä. Tietoturvanäkökulmat on hyvin dokumentoitu, eikä niiden noudattaminen ole mitään rakettitiedettä. Alla Unicoden ja OWASP:n dokumentaatiota Unicoden turvallisesta käyttämisestä ja lista tärkeimmistä huomioitavista asioista:

UTR #36: Unicode Security Considerations

UTS #39: Unicode Security Mechanisms

Input Validation - OWASP Cheat Sheet Series

Website with the collection of all the cheat sheets of the project.

cheatsheetseries.owasp.org

Jos ohjelmoijalla menee sormi suuhun Unicoden kanssa, on syy ennen kaikkea epäpätevässä ohjelmoijassa joka yrittää tehdä asiat kuten ne tehtiin 80-luvulla, ei teknologiassa. Ei omasta kyvyttömyydestä kannata syyttää aina uutta teknologiaa. Ei merkistöjen kohdalla, eikä muutoinkaan.

Ei ole ihme, että Unicode on syrjäyttänyt suuressa osassa sovelluskohteita vanhat puutteelliset merkistöt jotka aiheuttivat jatkuvia ongelmia.

Millä ohjelmointikielillä ohjelmoit ja miten matalan/korkean tason juttuja teet?

Unicode on kyllä helpottanut valtavasti elämää kaikenlaisten merkistöongelmien suhteen, mutta edelleen tulee vastaan hauskoja yllätyksiä. Esimerkiksi pari kuukautta sitten jouduin ihmettelemään kun MS Sharepointissa ääkkösiä sisältävät kansionimet "korruptoituivat" joillain käyttäjillä. Jossakin välissä käyttäjän nimetessä kansion uudelleen, päätti Sharepoint, että ä kirjain ei ollutkaan ä (U+00E4), vaan ä (U+0061 + U+0308)

Ei tuossa pitäisi olla mitään ihmeellistä. Unicode on vain yksi merkistö muiden joukossa, eikä varsinaisesti mitenkään vähennä merkistöongelmia. Unicoden tarkoitus on vain olla merkistö, jossa on kaikkien mahdollisten kirjoitusjärjestelmien kaikki kirjainmerkit. Tietenkin kyse on tavoitteesta, johon ei koskaan täysin päästä, mutta lähemmäs sitä voidaan kuitenkin jatkuvasti pyrkiä.

Unicodella on tarkoituksensa ja se on tarkoitukseensa hyödyllinen työkalu, mutta unicoden pakottaminen kaikkeen oletukseksi (sen lisäksi, että siihen liittyy vakavasti otettavia tietoturvaongelmia, joita olen aiemmissa viesteissäni maininnut) ei ole edes mitenkään realistista senkään takia, että niitä merkkejä on niin valtava määrä, ettei nykyaikainen unicode ole edes järkevästi toteutettavissa missään kovin pienessä tietokonejärjestelmässä. Sen lisäksi, koska unicodessa on niin valtava määrä merkkejä ettei niitä kaikkia voi mitenkään olla olemassa myöskään kaikissa fonteissa, aiheuttaa unicoden pakkokäyttö ongelmia myös sillä tavalla, että fontit joutuvat sitten "lainailemaan" merkkejä muista fonteista (tai korvaamaan tuntemattoman merkin laatikolla jossa on merkin numeroarvo sisällä), ja dokumentit sitten renderöityvät eri tavalla eri ohjelmilla katsottuina.

Unicodessa on se ongelma verrattuna yksinkertaisempiin merkistöihin, että siitä on olemassa monta versiota, joten jos sanoo jonkin dokumentin tai merkkijonon käyttävän vaikkapa UTF-8-merkistöä, niin se ei vielä kerro oikeastaan kovin paljoa. Ei joku Windows NT tue kakkaemojeita, vaikka unicode-toteutus siitäkin löytyy.

 

[jad]

Ei tuossa pitäisi olla mitään ihmeellistä. Unicode on vain yksi merkistö muiden joukossa, eikä varsinaisesti mitenkään vähennä merkistöongelmia. Unicoden tarkoitus on vain olla merkistö, jossa on kaikkien mahdollisten kirjoitusjärjestelmien kaikki kirjainmerkit. Tietenkin kyse on tavoitteesta, johon ei koskaan täysin päästä, mutta lähemmäs sitä voidaan kuitenkin jatkuvasti pyrkiä.

Jep, eihän tuossa mitään muuta ihmeellistä ole kuin se, että vaikka merkistöstä erikseen löytyy ä-kirjain, niin joku ohjelmisto jossain vaiheessa prosessia on tuon päättänyt korvata tällä yhdistelmämerkillä ja tästä sitten syntyi tietyillä käyttäjillä mainitsemasi renderöintiongelma, jossa tämä näkyi kahtena peräkkäisenä merkkinä (a") tai peräti ä merkkinä, jossa pisteet oli 50% sivussa.

 

[Sompi]

Jep, eihän tuossa mitään muuta ihmeellistä ole kuin se, että vaikka merkistöstä erikseen löytyy ä-kirjain, niin joku ohjelmisto jossain vaiheessa prosessia on tuon päättänyt korvata tällä yhdistelmämerkillä ja tästä sitten syntyi tietyillä käyttäjillä mainitsemasi renderöintiongelma, jossa tämä näkyi kahtena peräkkäisenä merkkinä (a") tai peräti ä merkkinä, jossa pisteet oli 50% sivussa.

Unicodessa on tosiaan lähes rajaton määrä eri tapoja tuottaa tietyt yleisesti käytössä olevat merkit, mikä aiheuttaa ongelmia, joita ei yksinkertaisempien merkistöjen kanssa ole olemassakaan.

Muutenkin unicode pikemminkin lisää merkistöongelmia kuin vähentää niitä, koska unicode itsessään synnyttää monta sellaista ongelmaa, jota ei ilman unicodea ole/ollut olemassa. Toisaalta unicode on lähes välttämätön työkalu siihen, mihin se on tarkoitettu, eli merkistöksi, jossa on kaikkien kirjoitusjärjestelmien kaikki merkit. Matalan tason asioiden, joissa informaatiolta edellytetään eksaktiutta (kuten ohjelmien lähdekoodit sekä tiedostonimet tiedostojärjestelmässä) olisi kuitenkin parempi käyttää jotain yksinkertaisempaa merkistöä.

Toisaalta sitten korkeammankin tason asioissa unicode rikkoo totaalisesti niinkin yksinkertaiset asiat kuin vaikkapa tekstihaun, jos hakusanassa on unicode-merkkejä ja hakutyökalu koostaakin ne kirjainmerkit hakusanaan eri tavujonolla kuin mitä haettavassa aineistossa on käytetty saman kirjainmerkin tuottamiseen. Siksi en pidä unicoden käyttämistä mitenkään suositeltavana edes minkään tekstiasiakirjojen vakiomerkistönä, jos jollain 8-bittisellä tasaleveyksisellä merkistölläkin pärjäisi.

 

[JCSH]

Matalan tason asioiden, joissa informaatiolta edellytetään eksaktiutta (kuten ohjelmien lähdekoodit sekä tiedostonimet tiedostojärjestelmässä) olisi kuitenkin parempi käyttää jotain yksinkertaisempaa merkistöä.

Paitsi että niitä tiedostoja nimeää ja sorsakoodeja kirjoittaa muutkin kuin latinalaisia aakkosia käyttävät ihmiset.
8-bittiset merkistöt eivät vain yksinkertaisesti ole riittäviä tuollaisessa käytössä nykyaikana, joten sen takia käytetään sitä Unicodea. Sä voit listata vaikka kuinka paljon Unicoden haittapuolia, mutta se ei muuta sitä, että nuo 8-bittiset vaihtoehdot ovat yksinkertaisesti riittämättömiä, joten sitä Unicodea on käytännössä pakko käyttää.

 

[Sompi]

Paitsi että niitä tiedostoja nimeää ja sorsakoodeja kirjoittaa muutkin kuin latinalaisia aakkosia käyttävät ihmiset.

Entä sitten? Unicode ei vain toimi tuollaisessa paikassa, koska niiden verrattavien merkkijonojen pitää olla eksakteja. Tarkkeiden kanssa on kaikenlaisia poikkeuksia kuten esimerkiksi se ä-kirjain, joka löytyy unicode-merkistöstä valmiina, vaikka sen voi koota "manuaalisesti" myös a-kirjaimesta ja tarkkeesta yhdistelemällä. Vaikka merkkijonoja vertaileva funktio osaisikin ottaa tarkkeet huomioon ja ohittaa ne merkkijonoja vertaillessa (mikä sekään ei eksaktin datan tapauksessa ole se mitä halutaan, mutta jossain asiakirjan tekstihaussa voi toimia), niin kirjaimen "valmiin" version tullessa vastaan se vertailu hajoaa kuitenkin, jos kaikkia niitä valmiita poikkeuksia ei ole otettu funktion koodissa erikseen huomioon. Ja niitähän on jatkuvasti kasvava määrä.

8-bittiset merkistöt eivät vain yksinkertaisesti ole riittäviä tuollaisessa käytössä nykyaikana, joten sen takia käytetään sitä Unicodea. Sä voit listata vaikka kuinka paljon Unicoden haittapuolia, mutta se ei muuta sitä, että nuo 8-bittiset vaihtoehdot ovat yksinkertaisesti riittämättömiä, joten sitä Unicodea on käytännössä pakko käyttää.

Pakko käyttää? Siis pakko rikkoa asiat niin, etteivät ne toimi?

Ymmärrän kyllä unicoden välttämättömyyden sellaisissa paikoissa, joihin 8-bittinen tasasivuinen merkistö ei vain yksinkertaisesti taivu, mutta sinä et tunnu ymmärtävän niitä teknisiä tosiasioita, joiden takia unicode ei vain yksinkertaisesti toimi noissa matalan tason paikoissa, joissa informaation pitää olla eksaktia. Latinalaisia aakkosia käyttämättömät ihmiset voivat sitten käyttää niissä paikoissa jotain omaa merkistöään tai jotain sellaista rajattua osajoukkoa unicodesta, jossa on minimoitu kaikenlaisten ongelmien mahdollisuus.

Ohjelmointikielet on tarkoituksella suunniteltu niin, että asiasanat ja muut tärkeät merkit ovat kaikki 7-bittistä ASCIIta. Monet kielet on tarkoituksella tehty yhteensopiviksi sitäkin rajallisempien merkistöjen kanssa. Unicoden ohjausmerkeillä saa helposti lähdekoodin näyttämään tekstieditorissa toisenlaiselle kuin mitä kääntäjä näkee koodia kääntäessään. Unicoden pakottaminen lähdekoodien merkistöksi siis ihan konkreettisesti haittaa jo vapaan koodin ohjelmien luotettavuuttakin. Siis jälleen kerran ollaan sellaisen ongelman äärellä, että jos käytetään unicodea, niin pitää määrittää kaikenlaisia poikkeuksia sille, mitä merkkejä saa ja mitä ei saa käyttää. Lopputuloksena on sitten helvetin räjähdysherkkä systeemi, ja joku inklusiivisuusaktivisti alkaa kuitenkin puolestaloukkaantumaan kun jonkun tosi harvinaisen kielen joku kirjoitusmerkki ei olekaan kirjoitettavissa rajoituksien kanssa.

Mitään tällaisia ongelmia ei ole, kun päätetään vain, että lähdekoodi on jollain 8-bittisellä tasalevyisellä merkistöllä koodattu ja kommentit ovat englanniksi. Tai sitten ajatellaan laatikon ulkopuolelta ja keksitään joku ihan kokonaan uusi juttu, joka mahdollistaa kaikkien maailman kirjainmerkkien kirjoittamisen ilman em. ongelmia ja joka ei ole unicode.

 

[herra57]

Mitään tällaisia ongelmia ei ole, kun päätetään vain, että lähdekoodi on jollain 8-bittisellä tasalevyisellä merkistöllä koodattu ja kommentit ovat englanniksi. Tai sitten ajatellaan laatikon ulkopuolelta ja keksitään joku ihan kokonaan uusi juttu, joka mahdollistaa kaikkien maailman kirjainmerkkien kirjoittamisen ilman em. ongelmia ja joka ei ole unicode.

Liittyykö tähän ongelman helppon ratkaisuun se että esim ranskalaiset 7 vuotiaat lapset eivät voi alkaa opetella ohjelmointia kun he eivät osaa englantia pystyäkseen kirjoittaa kommentteja. Tai ranskalaiset aikuiset jotka ovat opetelleet kakkos ja kolmos kielikseen venäjän ja kiinankielen että ohjelmointi ei ole mahdollista myöhemmälläkään iällä. Joillakin ihmisryhmillä on polittisia pyrkimyksiä yrittää estää englannin nousemista valta-asemaan.

Päätetäänkö me esim että nämä seuraavat eivät ole ohjelmointikieliä ja niitten koodit eivät ole lähdekoodia: Non-English-based programming languages - Wikipedia

Mutta oikeasti ongelma turvalliseen eksaktisuuteen pyrkimisessä on että ensin pitäisi eksaktisti määritellä mikä on tarkka määritelmä sanalle lähdekoodi ja sitten pitäisi päättää mikä eksaktisti on se paikka systeemissä joka tällaisen lukituksen kyvykyydessä tähän lähdekoodiin tekee.

Editointointiohjelmat monet haluavat pystyä editoimaan kaikenlaista tekstiä kaikenlaisilla kielillä siis myös kaikkea muuta kuin lähdekoodia.
Versionhallintaohjelmat haluavat pystyä tallentamaan kaikenlaista tekstiä ja jopa binäärejä.
Kumpikaan näistä eli editointiohjelmat tai versionhallintaohjelmat eivät siis halua rajoittua pelkästään lähdekoodin käsittelyyn.

Jos kyse on turvallisuudesta niin on ensiarvoisen tärkeää että se paikka joka tällaisen rajoituksen merkistöön tekee ei ole ohitettavissa vihulaisen toimesta. Ehkä se ainoa paikka jota voisi kuvitella on kääntäjä. Mutta jos joku kääntäjä alkaa keksiä uusia rajoituksia niin eikö se vain menetä markkinaosuuksia kilpailevalle kääntäjälle?

Koska uusien rajoituksien keksiminen olemassaolevaan ekosysteemiin ei kuulosta voittavalta taktiikalta niin ehkä tällaisen uuden ominaisuuden takaamiseksi tarvitaan joku uusi ohjelmointikieli joka sitten alusta lähtien perustuu tällaiseen filosofiaan ja voittaako tämä uusi kieli sitten sijaa markkinoilla? Kuuluuko tähän samaan pakettiin sitten se uusi hieno merkistö joka ei ole unicode ja joka tukee kaikkia maailman kieliä? Ei ole ainakaan vaatimattomuudella pilattu tämä uusi systeemi.

Kiinostaisi myös kuulla miten tällaisen rajoituksen kanssa eläessä kirjoitetaan ohjelmia jotka on kansainvälisöitävissä että ne esim osaavat kirjoittaa ruudulle "Hello World" kymmenillä eri kielillä ja myös esim kiinaksi ja onko tällaisen hyvin tärkeän ja yleisen ominaisuuden ohjelmointi näillä työkaluilla niin helppoa että tämä hieno uudistus saa sijaa markkinoilla. Missä esim kiinankieliset tulostettavat merkkijonot on kirjoitettuna jos niitä ei voi kirjoittaa lähdekooditiedostoihin? Kokeeko joku kiinalainen, venäläinen tai ranskalainen ihminen halua tutustua tähän uuteen ohjelmointikieleen jos "Hello World" ohjelman kirjoittaminen tällä uudella kielellä kohtaa jotakin vaikeuksia?

 

[jad]

Ohjelmointikielet on tarkoituksella suunniteltu niin, että asiasanat ja muut tärkeät merkit ovat kaikki 7-bittistä ASCIIta. Monet kielet on tarkoituksella tehty yhteensopiviksi sitäkin rajallisempien merkistöjen kanssa. Unicoden ohjausmerkeillä saa helposti lähdekoodin näyttämään tekstieditorissa toisenlaiselle kuin mitä kääntäjä näkee koodia kääntäessään. Unicoden pakottaminen lähdekoodien merkistöksi siis ihan konkreettisesti haittaa jo vapaan koodin ohjelmien luotettavuuttakin.

Mikä tässä on se konkreettinen ongelma ? Jos lähdekoodi on ohjausmerkkien avulla saatu näyttämään toiselta mitä kääntäjä näkee, niin kääntäjä toki antaa jonkinlaisen virheilmoituksen vikkapa siitä, että muuttujanimissä ei tueta emojeja. Tai pahimmassa tapauksessa kääntäjä kaatuu virheeseen. Haluaisin nähdä esimerkin sellaisesta koodista, joka a) näyttää editorissa eri koodilta, b) kääntyy kääntäjällä ongelmitta, c) tekee jotain muuta mitä editorissa koodia lukemalla luulisi sen tekevän.

Valmiit unicode kirjastothan sitten taas on olemassa sitä varten, että omassa koodissa ei tarvitse huomioida kaikkia mahdollisia poikkeuksia niitä merkkijonoja vertaillessa.

Aiheeseen liittyvä varsin viihdyttäväkin Dylan Beattien pitämä esitys "Plain Text" NDC 2022:ssa. n. 30 minuutin kohdalla käsetellään aakkosjärjestystä, mikä vahvasti liittyy tähän merkkijonojen vertailuun.

 

[Sompi]

Nyt on kyllä herra57:lta sellaista tahallista väärinymmärtämistä, että en vastaa ollenkaan, vaan raportoin moderaattorille.

Mikä tässä on se konkreettinen ongelma ? Jos lähdekoodi on ohjausmerkkien avulla saatu näyttämään toiselta mitä kääntäjä näkee, niin kääntäjä toki antaa jonkinlaisen virheilmoituksen vikkapa siitä, että muuttujanimissä ei tueta emojeja. Tai pahimmassa tapauksessa kääntäjä kaatuu virheeseen. Haluaisin nähdä esimerkin sellaisesta koodista, joka a) näyttää editorissa eri koodilta, b) kääntyy kääntäjällä ongelmitta, c) tekee jotain muuta mitä editorissa koodia lukemalla luulisi sen tekevän.

Kommentteihin ne ohjausmerkit tietysti laitetaan. Sillä saadaan sitten viereiset rivit näyttämään toisenlaisilta.

Valmiit unicode kirjastothan sitten taas on olemassa sitä varten, että omassa koodissa ei tarvitse huomioida kaikkia mahdollisia poikkeuksia niitä merkkijonoja vertaillessa.

Mitenkähän hyvin sellaiset "valmiit unicode kirjastot" ovat sovellettavissa matalan tason koodiin, kuten tiedostonimien parsimiseen käyttöjärjestelmäytimen tiedostojärjestelmäajurissa? Mieti hetki, ennen kuin vastaat.

Entä staattisesti linkitetyt ohjelmat, joissa on siitä "valmiista unicode kirjastosta" vanhempi versio, joka ei tunne uusinta unicodea?

 

[jad]

Kommentteihin ne ohjausmerkit tietysti laitetaan.

Ja kommenteissa olevista ohjausmerkeistä on haittaaa... missä ?

Mitenkähän hyvin sellaiset "valmiit unicode kirjastot" ovat sovellettavissa matalan tason koodiin, kuten tiedostonimien parsimiseen käyttöjärjestelmäytimen tiedostojärjestelmäajurissa? Mieti hetki, ennen kuin vastaat.

Tämähän toki on haaste jos olet kirjoittamassa omaa käyttöjärjestelmää assemblerilla, mutta oikeassa elämässä se käyttöjärjestelmäydin nykyaikana jo sisältää tuen unicodelle ja tarvittavat "valmiit unicode kirjastot" on siellä matalallakin tasolla käytettävissä, eikä tälläistä ongelmaa ole. Jos siis puhutaan mainline käyttiksistä, eikä mistään sulautetuista ym. "marginaali" käyttöjärjestelmistä.

 

[Sompi]

Ja kommenteissa olevista ohjausmerkeistä on haittaaa... missä ?

Mikä tuossa on niin hankalaa ymmärtää? Ohjausmerkeillä voi saada koodin näyttämään siltä kuin se tekisi jotain muuta kuin mitä se oikeasti tekee. Kääntäjä näkee yhtä ja koodin ihmistarkkailija toista.

Tämähän toki on haaste jos olet kirjoittamassa omaa käyttöjärjestelmää assemblerilla, mutta oikeassa elämässä se käyttöjärjestelmäydin nykyaikana jo sisältää tuen unicodelle ja tarvittavat "valmiit unicode kirjastot" on siellä matalallakin tasolla käytettävissä, eikä tälläistä ongelmaa ole. Jos siis puhutaan mainline käyttiksistä, eikä mistään sulautetuista ym. "marginaali" käyttöjärjestelmistä.

Paskapuhetta. Kuten olen jo aiemmin tässä viestiketjussa kirjoittanut, esim. Linux ei välitä merkistöistä mitään, vaan kaikki merkkijonot ovat käyttöjärjestelmäytimelle vain tavujonoja, useimmiten nollaloppuisia sellaisia. Mitään unicoden konseptia ei siis ole niin matalalla tasolla olemassa, eikä varsinkaan mitään "valmiita unicode kirjastoja". Tämä taitaa tosin olla sellainen asia, jota voi toistaa tässäkin ketjussa vaikka loputtomiin, eikä se silti mene unicode-pöhisijöiden kaaliin.

Ja unicode-merkkejä sisältävillä tiedostonimillä saa helposti ongelmia aikaan Linuxillakin.

 

[JCSH]

Ymmärrän kyllä unicoden välttämättömyyden sellaisissa paikoissa, joihin 8-bittinen tasasivuinen merkistö ei vain yksinkertaisesti taivu, mutta sinä et tunnu ymmärtävän niitä teknisiä tosiasioita, joiden takia unicode ei vain yksinkertaisesti toimi noissa matalan tason paikoissa, joissa informaation pitää olla eksaktia. Latinalaisia aakkosia käyttämättömät ihmiset voivat sitten käyttää niissä paikoissa jotain omaa merkistöään tai jotain sellaista rajattua osajoukkoa unicodesta, jossa on minimoitu kaikenlaisten ongelmien mahdollisuus.

Mutta sä et nyt ymmärrä tässä sitä, että nykyään käytännössä kaikki paikat ovat sellaisia, että 8-bittinen merkistö ei vain yksinkertaisesti taivu.
Tiedostonnimet ovat mainio esimerkki tuosta. Niitä tiedostoja luovat muutkin kuin latinalaisia aakkosia käyttävät ihmiset. Niitä latinalaisilla aakkosilla nimettyjä tiedostoja katselevat myös sellaiset, jotka eivät itse käytä latinalaisia aakkosia. Niitä ei-latinalaisilla aakkosilla nimettyjä tiedostoja käyttävät myös sellaiset henkilöt, jotka itse käyttävät latinalaisia aakkosia. Sä voit valittaa jostain hakutoiminnon toteuttamisesta unicoden kanssa, mutta tuo on pikkuinen ongelma verrattuna siihen, että jos sulla on koneella useita eri tiedostoja joiden tiedostonimet on kirjoitettu jollain eri merkistöllä.
Mitenkäs lähdet toteuttamaan sitä hakutoimintoa tuollaisessa tilanteessa, missä tiedostonimet ovat silkkaa siansaksaa jos on käytössä väärä merkistö?
Joten vastaus on se Unicode, jonka takia sitä Unicodea käytetään nykyään käyttöjärjestelmissä muun muassa siellä tiedostonimissä. Puhumattakaan siitä, että käytännössä kaikki softat ja koko internetti pyörivät UTF-8:lla.

Sorsakoodeissa sama juttu. Tarvitaan tuki useille eri aakkosille vähintäänkin merkkijonoliteraaleissa. Käytännössä myös kommenteille.
Joten ollaan tilanteessa, missä ne sorsakooditiedostot tulevat olemaan sitä UTF-8:ia. Jos siellä sitten on jotain UTF-8:n tuomia ansoja, niin se pitää sitten ottaa huomioon niissä kääntäjissä ja editoreissa.
Mutta ratkaisu ei ole mitkään 8-bittiset merkistöt, koska ne 8-bittiset merkistöt eivät täytä nykyajan vaatimuksia. Jonka takia käytännössä kaikissa nykyajan ohjelmointikielissä on siirrytty, tai ollaan siirtymässä, UTF-8:n käyttöön ihan siellä lähdekooditasollakin.

Mitään tällaisia ongelmia ei ole, kun päätetään vain, että lähdekoodi on jollain 8-bittisellä tasalevyisellä merkistöllä koodattu ja kommentit ovat englanniksi. Tai sitten ajatellaan laatikon ulkopuolelta ja keksitään joku ihan kokonaan uusi juttu, joka mahdollistaa kaikkien maailman kirjainmerkkien kirjoittamisen ilman em. ongelmia ja joka ei ole unicode.

Juuh okei, hyvä idea jos unohdetaan kaikki ne miljoonat koodarit maailmassa, jotka eivät puhu sitä englantia.

 

[Sompi]

Mutta sä et nyt ymmärrä tässä sitä, että nykyään käytännössä kaikki paikat ovat sellaisia, että 8-bittinen merkistö ei vain yksinkertaisesti taivu.
Tiedostonnimet ovat mainio esimerkki tuosta. Niitä tiedostoja luovat muutkin kuin latinalaisia aakkosia käyttävät ihmiset. Niitä latinalaisilla aakkosilla nimettyjä tiedostoja katselevat myös sellaiset, jotka eivät itse käytä latinalaisia aakkosia. Niitä ei-latinalaisilla aakkosilla nimettyjä tiedostoja käyttävät myös sellaiset henkilöt, jotka itse käyttävät latinalaisia aakkosia. Sä voit valittaa jostain hakutoiminnon toteuttamisesta unicoden kanssa, mutta tuo on pikkuinen ongelma verrattuna siihen, että jos sulla on koneella useita eri tiedostoja joiden tiedostonimet on kirjoitettu jollain eri merkistöllä.
Mitenkäs lähdet toteuttamaan sitä hakutoimintoa tuollaisessa tilanteessa, missä tiedostonimet ovat silkkaa siansaksaa jos on käytössä väärä merkistö?
Joten vastaus on se Unicode, jonka takia sitä Unicodea käytetään nykyään käyttöjärjestelmissä muun muassa siellä tiedostonimissä. Puhumattakaan siitä, että käytännössä kaikki softat ja koko internetti pyörivät UTF-8:lla.

Miten toteutat merkkijonovertailut luotettavasti unicodelle? Ymmärrätkö edes tämän aiheen teknisestä puolesta mitään? Ymmärrätkö, miten pahoja mm. tietoturvaan liittyviä ongelmia voidaan saada aikaan sillä, että tiedostoja tiedostojärjestelmästä hakiessa tiedostonimiin liittyvät merkkijonovertailut eivät ole eksakteja? Käytännössä niiden eksaktiudesta on luovuttava, jos halutaan sallia unicoden käyttäminen tiedostonimissä. Esimerkiksi joku "moottoriöljyn_määrät.txt" -tyyppinen tiedostonimi voidaan sitten koodata monella eri tavalla ja tiedostoa avatessa kernelin pitää assosioida useampi mahdollinen tavujono nimenomaan tuon yhden ja saman tiedoston tiedostonimeksi. Jos kyse sitten onkin tekstitiedoston sijaan vaikka jostain dynaamisesti linkitetystä kirjastosta, niin väärän tiedoston hakemisella saadaan jo helposti merkittävääkin tuhoa aikaiseksi.

Microsoft on UTF-16-merkistöä pakottanut tiedostonimiin jo ainakin VFATin keksimisestä asti ja sillä on saatu aikaan juuri noita edelläkuvatun kaltaisia ongelmia. Microsoft on tehnyt sillä tavalla tyhmästi, että ihan tiedostojärjestelmän speksin tasolla on määritelty tiedostonimien merkistöksi nimenomaan UTF-16. Sen sijaan esimerkiksi Linuxin ext4-tiedostojärjestelmässä tiedostonimi on vain tavujono, jonka pituus on kerrottu hakemistolistauksessa sitä tiedostonimeä edeltävässä kentässä - mitään merkistöä sille ei siis ole speksin tasolla pakotettu. Tuo Linuxin tapa tehdä asia on paljon järkevämpi.

Muun muassa HTTP:n (ja siinä sivussa myös HTML-dokumenttien) vakiomerkistön on muuten ihan speksissä määritelty olevan ISO-8859-1, joten "koko internetti" ei todellakaan pyöri UTF-8:lla. Sama pätee useimpiin yleisessä käytössä oleviin internet-protokolliin, joissa merkistöllä on merkitystä, käytännössä siis tekstipohjaisiin protokolliin.

Sorsakoodeissa sama juttu. Tarvitaan tuki useille eri aakkosille vähintäänkin merkkijonoliteraaleissa. Käytännössä myös kommenteille.
Joten ollaan tilanteessa, missä ne sorsakooditiedostot tulevat olemaan sitä UTF-8:ia. Jos siellä sitten on jotain UTF-8:n tuomia ansoja, niin se pitää sitten ottaa huomioon niissä kääntäjissä ja editoreissa.
Mutta ratkaisu ei ole mitkään 8-bittiset merkistöt, koska ne 8-bittiset merkistöt eivät täytä nykyajan vaatimuksia. Jonka takia käytännössä kaikissa nykyajan ohjelmointikielissä on siirrytty, tai ollaan siirtymässä, UTF-8:n käyttöön ihan siellä lähdekooditasollakin.

Olisipa mielenkiintoista tietää, miten matalan tason juttujen koodailusta sinullakaan on mitään kokemusta. Kummallista, että haluat vain pakottaa kaikille sitä omaa juttuasi piittaamatta tietoturvasta ja siitä, onko sille koko jutulle edes tarvetta kohderyhmällä.

Juuh okei, hyvä idea jos unohdetaan kaikki ne miljoonat koodarit maailmassa, jotka eivät puhu sitä englantia.

Sinäkin ymmärsit kyllä varmasti asiayhteydestä, että kyse oli yleisesti kontribuoitavista vapaan softan projekteista. Sellaisissa ei ole mitään tarvetta käyttää lähdekoodeissa unicodea, vaan 7-bittinen ASCII riittää hyvin. Mutta tietysti sinäkin ymmärsit tuon tahallasi väärin, jotta pääset näsäviisastelemaan ja derailaamaan keskustelua.

 

[love_doctor]

Paskapuhetta. Kuten olen jo aiemmin tässä viestiketjussa kirjoittanut, esim. Linux ei välitä merkistöistä mitään, vaan kaikki merkkijonot ovat käyttöjärjestelmäytimelle vain tavujonoja, useimmiten nollaloppuisia sellaisia. Mitään unicoden konseptia ei siis ole niin matalalla tasolla olemassa, eikä varsinkaan mitään "valmiita unicode kirjastoja". Tämä taitaa tosin olla sellainen asia, jota voi toistaa tässäkin ketjussa vaikka loputtomiin, eikä se silti mene unicode-pöhisijöiden kaaliin.

Ja unicode-merkkejä sisältävillä tiedostonimillä saa helposti ongelmia aikaan Linuxillakin.

Siis Linuxin kanta tuossa on erittäin selkeä. Se ei ota kantaa merkistöön natiiveilla tiedostojärjestelmillä ollenkaan. Tiedostonimen merkitys ja renderöinti on ihmisille suunnattu asia. Asiaa voi pohtia siitä näkökulmasta, minkä komponentin vastuulla jonkin asian pitäisi olla - esimerkkinä tiedostojen aakkostus hakemistossa. Aakkostuksen oikeellisuus riippuu lokaaliasetuksista. Linux on monen käyttäjän ympäristö. Jos seatissa 0 on suomalainen käyttäjä ja seatissa 1 tuon esimerkin itävaltalainen käyttäjä, he voivat haluta nähdä täsmälleen saman jaetun hakemiston aakkostettuna eri tavoin. Eli väliin tarvitaan kerroksia, jotka lukevat mm. käyttäjäasetukset. Jossain toisessa kielessä ei välttämättä ole lainkaan järjestyksen konseptia ja sekin pitäisi hallita.

Mitenkähän hyvin sellaiset "valmiit unicode kirjastot" ovat sovellettavissa matalan tason koodiin, kuten tiedostonimien parsimiseen käyttöjärjestelmäytimen tiedostojärjestelmäajurissa? Mieti hetki, ennen kuin vastaat.

Entä staattisesti linkitetyt ohjelmat, joissa on siitä "valmiista unicode kirjastosta" vanhempi versio, joka ei tunne uusinta unicodea?

Väliin tarvitaan 8-bittisilläkin merkistöillä muunnoskerroksia. Muutenhan sidot kaiken järjestelmässä siihen tiedostojärjestelmän käyttämään merkistöön. Tässäkin hyvä huomata, että tiedostojärjestelmä ottaa kantaa vain tiedostonimiin. Tiedoston sisältö on sille täysin musta laatikko. Noiden pienten (7/8-bittisten) merkistöjen kanssa pitää jatkuvasti tiedostaa merkistön näkyvyysalue.

Esimerkki: käytät vaikkapa Javaa. Sinulla voi olla 437-merkistö java-tiedostojen tiedostonimillä, 850-merkistö lähdekooditiedoston sisällöllä, iso-8859-1 luettavien tiedostojen nimissä usb-tikulla, win-1252-merkistö niiden tiedostojen sisällöissä, joita luet em. lähdekoodilla ja iso-8859-15 niissä tiedostoissa, joihin kirjoitat. Ja jos haluat lokittaa mitä teit, sen lokia lukevan terminaalin merkistö voi olla 860. Muunnoksia pitää tehdä ihan helvetisti. Lisäksi koska joka merkistössä voi olla toisista puuttuvia merkkejä, tarvitset välikappaleeksi jotain Unicoden kaltaista supermerkistöä tai laajempaa lookup-taulua ettei tietoa katoa.

Unicodeen löytyy kirjastoja. Liioittelet vaan niiden tarpeen yleisyyttä. Esim. monet tekstioperaatiot voi tehdä täysin ilman ymmärrystä mitä teksti sisältää. 8-bittisten merkkijonojen kanssa saatat haluta muokata tekstin käsittelyä varten editoriin esim. riviperustaisesti. UTF-8, vaikka on vaihtelevanmittainen, tukee kyllä esim. tekstin selaamista eteen ja taaksepäin ja pystyy toipumaan virheistäkin. UTF-8:n kanssa on fiksua käyttää datatyyppejä joissa on mukana pituustieto. Myös 8-bittisten merkistöjen kanssa tarvitset helposti apukirjastoja jos haluat tukea vaikkapa aakkostusta eri merkistöillä. Ja tähän päälle tulevat tietysti lokaali/kollaatio-asetukset.

 

[love_doctor]

Käytännössä niiden eksaktiudesta on luovuttava, jos halutaan sallia unicoden käyttäminen tiedostonimissä. Esimerkiksi joku "moottoriöljyn_määrät.txt" -tyyppinen tiedostonimi voidaan sitten koodata monella eri tavalla ja tiedostoa avatessa kernelin pitää assosioida useampi mahdollinen tavujono nimenomaan tuon yhden ja saman tiedoston tiedostonimeksi. Jos kyse sitten onkin tekstitiedoston sijaan vaikka jostain dynaamisesti linkitetystä kirjastosta, niin väärän tiedoston hakemisella saadaan jo helposti merkittävääkin tuhoa aikaiseksi.

Ä-kirjainten kanssa käytännössä tyypillisin ongelma on se, että Mac ja Linux koodaavat sen oletuksena mahdollisesti eri tavalla Unicodessa - koostemerkeillä tai ilman. Yleensä näissäkin on niin, että kaikki esiintymät kirjainta ovat samalla tavalla koodattu. Tietty pahempiakin sotkuja voi kehittää. Näihin auttaisi jos tiedonvälityksessä sovittaisiin esim. normaalimuodoista ja järjestelmä voi sitten sisäisesti tallentaa miten haluaa. Linuxin tapa on näissä aika suoraviivainen ja tarkka - jos nimi ei ole bitilleen oikein, tiedostoa ei löydy. Unicodessahan yksi ongelma on käyttäjän hämääminen. Voi olla monta samannimiseltä näyttävää tiedostoa, joista ei tiedä, mihin viitataan. Tässäkin hiukan ongelmia rajaa se, että järjestelmän hakemistojen merkityksellisiin tiedostoihin ei yleensä käytetä monitulkintaisia merkkejä ja niihin ei ole kaikilla kirjoitusoikeuksia.

 

[JCSH]

Miten toteutat merkkijonovertailut luotettavasti unicodelle? Ymmärrätkö edes tämän aiheen teknisestä puolesta mitään? Ymmärrätkö, miten pahoja mm. tietoturvaan liittyviä ongelmia voidaan saada aikaan sillä, että tiedostoja tiedostojärjestelmästä hakiessa tiedostonimiin liittyvät merkkijonovertailut eivät ole eksakteja? Käytännössä niiden eksaktiudesta on luovuttava, jos halutaan sallia unicoden käyttäminen tiedostonimissä. Esimerkiksi joku "moottoriöljyn_määrät.txt" -tyyppinen tiedostonimi voidaan sitten koodata monella eri tavalla ja tiedostoa avatessa kernelin pitää assosioida useampi mahdollinen tavujono nimenomaan tuon yhden ja saman tiedoston tiedostonimeksi. Jos kyse sitten onkin tekstitiedoston sijaan vaikka jostain dynaamisesti linkitetystä kirjastosta, niin väärän tiedoston hakemisella saadaan jo helposti merkittävääkin tuhoa aikaiseksi.

Microsoft on UTF-16-merkistöä pakottanut tiedostonimiin jo ainakin VFATin keksimisestä asti ja sillä on saatu aikaan juuri noita edelläkuvatun kaltaisia ongelmia. Microsoft on tehnyt sillä tavalla tyhmästi, että ihan tiedostojärjestelmän speksin tasolla on määritelty tiedostonimien merkistöksi nimenomaan UTF-16. Sen sijaan esimerkiksi Linuxin ext4-tiedostojärjestelmässä tiedostonimi on vain tavujono, jonka pituus on kerrottu hakemistolistauksessa sitä tiedostonimeä edeltävässä kentässä - mitään merkistöä sille ei siis ole speksin tasolla pakotettu. Tuo Linuxin tapa tehdä asia on paljon järkevämpi.

Sä nyt tässä jatkuvasti jumitat tuossa merkkijonovertailuissa ja luulet, että en tajuaisi sen ongelmallisuutta. Tajuan kyllä.
Mutta koita sä nyt tajuta, että kun vertailuun laitetaan nuo unicoden tuomat ongelmat ja unicoden ratkaisemat ongelmat, niin nuo ratkaistut ongelmat painavat enemmän siellä vaakakupissa kuin ne ongelmat.
Tuon seurauksena sitten niissä tiedostonimissä käytetään sitä Unicodea.

Muun muassa HTTP:n (ja siinä sivussa myös HTML-dokumenttien) vakiomerkistön on muuten ihan speksissä määritelty olevan ISO-8859-1, joten "koko internetti" ei todellakaan pyöri UTF-8:lla. Sama pätee useimpiin yleisessä käytössä oleviin internet-protokolliin, joissa merkistöllä on merkitystä, käytännössä siis tekstipohjaisiin protokolliin.

Okei, ei koko internet. Vain 98,3% webbisivuista käyttää UTF-8:ia.

Olisipa mielenkiintoista tietää, miten matalan tason juttujen koodailusta sinullakaan on mitään kokemusta. Kummallista, että haluat vain pakottaa kaikille sitä omaa juttuasi piittaamatta tietoturvasta ja siitä, onko sille koko jutulle edes tarvetta kohderyhmällä.

Vissiin varsinaiset argumentit on loppu ja joudut turvautumaan ad hominemiin?
En mä ole mitään pakottamassa, mä vain totean, että mitkä ovat nykyajan softakehitys vaatimukset ja miten niihin on mukauduttu. Unicoden laaja käyttö on osa tuota.

Sinäkin ymmärsit kyllä varmasti asiayhteydestä, että kyse oli yleisesti kontribuoitavista vapaan softan projekteista. Sellaisissa ei ole mitään tarvetta käyttää lähdekoodeissa unicodea, vaan 7-bittinen ASCII riittää hyvin. Mutta tietysti sinäkin ymmärsit tuon tahallasi väärin, jotta pääset näsäviisastelemaan ja derailaamaan keskustelua.

Vapaan softan projektit käyttävät samoja työkaluja ja kieliä kuin kaikki muutkin projektit.

 

[Paapaa]

Muun muassa HTTP:n (ja siinä sivussa myös HTML-dokumenttien) vakiomerkistön on muuten ihan speksissä määritelty olevan ISO-8859-1, joten "koko internetti" ei todellakaan pyöri UTF-8:lla.

HTML:n spesifikaatiossa kuitenkin suositellaan UTF-8:n käyttämistä:

Authors are encouraged to use UTF-8. Conformance checkers may advise authors against using legacy encodings. [RFC3629]

Authoring tools should default to using UTF-8 for newly-created documents. [RFC3629]

4 The elements of HTML — HTML5

Ja HTTP tietenkin sallii sen käyttämisen. Ja kyllä koko internet käytännössä pyörii UTF-8:lla. Tietenkin pyörii, muu olisi älytöntä. Suomalaisten liikenteessä luku on varmaan hyvin lähellä 100%:ia.

UTF-8 is the dominant encoding for the World Wide Web and other Internet technologies, accounting for 98.3% of all web pages, 99.1% of the top 100,000 pages, and up to 100% for many languages, as of 2024.[9] Virtually all countries and languages have 95% or more use of UTF-8 encodings on the web.

UTF-8 - Wikipedia

en.wikipedia.org