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

 

[pulatunnus]

Miten toteutat merkkijonovertailut luotettavasti unicodelle? Ymmärrätkö edes tämän aiheen teknisestä puolesta mitään?

tai jollain satunnaisilla 7-8bit merkistöillä.

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.

Taitaa melkein järjestän vapaan softan projekteissa olla tiedostoja joissa merkistöksi ei riitä ASCII , ja joku mainitsi aiemmin kommentit, ja tekijät. Ja jos kyse ei ole mistään hätäsestä rautalanka virityksestä, niin lähteä kannattaa kuitenkin siitä että se pienen pienikin juttu voi joskus ylittää rajat.

Tiedostojärjestelmä, tiedostojen nimet, niin miten ne voisi jollain ASCIIllä toteuttaa, tai jollain 8bittisellä "ASCII" laajennuksella mikä sitten vaatisi että jokaisen nimen yhteydessä pitäisi kertoa mikä merkistö, siitäkin seuraisi se että suppea merkistö johtaa siihen että yksittäisen tiedoston nimestä joutuu tiputtaa merkkejä pois, tai muuttaa toisiksi. vertaa siinä sitten tiedoston nimiä, tai etsi esim tietyn merkkijonon sisältäviä tiedoston nimiä.

 

[Sompi]

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.

Unicoden pakottaminen pakottaa nuo unicoden tuomat ongelmat sellaisiinkin käyttökohteisiin, joihin jokin muu merkistö (tai täydellinen merkistöriippumattomuus) sopii paremmin.

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

Pointti oli, että noissa tekstimuotoisissa protokollissa kuten HTTP:ssä on pakko olla protokollan speksin tasolla määriteltynä joku merkistö, jota se protokolla käyttää. Sen merkistön on hyvä olla joku yksinkertainen merkistö, eli 8-bittinen tasalevyinen merkistö kuten ISO-8859-1 sopii siihen hyvin. Johonkin unicoden kaltaiseen monimutkaisempaan ja alati muuttuvaan merkistöön pakottaminen aiheuttaisi melkoisia ongelmia protokollan toteutuksien kanssa.

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.

Usein vain nimenomaan tietyntyyppiset trendien aallonharjalla surffaavat javascript-pöhisijät näyttävät olevan sitä mieltä, että unicode on hyvä kaikille ja joka paikkaan, kun eivät ymmärrä sen teknistä toteutusta ja sen tuomia ongelmia. Jos kerran et pakota unicodea, niin en ymmärrä, mistä tässä edes kiistellään. Jokainen käyttäköön itse kuhunkin käyttötarkoitukseen parhaiten sopivaa merkistöä, tai mitä merkistöä nyt haluaakaan käyttää.

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

Tuo RFC3629 on UTF-8:n spesifikaatio, eikä siellä lue mitään tuollaista.

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.

HTTP:ssä on erikseen otsaketieto merkistön määrittelyä varten, mutta aloitusmerkistö HTTP-pyyntöä tehdessä on aina ISO-8859-1. Se HTTP:n Content-Type -otsakekentän charset-lisämääre tosin taitaa vaikuttaa vain itse hyötykuorman oletusmerkistöön eikä itse otsakkeen sen jälkeen tulevien kenttien merkistöön. Sen hyötykuorman merkistönkin voi sitten HTML:n tapauksessa vielä määrittää uusiksi HTML-tageilla. Lähinnä tuo merkistön määrittely HTTP:n otsaketiedoissa on tärkeää vain siinä tapauksessa, että se HTML- tai XML-dokumentti onkin koodattu jollain harvinaisemmalla merkistöllä, joka ei ole ASCII-yhteensopiva, ja ilman HTTP:n otsakkeessa olevaa merkistötietoa selain ei sitten osaisi tulkita edes niitä dokumentin tageja oikein.

 

[Paapaa]

Tuo RFC3629 on UTF-8:n spesifikaatio, eikä siellä lue mitään tuollaista.

Ei tietenkään, vaan se lukee HTML-spesifikaatiossa, josta oli kyse, ja jonka sulle jo linkkasinkin ja lainasin suoraan.

 

[pulatunnus]

Unicoden pakottaminen pakottaa nuo unicoden tuomat ongelmat sellaisiinkin käyttökohteisiin, joihin jokin muu merkistö (tai täydellinen merkistöriippumattomuus) sopii paremmin.

Tässä kai sitä nyt tarjottu käyttökohteisiin joissa sitä tarvitaan. eli tarvitaan tai tullaan tarvitsemaan muutakin kuin ASCII merkkejä.

Pointti oli, että noissa tekstimuotoisissa protokollissa kuten HTTP:ssä on pakko olla protokollan speksin tasolla määriteltynä joku merkistö, jota se protokolla käyttää. Sen merkistön on hyvä olla joku yksinkertainen merkistö, eli 8-bittinen tasalevyinen merkistö kuten ISO-8859-1 sopii siihen hyvin.

Riittääkö tuo edes fi domaineihin.

 

[JCSH]

