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.

 

[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.

 

[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.

 

[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ää.

 

[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.

 

[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ä.

 

[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.

 

[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ä.

 

[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.

 

[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.

 

[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ä.

 

[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.

 

[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Ç"

 

[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.

 

[love_doctor]

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.

Jos nyt oikein tulkitsen, tarkoitat vaikkapa tuota että kirjain ä voidaan koodata kahdella eri tavalla. Tässä tapauksessa Unicode ei hävitä mitään informaatiota. Ongelma tuossa on että Unicodea käytetään kontekstissa, jossa monitulkintaisuus on haitaksi. Monitulkintaisuus seuraa siitä, miten merkit renderöidään. Unicode-kirjastoissa on kyllä rutiineja vertaamaan noita eri muotoja keskenään. Unicoden code pointeissa on erittäin tarkasti ja yksikäsitteisesti kuvattu ko. merkki. 8-bittisissäkin merkistöissä on merkkejä, jotka renderöidään samalla tavalla. Monessa merkistössä merkit 0, 32 ja 255 renderöidään tyhjänä. Esim. minä piilotin ala-asteella koulun koneelle piraatti-doomin piilohakemistoon, jonka nimi oli merkki 255 c-aseman juuressa. Koulun atk-opettajalla ei riittänyt kompetenssi löytää ja poistaa peliä koneelta. Tuokin oli täysin hyödytön merkki DOS-aikaan kun monet editorit myös tulostivat sen ihan kuten välimerkin 32. Vasta Unicoden ja kehittyneiden latomisohjelmien myötä itsekin tajusin, mistä on kyse, jos merkki on nbsp

 

[huglo]

Juuh, vaikka modernissa tietotekniikassa on paljon paskaa niin Unicode/UTF-8 ei kyllä sitä ole. Hyi helkkari kun joskus ennen esim IRCissä ( ) joutui etsimään että mikäs merkistökoodaus tässä nyt pitää valita että ÄÖÅ näkyy oikein. Tai sama txt tiedostojen kanssa. Koodisivut =

Ohjelmoinnissa ymmärrän juuh että joillain erikoismerkeillä voi saada jänniä aikaiseksi mutta ehkä editorien ja kääntäjien olisi hyvä tunnistaa tällaiset kikkailut?

Ja sitten jos UTF8:n muuttuva tavua/merkki ei kelpaa niin onhan meillä UTF-32

 

[pulatunnus]

Digitalisaatio ketjusta

Usein ihmettelen, miten hankalaa työkseen ohjelmakoodia vääntäville voi olla toteuttaa toimiva hakutoiminto. Eihän siinä tarvitse muuta kuin vain toteuttaa yksinkertainen merkkijonohaku, johon on useimmissa ohjelmointikielissä valmiit funktiot olemassa. Ehkä sitä ennen eliminoi vertailtavista merkkijonoista isot kirjaimet ja diakriittiset merkit. Siihenkin on yleensä olemassa valmiit funktiot ilman, että tarvitsee edes mitään frameworkkia. Nykyaikana hyvin harvoin esimerkiksi missään verkkokaupassa kohtaa oikeasti toimivaa hakutoimintoa. Jopa Google on nykyään aivan uskomattoman huono ja palauttaa yleensä täysin epärelevantteja hakutuloksia, jotka eivät edes liity hakusanoihin mitenkään.

Jos ja kun ei haeta joka tarkkaa merkkijonoa, vaan jotain muuta, asioita, niin ei se ihan helppoakaan ole. ja oleellinen asia myös esittää se hakutulos.

Tyypillinen vaikea paikka on ns verkkokaupat, ja mitä enemmän nimikkeitä niin sitä vaikeampaa. Tilannetat ei helpota se että jos kaupalla paljon tavarantoimittajia, päämiehiä , niin niiltä ei saa hakemiseen liittyen hyvää dataa, tai edes kohtuullista. Tilannetta ei helpota että monissa tuoteryhmissä nimikkeiden elinkaari on lyhyt, termit kirjavia jne.

Vielä vaikeampaa on jossain avoimessa verkkokauppa paikassa/alustassa missä markkinoi useat toimijat, tai jopa yksityiset. jolloin vielä epämääräisemät tiedot tuotteesta.

Digitalisaatio, AI kehittyminen vienyt toki hakua "alaa" hurjasti eteenpäin, kehittyneet ja osaavat tekijät eivät tarkoita että hakutulosten esittäminen olis pelkästään asiakaslähtöistä, vaan ihan muut motiivit.

Merkistöön siirsin sen takia että lähdit toteutustapohtiin merkkien haulla, merkkijonojen haulla.

Haluttujen hakutulosten löytämiseksi ja niiden esittämiseksi on merkitystä isoilla kirjaimilla, mitä merkkijonon ympärillä, ja varsinkin jos ei ole unicodemerkistöä niin myös miettiä ne vaihtoehdot miten jokin tietty merkki on haettavaan tietokantaan/tidostoon tallenettu, ja noin yleisemmin millä eri tavoin sitä eri sisällön luojat ovat kirjoittaneet.

Lisäksi ne merkkijonon ympärillä olevat merkit. Tämä siis johdattelu siihen että jos käytettävässä ympäristössä ei ole kehittyneitä hakuominaisuuksia niin siinä jää kovasti tehtävää koodarille. pelkästään löytää ne halutut esiintymät, jonka jälkeen sitten pitäisi valita mitä esittää ja miten.

Toimii. Merkistö ei vaikuta tavujonojen vertailuihin sinänsä mitään, vaan ongelmana on vain lähinnä se, että UTF-8:ssa merkkijonon muunnos tietokoneen ymmärtämästä muodosta ihmisen ymmärtämään muotoon on häviöllinen prosessi. Jos kuitenkin diakriittiset merkit on joka tapauksessa tarkoitus eliminoida, niin asialla ei suomen kielen aakkoston kanssa ole merkitystä.

Diakriittisten merkkien eliminointi nimenomaan UTF-8:ssa on varsin simppeliä. Diakriittiset merkit tulevat kokonaan omana kirjainmerkkinä varsinaisen perusmerkin jälkeen ja ne voi vain yksinkertaisesti jättää kokonaan huomiotta. On olemassa erikoistapauksia, joissa diakriittinen merkki on kiinteänä osana itse peruskirjainta, mutta niistä on kyllä varmasti olemassa valmiita muunnostaulukoita, joilla sen saa muunnettua perusmerkkiä vastaavaksi ASCII-merkiksi.

Varsinkaan suomalaisen aakkoston kanssa ei pitäisi oikeasti tulla mitään ylitsepääsemättömiä ongelmia jotain merkkijonohakua tehdessä.

Jos mennään UTFllä niin ääkköset varmaan löytyy, ASCIIlla ei edes ole.

Jos haetaan ihmisen tuottamasta vapaasta sisällöstä, niin lähtökohta on että siellä on erilaisia tapoja ilmaista sama asia, ja sitten kirjoitus ja termivirheitä.

 

[takomo]

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.

Ongelmien juurisyy on merkistön muuttuvassa pituudessa, mikä johtaa vaikeaan implementointiin. Toteutuksen oikeellisuutta kaikissa tilanteissa on vaikeaa ellei mahdotonta todentaa. Jos tietojenkäsittelylle asetetaan luotettavuusvaatimuksia, niin merkkijonojen käsittely ei yleensä saisi bugittaa.

Toiseksi, algoritmeista tulee tehottomia, kun aina pitää varautua ties mihin. Toisaalta 'mutkat-suoriksi'-koodikin toimii usemmiten ja kosahtaa vain harvoin.

8-bittisestä koodauksesta kuten Latin-x ei pitäisi luopua, jos se ei ole aivan välttämätöntä. Jos aidosti tarvitaan globaalia merkistötukea, niin tätä varten pitäisi luoda 16-bittinen - edelleen kiinteälevyinen - merkistö. Se riittäisi varsin pitkälle: Basic Multilingual Plane (BMP)
Tuollakin olisi luudalle käyttöä: kuolleita kieliä ja käytöstä poistuneita merkkejä ei ole tarpeen raahata mukana.

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ä.

Foorumisoftat on sangen pieni osuus käytössä olevista koodeista.

Vieraita merkistöjä varten on käytössä semmoinen erikoistekniikka kuin translitterointi. Sillä vierasperäiset sanat voidaan esittää ymmärrettävästi meidän niin ahdistavan suppealla merkistöllä. Kumpi on ymmärrettävämpää 福岡市 vai Fukuoka? ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ vai Ulaanbaatar?
Nämäkin 福岡市 ja ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ pitäisi kirjoittaa pystyyn mutta eihän tämä ... kulttuuri-imperialistinen foorumisofta siihen taivu.

8-bittinen merkistö ISO-8859-15 on taasen niin suppea että rajoittaa ilmaisua

Istuhan alas ja ota rauhallinen asento...
Kerropa nyt ihan omin sanoin suomeksi siitä tyhjyyden ja riittämättömyyden tunteesta, jonka ISO-8859-15-merkistö sinussa aiheuttaa.

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.

Sinun kupla ei taida olla koko maailma. Jos tehdään suomalaisille ohjelmistoa suomeksi tai länsieurooppalaisille länsieurooppalaisilla kielillä, niin mihin *olennaiseen* Latin9 ei muka veny?
Mihin vaikkapa verottajan tietojärjestelmissä tarvitaan muuta kuin 8-bittistä merkistöä?

Sitten meillä on erinäiset legacy-ohjelmistot, joilla voi olla vuosikymmenten historia takanaan. Niitä koodatessa ei useinkaan ole ajateltu muuta kuin 8-bittisiä merkistöjä. Muu kuin 8-bittisesti koodattu data voi rikkoa luotettavina pidetyt koodit.

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.

Päinvastoin: länsieurooppalaisilla kielillä tapahtuvaan tietojenkäsittelyyn laajemmat merkistöt ei tuo muuta kuin ongelmia ja harmaita hiuksia. Uusilla merkistöillä ratkaistaan asioita, jotka ei ole ongelmia ja aiheutetaan uusia ongelmia toisaalle.

 

[JCSH]

Sinun kupla ei taida olla koko maailma. Jos tehdään suomalaisille ohjelmistoa suomeksi tai länsieurooppalaisille länsieurooppalaisilla kielillä, niin mihin *olennaiseen* Latin9 ei muka veny?
Mihin vaikkapa verottajan tietojärjestelmissä tarvitaan muuta kuin 8-bittistä merkistöä?

Päinvastoin: länsieurooppalaisilla kielillä tapahtuvaan tietojenkäsittelyyn laajemmat merkistöt ei tuo muuta kuin ongelmia ja harmaita hiuksia. Uusilla merkistöillä ratkaistaan asioita, jotka ei ole ongelmia ja aiheutetaan uusia ongelmia toisaalle.

Sitä softaa ei tehdä enää vain länsimaalaisille, vaan sitä softaa tehdään kaikille. Vaikka jonkun Suomen verottajan softan voisikin tehdä vain 8-bittisillä merkistöillä, niin ei ole mitään järkeä lähteä tekemään sitä vain 8-bittisellä merkistöllä, koska kuitenkin kaikki ne softakomponentit, joista sitä verottajan softaa lähdetään tekemään, kuitenkin tukevat UTF-8:ia ja myös defaulttaavat siihen.
Puhumattakaan siitä, että jos tulee tarve tulevaisuudessa laajentaa kyseistä softaa. Tai integroida se johonkin muuhun järjestelmään, sanotaan nyt vaikkapa EU:n tasolla. Jolloin huppistakeikkaa, Latin-9 ei riitäkään, vaan meillä onkin sekaisin Latin-9:iä, Latin-16:sta, Latin/Cyrillicia ja Latin/Greekkiä.

Että joo, nykypäivänä ei ole mitään järkeä lähteä rakentamaan mitään uutta tietojärjestelmään minkään muun kuin Unicoden päälle.

 

[pulatunnus]

Istuhan alas ja ota rauhallinen asento...
Kerropa nyt ihan omin sanoin suomeksi siitä tyhjyyden ja riittämättömyyden tunteesta, jonka ISO-8859-15-merkistö sinussa aiheuttaa.

Jos se ei riitä edes kansallisesti, siellä on ne tyypilliset merkit , mutta ymmärtääkseni siitä puuttuu jo ihan ne merkit mitä tarvitaan fi domainiin, tai mitä tarvitaan jos kirjoitetaan "kotimaisia" kielliä, saati sitten kohtuullisen yleisiä vieraita kieliä.

Jos on on tällä vuosikymmenellä joutunut tekemään merkistövalintoja, niin joutuu jonkunverran perusteleen jos valitsee jonkin muun kuin unicodemerkistön, ja syyt on jotkin muut kuin se että esimerkin ISO-8859-15 pärjäisi, ainakin jotenkin.

Mihin vaikkapa verottajan tietojärjestelmissä tarvitaan muuta kuin 8-bittistä merkistöä?

No verottajan "asiakaissa" on niitä kotimaisia kieliä puhuvia, vieraita kieliä puhuvia ja verotta tekee, voi tehdä tietojen vaihtoa nyt sinne ja tänne, ja tulevaisuutta ei kannata vaikeuttaa ihan vain periaatteentakia.

Vieraita merkistöjä varten on käytössä semmoinen erikoistekniikka kuin translitterointi. Sillä vierasperäiset sanat voidaan esittää ymmärrettävästi meidän niin ahdistavan suppealla merkistöllä. Kumpi on ymmärrettävämpää 福岡市 vai Fukuoka? ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ vai Ulaanbaatar?
Nämäkin 福岡市 ja ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ pitäisi kirjoittaa pystyyn mutta eihän tämä ... kulttuuri-imperialistinen foorumisofta siihen taivu.

Niin translitterointi veisi vielä syvempään suohon, (kannatan sinänsä tekstin esityksessä sitä tietyissä tilanteissa, esim molemmat rinnan, tallenne ja siirrot varmaan selkeämpää unicode merkistöllä)

Sitä softaa ei tehdä enää vain länsimaalaisille, vaan sitä softaa tehdään kaikille.

Hyvä huomio, toki varmaan ihan tyypilistä, joku ankyrä päättää että asiakas haluaa vain tämän, niin koodataan sitten niin, entäs jos joku joku toinen haluaa asiakkaiden nimet oikein, ja ALViin desimaalin, ei halua, ihan tyhmää, tieturvariski.,,. Koodataan sitten kaikki uudestaa.

 

[pulatunnus]

Jos hakusana on kirjoitettu väärin, niin silloin hakutoiminnon ei kuulukaan palauttaa mitään järkeviä tuloksia. Käyttäjän pitää kirjoittaa hakusana oikein.

Sen verran ympäripyöreä heitto että nyt joutuu tulkkaan mitä tarkoitat.

Tietenkin jos kirjoittaa hakuun manuaalilaatikko, silloin kun hakee punaista maalia niin ensimmäisenä tulee mieleen että nyt ei ehkä ihan hyvä hakusana.

Sitten jos hakee käyttöohjeita varten laatikkoa niin ei niin väärin, tai jos hakee käsivalintaista vaihdelaatikkoa, (esim autoon)


Jos teet hakua ASCII merkeillä, niin miten esität tulokset, jos haetaan mäki, maki, Mäki, Maki, Mággá, magga, Biđe, bide

 

[takomo]

Sitä softaa ei tehdä enää vain länsimaalaisille, vaan sitä softaa tehdään kaikille.

Riippuu ihan siitä mihin tarkoitukseen ja kenelle softaa tehdään. Nykyään voi nähdä jopa etuna, jos esim. kiinalaiset eivät voi ihan suoraan softaa käyttää itse.

Jos NASA koodaa Mars-mönkijän softaa, miksi siellä pitäisi olla täysi tuki etiopialaiselle merkistölle sekä riimukirjoitukselle?

Että joo, nykypäivänä ei ole mitään järkeä lähteä rakentamaan mitään uutta tietojärjestelmään minkään muun kuin Unicoden päälle.

Yksikään iso toimija ei lähde kehittämään softia puhtaalta pöydältä vaan on olemassa legacy-järjestelmät, joihin on investoitu paljon. Kaikkea ei varmasti laiteta kerralla uusiksi jonkun merkistön takia.

Jos ei ole polttavaa tarvetta Unicoden tukemiselle, säästyy paljolta päänsäryltä tilkitsemällä järjestelmät niin, että Unicodea ei pääse mistään vuotamaan sisään.

Jos se ei riitä edes kansallisesti, siellä on ne tyypilliset merkit , mutta ymmärtääkseni siitä puuttuu jo ihan ne merkit mitä tarvitaan fi domainiin, tai mitä tarvitaan jos kirjoitetaan "kotimaisia" kielliä, saati sitten kohtuullisen yleisiä vieraita kieliä.

Voitko tarkentaa, mitä olennaista puuttuu, etenkin jos keskitytään Suomessa suomen ja ruotsin kirjoittamiseen:

Jos käsitellään vain länsieurooppalaisia kieliä, niin Unicode ei tuo MITÄÄN lisäarvoa 8-bittisiin merkistöihin nähden.

 

[JCSH]

Riippuu ihan siitä mihin tarkoitukseen ja kenelle softaa tehdään. Nykyään voi nähdä jopa etuna, jos esim. kiinalaiset eivät voi ihan suoraan softaa käyttää itse.

Jos NASA koodaa Mars-mönkijän softaa, miksi siellä pitäisi olla täysi tuki etiopialaiselle merkistölle sekä riimukirjoitukselle?

Kuten tuolla jo aiemmin totesin, aina kun kyse on informaatiosta, joka on tarkoitettu ihmisten luettavaksi, niin kannattaa käyttää Unicodea. Jos kyseessä on joku koneiden välinen viestiprotokolla, niin sitten tilanne on eri.

Jos NASA koodaa Mars-mönkijän ohjaussoftan käyttöliittymää ja toteaa, että "Latin-1 riittää hyvin, kerta 'Muhrica", niin mitä sitten, kun seuraava mönkijä onkin yhteistyö JAXA:n kanssa?
Huppistakeikkaa, sitten tarvitaankin se kanji-tuki ja softakoodarit kiroavat, että kuka vitun idiootti luuli, että 8-bittiä riittää.

Yksikään iso toimija ei lähde kehittämään softia puhtaalta pöydältä vaan on olemassa legacy-järjestelmät, joihin on investoitu paljon. Kaikkea ei varmasti laiteta kerralla uusiksi jonkun merkistön takia.

Toki harvaa legacy-järjestelmää kiskotaan alas pelkästään Unicoden takia, mutta se ei tarkoita sitä, etteikö uusissa järjestelmissä pitäisi aina pyrkiä siihen Unicodeen

Jos ei ole polttavaa tarvetta Unicoden tukemiselle, säästyy paljolta päänsäryltä tilkitsemällä järjestelmät niin, että Unicodea ei pääse mistään vuotamaan sisään.

Paljon enemmän päänvaivaa aiheuttaa se, että ei käytä sitä Unicodea ja sitten toteaa, että hitto, nyt sitä tarvitaankin.

 

[takomo]

Kuten tuolla jo aiemmin totesin, aina kun kyse on informaatiosta, joka on tarkoitettu ihmisten luettavaksi, niin kannattaa käyttää Unicodea. Jos kyseessä on joku koneiden välinen viestiprotokolla, niin sitten tilanne on eri.

Vaikka olisi kyse vain binäärisestä viestiprotokollasta, niin jollain kielellä sen lähdekoodi on koodattava. Debuggausta helpottaa suuresti, jos tila- ja virhetiedoissa on myös ihmisen luettavaa tekstiä.

Jos NASA koodaa Mars-mönkijän ohjaussoftan käyttöliittymää ja toteaa, että "Latin-1 riittää hyvin, kerta 'Muhrica", niin mitä sitten, kun seuraava mönkijä onkin yhteistyö JAXA:n kanssa?
Huppistakeikkaa, sitten tarvitaankin se kanji-tuki ja softakoodarit kiroavat, että kuka vitun idiootti luuli, että 8-bittiä riittää.

Huppistakeikkaa, japanilaiset ovat harjoittaneet tietotekniikkaa jo ennen Unicode-aikaa ja luoneet mm. 8-bittisen JIS X 201-merkistön, joka kattaa ASCIIn ja katakana-merkistön:

JIS X 0201 - Wikipedia

en.wikipedia.org

Jos nyt välttämättä halutaan koodata kaksikielisiä tekstejä, niin tuo välttää siihen mainiosti.

 

[JCSH]

Vaikka olisi kyse vain binäärisestä viestiprotokollasta, niin jollain kielellä sen lähdekoodi on koodattava. Debuggausta helpottaa suuresti, jos tila- ja virhetiedoissa on myös ihmisen luettavaa tekstiä.

Lähdekoodit tietenkin UTF-8:ia. Kuten nykyään aikalailla kaikissa moderneissa softakehitystyökaluissa toimitaankin.

Huppistakeikkaa, japanilaiset ovat harjoittaneet tietotekniikkaa jo ennen Unicode-aikaa ja luoneet mm. 8-bittisen JIS X 201-merkistön, joka kattaa ASCIIn ja katakana-merkistön:

JIS X 0201 - Wikipedia

en.wikipedia.org

Jos nyt välttämättä halutaan koodata kaksikielisiä tekstejä, niin tuo välttää siihen mainiosti.

Entä sitten kun pitääkin saada myös sen ESA mukaan projektiin ja tulee ne eurooppalaiset kielet mukaan? Tai jos onkin käytetty sitä Latin-1:tä ja sieltä löytyy käyttäjiä, joiden nimissä on noita Latin-1:n ASCII:n ulkopuolisia merkkejä.
Sitten et saakaan enää ASCII:ta, noita kieliä ja japania samaan merkistöön. Joten sun pitää alkaa vaihteleen monien eri merkistöjen välillä. Kaikki vaikeutuu aivan helvetisti sen sijaan, että vain käyttäisit sitä Unicodea.

Kyllä, muitakin kuin englantia käytettiin tietokoneissa aikana, jolloin merkistöt oli niitä 8-bittisiä. Kyllä, tuollaisia monen merkistön kikkailuja voidaan tehdä. Mutta ne ovat helvetin epäkäteviä ja aiheuttavat pirusti ongelmia siinä vaiheessa, kun niitä softia piti käyttää sen oman pienen kuplan ulkopuolella. Jonka takia nykyään on siirrytty siihen Unicodeen.

 

[jad]

Vieraita merkistöjä varten on käytössä semmoinen erikoistekniikka kuin translitterointi. Sillä vierasperäiset sanat voidaan esittää ymmärrettävästi meidän niin ahdistavan suppealla merkistöllä. Kumpi on ymmärrettävämpää 福岡市 vai Fukuoka? ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ vai Ulaanbaatar?
Nämäkin 福岡市 ja ᠤᠯᠠᠭᠠᠨᠪᠠᠭᠠᠲᠤᠷ pitäisi kirjoittaa pystyyn mutta eihän tämä ... kulttuuri-imperialistinen foorumisofta siihen taivu.

Ja sitten päästäänkin siihen ongelmaan, että translitteroidaanko esim. Ukrainan venäjänkieliset paikkakuntien nimet ukrainalaisittain vai venäläisittäin. Muitakin esimerkkejä erilaisista translitterointikäytännöistä löytyy, mutta tämä nyt ensimmäisenä tuli mieleen.

 

[pulatunnus]

Voitko tarkentaa, mitä olennaista puuttuu, etenkin jos keskitytään Suomessa suomen ja ruotsin kirjoittamiseen:

Jos käsitellään vain länsieurooppalaisia kieliä, niin Unicode ei tuo MITÄÄN lisäarvoa 8-bittisiin merkistöihin nähden.

Miksi lähestyä ajatuksella, tällä ohjelmistolla käsitellään vain länsieurooppalaisia kieliä, teksti, nimiä, asioita, yms.
Mutta onko tuossa edes niitä merkkejä joita käytetään pohjoismaissa, EU alueen kielten merkki tuki jää sitten enemmän vajaaksi.

Ja kreikkalaistenkin merkkien osalta aika niukka, niitäkin käytetään aika paljon vaikka ei sitä kieltä kirjoittaisi.

Edit, ei tuossa tainnut olla ajatusviivaa ?