Unicoden pakottaminen pakottaa nuo unicoden tuomat ongelmat sellaisiinkin käyttökohteisiin, joihin jokin muu merkistö (tai täydellinen merkistöriippumattomuus) sopii paremmin.

Eihän sitä Unicodea taideta pakottaa mihinkään muualle kuin sellaisiin paikkoihin, joissa sen käyttö on erittäin tarpeellista. Eli käytännössä kaikki sellaiset paikat, joissa on ihmisen luettavaksi tarkoitettua tekstiä.

Pointti oli, että noissa tekstimuotoisissa protokollissa kuten HTTP:ssä on pakko olla protokollan speksin tasolla määriteltynä joku merkistö, jota se protokolla käyttää. Sen merkistön on hyvä olla joku yksinkertainen merkistö, eli 8-bittinen tasalevyinen merkistö kuten ISO-8859-1 sopii siihen hyvin. Johonkin unicoden kaltaiseen monimutkaisempaan ja alati muuttuvaan merkistöön pakottaminen aiheuttaisi melkoisia ongelmia protokollan toteutuksien kanssa.

Toki jos kyse on jostain protokollaviesteistä, jotka ei ole tarkoitettu ihmisten luettavaksi, niin niissä ei välttämättä ole tarvetta sille Unicodelle.

Usein vain nimenomaan tietyntyyppiset trendien aallonharjalla surffaavat javascript-pöhisijät näyttävät olevan sitä mieltä, että unicode on hyvä kaikille ja joka paikkaan, kun eivät ymmärrä sen teknistä toteutusta ja sen tuomia ongelmia. Jos kerran et pakota unicodea, niin en ymmärrä, mistä tässä edes kiistellään. Jokainen käyttäköön itse kuhunkin käyttötarkoitukseen parhaiten sopivaa merkistöä, tai mitä merkistöä nyt haluaakaan käyttää.

Ohjelmointikielissä Unicode on nykyään enemmänkin sääntö kuin poikkeus. Uudemmat kielet (esim. vaikkapa Rust, Kotlin ja Swift) on tehty lähtökohtaisesti käyttämään UTF-8:ia.
Vanhempiin kieliin, kuten esim. C++ ja Java, tuo tuki on lisätty jälkikäteen työkaluihin ja spekseihin. C++:ssa luonnollisesti toteutukset juoksevat reippaasti speksejä edellä ja nyt sitten vissiin C++ 23:ssa alkavat laittamaan vähän enemmän sääntöjä. Esim poop-emojin heittäminen poikkeuksena tullaan kieltämään.
Toki voit leimata kaiken mitä on tullut alkuperäisen ANSI C:n jälkeen "javascript-pöhinäksi", mutta se nyt ei ole kovin realistinen kuva nykyajan softakehityksestä.

 

[love_doctor]

Ohjelmointikielissä Unicode on nykyään enemmänkin sääntö kuin poikkeus. Uudemmat kielet (esim. vaikkapa Rust, Kotlin ja Swift) on tehty lähtökohtaisesti käyttämään UTF-8:ia.
Vanhempiin kieliin, kuten esim. C++ ja Java, tuo tuki on lisätty jälkikäteen työkaluihin ja spekseihin.

Javassahan tilanne on se, että siinä oli niin aikaisessa vaiheessa Unicode-tuki, että silloin Unicode ei ollut vielä kehittynyt nykyiseen muotoonsa. Sittemmin Javassa on vaihtunut UTF-8 oletukseksi esim. API-tasolla. Eli tukea oli, mutta formaatti vaan vanha.

 

[jad]

Niin, koska sitä unicodea ei ole sinne HTTP otsakkeisiin pakotettu, niin ne näyttää sitten tältä:

GET /%E4%E4li%F6-%E4l%E4-ly%F6-%F6%F6li%E4-l%E4ikkyy/
Host: xn--kksellist-u2aaj0u.fi

sen sijaan, että unicodella näyttäisi tältä:

GET /ääliö-älä-lyö-ööliä-läikkyy/
Host: ääkkösellistä.fi

Totta on, että ei näitä varsinaisesti ole ihmisten luettavaksi tarkoitettu, mutta välillä sekin on tarpeen.

 

[Sompi]

Niin, koska sitä unicodea ei ole sinne HTTP otsakkeisiin pakotettu, niin ne näyttää sitten tältä:

GET /%E4%E4li%F6-%E4l%E4-ly%F6-%F6%F6li%E4-l%E4ikkyy/
Host: xn--kksellist-u2aaj0u.fi

sen sijaan, että unicodella näyttäisi tältä:

GET /ääliö-älä-lyö-ööliä-läikkyy/
Host: ääkkösellistä.fi

Totta on, että ei näitä varsinaisesti ole ihmisten luettavaksi tarkoitettu, mutta välillä sekin on tarpeen.

Mutta edelleenkin tuo unicode-versio voisi näyttää hexdumppina aika monenlaiselta riippuen siitä, miten nuo ääkköskirjaimet on koostettu. Mistä palvelin voi tietää, mitä haetaan? 8-bittisten koodisivumerkistöjen kanssa ei ole tuollaista ongelmaa, koska kullekin kirjaimelle on vain yksi esitystapa.

 

[pulatunnus]

Mutta edelleenkin tuo unicode-versio voisi näyttää hexdumppina aika monenlaiselta riippuen siitä, miten nuo ääkköskirjaimet on koostettu. Mistä palvelin voi tietää, mitä haetaan? 8-bittisten koodisivumerkistöjen kanssa ei ole tuollaista ongelmaa, koska kullekin kirjaimelle on vain yksi esitystapa.

Yritätkö nyt sanoa että jos yhden kirjaimen esittämiseen tarvitaan yhdestä useaan tavuun, niin se on jotenkin hyvä juttu, vs se että käytettäisiin merkistö jossa yhden kirjaimen esittämiseen tarvitaan tavuja yhdestä useampaan riippuen tarpeesta. Ja vaikka eivät olisi tarkoitettu ihmisen luettavaksi niin olisivat myös sitä.

Ja vielä asiayhteydessä missä osa tekstistä on ihmiselle esitettävää ja tai ihmisen syöttämää., jonka kaveriksi sitten esitit merkistöä joka ei riittä edes fi domainien esittämiseen.

 

[JCSH]

Mutta edelleenkin tuo unicode-versio voisi näyttää hexdumppina aika monenlaiselta riippuen siitä, miten nuo ääkköskirjaimet on koostettu. Mistä palvelin voi tietää, mitä haetaan? 8-bittisten koodisivumerkistöjen kanssa ei ole tuollaista ongelmaa, koska kullekin kirjaimelle on vain yksi esitystapa.

Nyt ne urlit käyttävät 8-bittisiä merkistöjä, mutta serverillä on silti tasan tarkkaan sama ongelma. Johtuen siitä, että kerta 8-bittiä ei riitä urleissa nykyaikana, joudutaan käyttämään Punycodea ja url encodingia workaroundeina . Eli serveri saa sen 8-bittisen urlin, mutta se serveri joutuu tekemään ekana sen ASCII -> UTF-8 konversion ja sitten arpomaan, että mitä haetaan.
Helpompaa olisi, että urlit olisivat suoraan UTF-8:ia. Koska sitten ei olisi tuota turhaa UTF-8 -> ASCII -> UTF-8 konversiota välillä, joka vain monimutkaistaa asioita.

 

[Sompi]

Nyt ne urlit käyttävät 8-bittisiä merkistöjä, mutta serverillä on silti tasan tarkkaan sama ongelma. Johtuen siitä, että kerta 8-bittiä ei riitä urleissa nykyaikana, joudutaan käyttämään Punycodea ja url encodingia workaroundeina . Eli serveri saa sen 8-bittisen urlin, mutta se serveri joutuu tekemään ekana sen ASCII -> UTF-8 konversion ja sitten arpomaan, että mitä haetaan.
Helpompaa olisi, että urlit olisivat suoraan UTF-8:ia. Koska sitten ei olisi tuota turhaa UTF-8 -> ASCII -> UTF-8 konversiota välillä, joka vain monimutkaistaa asioita.

Mutta nämä kaikki ongelmathan johtuvat nimenomaan unicodesta. Sen lisäksi, että unicoden takia on nyt olemassa useampi mahdollinen tapa koodata merkittävä osa kirjainmerkeistä eikä merkkijonojen eksakti vertailu ole sen takia enää mahdollista, niin nyt joudutaan vielä tekemään muunnoksia unicoden ja 8-bittisten merkistöjen välillä edestakaisin. Ei noin matalan tason asiaa saada kuitenkaan toimimaan unicodella ikinä kunnolla, koska merkkijonojen vertailun on oltava eksaktia.

Ongelmia tulee jo ihan siitäkin, että Mozillan devaajat halusivat muuttaa Firefoxin osoiterivin merkistön unicodeksi vieläpä niin, ettei se edes konvertoi niitä merkkejä ISO-8859-1-muotoon kuten sen speksin mukaan kai "kuuluisi" tehdä, vaan escapettaa kaikki numeroarvoltaan yli 127:n olevat kirjainmerkit, sellaisetkin jotka eivät ennen olleet unicodea. Kun ennen unicode-siirtymää kirjoitti osoiteriville domainin jälkeen vaikka "ä.txt", niin se tarkoitti hexdumppina tavujonoa 0xE4 0x2E 0x7E 0x78 0x7E. Nyt kun osoite on unicodea, niin "ä.txt" muuntuukin GET-pyyntöä tehdessä muotoon "%C3%A4.txt", jonka palvelin tietysti tulkitsee prosenttiescapet purettuaan tarkoittavan 0xC3 0xA4 0x2E 0x7E 0x78 0x7E, mikä ei ole sama asia kuin aiempi muoto, eikä palvelin välttämättä löydä tiedostoa, jonka se aikaisemmin löysi.

Sen lisäksi tuo unicode-versio "ä.txt":stä voitaisiin escapettaa myös muotoon "a%CC%88.txt", jonka palvelin prosenttiescapet purettuaan tulkitsisi tarkoittavan tavujonoa 0x61 0xCC 0x88 0x2E 0x7E 0x78 0x7E. Muitakin mahdollisia esitystapoja lienee unicodella olemassa.

Unicoden varsinainen ongelma näissä asioissa on nimenomaan se, että merkkijonon muunnos koneen näkemästä muodosta ihmisen näkemään muotoon toimii kyllä aina "samalla tavalla", mutta muunnos toiseen muotoon voi sitten palauttaa monta erilaista muotoa, jotka ovat erilaisia eli kone ei niitä tunnista samoiksi. Sen lisäksi sitten tulee vielä nuo lukuisat ongelmat merkistömuunnoksista, joita on tehtävä unicoden ja yksinkertaisempien merkistöjen välillä.

 

[JCSH]

Mutta nämä kaikki ongelmathan johtuvat nimenomaan unicodesta. Sen lisäksi, että unicoden takia on nyt olemassa useampi mahdollinen tapa koodata merkittävä osa kirjainmerkeistä eikä merkkijonojen eksakti vertailu ole sen takia enää mahdollista, niin nyt joudutaan vielä tekemään muunnoksia unicoden ja 8-bittisten merkistöjen välillä edestakaisin. Ei noin matalan tason asiaa saada kuitenkaan toimimaan unicodella ikinä kunnolla, koska merkkijonojen vertailun on oltava eksaktia.

Ei vaan ne ongelmat johtuvat siitä, että 8-bittiset merkistöt eivät riitä nykyaikaisessa käytössä. Joten tarvitaan jotain muuta ja se jotain muu on nyt Unicode.
Toistat, että noin matalan tason asiaa ei saada kuitenkaan toimimaan unicodella ikinä kunnolla, niin ok, ehkä ei saada.
Mutta noin matalan tason asiaa ei myöskään saada ikinä toimimaan kunnolla 8-bittisillä merkistöillä, koska ne eivät ole riittäviä. Joten sitten pitää kikkailla se Unicode sinne mukaan.

 

[pulatunnus]

Mutta nämä kaikki ongelmathan johtuvat nimenomaan unicodesta. Sen lisäksi, että unicoden takia on nyt olemassa useampi mahdollinen tapa koodata merkittävä osa kirjainmerkeistä eikä merkkijonojen eksakti vertailu ole sen takia enää mahdollista, niin nyt joudutaan vielä tekemään muunnoksia unicoden ja 8-bittisten merkistöjen välillä edestakaisin. Ei noin matalan tason asiaa saada kuitenkaan toimimaan unicodella ikinä kunnolla, koska merkkijonojen vertailun on oltava eksaktia.

Vai johtuisiko ongelmat kuitenkin ASCII, ja sen päälle viritellyistä systeemeistä.

Ja jos vedät niitä HEX dumppeja, niin ne riippuu ihan siitä mitä merkistö käyttät. Jos ja kun 8 bittisellä merkistöllä on kuljetettava se tieto mitä merkistö käytetään, niin joka tapauksessa sen joutuu parsiin. Ja jos kaikkia merkkejä ei voi yhdellä 8 bittisellä merkistöllä esittää, niin tarvitaan osaan merkkejä useampi tavu, tai sitten kuljettaa kesken merkkijonon tieto millä merkistöllä seuraava merkki kerrottu.

Jos koodaat palvelimen jotka vastaa HTTP pyyntöihin, niin jo se fi domainin merkistö ei onnistu 8bit Latin-1 merkistöllä, saati ASCIIlla. Eli joudut ne merkit parsiin useammasta tavusta kasaan. Jos pyydetään jotain tiedosta tiedostojärjestelmästä niin joudut sen sitten parsiin, jos vedät unicodella mahdollisimman paljon niin vähemmän sähläämistä.

 

[Sompi]

Ja jos vedät niitä HEX dumppeja, niin ne riippuu ihan siitä mitä merkistö käyttät. Jos ja kun 8 bittisellä merkistöllä on kuljetettava se tieto mitä merkistö käytetään, niin joka tapauksessa sen joutuu parsiin. Ja jos kaikkia merkkejä ei voi yhdellä 8 bittisellä merkistöllä esittää, niin tarvitaan osaan merkkejä useampi tavu, tai sitten kuljettaa kesken merkkijonon tieto millä merkistöllä seuraava merkki kerrottu.

Tasalevyisillä 8-bittisillä merkistöillä osa merkeistä vain näyttää käyttäjälle erilaisilta, mutta tietokoneen näkökulmasta niillä on kuitenkin samat numeroarvot (hexdump näyttää siis samalta merkistöstä riippumatta) eli merkkijonojen vertailu on eksaktia eikä mitään mene rikki. Muunnoksissa tasalevyisten 8-bittisten merkistöjen välillä ei siis häviä informaatiota, toisin kuin unicoden kanssa helposti käy ihan merkkijonoa koneen ymmärtämästä muodosta ihmisen ymmärtämään muotoon muuntaessa ilman merkistömuunnoksiakin.

8-bittisten merkistöjen kanssa käyttäjä saattaa joutua jotain tiedostonimeä kirjoittaessaan korvaamaan ääkköset joillain erikoismerkeillä, esim. { ja | tai “ ja „, mikä ei yleensä ole ongelma paikallisten tiedostojen kanssa, koska käyttäjä tiedostolistauksen nähdessään kuitenkin näkee minkä merkin tietokone haluaa. Web-osoitteissa tuosta taas saadaan helposti aika merkittävä ja käytön estävä ongelma, jonka takia osoitteissa olisikin hyvä olla vain kirjaimia, jotka kaikki käyttäjät voivat kirjoittaa helposti näppäimistöllään - ei siis unicode-merkkejä eikä edes niitä ISO-8859-1-merkistön numeroarvoltaan yli 127:n olevia merkkejä, vaan pelkkää 7-bittistä ASCIIta.

 

[pulatunnus]

Tasalevyisillä 8-bittisillä merkistöillä osa merkeistä vain näyttää käyttäjälle erilaisilta, mutta tietokoneen näkökulmasta niillä on kuitenkin samat numeroarvot, eli merkkijonojen vertailu on eksaktia eikä mitään mene rikki.

Jos tarkastelet yhtä merkkiä kuvaavaa tavua, niin 8 bittisellä merkistöllä sen kuvaama merkki riippuu ihan siitä mikä merkistö käytössä, ja jos sen merkin esittämiseen tarvitaan kaksi tavua, niin no....

Web-osoitteissa tuosta taas saadaan helposti aika merkittävä ja käytön estävä ongelma, jonka takia osoitteissa olisikin hyvä olla vain kirjaimia, jotka kaikki käyttäjät voivat kirjoittaa helposti näppäimistöllään - ei siis unicode-merkkejä eikä edes niitä ISO-8859-1-merkistön numeroarvoltaan yli 127:n olevia merkkejä, vaan pelkkää 7-bittistä ASCIIta.

Vai olisko parempi tavoitella sitä että ihmisille, käytäjällä esitetään asiat luettavasti, ja koska alettu pääsemaan eroon ASCII rajoittaiesta, niin yritään nyt ihan oikeasti niistä eroon ja jos ei vielä, niin tästä eteenpäin toimitaan niin että ainakin suunitellaan niin että ei tarvi kaikkea kirjoittaa uudestaan kun otetaan käyttöön laajempaa merkistöä.

Domaineissa ei olla enään aikoihin rajoitettu ASCII merkkeihin, tiedostonimissä ei enään aikoihinrajoitettu niihin. saati tekstissä jne.

Domainit, nimiaplvelut, ovat luotu ihmisiävarten, jotta ne olisi ihmisen luettavissa, muistetavissa. joten niissä ihan järkevää käyttää merkkejä joita ihmiset käyttää. Sama toki tiedostonimissä.

Koodarille paljon helpompaa käyttää merkistö joilla sujuu kaikki, ilman että täytyy eri domainein tai tiedostonimen kohdalla vaihtaa merkistö, saati että kesken domainnen , tiedosto nimen merkkijonon vaihtaa merkistöä.

Muunnoksissa tasalevyisten 8-bittisten merkistöjen välillä ei siis häviä informaatiota, toisin kuin unicoden kanssa helposti käy ihan merkkijonoa koneen ymmärtämästä muodosta ihmisen ymmärtämään muotoon muuntaessa ilman merkistömuunnoksiakin.

Jos et edes pysty esittämään kaikkia merkkejä 8 bittisellä merkistöllä, niin miten ajattelit säilyttää informaation 8 bittisillä merkistömuunnoksilla. Olen toistannut fi domainit, millä 8 bittisellä merkistöllä ajattelit ne esittää ja jos ajattelit säilyttää sisällön muunnoksissa, niin ilmeisesti mielessä useitakin merkistöjä joilla se sujuu. jos siis ajatuksesi nimenomaan 8 bitti per merkki. Ehdotit aiemmin sitä ISO-8859-1/Latin-1 merkistö, niin eikö se hukkaa jo sen informaation.

Unicode muunnoksilla on moninkertainen potenttiaali säilyttää sisältö muuttumattomana, en nyt edes tiedä mitä merkkejä olet sillä hukkaamassa, ja vielä sellaista että se 8 bittisellä säilyisi turvassa.

 

[JCSH]

Tasalevyisillä 8-bittisillä merkistöillä osa merkeistä vain näyttää käyttäjälle erilaisilta, mutta tietokoneen näkökulmasta niillä on kuitenkin samat numeroarvot (hexdump näyttää siis samalta merkistöstä riippumatta) eli merkkijonojen vertailu on eksaktia eikä mitään mene rikki. Muunnoksissa tasalevyisten 8-bittisten merkistöjen välillä ei siis häviä informaatiota, toisin kuin unicoden kanssa helposti käy ihan merkkijonoa koneen ymmärtämästä muodosta ihmisen ymmärtämään muotoon muuntaessa ilman merkistömuunnoksiakin.

8-bittisten merkistöjen kanssa käyttäjä saattaa joutua jotain tiedostonimeä kirjoittaessaan korvaamaan ääkköset joillain erikoismerkeillä, esim. { ja | tai “ ja „, mikä ei yleensä ole ongelma paikallisten tiedostojen kanssa, koska käyttäjä tiedostolistauksen nähdessään kuitenkin näkee minkä merkin tietokone haluaa. Web-osoitteissa tuosta taas saadaan helposti aika merkittävä ja käytön estävä ongelma, jonka takia osoitteissa olisikin hyvä olla vain kirjaimia, jotka kaikki käyttäjät voivat kirjoittaa helposti näppäimistöllään - ei siis unicode-merkkejä eikä edes niitä ISO-8859-1-merkistön numeroarvoltaan yli 127:n olevia merkkejä, vaan pelkkää 7-bittistä ASCIIta.

Mutta kun niitä softia tehdään ihmisiä varten, ei koneita varten. Sä voit hehkuttaa niin paljon sen 8-bittisen merkistön kätevyyttä kuin sua huvittaa, mutta se ei poista sitä faktaa, että 8-bittiset merkistöt eivät ole enää mitenkään riittäviä nykypäivän käyttöön.
2/3 maailman ihmisistä käyttää äidinkielenään kieliä, jotka käyttävät jotain muita aakkosia kuin mitä voidaan esittää ASCII:lla. Eli ASCII ei yksinkertaisesti ole millään tasolla enää riittävä mihinkään ihmisten luettavaksi tarkoitettuun tekstiin.

 

[love_doctor]

Muunnoksissa tasalevyisten 8-bittisten merkistöjen välillä ei siis häviä informaatiota, toisin kuin unicoden kanssa helposti käy ihan merkkijonoa koneen ymmärtämästä muodosta ihmisen ymmärtämään muotoon muuntaessa ilman merkistömuunnoksiakin.

Tämä on ihan höpöä. Eri koodisivuilla on aidosti eri merkkejä. Esim. iso-8859-15:ssä on paikassa 0xA4 euromerkki. Totta vitussa se informaatio häviää jos siirrät 80-luvun merkistöihin, kun niissä ei ole mitään euromerkkejä. Latin1:ssä on tilalla geneerinen rahayksikkömerkki ¤. Noissa legacy-merkistöissä on yleensä valuuttamerkkeinä vain punta, dollari, sentti, jeni ja/tai geneerinen valuuttamerkki. Iso-8859-14:ssä ei ole edes jeniä. Ihan jo näiden kolmen merkistön välillä kun vaihtelee, joudutaan kaksi tiedossa olevaa valuuttaa konvertoimaan geneeriseksi, missä menetetään tieto valuutasta.

 

[Sompi]

Tämä on ihan höpöä. Eri koodisivuilla on aidosti eri merkkejä. Esim. iso-8859-15:ssä on paikassa 0xA4 euromerkki. Totta vitussa se informaatio häviää jos siirrät 80-luvun merkistöihin, kun niissä ei ole mitään euromerkkejä. Latin1:ssä on tilalla geneerinen rahayksikkömerkki ¤. Noissa legacy-merkistöissä on yleensä valuuttamerkkeinä vain punta, dollari, sentti, jeni ja/tai geneerinen valuuttamerkki. Iso-8859-14:ssä ei ole edes jeniä. Ihan jo näiden kolmen merkistön välillä kun vaihtelee, joudutaan kaksi tiedossa olevaa valuuttaa konvertoimaan geneeriseksi, missä menetetään tieto valuutasta.

Pointti oli, että jos teet muunnoksen kahden 8-bittisen tasalevyisen merkistön välillä, niin informaatiota ei häviä, ja takaisin muuntaessa data muuttuu samanlaiseksi kuin ennen muuntamista. Unicodessa taas se merkkijonon muuntaminen tietokoneen ymmärtämästä muodosta ihmisen luettavaan muotoon on häviöllinen prosessi, ja takaisin muuntaessa ei välttämättä saada samanlaista tavujonoa kuin se alkuperäinen.

 

[love_doctor]

Pointti oli, että jos teet muunnoksen kahden 8-bittisen tasalevyisen merkistön välillä, niin informaatiota ei häviä, ja takaisin muuntaessa data muuttuu samanlaiseksi kuin ennen muuntamista. Unicodessa taas se merkkijonon muuntaminen tietokoneen ymmärtämästä muodosta ihmisen luettavaan muotoon on häviöllinen prosessi, ja takaisin muuntaessa ei välttämättä saada samanlaista tavujonoa kuin se alkuperäinen.

Puhut nyt jostain muunnoksesta, jossa ei yritetä tulkita mikä merkki on vaan siirretään merkin bittiesitys kontekstista toiseen eli tavallaan ei tehdä mitään. Tämä ei ole minkäänlainen muunnos. Et voi yleisesti mitenkään tehdä häviötöntä muunnosta 256 merkistä 256 merkkiin jos ne lähde- ja kohdemerkistön merkit eroavat yhdenkään merkin osalta. Ainut tilanne missä muunnos on häviötön on silloin kun muunnettavassa merkkijonossa ei esiinny sellaisia merkkejä, joita kohdemerkistössä ei ole. Eli esim. jos muunnetaan ASCII:ta, joka on yhteinen alijoukko monessa noista.

Kerropa vaikka ihan konkreettisesti, miten muunnat häviöttömästi jenin ja euromerkin kahden eri legacy-merkistön välillä. Toinen merkistö saa olla latin9 tai win-1252, mutta toinen jokin sellainen, josta puuttuu jompi kumpi. Listaa vaikka näin:

Lähtötilanne (merkistö 1): euro = <syötä heksakoodi>, jeni = <syötä heksakoodi>
Muunnoksen jälkeen (merkistö 2): euro = <syötä heksakoodi>, jeni = <syötä heksakoodi>
Muunnoksen jälkeen (takaisin merkistöön 1): euro = <syötä heksakoodi>, jeni = <syötä heksakoodi>

Kerro myös merkistöt: merkistö 1 = <merkistön tunnus>, merkistö 2 = <merkistön tunnus>

Ja kerro algoritmi, jolla voin muuntaa noiden välillä ilman tarvetta ihmisen tulkinnalle.

Laitan oman esimerkin tähän:

$ echo jeni ¥, euro € > testi1
$ iconv -f utf8 -t latin9 testi1 > testi2
$ iconv -f latin9 -t utf8 testi2 > testi3
$ cat testi3
jeni ¥, euro €

Häviöttömän muunnoksen perusominaisuus on tietysti datan pysyminen identtisenä:

$ md5sum testi1 testi3
68d7e420fe0a49250ab59f620a2cd03d  testi1
68d7e420fe0a49250ab59f620a2cd03d  testi3

 

[JCSH]

Puhut nyt jostain muunnoksesta, jossa ei yritetä tulkita mikä merkki on vaan siirretään merkin bittiesitys kontekstista toiseen eli tavallaan ei tehdä mitään. Tämä ei ole minkäänlainen muunnos. Et voi yleisesti mitenkään tehdä häviötöntä muunnosta 256 merkistä 256 merkkiin jos ne lähde- ja kohdemerkistön merkit eroavat yhdenkään merkin osalta. Ainut tilanne missä muunnos on häviötön on silloin kun muunnettavassa merkkijonossa ei esiinny sellaisia merkkejä, joita kohdemerkistössä ei ole. Eli esim. jos muunnetaan ASCII:ta, joka on yhteinen alijoukko monessa noista.

Joo, näyttää kyllä vahvasti siltä, että @Sompi :n ajatus muunnoksesta merkistöjen välillä on:
1. Otetaan tiedosto, jossa on Latin-9 teksti "Tämä maksoi 30€"
2. Avataan tuo tiedosto tekstieditorissa read-onlynä käyttäen Latin-9:iä ja todetaan, että siinä lukee "Tämä maksoi 30€"
3. Avataan sama tiedosto uudestaan read-onlynä käyttäen Latin-1:tä, ja todetaan, että siinä lukee "Tämä maksoi 30¤"
4. Avataan tiedosto uudestaan read-onlynä käyttäen Latin-9:iä ja todetaan, että kerta siinä vielä lukee "Tämä maksoi 30€", niin mitään tietoa ei ole menetetty "muunnoksissa". Toki unohtaen sen, että kohdassa 3. ei tiedetä, että mistä valuutasta on kyse, mutta kuka nyt semantiikasta välittää.

 

[JCSH]

Mutta mitä jos tehdään oikeasti muunnoksia niiden merkistöjen välillä, eli yritetään säilyttää se merkkien semanttinen tarkoitus. Sen sijaan että vain sokeasti kopioidaan tavuja.

Lause on sama "Tämä maksoi 30€"
Otetaan kolme merkistöä, niinkin eksoottiset kuin Latin-1, Latin-9 ja Windows-1252.
Muunnokset tehdään yksinkertaisilla periaatteilla:
1. Jos sama merkki löytyy toisesta merkistöstä, niin käytä kohteen arvoa kyseiselle merkille.
2. Jos samaa merkkiä ei löydy, käytä alkuperäistä arvoa.

Lähdetään liikkeelle Windows-1252:stä ja tarkastellaan vain €-merkkiä.
Windows-1252:ssä € merkin arvo on 0x80
Tehdään konversio Latin-9:iin. Sieltä löytyy €-merkki kohdasta 0xA4.
Tehdään konversio Latin-1:een, sieltä ei löydy €-merkkiä, joten pidetään arvo 0xA4.
Sitten takaisin Windows-1252:een. Latin-1:n merkki 0xA4 on ¤. Sama merkki löytyy Windows-1252:stä samasta kohtaa.

Eli kun tehdään muutos
Windows-1252 -> Latin-9 -> Latin-1 -> Windows-1252 niin teksti "Tämä maksoi 30€" muuttuu tekstiksi "Tämä maksoi 30¤" vaikka alku- ja loppupiste ovat samat ja kaikki välissä olevat merkistöt ovat 8-bittisiä ja kiinteämittaisia. Ihan eksaktia ja informaatiota ei häviä, vai mitä @Sompi ?

*edit*
Mutta ei siinä vielä kaikki. Otetaan mukaan toinen 8-bittinen merkistö itärajan takaa. KOI8-RU.
Eli jäätiin Windows-1252:ssä tekstiin "Tämä maksoi 30¤".
Onneksi KOI8-RU:sta löytyy ¤. Tosin se löytyy uudesta paikkaa, 0x9F.
Hypätäänpäs siitä sitten takas kaveriin Latin-9. ¤:iä sieltä ei löytynyt, paikasta 0x9F löytyykin yksi tarke, pituusmerkki.
Eli teksti on "Tämä maksoi 30◌̄"
Sitten otetaankin Mikkisoftan poikien mielipide siitä, että miten venäjää pitäisi kirjoittaa ja pompataan Windows-1251:een.
Pysytään kohdassa 0x9F, kerta pituusmerkkiä ei löydy kyseisestä merkistöstä. Eli kirjain onkin џ. Mutta ei me haluta tuollaisia Mikkisoftan merkistöjä käyttää, vaihdetaan ISO-standardiin.
Eli ISO/IEC 8859-5. Sieltä tietenkin löytyy џ, mutta nyt kohdasta 0xFF.
Jos nyt hypätään takaisin siihen lähtöpisteeseen, eli Windows-1252, niin lause on "Tämä maksoi 30ÿ"
Mutta jos mennäänkin KOI8-RU, niin sieltä ei löyty џ (vissiin ei tarvita venäjän kielessä), joten tuolta paikalta löytyy Ъ.
Sitten hypätään takaisin Windows-1251, niin sieltähän kyseinen merkki löytyy kohdasta 0xDA.
Eli jos nyt palataan sinne alkuperäiseen 1252:iin, niin saadaan "Tämä maksoi 30Ú"

*edit2*
ä myös lähtee vähän tangentille aina välillä.
ä on 0xE4. Kun lähdetään tuolle kyrilliselle detourille, niin Windows-1251:ssä 0xE4 on г. Mutta ISO/IEC 8859-5:ssä se on 0xD4.
Eli jos tuossa pompataan takas Windows-1252:een, niin lause onkin "TÔmÔ maksoi 30ÿ".
Jos mennään KOI8-RU:n kautta, niin se löytyy kohdasta 0xC7, eli jos tuossa vaiheessa hypätään takas "länsimaisiin" merkistöihin, niin "Tämä" onkin "TÇmÇ"

 

[Sompi]

Kyse oli muunnoksesta tietokoneen ymmärtämän muodon ja ihmisen ymmärtämän muodon välillä. Unicodessa se muunnos tietokoneen ymmärtämästä muodosta ihmisen ymmärtämään muotoon on häviöllinen, ja se aiheuttaa ongelmia merkkijonovertailuissa, koska niitä ei pysty tekemään täysin eksaktisti.

Myös tasalevyisten 8-bittisten merkistöjen välillä muuntaminen on kyllä häviötöntä, paitsi tietysti jos muunnostaulukot on tehty niin, että siinä häviää informaatiota.

 

[JCSH]

Kyse oli muunnoksesta tietokoneen ymmärtämän muodon ja ihmisen ymmärtämän muodon välillä. Unicodessa se muunnos tietokoneen ymmärtämästä muodosta ihmisen ymmärtämään muotoon on häviöllinen, ja se aiheuttaa ongelmia merkkijonovertailuissa, koska niitä ei pysty tekemään täysin eksaktisti.

Sä sanoit:

Pointti oli, että jos teet muunnoksen kahden 8-bittisen tasalevyisen merkistön välillä, niin informaatiota ei häviä, ja takaisin muuntaessa data muuttuu samanlaiseksi kuin ennen muuntamista. Unicodessa taas se merkkijonon muuntaminen tietokoneen ymmärtämästä muodosta ihmisen luettavaan muotoon on häviöllinen prosessi, ja takaisin muuntaessa ei välttämättä saada samanlaista tavujonoa kuin se alkuperäinen.

Mutta joo, kaiva vaan syvempää kuoppaa

 

[JCSH]

Myös tasalevyisten 8-bittisten merkistöjen välillä muuntaminen on kyllä häviötöntä, paitsi tietysti jos muunnostaulukot on tehty niin, että siinä häviää informaatiota.

Ei vaan niiden välillä muuntaminen on häviötöntä vain ja ainoastaan, jos ne merkistöt sisältävät kaikki samat merkit. Jos eivät, niin sitten et sä pysty tekemään mitään sellaista muunnostaulukkoa, jolla informaatiota ei häviä.

 

[pulatunnus]

Laitan oman esimerkin tähän:

$ echo jeni ¥, euro € > testi1
$ iconv -f utf8 -t latin9 testi1 > testi2
$ iconv -f latin9 -t utf8 testi2 > testi3
$ cat testi3
jeni ¥, euro €

Häviöttömän muunnoksen perusominaisuus on tietysti datan pysyminen identtisenä:

$ md5sum testi1 testi3
68d7e420fe0a49250ab59f620a2cd03d  testi1
68d7e420fe0a49250ab59f620a2cd03d  testi3

Aiemmin oli puhetta lähdekoodeista, niin tuo esimerkki sopii siihenkin, jos lähdekoodit esitettäisiin ASCIIna, niin ei noitakaan esimerkkejä niin helpolla ihminen lukisi.