Merkistöistä

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

 

[Sompi]

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.

 

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

 

[Sompi]

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



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.

Ajattelet ilmeisesti, että kaikki unicodeen liittyvät ongelmat voi sivuuttaa ihan vain jankkaamalla tarpeeksi kauan samaa asiaa.

 

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

 

[pulatunnus]

Ajattelet ilmeisesti, että kaikki unicodeen liittyvät ongelmat voi sivuuttaa ihan vain jankkaamalla tarpeeksi kauan samaa asiaa.

Kuka niiden sivuuttamisesta on jankannut ?

Ongelmaksi on mainittu että merkistössä on ohjausmerkkejä, on niitä muissakin, ja joka tapauksessa koodari joka tekee sitä osaa joka käsittelee, esittää sisältöä käyttäjälle, niin joutuu suhtautuun vieraaseen sisältöön että se on vihameilistä.

 

[JCSH]

Ajattelet ilmeisesti, että kaikki unicodeen liittyvät ongelmat voi sivuuttaa ihan vain jankkaamalla tarpeeksi kauan samaa asiaa.

Kuinka monta kertaa sulle pitää toistaa se, että ei tässä olla sivuuttamassa unicoden ongelmia.
Vaan totean, että unicode ratkaisee paljon enemmän ongelmia kuin mitä se aiheuttaa. Jonka lopputuloksena on parempi käyttää unicodea kuin kasaa erilaisia 8-bittisiä merkistöjä.

 

[love_doctor]

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.

Tässähän riippuu paljon, voiko puuttuvia merkkejä escapettaa jollain systeemillä. HTML tukee entiteettien koodaamista Asciilla ja Latexissa ja vastaavissa on myös keinot. Ainakin oman kokemuksen perusteella merkit on kyllä helpompi kirjoittaa Latexiinkin nykyään Unicodella kuin lähteä paloista rakentamaan tai escape-koodeilla jotain erikoismerkkejä.

Kyllähän latin9:stä puuttuu todella monta ihan suomen arkikielessä olevaa asiaa. Esim. haluat ehkä muitakin viivamerkkejä kuin alaviivan ja tavallisen. Ajatusviiva (joita muuten on kahta eri kokoa) on normaalia suomea ja sitä esiintyy mekaanisesti painetuissakin kirjoissa todella paljon. Toki voit sen kirjoittaa kahdella viivamerkillä, mutta ei ole ihan sama asia. Latin9:n numeerinen ja matematiikkaosio on ylipäänsä melko onneton. Promillemerkki ‰ voi olla kätevä jos et halua kirjoittaa sitä auki aina, samoin pii (π). Likimäärin yhtäsuuren (≈) merkki puuttuu kuten myös erisuuren (≠) ja pienemmän/suuremman tai yhtäsuuren kuin (≤ ≥). Tyhjän joukon symboli löytyy, mutta vaikkapa joukkoon kuulumista (∈) ei voi kirjoittaa. Vaikka tietokoneissa on monessa numpad-näppis, tätä merkistöä käytetään yleensä niin, että numpadin kerto/jakonäppäimistä tulee asteriski ja kauttamerkki eikä merkistön kerto- ja jakomerkkiä. Monet ohjelmat eivät edes tunnista näiden käyttöä. Jos haluat kertoa miten joku sana lausutaan, foneettiset merkit puuttuvat. Jos haluat hymiöitä, pitää koodata ne asciina. Erilaisia lainausmerkkejä, heittomerkkejä, tuuma- ja jalkamerkkejä yms. on aika rajallisesti. © ja ® löytyvät, mutta trademark ™ puuttuu. No nekin voi kirjoittaa kaikki asciina varmaan juu. Suomessa on myös venäjänkielisiä vähemmistöjä ja kyrillisten puute on aika paha ihan arkikäytössä.

 

[love_doctor]

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.

Tuli tämän ketjun myötä mieleen, että muistan jossain vaiheessa viime vuosina lukeneeni jostain vaihtoehtoisestakin "modernista" merkkien koodauksesta Unicoden sijaan. Unicodea kohtaan kun voi esittää ihan validiakin kritiikkiä eikä tätä legacy-koodisivujen jauhantaa. Koitin etsiä jos löytäisin, mutta ei tullut vastaan. Lienee vähän pienempien piirien juttu, mutta jos jollain tulee mieleen, kiinnostaisi kyllä lukea vielä lisää aiheesta. Kyllä Unicode noin yleisesti ottaen on aika varma de facto -standardi, joten ei siinäkään väärin tee, jos mieluummin vaan käyttää sitä.

edit: Löytyi! TRON (encoding) - Wikipedia
Tässä tosiaan taustalla oli se, että Unicodesta alunperin suunniteltiin 65536-merkkistä. CJK-kielet olisi syöneet "liikaa" merkkejä ja niitä haluttiin unifioida, vaikkei tämä sitten täysin toiminut.

 

[takomo]

Tässähän riippuu paljon, voiko puuttuvia merkkejä escapettaa jollain systeemillä. HTML tukee entiteettien koodaamista Asciilla ja Latexissa ja vastaavissa on myös keinot. Ainakin oman kokemuksen perusteella merkit on kyllä helpompi kirjoittaa Latexiinkin nykyään Unicodella kuin lähteä paloista rakentamaan tai escape-koodeilla jotain erikoismerkkejä.

Latexin matematiikkasymbolit syntyy luontevimmin Latexin omilla symbolikomennoilla ja ääkköset toimivat \usepackage[latin1]{inputenc} -komennolla oikein.

Kyllähän latin9:stä puuttuu todella monta ihan suomen arkikielessä olevaa asiaa. Esim. haluat ehkä muitakin viivamerkkejä kuin alaviivan ja tavallisen. Ajatusviiva (joita muuten on kahta eri kokoa) on normaalia suomea ja sitä esiintyy mekaanisesti painetuissakin kirjoissa todella paljon. Toki voit sen kirjoittaa kahdella viivamerkillä, mutta ei ole ihan sama asia. Latin9:n numeerinen ja matematiikkaosio on ylipäänsä melko onneton. Promillemerkki ‰ voi olla kätevä jos et halua kirjoittaa sitä auki aina, samoin pii (π). Likimäärin yhtäsuuren (≈) merkki puuttuu kuten myös erisuuren (≠) ja pienemmän/suuremman tai yhtäsuuren kuin (≤ ≥). Tyhjän joukon symboli löytyy, mutta vaikkapa joukkoon kuulumista (∈) ei voi kirjoittaa.

Yleisesti, erilaisia symboleita varten on wysiwyg-ympäristöissä luontevasti erillinen Symbol-fontti. Se on huomattavasti näppärämpi kuin alkaa kahlata Unicoden 100000 inuiittisymbolia ym. läpi. Latexin (varsinkin AMS-Latexin) symbolikirjasto taas on varsin kattava. Useinkin on selkeämpää, että lähdekoodissa on kirjoitettu vaikka $^\circ$ kuin °. Eihän tavallisella merkistöllä pysty esittämään esim. ala- ja yläindeksejä kuin hyvin rajoitetusti mutta Latexilla onnistuu mikä vain - eikä tarvita Unicodea.

Tässä tosiaan taustalla oli se, että Unicodesta alunperin suunniteltiin 65536-merkkistä. CJK-kielet olisi syöneet "liikaa" merkkejä ja niitä haluttiin unifioida, vaikkei tämä sitten täysin toiminut.

Jos tarvitaan aidosti monikielistä kirjoitusta, niin kiinteä 16-bittinen merkistö olisi asiaa. Vaihtuvamittaisista merkeistä olisi syytä päästä eroon. Vaikka jokainen symboli olisi 16 bittiä, 8-bittinen teksti todennäköisesti pakkautuisi hyvin, joten tila ei olisi ongelma tallennuksessa eikä tiedonsiirrossa.

Nollaa olisi epäviisasta koodata muuksi kuin NUL-symboliksi, joten 16-bittisellä merkistöllä olisi käytettävissä 255 sivua à 255 merkkiä eli 65025 symbolia. Mihin olennaiseen se ei olisi tarpeeksi? CJK-kielilläkin on ollut omat 94x94 (8836) suuruiset - ja vajaat - standardimerkistönsä.

 

[takomo]

Kuinka monta kertaa sulle pitää toistaa se, että ei tässä olla sivuuttamassa unicoden ongelmia.
Vaan totean, että unicode ratkaisee paljon enemmän ongelmia kuin mitä se aiheuttaa.

Sinä nimenomaan sivuutat Unicoden ongelmat eikä se pelkällä toteamisen toistamisella muuksi muutu. Toisaalta kehittämäsi "ongelma"-skenaariot on aika mielikuvituksellisia. Oikeasti kansainvälisessä yhteistyössä englanninkielisyys ei ole mikään ongelma vaan kaikki osapuolet odottaa sitä.

Ongelmia tulee jo, jos vaikka jotain on koodattu saksaksi ja jotain toista ranskaksi. En halua edes arvata, miten yhteistyö sujuisi, jos lisäksi olisi koodifragmentteja thaiksi, gujaratiksi ja koreaksi. Sitten näistä koodinosista löytyy bugi tai jotain pitäisi päivittää, esim. lisätä tuki ALV:n desimaaleille.

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.

Ja sitten se todennäköisin ratkaisu, pidetään kaikki englanninkielisenä.

Kaivetaanpa sitten esiin olkipaali - joskaan ei välttämättä aivan epärealistinen...
Oletetaanpa, että NASA on joskus kirjoittanut FORTRAN-66:lla viimeisen päälle olevan koodin luotainten ratalaskuihin. Ei oltu köyhiä eikä kipeitä, joten oli varaa tehdä asiat kunnolla. Koodin avulla on lennetty lähiplaneetoille ja Apollolla Kuuhun ja takaisin. Koodi on osittain päivitetty FORTRAN-77:lle Voyagareita varten, joille on laskettu planetaarista biljardia. Koodi ei ole liian hyvin dokumentoitu mutta se on kiistämättömän hyvin validoitu: se laskee oikein ja siihen voi luottaa.

Koskapa koodarit on jo mullan alla, koodia ei kukaan halua käydä avaamaan mutta moderni, graafinen käyttöliittymä olisi kiva. Sehän syntyy vaikka Python3:lla, jolla voi myös visualisoida tulokset. Millaisia riskejä liittyy siihen, että vanha koodi paketoitaisiin Unicodea puhuvan - tietenkin monikielisen - paketin sisään?

 

[love_doctor]

Latexin matematiikkasymbolit syntyy luontevimmin Latexin omilla symbolikomennoilla ja ääkköset toimivat \usepackage[latin1]{inputenc} -komennolla oikein.

"Oikein". Olet kyllä jossain aikalimbossa tämän kanssa nyt 2024. TeX:ssä alunperin standardimerkistö oli 7-bittinen ASCII. Koko inputenc-mekanismi kehitettiin ratkomaan ongelmia, mikä syntyi kun ihmiset käyttivät 8-bittisiä merkistöjä, jotka eivät olleet yhteensopivia. Jos nyt katotaan TeX-engineitä, Luatexissä ja Xelatexissa on utf8 ollut oletusarvo (ja ainut tuettu merkistökoodaus) aina. Pdflatexissa tuli 2018 utf8 oletukseksi ja esim. Overleaf-palvelussakin utf8 on oletus. Tukea tietenkin oli jo tätä ennen eli ihan tyhjästä siirtymä ei syntynyt. Paketteihin on jo vuosia rakennettu utf8-tukea reflektoimaan tätä siirtymää. Ohjeesi on ainakin vuosikymmenen verran vanhentunut.

Jos tarvitaan aidosti monikielistä kirjoitusta, niin kiinteä 16-bittinen merkistö olisi asiaa. Vaihtuvamittaisista merkeistä olisi syytä päästä eroon. Vaikka jokainen symboli olisi 16 bittiä, 8-bittinen teksti todennäköisesti pakkautuisi hyvin, joten tila ei olisi ongelma tallennuksessa eikä tiedonsiirrossa.

Unicodessa oli lähtökohtana 16-bittinen merkistö. Tunnetko yhtään historiaa miksi ideasta luovuttiin? Listaatko vielä perään ne syyt miksi merkistön pitäisi olla kiinteämittainen? Voin koittaa selventää kohta kohdalta, mikä vika tässä ajattelussa on.

 

[JCSH]

Sinä nimenomaan sivuutat Unicoden ongelmat eikä se pelkällä toteamisen toistamisella muuksi muutu. Toisaalta kehittämäsi "ongelma"-skenaariot on aika mielikuvituksellisia. Oikeasti kansainvälisessä yhteistyössä englanninkielisyys ei ole mikään ongelma vaan kaikki osapuolet odottaa sitä.

Ongelmia tulee jo, jos vaikka jotain on koodattu saksaksi ja jotain toista ranskaksi. En halua edes arvata, miten yhteistyö sujuisi, jos lisäksi olisi koodifragmentteja thaiksi, gujaratiksi ja koreaksi. Sitten näistä koodinosista löytyy bugi tai jotain pitäisi päivittää, esim. lisätä tuki ALV:n desimaaleille.

Oikeassa kansainvälisessä yhteistyössä ei todellakaan voi odottaa englanninkielisyyttä kaikilta. Tiedän tuon, koska olen kohta 20 vuotta vanhan työurani aikana tehnyt jatkuvasti kansainvälisiä projekteja. Länsimaalaisilla on usein harhaluulo siitä, että englanti olisi joku globaali lingua franca ainakin korkeasti koulutettujen joukossa. Mutta se ei todellakaan ole sitä, kun aletaan puhumaan vaikkapa kiinalaisista ja japanilaisista.
Tuossa vaiheessa aletaan puhumaan erittäin vaihtelevista englannin taidoista, jonka takia tarvitaan tukea niille muillekin kielille.

Ja sitten se todennäköisin ratkaisu, pidetään kaikki englanninkielisenä.

Kaivetaanpa sitten esiin olkipaali - joskaan ei välttämättä aivan epärealistinen...
Oletetaanpa, että NASA on joskus kirjoittanut FORTRAN-66:lla viimeisen päälle olevan koodin luotainten ratalaskuihin. Ei oltu köyhiä eikä kipeitä, joten oli varaa tehdä asiat kunnolla. Koodin avulla on lennetty lähiplaneetoille ja Apollolla Kuuhun ja takaisin. Koodi on osittain päivitetty FORTRAN-77:lle Voyagareita varten, joille on laskettu planetaarista biljardia. Koodi ei ole liian hyvin dokumentoitu mutta se on kiistämättömän hyvin validoitu: se laskee oikein ja siihen voi luottaa.

Koskapa koodarit on jo mullan alla, koodia ei kukaan halua käydä avaamaan mutta moderni, graafinen käyttöliittymä olisi kiva. Sehän syntyy vaikka Python3:lla, jolla voi myös visualisoida tulokset. Millaisia riskejä liittyy siihen, että vanha koodi paketoitaisiin Unicodea puhuvan - tietenkin monikielisen - paketin sisään?

Siis sä väität mun "ongelma" skenaarioita mielikuvituksellisiksi ja sitten sun omat esimerkit ovat jotain Voyager-luotaimien fortrania 70-luvulta? Kuinka monta kertaa mun pitää toistaa sulle:

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

*edit*

Tosin jos sulla on jotain vanhaa ASCII-pohjaista koodia, niin sen käyttäminen Unicodea tukevasta järjestelmästä ei ole mikään ongelma. Kaikki ASCII-sisältö on kuitenkin validia UTF-8:ia, joten sisäänpäin tuleva data on valmiiksi yhteensopivaa. Jos on tarvetta siirtää dataa sieltä uudesta järjestelmästä vanhaan, niin sitten sen UTF-8:n rajaaminen ASCII-yhteensopivaksi on erittäin trivaali juttu.

 

[Paapaa]

Vieraita merkistöjä varten on käytössä semmoinen erikoistekniikka kuin translitterointi.

Unicodehan ei millään tavalla estä translitterointia jos sellaista halutaan käyttäjälle tarjota. Taisit itkeä myös Mapsin alkukielisistä paikannimistäkin aiemmin. Unicode ei estä paikannimien esittämistä kulloinkin sopivalla translitteroinnilla. Päinvastoin, se helpottaa sitä kun sen voi tehdä joka suuntaan käyttäen samaa merkistöä ja luultavasti pärjäät samalla vähemmillä fonteilla. Se on täysin palveluntarjoajasta kiinni, tarjoaako se translitterointia vai ei. Unicode ei sitä millään tasolla tietenkään estä.

 

[takomo]

"Oikein". Olet kyllä jossain aikalimbossa tämän kanssa nyt 2024. TeX:ssä alunperin standardimerkistö oli 7-bittinen ASCII. Koko inputenc-mekanismi kehitettiin ratkomaan ongelmia, mikä syntyi kun ihmiset käyttivät 8-bittisiä merkistöjä, jotka eivät olleet yhteensopivia. Jos nyt katotaan TeX-engineitä, Luatexissä ja Xelatexissa on utf8 ollut oletusarvo (ja ainut tuettu merkistökoodaus) aina. Pdflatexissa tuli 2018 utf8 oletukseksi ja esim. Overleaf-palvelussakin utf8 on oletus. Tukea tietenkin oli jo tätä ennen eli ihan tyhjästä siirtymä ei syntynyt. Paketteihin on jo vuosia rakennettu utf8-tukea reflektoimaan tätä siirtymää. Ohjeesi on ainakin vuosikymmenen verran vanhentunut.

Pointti ei olekaan siinä onko inputenc latin1 viimeistä huutoa oleva tapa kertoa Latexille, että tekstissä on ääkkösiä vaan se, että sillä ääkköset on toimineet "aina", kai 90-luvulta lähtien; 8-bittisin merkein ja ilman unicodea. UTF-8 ei ole millään muotoa välttämätön eurooppalaisten merkistöjen esittämiseen Latexissa. Tässäkin UTF-8:a tarjotaan ratkaisemaan ongelmaa, jota ei ole ollut vuosikymmeniin.

Onko TeX:n Computer Modern-fonttiin muuten luotu typografisesti yhdenmukaiset merkit koko Unicode-merkistölle? Entä muihin TeX:n tukemiin fontteihin? Jos ei ole, niin mihin edes tarvitaan UTF-8:a? Jos on, niin paljonko tähän on käytetty työtä - ja onko se todella ollut työtä, jolla on tarkoitus?

PC-maailmassa rautatason tuki ääkkösille näyttää olleen aina, v. 1981 lähtien: Code page 437 - Wikipedia

Unicodessa oli lähtökohtana 16-bittinen merkistö. Tunnetko yhtään historiaa miksi ideasta luovuttiin? Listaatko vielä perään ne syyt miksi merkistön pitäisi olla kiinteämittainen? Voin koittaa selventää kohta kohdalta, mikä vika tässä ajattelussa on.

En tunne tarkasti, olettaisin syyn olleen perfektionismi. Toisaalta haluttiin säilyttää 7-bittinen ASCII mutta toisaalta annettiin merkistöavaruuden paisua kuin pullataikina. Käsittääkseni CJK-alueella ihmiset käyttävät yleisesti n. 2000 symbolia. Jos symboleita on 30000, niin valtaosa ihmisistä ei edes tiedä, mitä ne tarkoittavat tai miten ne pitäisi lausua. Niitä on täysin hyödytöntä ottaa mukaan globaaliin merkistöön.

Ei tietokonemerkistön tarvitse olla täydellinen. Aivan hyvin paikallisesti tunnettuja symboleita voisi toteuttaa fonteilla. Esim. 0x8001-0xFFFF voisi allokoida neljäksi 8k kokoiseksi sivuksi C, J, K ja paikalliset variantit. 32k symbolia jäisi muulle maailmalle.

Miksi kiinteämittainen? Tehokkuus ja yksinkertaisuus. Kiinteämittaisin merkistöin toteutetut merkkijonot on suoraan indeksoitavissa eikä tarvitse pureskella koko merkkijonoa läpi, jos haluaa vaikka merkkijonon 58. merkin. 58. merkkiä voi myös muuttaa suoralla sijoituksella ilman, että pitää käyttää koodia ja aikaa siihen, että uusi merkki onkin ehkä eri mittainen kuin vanha:
txt[57]='Ä' vs.
<etsi txt:n 58. merkki> -> ix
<tutki onko txt[ix] samankokoinen kuin 'Ä'>
<jos ei, siirrä merkkijonon loppua vastaamaan 'Ä'-merkin kokoa.
Muista txt:lle varattu muisti, varaa tarvittaessa lisää.
Muista virheenhallinta, jos lisämuistia ei olekaan saatavilla>
txt[ix]='Ä'
<Lopuksi voikin miettiä, miten aliohjelma palauttaa tiedon siitä, että txt:n sijainti on ehkä muuttunut muistijumpassa.>

Vaihtuvamittaiset merkit rikkovat tai voivat rikkoa kiinteämittaisille koodatun, ja vieläpä ikävällä tavalla: bugaaminen ei välttämättä ilmene heti (mm. ASCII toimii), eikä bugaaminen välttämättä kaada koodia vaan rikkoo datan. Korjaaminen voi olla työlästä. Kun tarvitaan globaalia merkistöä, olisi parempi, että se olisi aidosti epäyhteensopiva 8-bittisten kanssa.

Unicodehan ei millään tavalla estä translitterointia jos sellaista halutaan käyttäjälle tarjota.

Eihän tässä siitä ole kyse vaan siitä, että vieraat nimet voidaan esittää translitteroimalla meidän 8-bittisellä merkistöllä. Ei tarvita Unicodea.

 

[JCSH]

Eihän tässä siitä ole kyse vaan siitä, että vieraat nimet voidaan esittää translitteroimalla meidän 8-bittisellä merkistöllä. Ei tarvita Unicodea.

Ei se ongelma ole koskaan ollut, että miten kirjoitetaan Japanin pääkaupungin nimi siten, että suomalaiset ymmärtävät sen.

Se mitä Unicodella ratkaistaan on tilanne, missä sulla on softa, jonka pitää näyttää suomalaisille sana Tokio, japanilaisille sana 東京都, venäläisille sana Токио ja arabeille sana طوكيو
Unicode mahdollistaa sen, että kaikki nuo voidaan tallettaa ja näyttää ilman, että tarvii vaihdella neljän eri merkistön välillä. Tai että noita voidaan käyttää ristiin vaikkapa ihan samassa tekstikentässä.

Translitterointi ratkaisee ongelman, mutta se on eri ongelma kuin mitä ratkaistaa Unicodella.

 

[Paapaa]

...vieraat nimet voidaan esittää translitteroimalla meidän 8-bittisellä merkistöllä. Ei tarvita Unicodea.

Vieraat nimet voidaan esittää translitteroimalla meidän Unicode-merkistöllä. Ei tarvita suppeaa Latin-9:ää tai muita vanhentuneita ja suppeita merkistöjä. Asian voi hoitaa yhdellä merkistölläkin. Boonuksena - toisin kuin Latin-9:llä, voidaan se sama nimistö translitteroida kantoninkiinalle ja kaikelle muullekin ihan sillä samalla merkistöllä. Ei tarvita mitään muuta kuin yksi Unicode.

Sä haikailet jostain täysin käsittämättömästä syystä suppeiden merkistöjen aikaa - merkistöjä, jotka aiheuttivat jatkuvasti ongelmia. Sä yrität epätoivoisesti markkinoida paskaa laatutuotteena keksimällä täysin absurdeja argumentteja jostain translitteroinneista, mutta ei toi nyt vaan onnistu. Maailma meni jo eteenpäin. Tuu jo hei tänne 2000-luvun puolelle meidän muiden kanssa ja unohda toi täysin älyvapaa latin-9-fanittelusi. Ei me kaivata enää tämännäköisiä sivuja:

PS. Ja sä siis olet jo hävinnyt tämä taistelusi. Unicode on de facto standardi, ja siirtyminen tapahtuu käytännössä vain siihen suuntaan, ei siitä pois.

 

[JCSH]

Miksi kiinteämittainen? Tehokkuus ja yksinkertaisuus. Kiinteämittaisin merkistöin toteutetut merkkijonot on suoraan indeksoitavissa eikä tarvitse pureskella koko merkkijonoa läpi, jos haluaa vaikka merkkijonon 58. merkin. 58. merkkiä voi myös muuttaa suoralla sijoituksella ilman, että pitää käyttää koodia ja aikaa siihen, että uusi merkki onkin ehkä eri mittainen kuin vanha:
txt[57]='Ä' vs.
<etsi txt:n 58. merkki> -> ix
<tutki onko txt[ix] samankokoinen kuin 'Ä'>
<jos ei, siirrä merkkijonon loppua vastaamaan 'Ä'-merkin kokoa.
Muista txt:lle varattu muisti, varaa tarvittaessa lisää.
Muista virheenhallinta, jos lisämuistia ei olekaan saatavilla>
txt[ix]='Ä'
<Lopuksi voikin miettiä, miten aliohjelma palauttaa tiedon siitä, että txt:n sijainti on ehkä muuttunut muistijumpassa.>

Tosin nämä tehokkuus ja yksinkertaisuus asiat ovat vähän kyseenalaiset tuossa kohtaa.

Ensinnäkin, todellisuudessahan nykyaikana ylivoimaisessa enemmistössä tapauksista koodari toteuttaa tuon kutsumalla jotain tämän suuntaista, oli käytössä Unicode tai ei:

txt = txt.replaceAt(57, "ä")

ja antaa kyseisen ohjelmointikielen standardikirjaston tai käytössä olevan frameworkin string-toteutuksen hoitaa se monimutkainen osa.

Toiseksi, tuollaiset puhtaasti indeksipohjaiset muutokset teksteihin ovat aika marginaalinen käyttötapaus. Missä tapauksessa pitää vaihtaa juurikin se 58. merkki?
Se mitä yleensä halutaan tehdä, on korvata tietyt merkit toisilla merkeillä. Jolloin pitää kuitenkin pureskella se koko merkkijono läpi ja tuon indeksipohjaisen random accessin optimointi on lopulta aika turhaa.
Jolloin se mitä oikeasti halutaan, on jotain tyyliin:

txt = txt.replaceAll("ö", "ä")

Jolloin riippumatta siitä, että onko käytössä fixed 8-bit tai se UTF-8, niin koko merkkijono pitää kuitenkin mennä alusta loppuun.
Toki tuossa fixed 8-bitillä saadaan vielä se muistiallokaatioetu, mutta tuokin on suht rajallinen käyttötapaus.

Jos se mitä halutaan onkin:

txt = txt.replaceAll("äiti", "mutsi")

Nyt tarvitaankin niitä muistiallokaatiota ihan sillä fixed 8-bittiselläkin.

Eli lopulta tuo fixed 8-bit merkistön tuoma etu on erittäin rajallinen ja koskee vain jotain suht niche tapauksia.

 

[takomo]

Se mitä Unicodella ratkaistaan on tilanne, missä sulla on softa, jonka pitää näyttää suomalaisille sana Tokio, japanilaisille sana 東京都, venäläisille sana Токио ja arabeille sana طوكيو

Kansainväliselle merkistölle on todellakin paikkansa silloin, kun on tarpeen tukea samanaikaisesti useita eri merkistöjä. Läheskään kaikkeen tietojenkäsittelyyn EI liity tällaista vaatimusta tai edes olennaista tarvetta. Länsimaissa riittää silloin 8-bittinen merkistö vallan mainiosti.

Ensinnäkin, todellisuudessahan nykyaikana ylivoimaisessa enemmistössä tapauksista koodari toteuttaa tuon kutsumalla jotain tämän suuntaista, oli käytössä Unicode tai ei:

txt = txt.replaceAt(57, "ä")

ja antaa kyseisen ohjelmointikielen standardikirjaston tai käytössä olevan frameworkin string-toteutuksen hoitaa se monimutkainen osa.

Niinpä niin. Kun kaikkein yksinkertaisimpiakaan asioita ei tehdä eksplisiittisesti itse, vaan annetaan 'standardikirjaston tai käytössä olevan frameworkin string-toteutuksen hoitaa', ei tarvitsekaan ihmetellä miksi toisaalla kummastellaan

(Nyky)softien hitaus

Ei tullut tämmöistä ketjua vielä vastaan, mutta olenko ainoa ketä häiritsee varsinkin modernien ohelmien/ohjelmistojen hitaus? Tuntuu, että mitä enemmän itse oppii ohjelmoimista ja prosessorien/koneiden sielunelämästä, niin sitä vähemmän sietää ohjelmia, jotka eivät käynnisty välittömästi...

bbs.io-tech.fi

Ei koodi siitä nopeudu, että ulkoistetaan kirjastolle koko jumppa, jota ei ollenkaan tarvita vakiolevyisellä merkistöllä. Päinvastoin, kirjaston pitää olla geneerinen eikä se voi olettaa sitäkään vähää mitä itse tehdessä ehkä voi.

Toiseksi, tuollaiset puhtaasti indeksipohjaiset muutokset teksteihin ovat aika marginaalinen käyttötapaus. Missä tapauksessa pitää vaihtaa juurikin se 58. merkki?

Siinä voi olla esim. kenttä, johon merkitään kuka toi lapsen hoitoon: 'I'=isä, 'Ä'=äiti, 'M'=muu.

Minkä tahansa yksittäisen esimerkin voi väittää olevan marginaalinen. Tilanne on kuitenkin sellainen, että parhaimmassa tapauksessa vaihtuvapituiset merkit eivät aiheuta lisävaivaa mutta muuten vaivaa aiheutuu aina, joskus enemmän, joskus vähemmän. Vaiva voi olla suurikin, jos suora osoitus koodissa korvataan funktiokutsulla. Keskimäärin vaihtuvapituisten merkistöjen käsittely on tehottomampaa kuin vakiomittaisten.

Vaikutukset ulottuvat myös legacy-ASCII-tiedostojen käsittelyyn. Ajatellaanpa, että grep:llä (tmv.) haetaan rivejä, joissa 60. sarakkeesta alkaen on merkkijono "ERROR". ASCII-grep pystyy suoraan osoittamaan rivin 60. elementin mutta UTF-grep joutuu käymään joka rivin merkki merkiltä läpi löytääkseen 60. sarakkeen. Vaikka ASCII-toteutus ei muodollisesti tukisikaan 8-bittisiä merkkejä, käytännössä harva koodi oikeasti menee nutulleen vaikka 8. bitti olisi käytössä.

unohda toi täysin älyvapaa latin-9-fanittelusi. Ei me kaivata enää tämännäköisiä sivuja:

Ja miten UTF-auttaa tähän, jos UTF-renderöijä saa syötteekseen Latin9-tekstin? Teksti menee rikki ihan kuten aina ennenkin.

PS. Ja sä siis olet jo hävinnyt tämä taistelusi. Unicode on de facto standardi, ja siirtyminen tapahtuu käytännössä vain siihen suuntaan, ei siitä pois.

Tarpeeton UTF:n käyttö tekee tekstinkäsittelystä tehotonta. Tästä saa lokaämpärin, josta voi ammentaa hiilenmustia pilviä UTF-fanittajien päälle. UTF ja muu tehottoman tiedonkäsittelyn fanittaminen on rinnastettavissa päivittäisiin työmatkoihin yksityisjetillä. Eläköön tehokkaat algoritmit!

 

[JCSH]

Kansainväliselle merkistölle on todellakin paikkansa silloin, kun on tarpeen tukea samanaikaisesti useita eri merkistöjä. Läheskään kaikkeen tietojenkäsittelyyn EI liity tällaista vaatimusta tai edes olennaista tarvetta. Länsimaissa riittää silloin 8-bittinen merkistö vallan mainiosti.

Pelkästään EU:n sisällä tarvitaan se neljä eri 8-bittistä merkistöä, joten miten ihmeessä sä meinaat, että länsimaissa riittäisi se 8-bittinen merkistö?
Puhumattakaan siitä, että länsimaissa alkaa olemaan aika paljon sisäistä tarvetta noille ihan ei-eurooppalaisillekin merkistöille

Niinpä niin. Kun kaikkein yksinkertaisimpiakaan asioita ei tehdä eksplisiittisesti itse, vaan annetaan 'standardikirjaston tai käytössä olevan frameworkin string-toteutuksen hoitaa', ei tarvitsekaan ihmetellä miksi toisaalla kummastellaan

(Nyky)softien hitaus

Ei tullut tämmöistä ketjua vielä vastaan, mutta olenko ainoa ketä häiritsee varsinkin modernien ohelmien/ohjelmistojen hitaus? Tuntuu, että mitä enemmän itse oppii ohjelmoimista ja prosessorien/koneiden sielunelämästä, niin sitä vähemmän sietää ohjelmia, jotka eivät käynnisty välittömästi...

bbs.io-tech.fi

Ei koodi siitä nopeudu, että ulkoistetaan kirjastolle koko jumppa, jota ei ollenkaan tarvita vakiolevyisellä merkistöllä. Päinvastoin, kirjaston pitää olla geneerinen eikä se voi olettaa sitäkään vähää mitä itse tehdessä ehkä voi.

Ne standardikirjastot ovat kuitenkin erittäin hyvin optimoituja tuollaisiin yksinkertaisiin asioihin, joten niiden käyttämättä jättäminen on silkkaa ajan tuhlausta.
Pointtina oli se, että se normikoodari ei joudu UTF-8:n takia itse kirjoittamaan tuota toimintaa, koska se on jo kuitenkin kirjoitettu hänen puolesta.

Siinä voi olla esim. kenttä, johon merkitään kuka toi lapsen hoitoon: 'I'=isä, 'Ä'=äiti, 'M'=muu.

Mitä hittoa ne tuota edeltävät 57 merkkiä sitten sisältävät?
Kuka hemmetin idiootti on rakentanut tietorakenteen, jossa on joku 58 merkin tekstikenttä, jonka 58. merkillä on joku erikoismerkitys?

Minkä tahansa yksittäisen esimerkin voi väittää olevan marginaalinen. Tilanne on kuitenkin sellainen, että parhaimmassa tapauksessa vaihtuvapituiset merkit eivät aiheuta lisävaivaa mutta muuten vaivaa aiheutuu aina, joskus enemmän, joskus vähemmän. Vaiva voi olla suurikin, jos suora osoitus koodissa korvataan funktiokutsulla. Keskimäärin vaihtuvapituisten merkistöjen käsittely on tehottomampaa kuin vakiomittaisten.

Väitän marginaalisia esimerkkejä marginaalisiksi. Esim. jos voisit käyttää esimerkkinä tuota normaalia ”korvaa n-mittainen teksti m-mittaisella”, niin tuo olisi kaikkea muuta kuin marginaalinen. Kerta tuo on erittäin yleinen operaatio, toisin kuin jonkun yksittäisen merkin muuttaminen puhtaasti indeksipohjaisella random accessillä.

Vaihtuvapituiset merkit kyllä aiheuttavat vaivaa joissakin tapauksissa. Mutta silti se vaiva on pientä verrattuna siihen vaivaan, mitä nuo 8-bittiset merkistöt aiheuttavat. Jonka takia niistä onkin lähes täysin luovuttu.

 

[pulatunnus]

Siinä voi olla esim. kenttä, johon merkitään kuka toi lapsen hoitoon: 'I'=isä, 'Ä'=äiti, 'M'=muu.

Esimerkki saa mielikuvituksen laukkaan, on toki mahdollista että on jokin teksti massa missä on tuollainen kohta, joka sitten pitää etsiä ja korvata. joku tietokannan kenttä, johon tallennettu yksi merkki, valittu suomenkielestä (*, josta mielikuvitus vei ajatukset Suomeen ja jonkun päivähoitopaikan tietokantaan. Vaikka kuvitellaan että kyse olisi pienestä yhden toimipaikan yksityisestä päiväkodista, niin voisi kuvitella että keräävät myös niiden lasta noutavien nimetkin. Vaikka koodari oli päiväkodin omaa tuotosta, niin ehkä ei kannata tuossa ampua heti jalkaan.

Jos ohjelman/palvelun tekee joku ulkopuolinen oikea toimia, niin usein joku miettii että tämänhän voisi myydä muuallekkin (Suomeen), vaikka asiakas inttäisi että heillä vain suomenkielisiä lapsia ja vanhempia joilla perinteiset suomenkieliset nimet. No ehkä merkistövaatimus konsti estää saman ohjelman myynti muille.



(*
Ehkä tässä yhden kohdan esimerkissä kannattaisi käyttää ASCII merkkejä jos merkkiä pitää käyttää, mutta niitä jonain muuna käsitellä, niin minimoi merkistö ongelmat.

 

[love_doctor]

Miksi kiinteämittainen? Tehokkuus ja yksinkertaisuus.

Minkä tehokkuus? Listasit tasan yhden esimerkin joka oli merkkijonon indeksointi. Jos mietit jonkun tietotyypin tehokkuutta, pitäisi tarkastella kaikkia sillä tehtäviä operaatioita ja käyttötapausta. Esim. jos googlaan 'most common string operations', saan listan 'Common examples include case conversion, comparison, concatenation, find, join, length, reverse, split, substring, and trim.'.

Jos katsotaan tätä listaa:

- case-muunnos on O(n) merkki kerrallaan tehtävä ja käy koko jonon joka tapauksessa eli ei eroa. Senkin voi O(0)-optimoida tapauskohtaisesti jos merkkijono pitäisi kirjaa kirjainkoosta.
- leksikografinen vertailu käy O(n)-ajassa myös jonoa alusta kunnes löytyy eroava merkki eli ei eroa. Tässäkin jos nopeus on tärkeää, järjestyksen säilyttävän tietorakenteen käyttö hyödyttää.
- konkatenoinnin tehokkain rakenne/algoritmi on O(1)-aikainen. O(n)-ajassa taulukoilla kopiointi on suoraviivainen ja tehokkuusero tulee enemmän muistiallokaattorista kuin koodaustavasta
- oletetaan rakenteeksi taulukko eikä esim. trie, niin hakukin etsii alijonoa alusta asti kummassakin tapauksessa eli ei eroa
- yhdistäminen erotinmerkillä tai ilman on myös rope-rakenteella tehokkain tai jos taulukoilla tekee, käydään läpi kaikki pääteosat ja tarvittaessa allokoidaan koko taulukko tai kuoletetulla kustannuksella tehokkaasti ihan vastaavasti.
- pituuden laskentaan on O(1)-algoritmi jos rakenne säilyttää tiedon pituudesta kuten Pascal
- Kääntäminen on näistä eka, missä on emojien ja muiden yhdistelmämerkkien takia hiukan haastetta, mutta kompleksisuus ei siitäkään kokonaisuudessaan muutu O(n)-ajasta utf8:lla
- paloittelu merkin mukaan on ihan vastaava O(n)-aikainen operaatio. Paloittelu kiinteämittaisiin paloihin on nopeampi vakiolevyisellä merkkijonolla, mutta kuulostaa melko harvinaiselta operaatiolta ylipäänsä (?)
- alimerkkijonojen etsinsä voi olla tehokkaampi, mutta toisaalta tässäkin utf8 ja COW-rakenne roskienkeruulla voi olla tehokkaampi kuin alkeellinen C-ohjelma
- trimmaus on myös varsin suoraviivainen O(n)-algoritmi ja jälleen range/COW-toteutus isompi optimointi kuin mitä utf8 tuo haittaa

Listasta nähdään, että vain pari operaatiota ylipäänsä hyötyy kiinteämittaisista merkeistä. Mietin alimerkkijonojen tapausta, miten siinä saat operaatiota edeltävät indeksit? Tulevatko ne jonkin hakufunktion tuloksena? Silloin se haku voisi palauttaa utf8:n tapauksessa jo alimerkkijonon ja ainakin toisen pään indeksoinnin voisi välttää.

Ja kuten aiemmin sanoin, ylipäänsä jos merkkijonojen käytössä päästäisiin eroon toteutuskeskeisyydestä ja käsiteltäisiin niitä APIn läpi, niin kaikenlaiset puskuriylivuoto-ongelmat vähenisivät. Indeksointi ja puskurihaavoittuvuudet ovat yksi yleisimmistä bugien lähteistä, jos katotaan CVE-tietokantoja. Myös paikallaan muutettavat rakenteet ovat monessa kohtaa ongelmallisia, varsinkin nykyään kun käytetään säikeitä. COW/range-pohjaiset ratkaisut, ropet ja muut olisivat myös mahdollisia vaihtoehtoisina rakenteina.

Kiinteämittaisin merkistöin toteutetut merkkijonot on suoraan indeksoitavissa eikä tarvitse pureskella koko merkkijonoa läpi, jos haluaa vaikka merkkijonon 58. merkin.

Ei sitä kokonaan käydä läpi vaan alusta utf8:lla. Kysymys kuuluu, miten usein indeksoit ja mikä on sille hyväksyttävä hinta? 58. merkin hakuun tyypillisellä tekstillä menee se 58-116 iteraatiota. On myös se mahdollisuus, että jos voit pysyä ASCII-merkeissä, utf8:nkin kanssa voit tehdä sen oletuksen, että merkkien pituus ei vaihtele.

58. merkkiä voi myös muuttaa suoralla sijoituksella ilman, että pitää käyttää koodia ja aikaa siihen, että uusi merkki onkin ehkä eri mittainen kuin vanha:

Joo ja miten yleinen tämä on nykyään? Onko dataa siitä, miten paljon näitä tehdään vs format stringit?

Muista txt:lle varattu muisti, varaa tarvittaessa lisää.
Muista virheenhallinta, jos lisämuistia ei olekaan saatavilla

Jos ohjelman pointtina on tehdä tämäntyyppistä paljonkin, niin tämä algoritmi ei skaalaudu yhtään. Mieti vaikka megatavun kokoisen merkkijonon siirtelyä tavu kerrallaan. Ei mitään järkeä. Esim. tekstieditoreihin on koko joukko omia tietorakenteita, jotka eivät pohjaudu kielten sisäänrakennettuihin merkkijonotyyppeihin.

Vaihtuvamittaiset merkit rikkovat tai voivat rikkoa kiinteämittaisille koodatun, ja vieläpä ikävällä tavalla: bugaaminen ei välttämättä ilmene heti (mm. ASCII toimii), eikä bugaaminen välttämättä kaada koodia vaan rikkoo datan. Korjaaminen voi olla työlästä.

Oletko yksikkötestaamisesta sattumalta kuullut? Tai sen edistyneemmästä muodosta?

Siinä voi olla esim. kenttä, johon merkitään kuka toi lapsen hoitoon: 'I'=isä, 'Ä'=äiti, 'M'=muu.

Näihin tapauksiin kielissä on enum/variant-tyypit. Eipä siinä, tuota vanhaa paskakoodia varmaan saa lapioida vielä vuosikymmeniä työelämässä, mutta ei sitä kuulu tehdä noin. Ihan esimerkkinä - jos haluttaisiin myöhemmin kirjatakin isoäiti ja isoisä myös vaihtoehdoiksi, niille pitäisi keksiä muu kirjain kuin alkukirjain. Tai jos on valittu I=isä ja i=isoisä, niin kolmannen kohdalla jo loppuvat "järkevät" kirjaimet. No joo, ä sitten varmaan olisi isoäiti. Entäs äitipuoli, Ö? MVC on tietyissä piireissä ollut juttu jo 40-50 vuotta, mutta näissä edelleen 2020-luvulla halutaan hirttää yhteen malli ja esitysmuoto.

 

[Paapaa]

Ja miten UTF-auttaa tähän, jos UTF-renderöijä saa syötteekseen Latin9-tekstin?

Siten, että tulee jatkuvasti vähemmän eteen tilanteita, jossa syöte on jotain muuta kuin UTF-8:aa. Mitä laajemmin tuetaan UTF-8:aa, sitä vähemmän tulee eteen tilanteita jossa tarvitaan merkistökonversioita. Siksi meillä on yhtenäinen käytäntö. Siihen ollaan koko ajan pääsemässä, kun legacy jää unholaan niin sisällön kuin ohjelmien osalta. Ja ollaan onneksi merkittävissä määrin jo päästykin.

Tarpeeton UTF:n käyttö tekee tekstinkäsittelystä tehotonta.

Tällaiset mielivaltaiset yleistykset ovat tietenkin ihan puhdasta soopaa, joihin voi vastata samalla tavalla: ei tee.

Ei osaamattoman ja epäpätevän devaajan kannata syyttää uutta teknologiaa siitä, ettei osaa sitä käyttää tai ei osaa kirjoittaa kulloiseenkin tarpeeseen tarpeeksi tehokasta koodia - tai toimivaa koodia. Tai yrittää itse tehdä jotain jonka standardikirjasto tekee 100x paremmin ja nopeammin ja virheettömästi. Tai kuvitella tehokkuuseroja sinne missä niitä ei ole. UTF-8-enkoodauksesta se tehokkuus ei ole kiinni käytännössä juuri missään. Todelliset pullonkaulat ovat ihan muualla. Ei ole sattumaa eikä salaliitto, että UTF-8 on de facto standardi niin monessa paikassa, eikä jostain käsittämättömästä syystä fanittamasi Latin-9. Tämä juna meni jo. Kannattaa hissukseen alkaa tutustua Unicodeen ja UTF-8:aan, ei niiden käyttö ole oikeasti vaikeaa.

 

[love_doctor]

Siten, että tulee jatkuvasti vähemmän eteen tilanteita, jossa syöte on jotain muuta kuin UTF-8:aa. Mitä laajemmin tuetaan UTF-8:aa, sitä vähemmän tulee eteen tilanteita jossa tarvitaan merkistökonversioita. Siksi meillä on yhtenäinen käytäntö. Siihen ollaan koko ajan pääsemässä, kun legacy jää unholaan niin sisällön kuin ohjelmien osalta. Ja ollaan onneksi merkittävissä määrin jo päästykin.

Tähän vielä tarkennuksena, niin jos renderöijällä tarkoitetaan jotain GUI-kirjastoa tässä, se on ihan ehdoton ohjelmointivirhe että tarjotaan 8-bittistä merkistöä sinne jos sen API odottaa Unicodea. Ei sen virheen pitäisi tulla tässä kohtaa. Sitten taas jos käyttäjä copypasteaa leikepöydältä jotain moskaa, se on puolestaan GUI-kirjaston vastuulla eli ei sovelluskoodarin ongelma.

Tuntemattomalla tai epäyhteensopivalla tavalla koodattu syöte voi tulla verkon yli tai tiedostosta, mutta se pitäisi lukea näistä samalla logiikalla kuin miten syöte sanitoidaan muutenkin vaikka netin yli luettaessa. SQL-kysely sanitoidaan Bobby Tables -ongelmien varalta ja syötteen Unicode-validius tarkistetaan ihan vastaavasti. Tätä voi tehostaa koodaamalla tekstin eri tietotyyppiin. Esim. Javassa on byte[] legacy-tekstiä varten ja String Unicodelle. String:lle on konstruktori, jolla voidaan kuvata tavutaulukon enkoodaus. Tämä funktio on ollut saatavilla nyt kuukauden päästä jo 18 vuotta. Sieltä dokumentaatiosta lukee miten käy, jos syöte ei ole validia:

"This method always replaces malformed-input and unmappable-character sequences with this charset's default replacement string. The CharsetDecoder class should be used when more control over the decoding process is required."

Ainut ongelma mitä itselle on näidenkin kanssa tullut viime vuosina on se tilanne, kun on tehnyt kevyen Docker imagen ja unohtanut alustaa sinne localet. Javan jlink-toiminto myös jättää oletuksena localet pois Javan puolelta, jos ei huomaa importata tätä moduulia. Nämä kun muistaa, niin mitään ongelmia ei tule.

 

[takomo]

Ei pelkkä O(n^y) yksin kerro nopeutta vaan olennainen merkitys on sillä miten monimutkainen on yksi alkeisoperaatio. Kun tekstiä käsitellään, eri prosessien O-vaikeus on tietenkin sama merkistöstä riippumatta. Vaikuttaa siltä, että tässä on vähän hakusessa se, *miten* tehokasta 8-bittisen merkistön käsittely todella voi olla.

Jos katsotaan tätä listaa:

- case-muunnos on O(n) merkki kerrallaan tehtävä ja käy koko jonon joka tapauksessa eli ei eroa. Senkin voi O(0)-optimoida tapauskohtaisesti jos merkkijono pitäisi kirjaa kirjainkoosta.

ASCII:lle case-muunnos on yksinkertaisimmillaan OR 0x20 tai AND 0xDF, mikä riittää esim. case-epäherkän haun toteuttamiseen. 32 bit kerrallaan operoidessa OR 0x20202020 tai AND 0xDFDFDFDF, millä flipataan joka merkistä yksi bitti suuntaan tai toiseen, yhden kellojakson operaatiolla. Tämä toimii varsin hyvin myös ISO Latin-merkistölle. Vähän enemmän nypläystä tarvitaan, jos tuloksen pitää olla esityskelpoinen.

Kuinka toimii UTF:lle?

- leksikografinen vertailu käy O(n)-ajassa myös jonoa alusta kunnes löytyy eroava merkki eli ei eroa. Tässäkin jos nopeus on tärkeää, järjestyksen säilyttävän tietorakenteen käyttö hyödyttää.

Pelkkä koodivertailu on helppoa mutta yleisesti vertailua helpottaisi suuresti se, että yhdelle merkille olisi yleisesti vain yksi esitystapa. Esim. täällä näyttää olevan n. 10 erilaista välilyöntiä:

General Punctuation - Wikipedia

en.wikipedia.org

Vaikka katsottaisiin vain yhtä merkin esitystä, merkkien eron havaitseminen on UTF:lla vaikeampaa. 16-bit merkin 1. tavu sisältää vain 2 merkitsevää bittiä sivulta, joten kaikkien "Latin1 Supplement"-kirjainten 1. tavu on sama. Tulee paljon alkavia osumia.

Kuka tämänkin on koodannut? Jo se, että tavut olisivat käänteisessä järjestyksessä, parantaisi tehokkuutta.

- konkatenoinnin tehokkain rakenne/algoritmi on O(1)-aikainen. O(n)-ajassa taulukoilla kopiointi on suoraviivainen ja tehokkuusero tulee enemmän muistiallokaattorista kuin koodaustavasta

Melkoinen overhead tulee siitä, että ensin rakennetaan merkkijonosta tietorakenne, jotta voidaan tehtä O(1)-operaatio ja uudestaan, kun rakenne puretaan merkkijonoksi. Yhtä riviä tuskin kannattaa purkaa tietorakenteeksi mutta riveistä tai kappaleista ehkä kannattaakin tehdä jokin rakenne.

Kopioinnissa ei tule suurta eroa paitsi tietenkin siitä, että kopioitavaa dataa on enemmän. UTF8:lla joudutaan helpommin varaamaan lisätilaa tai tilaa on aina varattava reilusti. Välimuisti, muistikaista,...

- oletetaan rakenteeksi taulukko eikä esim. trie, niin hakukin etsii alijonoa alusta asti kummassakin tapauksessa eli ei eroa

Jos etsitään vain tietokoneen mielestä identtisiä symboleita, niin näin - paitsi muistin osalta.

UTF8:lla menee hankalaksi, jos halutaan case-epäherkkä haku. Vielä hankalammaksi menee, jos halutaan, että hakusanalla "irina" löytyy myös nimi "Ирина" tai samoin mikä tahansa muu "oikein" kirjoitettu ei-latinalainen nimi. On tuolla muitakin ylläreitä kuten °C vai ℃ tai peräti K vai K.

- yhdistäminen erotinmerkillä tai ilman on myös rope-rakenteella tehokkain tai jos taulukoilla tekee, käydään läpi kaikki pääteosat ja tarvittaessa allokoidaan koko taulukko tai kuoletetulla kustannuksella tehokkaasti ihan vastaavasti.

Taulukkoon tai muistiblokkiin verrattuna kaikki rakenteet aiheuttavat omat kustannuksensa. Taas tulee UTF8:lle lisätaakkaa tehottomasta koodauksesta. Toki on niin, että blokin kopiointi onnistuu hyvinkin tehokkaasti.

- pituuden laskentaan on O(1)-algoritmi jos rakenne säilyttää tiedon pituudesta kuten Pascal

Tämä ei ole merkistöriippuvainen asia. NUL-päätteisissä merkkijonoissa on heikkoutensa.

Ei tieto merkkijonon pituudesta ihan itsestään muodostu vaan kyllä se on jossain vaiheessa laskettava, ja lasku on taas triviaali 8-bittisillä merkeillä mutta aikaa ja tupakkia palaa UTF8:n kanssa. UTF8:llä pituus ei edes ole yksikäsitteinen: pituus tavuina vs. pituus merkkeinä. Hinta silläkin on, jos pidetään yllä pituustietoa, jota ei tarvita.

- Kääntäminen on näistä eka, missä on emojien ja muiden yhdistelmämerkkien takia hiukan haastetta, mutta kompleksisuus ei siitäkään kokonaisuudessaan muutu O(n)-ajasta utf8:lla

Niinpä, UTF8 käyttää yhden merkin nypläämiseen enemmän aikaa.

8-bittisillä voi ehkä hyödyntää assemblerin little/big-endian muunnoksiin tarkoitettua BSWAP-käskyä. Yhdellä käskyllä kääntyy 4/8 merkkiä, yhden kellojakson latenssilla. Joutuisaa.

BSWAP — Byte Swap

- paloittelu merkin mukaan on ihan vastaava O(n)-aikainen operaatio. Paloittelu kiinteämittaisiin paloihin on nopeampi vakiolevyisellä merkkijonolla, mutta kuulostaa melko harvinaiselta operaatiolta ylipäänsä (?)

Voi tulla esiin, esim. FORTRANin kiinteäformaattisia tuloksia parsiessa. Taas on 8-bit-koodi tehokkaampi kuin yksittäisiä merkkejä analysoiva UTF8-koodi.

- alimerkkijonojen etsinsä voi olla tehokkaampi, mutta toisaalta tässäkin utf8 ja COW-rakenne roskienkeruulla voi olla tehokkaampi kuin alkeellinen C-ohjelma

Eli etsitään vaikka riviltä sanaa "ERROR". Tämä on asia, jonka on toimittava tehokkaasti esim. tutkiessa tulostiedostoja, jotka voi helposti olla isoja. Väittäisinpä, että käsiteltäessä yhtä riviä kerrallaan ei maksa vaivaa muodostaa siitä tietorakennetta.

Alkeellinenkin C-ohjelma voi käyttää 8-bittistä kirjastoa, joka pulauttaa koodiin tehokkaan inline-assembler-pätkän.

- trimmaus on myös varsin suoraviivainen O(n)-algoritmi ja jälleen range/COW-toteutus isompi optimointi kuin mitä utf8 tuo haittaa

Listasta nähdään, että vain pari operaatiota ylipäänsä hyötyy kiinteämittaisista merkeistä. Mietin alimerkkijonojen tapausta, miten siinä saat operaatiota edeltävät indeksit? Tulevatko ne jonkin hakufunktion tuloksena? Silloin se haku voisi palauttaa utf8:n tapauksessa jo alimerkkijonon ja ainakin toisen pään indeksoinnin voisi välttää.

Kun minusta lista näyttää siltä, että parhaimmillaan UTF8 olisi likimain tasoissa ja häviäisi vain tehottomamman koodauksen vuoksi mutta kaikissa tilanteissa, missä UTF8 edellyttää mitä tahansa merkkikohtaista nypläystä, 8-bittinen koodi vie UTF8:aa kuin litran mittaa. 64-bittisellä prosessorilla 8-bittistä tekstiä prosessoidaan jopa 8 merkkiä per prosessorin kellojakso.

Joitakin operaatioita on vaikeaa tehdä ollenkaan hyvin, kun sama asia voidaan ilmaista UTF-8:lla usealla eri tavalla. Hyvä koodaus ei anna samalle merkitykselle useita eri koodeja. Ei tietokone ymmärrä merkityksiä, se tulkkaa vain koodeja.

Ja kuten aiemmin sanoin, ylipäänsä jos merkkijonojen käytössä päästäisiin eroon toteutuskeskeisyydestä ja käsiteltäisiin niitä APIn läpi, niin kaikenlaiset puskuriylivuoto-ongelmat vähenisivät. Indeksointi ja puskurihaavoittuvuudet ovat yksi yleisimmistä bugien lähteistä, jos katotaan CVE-tietokantoja. Myös paikallaan muutettavat rakenteet ovat monessa kohtaa ongelmallisia, varsinkin nykyään kun käytetään säikeitä. COW/range-pohjaiset ratkaisut, ropet ja muut olisivat myös mahdollisia vaihtoehtoisina rakenteina.

Että ihan API pitäisi olla merkkijonoille Unicode-maailmassa. Säikeetkään eivät ole ihan ilmaisia. Eikö kontekstinvaihto vie kuitenkin satoja ellei tuhansia kellojaksoja?

Ei sitä kokonaan käydä läpi vaan alusta utf8:lla. Kysymys kuuluu, miten usein indeksoit ja mikä on sille hyväksyttävä hinta? 58. merkin hakuun tyypillisellä tekstillä menee se 58-116 iteraatiota. On myös se mahdollisuus, että jos voit pysyä ASCII-merkeissä, utf8:nkin kanssa voit tehdä sen oletuksen, että merkkien pituus ei vaihtele.

8-bit koodistolla indeksin osoitus on parin-kolmen kellojakson muistihaku. Tekstimuotoisia tulostiedostoja parsiessa lähtökohtana on yleensä se, että tietty data löytyy tietyistä sarakkeista. Näissä on se hyvä puoli, että ne on helposti luettavissa koneellisesti mutta myös ihmisen luettavissa.

Ehdotus ratkaista UTF-8:n ongelmat olettamalla 70-luku onkin nerokas ehdotus. Eipä silti, tähän se käytännössä varmaan menee. Sitten tulee lokinsiipiä.

Jos ohjelman pointtina on tehdä tämäntyyppistä paljonkin, niin tämä algoritmi ei skaalaudu yhtään. Mieti vaikka megatavun kokoisen merkkijonon siirtelyä tavu kerrallaan. Ei mitään järkeä.

On tietenkin selvää, että isojen tietomassojen käsittelyyn tarvitaan kunnolliset tietorakenteet. Tässä vaan helposti lähtee laukalle. Jos gigatavun tekstitiedosto skannataan läpi, se on pienten tietomäärien käsittelyä mutta toistoja tulee melko lailla paljon.

Näihin tapauksiin kielissä on enum/variant-tyypit.

Nämä on luettavia koodarille mutta enumeita on paha tulostaa käyttäjälle.

Tai jos on valittu I=isä ja i=isoisä, niin kolmannen kohdalla jo loppuvat "järkevät" kirjaimet.

Nyt löytyi käyttöä Unicodelle! Sieltä löytyy varmasti lisää I-kirjamia.

 

[JCSH]

Nämä on luettavia koodarille mutta enumeita on paha tulostaa käyttäjälle.

Nyt kyllä ylitetään parodiahorisontti.
Tuohan on kielestä riippuen joko erittäin helppoa tai naurettavan helppoa.

 

[JCSH]

Vielä hankalammaksi menee, jos halutaan, että hakusanalla "irina" löytyy myös nimi "Ирина" tai samoin mikä tahansa muu "oikein" kirjoitettu ei-latinalainen nimi. On tuolla muitakin ylläreitä kuten °C vai ℃ tai peräti K vai K.

Ирина, tai kuten 8-bittisessä maailmassa hänet tunnetaan Èðèíà
Vai tarkoititko kenties žàØÝÐ ?

 

[love_doctor]

Ei pelkkä O(n^y) yksin kerro nopeutta vaan olennainen merkitys on sillä miten monimutkainen on yksi alkeisoperaatio. Kun tekstiä käsitellään, eri prosessien O-vaikeus on tietenkin sama merkistöstä riippumatta. Vaikuttaa siltä, että tässä on vähän hakusessa se, *miten* tehokasta 8-bittisen merkistön käsittely todella voi olla.

Jos oikeasti olet huolissasi tekstin prosessoinnin nopeudesta isoilla massoilla, kyllä kompleksisuusluokat siinä korostuvat. Toki sekin on ongelma, jos yksittäisiin operaatioihin ei voida hyödyntää tehokkaita bittitason optimointeja, mutta se että jokin operaatio on vaikka tuplasti hitaampi vakiokertoimella on vain parin vuoden takaisku tekniikan kehityksessä. Sivuutat nyt kokonaan sen, miten iso hinta sille tulee kun vaihdellaan eri merkistöjen välillä. Tämä vertailu on älyttömän epäreilu kun toisen koodauksen kanssa siihen sisältyy kaikki työ ja toisen kanssa ei. Esim. Windows NT -pohjaisissa on wide-koodaus ollut APIssa oletus jo 30+ vuotta. "Ulkomaailman" kanssa kommunikointi tod.näk. vaatii muunnoksia. Tosi moni API ja alusta on myös vaihtanut nyt Unicoden oletukseksi, eikä yksittäinen koodari oikein voi vaikuttaa asiaan. Tilanne olikin varsin erilainen sanotaan vaikka 20 vuotta sitten.

Legacy-koodeissa isoja ongelmia tulee jo ihan siitä, että niissä merkkijonojen varauksiin voi olla keinotekoisia rajoja kuten esim. 64 kilon segmentit ja toisaalta nollaloppuisten merkkijonojen kanssa osa operaatioista kestää paljon kauemmin. Esim. jos C:n sijaan Pascal olisi yleistynyt valtakielenä, moni merkkijono-operaatio saattaisi nyt olla tehokkaampi ja vähemmän bugiherkkä. Myös kun nykyään koodataan pääasiassa korkean tason kielillä, merkkijonojen käytössäkin tulisi hyödyntää automaattista muistinkäsittelyä. Se mahdollistaa ihan eri tavalla dynaamisten tietorakenteiden käytön. Varmasti sellaisiakin erikoisalueita vielä on, jossa tehokkuussyistä voi kannattaa tehdä jokin backend C/C++:lla ja 8-bittisillä merkistöillä. Ongelma sitten vaan, jos tämän frontendinä on joku Unicodea tukeva systeemi, miten diilataan kun käyttäjiltä tulee erikoisia merkkejä. Jos vaikka tämän foorumin tilannettakin miettii.

ASCII:lle case-muunnos on yksinkertaisimmillaan OR 0x20 tai AND 0xDF, mikä riittää esim. case-epäherkän haun toteuttamiseen. 32 bit kerrallaan operoidessa OR 0x20202020 tai AND 0xDFDFDFDF, millä flipataan joka merkistä yksi bitti suuntaan tai toiseen, yhden kellojakson operaatiolla. Tämä toimii varsin hyvin myös ISO Latin-merkistölle. Vähän enemmän nypläystä tarvitaan, jos tuloksen pitää olla esityskelpoinen.

Kuinka toimii UTF:lle?

Tästähän oli jo juttua, että ASCII-merkkien osalta UTF-8 ei eroa. Jos pystyt ennakkoon takaamaan että merkkijono on ASCIIta, voit käyttää samoja algoritmeja. Tuo bittikikka vaatii aina parikseen merkkivälien tarkistuksen. On se tavallaan ihan näppärä, mutta en osaa sanoa, miten hyvin skaalautuu useamman merkin vektorioperaatioihin. Nuo välit ovat vielä hankalan pituisiakin. Esim. saksalainen ß ei muunnu merkiksi 0xFF. 8-bittisistäkin tuo toimii laajennettujen merkkien osalta vain niihin merkistöihin, joissa ääkköset ovat latin1:n tavoin "riveissä". 437, 850 jne. eivät hyödy.

Pelkkä koodivertailu on helppoa mutta yleisesti vertailua helpottaisi suuresti se, että yhdelle merkille olisi yleisesti vain yksi esitystapa. Esim. täällä näyttää olevan n. 10 erilaista välilyöntiä:

General Punctuation - Wikipedia

en.wikipedia.org

8-bittisillä merkistöillä voi vastaavasti olla 2-3 eri tyhjän näköistä merkkiä (0x00, 0x20 ja 0xFF - win-1252:ssa tuo on 0xA0). Typografialla on hintansa. Toisaalta näiden mäppäys APIssa ei ole mikään ongelma. Tässäkin on jälleen se, että se että merkistö mahdollistaa jotain ei tarkoita sitä, että sitä olisi pakko käyttää. Voit tehdä vaikka iobbs:n tyylistä foorumisoftaa sillä oletuksella, että erikoisempien Unicode-merkkien printtaus veisi vaikka minuutinkin per merkki. Silti mitään tästä ei seuraa, koska jotain typografian helmiä ei nähdä nettikeskustelussa, kun kaksi suomituraania hakkaa suominäppistä kahdella etusormella ilman tarvetta erikoismerkeille.

Kun minusta lista näyttää siltä, että parhaimmillaan UTF8 olisi likimain tasoissa ja häviäisi vain tehottomamman koodauksen vuoksi mutta kaikissa tilanteissa, missä UTF8 edellyttää mitä tahansa merkkikohtaista nypläystä, 8-bittinen koodi vie UTF8:aa kuin litran mittaa. 64-bittisellä prosessorilla 8-bittistä tekstiä prosessoidaan jopa 8 merkkiä per prosessorin kellojakso.

Koko pointtihan on, että UTF-8 pystyy tarjoamaan paljon enemmän typografisia ominaisuuksia ja merkistöjä lähes samalla kustannuksella. Se vasta mainiota olisikin, jos se olisi samalla tehokkaampi. Se että sillä on pieni hinta on ihan odotettu lopputulema. Minusta Unicodea on ihan validia kritisoida siitä, onko se hyvin suunniteltu universaali merkistö. Osa kritiikistä tuntuu olevan vaan sitä, että asioita ei saa muuttaa kun joskus keksittiin hyvä koodaus. 8-bittisistä DOS-ajan merkistöistäkin menee paljon (=neljäsosa) tilaa "hukkaan" sellaisiin merkkeihin, joita ei ole tarkoitus tulostaa ja vielä osa sellaisiin puoligraafisiin, joita ei enää ole tarkoitus käyttää. Jos asiaa miettii näin päin, nämä vanhat merkistöt ovat paljon huonompia tilankäyttönsä kannalta. Erilaiset kontrollimerkit olisi voinut kaikki piilottaa jonkun yksinkertaisen escape-merkinnän taakse eikä tuhlata 64 eri merkkipaikkaa niihin.

 

[takomo]

Jos oikeasti olet huolissasi tekstin prosessoinnin nopeudesta isoilla massoilla, kyllä kompleksisuusluokat siinä korostuvat.

Kompleksisuusluokilla on merkitystä silloin, kun käsitellään suuria tietomassoja. Ei silloin, kun käsitellään pieniä määriä dataa kerrallaan, vaikka toistoja olisi paljonkin. Jos pitää lukea miljoonan rivin dokumentti muistiin ja käsitellä sitä kokonaisuutena -> tietorakenteilla on väliä. Jos dokumentti käsitellään rivi kerrallaan, ratkaisee vain yhden rivin käsittelynopeus. Tuskin kannattaa tehdä mitään indeksoitavaa taulukkoa monimutkaisempaa.

Toki sekin on ongelma, jos yksittäisiin operaatioihin ei voida hyödyntää tehokkaita bittitason optimointeja, mutta se että jokin operaatio on vaikka tuplasti hitaampi vakiokertoimella on vain parin vuoden takaisku tekniikan kehityksessä.

Kun se ero ei ole tekijä 2 vaan äkkiä ainakin 100, jos verrataan tehokasta bittioperaatiota API-funktiokutsuun. Mooren lakikaan ei ole ollut viime vuosina voimissaan.

Sivuutat nyt kokonaan sen, miten iso hinta sille tulee kun vaihdellaan eri merkistöjen välillä. Tämä vertailu on älyttömän epäreilu kun toisen koodauksen kanssa siihen sisältyy kaikki työ ja toisen kanssa ei.

Ei tule mitään hintaa merkistöjen vaihtelulle sellaisissa sovelluksissa, joissa sille ei ole tarvetta. Tähän kuuluu sovellukset, joissa pärjätään pelkällä ASCII:lla tai Latin1:llä tai muulla kertavalinnalla. Sen sijaan UTF8:lle tulee hintaa, kun juuri mitään ei voi tehdä tehokkaasti ja legacy-koodit särkyy.

Esim. Windows NT -pohjaisissa on wide-koodaus ollut APIssa oletus jo 30+ vuotta.

Vakiolevyinen 16-bittinen koodaus onkin hyvä vaihtoehto tilanteisiin, joissa aidosti tarvitaan kansainvälistä merkistöä. Mikä UTF-16:ssa oikein on vikana? Miksi se ei käy vaan pitää pakolla tuputtaa aivokuollutta UTF-8:a? Toki myös UTF-16 pitäisi järkeistää yksikäsitteiseksi.

Legacy-koodeissa isoja ongelmia tulee jo ihan siitä, että niissä merkkijonojen varauksiin voi olla keinotekoisia rajoja kuten esim. 64 kilon segmentit ja toisaalta nollaloppuisten merkkijonojen kanssa osa operaatioista kestää paljon kauemmin.

Ensinnäkin harvemmin on tarvetta yli 64k merkkijonoille ja toiseksi tämä koskee vain Intelin 8086-ajan ohjelmistoja. Tässä puhutaan DOS-legacystä. Jo i386 tuki 32-bittisiä segmenttejä tai lineaarista 32-bit muistia.

Onkin hyvä kysymys kestääkö nollaloppuisten merkkijonojen käsittely kauemmin ja jos, niin milloin. Esim. osaako CPU rinnakkaistaa alimerkkijonon haussa NUL-vertailun ja data-vertailun:
.
cmp bh,00h ;rbx=data
je loppu
cmp bx,dx ;dx=haku
je osuma_1
shr rbx,8 ;seuraava tavu
.
.
Jos ei, niin tuossa menetetään ehkä 0,5 ns/merkki 4 GHz-prosessorilla.

Tästähän oli jo juttua, että ASCII-merkkien osalta UTF-8 ei eroa. Jos pystyt ennakkoon takaamaan että merkkijono on ASCIIta, voit käyttää samoja algoritmeja.

Siitähän kenkä puristaakin, että tätä on käytännössä vaikeaa taata. ASCII-koodista 8-bit Latin menee todennäköisesti ehjänä läpi, mutta jos joku kirjoittaa UTF-8-ympäristössä ohjaustiedostoon "yö" tai "päivä" tai "℃", niin on jokseenkin arvaamatonta kuinka käy. Tuloksena voi hyvinkin olla laitonta UTF-8:a ja ongelmat ilmenevät ehkä vasta tuloksia purettaessa.

8-bittisillä merkistöillä voi vastaavasti olla 2-3 eri tyhjän näköistä merkkiä (0x00, 0x20 ja 0xFF - win-1252:ssa tuo on 0xA0). Typografialla on hintansa. Toisaalta näiden mäppäys APIssa ei ole mikään ongelma.
.
Koko pointtihan on, että UTF-8 pystyy tarjoamaan paljon enemmän typografisia ominaisuuksia ja merkistöjä lähes samalla kustannuksella.

Typografian kommunikointi ei ole tietokonemerkistön asia ensinkään. Sen pitäisi välittää vain olennaisia merkityksiä ja tehdä se yksikäsitteisesti.

Ei Latin-merkistökään täydellinen ole mutta ongelmat on pieniä Unicodeen verrattuna. ASCII:ssakin voi nähdä pienen redundanttisuuden isojen ja pienten kirjainten välillä mutta se on korjattavissa yhden bitin operaatiolla.

Tässäkin on jälleen se, että se että merkistö mahdollistaa jotain ei tarkoita sitä, että sitä olisi pakko käyttää.

Tietokoneohjelmien pitäisi pudota jaloilleen riippumatta siitä, mitä käyttäjät keksivät niille syöttää. Ainakaan mikään helposti muodostettava syöte kuten ääkköset ei saisi aiheuttaa ongelmia.

 

[love_doctor]

Ensinnäkin harvemmin on tarvetta yli 64k merkkijonoille ja toiseksi tämä koskee vain Intelin 8086-ajan ohjelmistoja. Tässä puhutaan DOS-legacystä. Jo i386 tuki 32-bittisiä segmenttejä tai lineaarista 32-bit muistia.

Niinno, legacyä nuo 8-bittiset ovatkin. Itselläni on ollut järjestelmänlaajuisesti utf-8 muistaakseni Linuxissa noin 20 vuotta. 2005 vielä jossain ohjelmissa oli pientä säätämistä ja piti käyttää ihan uusimpia versioita, mutta se ei ollut Gentoolla ongelma. Sitä ennen käytössä oli muutaman vuoden Windows XP ja siinä mm. ntfs. Sitä ennen pääkäyttis olikin DOS ja Windows 95/98 jotain satunnaista käyttöä varten. Devaus pääasiassa DOS-puolella ja DOS:han oli pääosan ajasta muussa kuin suojatussa tilassa. En ymmärrä lainkaan, miksi legacy-merkistöt olisi pitänyt tuoda DOS-puolelta mukana.

Onkin hyvä kysymys kestääkö nollaloppuisten merkkijonojen käsittely kauemmin ja jos, niin milloin. Esim. osaako CPU rinnakkaistaa alimerkkijonon haussa NUL-vertailun ja data-vertailun:

Voit katsoa vaikka noita saatavilla olevia tehokkaita string-kirjastoja kuten GitHub - ashvardanian/StringZilla: Up to 10x faster strings for C, C++, Python, Rust, and Swift, leveraging NEON, AVX2, AVX-512, and SWAR to accelerate search, sort, edit distances, alignment scores, etc -- tuossahan tietotyyppiin on koodattu mukaan pituus.

 

[takomo]

Voit katsoa vaikka noita saatavilla olevia tehokkaita string-kirjastoja kuten GitHub - ashvardanian/StringZilla: Up to 10x faster strings for C, C++, Python, Rust, and Swift, leveraging NEON, AVX2, AVX-512, and SWAR to accelerate search, sort, edit distances, alignment scores, etc -- tuossahan tietotyyppiin on koodattu mukaan pituus.

Olkoonpa toteutustapa mikä hyvänsä, niin yksinkertainen merkistökoodaus on nopeampi käsitellä kuin monimutkainen. Ihan pelkästään kirjastokutsuun kuluu aikaa.

Rupesinpa tässä kokeilemaan merkkikäsittelyä C:llä:

#include<stdio.h>
#include<string.h>

const char tst[]="Merkkijono ääkkösillä";

int main(int argc, char *argv[])
{
  int k;
  printf("%s\n",tst);
  for(k=0;k<strlen(tst);k++)
    printf(".%c. ",tst[k]);
  printf("\n");
 
  return(1);
}

Ja ajo:

~/src/txt$ ./a.out 
Merkkijono ääkkösillä
.M. .e. .r. .k. .k. .i. .j. .o. .n. .o. . . .�. .�. .�. .�. .k. .k. .�. .�. .s. .i. .l. .l. .�. .�.

Näemmä UTF-virus on tarttunut emacsiin ja C-lähdekoodiin. Voi *****!

Oliko se niin, että kunhan kaikki pysyy ASCIIna, niin tämä ei haittaa? Eihän tässä sitten mitään oikeaa ongelmaa ole, varmaankaan.

 

[pulatunnus]

Olkoonpa toteutustapa mikä hyvänsä, niin yksinkertainen merkistökoodaus on nopeampi käsitellä kuin monimutkainen. Ihan pelkästään kirjastokutsuun kuluu aikaa.

Haara lähti siitä montako tavua yksimerkki voi olla, ja nimenomaan se että ei kiinteä, vaan vaihteleva.

Jos palataan siihen verottaja esimerkkiin, niin 8bit merkistössä voi olla ideaa jos käsittely vaatii paljon resursseja ja sillä ASCIIlla aidosti pärjätä.
Verottajan järjestelmissä taasen ei pärjää, ja resurssi pulaa ei ole, eikä oikein säästöäkään.

 

[takomo]

Haara lähti siitä montako tavua yksimerkki voi olla, ja nimenomaan se että ei kiinteä, vaan vaihteleva.

Jos palataan siihen verottaja esimerkkiin, niin 8bit merkistössä voi olla ideaa jos käsittely vaatii paljon resursseja ja sillä ASCIIlla aidosti pärjätä.
Verottajan järjestelmissä taasen ei pärjää, ja resurssi pulaa ei ole, eikä oikein säästöäkään.

Nimenomaan merkin vaihteleva pituus aiheuttaa tehokkuusongelman. ...tai mikäpä ongelma se on, resurssithan on rajattomat. Muuten vain Microsoft ostaa ydinvoimalan verran sähköä:

Microsoft pens deal to restart Three Mile Island reactor five years after closure - Central Penn Business Journal

Three Mile Island’s Unit One reactor may come back online as early as 2028 through a new partnership with TMI’s owners.

www.cpbj.com

"Baltimore-based energy supplier Constellation announced on Friday that it signed a 20-year power purchase agreement with Microsoft in a deal that would see TMI’s owner reopen the plant as the Crane Clean Energy Center. "

Verottaja on käsittääkseni pärjännyt ilman kohtuuttomia ongelmia 8-bittisellä merkistöllä ja sitä ennen julkishallinto on pärjännyt lokinsiipi-ASCII:lla.

Jos 8-bit ei ihan oikeasti riitä, niin miksi ei käytetä 16-bittistä UTF-16:a? Vakiolevyisiä, 16-bittisiä merkkejäkin pystyy käsittelemään tehokkaasti. mutta muistinhallintaa ne toki kuormittavat 8-bittisiä enemmän.

 

[JCSH]

Verottaja on käsittääkseni pärjännyt ilman kohtuuttomia ongelmia 8-bittisellä merkistöllä ja sitä ennen julkishallinto on pärjännyt lokinsiipi-ASCII:lla.

Se, että joskus 90-luvulla on pärjätty jollain tietyllä järjestelmällä, ei tarkoita, että se olisi enää nykypäivänä riittävä.

Verottaja on tuosta erittäin hyvä esimerkki. Joskus 90-luvulla varmaan oli ihan ok, että verottajan tietojärjestelmät olivat oma pikku kuplansa. Ei ollut mitään integraatiota muihin tietojärjestelmiin. Tai jos oli, niin se oli tyyliin pariin muuhun valtionhallinnon omaan järjestelmään.

Mutta nykyään tilanne on täysin eri. Verohallinnon tietojärjestelmien pitää toimia yhteen esimerkiksi yritysten payroll-järjestelmien ja pankkien järjestelmien kanssa. Sitten myös esimerkiksi poliisin järjestelmiin olisi hyvä integroitua. Eivät nuo rajoitu Suomen sisälle vaan esimerkiksi on tarvetta sille verojärjestelmien integraatioon EU-tasolla. Ja kuten tuossa jo pariin otteeseen olen maininnut, pelkästään EU:n sisällä tarvitaan neljä eri 8-bittistä merkistöä ihan niihin EU:n omiin kieliin.
Eli nykyaikana verottajan järjestelmät ovat todella hyvä esimerkki sellaisesta, joka todellakin tarvitsee sitä Unicodea.

Jos 8-bit ei ihan oikeasti riitä, niin miksi ei käytetä 16-bittistä UTF-16:a? Vakiolevyisiä, 16-bittisiä merkkejäkin pystyy käsittelemään tehokkaasti. mutta muistinhallintaa ne toki kuormittavat 8-bittisiä enemmän.

Tämä on tietenkin mielenkiintoinen kysymys. Tosin UTF-16 ei ole vakiolevyinen, vaan siinä merkit ovat joko 16- tai 32-bittisiä.

Mutta se, että miksi joku standardi leviää ja toinen ei, on yleensä monien asioiden summa. En tiedä onko tätä UTF-8 vs UTF-16 tapausta kartoitettu kuinka paljon, mutta jos katsotaan sitä, miten UTF-8 on käytännössä täysin vallannut internetin kun taaskin UTF-16 roikkuu mukana vielä muualla, niin veikkaisin, että syyt löytyy internetistä. Joten voi olla ihan hyvin siitä kiinni, että internetissä on tärkeämpää saada se data pakattua tiiviimmäksi ja UTF-8 tarjoaa mahdollisuuden lähettää osan tekstistä tavu per merkki kun UTF-16 vaatii vähintään 2 tavua per merkki.

 

[pulatunnus]

Se, että joskus 90-luvulla on pärjätty jollain tietyllä järjestelmällä, ei tarkoita, että se olisi enää nykypäivänä riittävä.

Verottaja on tuosta erittäin hyvä esimerkki. Joskus 90-luvulla varmaan oli ihan ok, että verottajan tietojärjestelmät olivat oma pikku kuplansa. Ei ollut mitään integraatiota muihin tietojärjestelmiin. Tai jos oli, niin se oli tyyliin pariin muuhun valtionhallinnon omaan järjestelmään.

Mutta nykyään tilanne on täysin eri. Verohallinnon tietojärjestelmien pitää toimia yhteen esimerkiksi yritysten payroll-järjestelmien ja pankkien järjestelmien kanssa. Sitten myös esimerkiksi poliisin järjestelmiin olisi hyvä integroitua. Eivät nuo rajoitu Suomen sisälle vaan esimerkiksi on tarvetta sille verojärjestelmien integraatioon EU-tasolla. Ja kuten tuossa jo pariin otteeseen olen maininnut, pelkästään EU:n sisällä tarvitaan neljä eri 8-bittistä merkistöä ihan niihin EU:n omiin kieliin.
Eli nykyaikana verottajan järjestelmät ovat todella hyvä esimerkki sellaisesta, joka todellakin tarvitsee sitä Unicodea.

Verottajan osalta voisi olettaa että sen järjestelmät tukee kotimaisten kielien merkistöjä, ja tuskin olisi pahaksi jos pohjoismaiset ja EU kielet tuettuna. ja miksi rajoittua noihin, koska siellä joudutaan myös viaraitakieliä tukemaan.

Ja kuten kirjoitit ei ole mikään kupla, lisäksi pitää toimia muiden kanssa.

 

[morkit]

Olkoonpa toteutustapa mikä hyvänsä, niin yksinkertainen merkistökoodaus on nopeampi käsitellä kuin monimutkainen. Ihan pelkästään kirjastokutsuun kuluu aikaa.

Rupesinpa tässä kokeilemaan merkkikäsittelyä C:llä:

#include<stdio.h>
#include<string.h>

const char tst[]="Merkkijono ääkkösillä";

int main(int argc, char *argv[])
{
  int k;
  printf("%s\n",tst);
  for(k=0;k<strlen(tst);k++)
    printf(".%c. ",tst[k]);
  printf("\n");
 
  return(1);
}

Ja ajo:

~/src/txt$ ./a.out
Merkkijono ääkkösillä
.M. .e. .r. .k. .k. .i. .j. .o. .n. .o. . . .�. .�. .�. .�. .k. .k. .�. .�. .s. .i. .l. .l. .�. .�.

Näemmä UTF-virus on tarttunut emacsiin ja C-lähdekoodiin. Voi *****!

Oliko se niin, että kunhan kaikki pysyy ASCIIna, niin tämä ei haittaa? Eihän tässä sitten mitään oikeaa ongelmaa ole, varmaankaan.

Tuohon voisi heittää vasta-argumenttina hieman modernimman kielen, joka tukee UTF-8 suoraan.
Esimerkiksi Rustilla tuo onnistuu suoraan:

const TST: &str = "Merkkijono ääkkösillä";

fn main() {
    println!("{}",TST);
    for character in TST.chars() {
        print!(".{character}. ");
    }
    print!("\n");
    for character in TST.bytes() {
        print!(".{character}. ");
    }
}

Ulos tulee nätisti seuraavaa:

Merkkijono ääkkösillä
.M. .e. .r. .k. .k. .i. .j. .o. .n. .o. . . .ä. .ä. .k. .k. .ö. .s. .i. .l. .l. .ä.
.77. .101. .114. .107. .107. .105. .106. .111. .110. .111. .32. .195. .164. .195. .164. .107. .107. .195. .182. .115. .105. .108. .108. .195. .164.

UTF-8 ei ole täydellinen, mutta helpottaa merkittävästi toimintaa jo monikansallisessa Suomessakin. Mikään ohjelma ei lähde vaihtamaan merkistöä vain sen takia että voitaisiin näyttää henkilöiden nimet keskeltä tekstiä oikein. Toki UTF-8:ssa on muutamia suuria ongelmia, kuten aiemmin mainittu umlauttien mahdollinen esittäminen joko yhdellä merkillä tai kahdella tavulla. Samoin samannäköiset merkit on ikäviä, koska merkistöt on kuitenkin loppujenlopuksi tarkoitettu näytettäväksi ihmisille. Tuolloin ulkonäkö on oleellinen tekijä, eikä niinkään kuuluuko merkki vaikka kreikkalaisiin merkkeihin vai onko kyseessä kertaluokkaa kuvaava merkki. Molemmat ongelmat voidaan toki ratkaista valmiilla kirjastoilla, jotka muokkaavat tekstin käyttämään yksittäistä merkkiä (samalla heikentäen hieman ohjelman tehokkuutta tarkastuksen verran). Tuon kohdalla olisi tosin paljon parempi jos tekstieditorit pakottaisivat kyseiset tapaukset yhdeksi merkiksi ja standartista poistettaisiin mahdollisuus tallentaa samalla tavalla näkyvät merkit eri tavoin.
Vaihtuvan leveyden kanssa pitää miettiä kumpi on tärkeämpää, suurimman osan ajasta merkin tarvitsema 1 tavun tila vai mahdollisuus hyppiä tekstissä haluttuun kirjaimeen 2 tavun askelissa? Kuinka usein tiedetään etukäteen monenteen merkkiin halutaan hypätä? Muokattavan merkin tai merkkijonon etsimiseen tuo ei oikeasti vaikuta, koska siinä joudutaan joka tapauksessa käymään kaikki merkit kertaalleen läpi. Yksittäisien merkkien korvauksessa tasapituisuudesta on hyötyä jonkin verran, kun voidaan korvata suoraan merkin paikalle, mutta silloin joudutaan joko käymään lähes kaksi kertaa enemmän tavuja läpi tai ollaan taas monen eri merkistön ongelmassa yhdelle tekstille. Jos korvattavana onkin millään tavalla bittitasolla eripituinen kokonaisuus, on ihan sama onko käytössä tasa- vai vaihtelevapituinen merkistö.

 

[takomo]

Se, että joskus 90-luvulla on pärjätty jollain tietyllä järjestelmällä, ei tarkoita, että se olisi enää nykypäivänä riittävä.

Verottaja on tuosta erittäin hyvä esimerkki. Joskus 90-luvulla varmaan oli ihan ok, että verottajan tietojärjestelmät olivat oma pikku kuplansa. Ei ollut mitään integraatiota muihin tietojärjestelmiin. Tai jos oli, niin se oli tyyliin pariin muuhun valtionhallinnon omaan järjestelmään.

Mutta nykyään tilanne on täysin eri. Verohallinnon tietojärjestelmien pitää toimia yhteen esimerkiksi yritysten payroll-järjestelmien ja pankkien järjestelmien kanssa.

Miten edes viitsit heittää tuollaista legendaa, ihan kuin organisaatioiden välinen tiedonsiirto olisi joku uusi juttu? Käsittääkseni OVT-protokollat määriteltiin 80-luvulla ja isojen organisaatioiden välillä data liikkui mm. X.25 pakettikytkentäisten siirtoyhteyksien yli ...tai lähetin viemällä nauhakelalla. Suomi oli näissä asioissa oikeasti edistyksellinen viime vuosituhannella. Olettaisin, että merkistöksi on riittänyt lokinsiipi-ääkköset.

Muistatko edes milloin olet saanut ensimmäisen esitäytetyn veroilmoituksen? Se ei ole mahdollista ilman, että data kulkee muutenkin kuin "pikku kuplassa".

Tämä on tietenkin mielenkiintoinen kysymys. Tosin UTF-16 ei ole vakiolevyinen, vaan siinä merkit ovat joko 16- tai 32-bittisiä.

32-bittisyys näyttää niin toteutetulta, että kaikkien ei tarvitse olla siitä tietoisia. On vain 2k-kokoinen blokki, jonka voi rinnastaa ASCII-kontrollimerkkeihin. Toki symbolien koodaukset olisi syytä tarkistaa niin, että 32-bit avaruudessa olisi lähinnä harvoin tarvittavia erikoisuuksia. Esim. kuolleet ja marginaaliset kielet sekä historialliset merkit on syytä siivota kuikkaan 16-bit-avaruudesta.

Joten voi olla ihan hyvin siitä kiinni, että internetissä on tärkeämpää saada se data pakattua tiiviimmäksi ja UTF-8 tarjoaa mahdollisuuden lähettää osan tekstistä tavu per merkki kun UTF-16 vaatii vähintään 2 tavua per merkki.

Minäpä epäilen, että UTF-8-virus on räätälöity sellaiseksi, että sen saa syötettyä järjestelmiin niin, että päällisin puolin mikään ei näytä menevän rikki ja pikaisesti testattuna kaikki näyttää toimivan kuten ennenkin. Se ei herätä välitöntä oksennusrefleksiä ja ASCII-maailmalle se on yhdentekevä. "Big deal... ei vaikuta meihin".

ASCII-maailman ulkopuolella UTF-8-virus vaikuttaa eleettömästi ja se korruptoi dataa hiljaisesti jossain taustalla. On kai jossain määrin huonoa tuuria, jos koodi kaatuu, ja harvoin datan korruptoitumisellakaan on dramaattisia vaikutuksia. Yhtäkaikki, luotettavina pidetyt koodit alkavat tehdä UTF-8-ympäristössä sattumanvaraisia virheitä.

On sitten pahasti harhaista kuvitella, että kaikki käytössä olevat koodit olisivat nykyään UTF-8 yhteensopivia. Satuinpa vilkaisemaan NIST:n FDS-palosimulaatio-koodia: FDS-SMV
Se on 2000-luvulla kehitetty, Fortranilla toteutettu koodi, joka mallintaa erilaisia tulipaloprosesseja. Sitä voi ajaa yhdellä prosessorilla mutta myös tuhansien ytimien klustereilla. Kehittäjä ei ole nakkikiska, eikä koodi ole mikään opiskelijan harjoitustyö. Tästä huolimatta, User's Guide, April 8, 2024: "Make sure there are no non-ASCII characters being used, as can sometimes happen when text is cut and pasted from other applications or word-processing software".

Jos toimitaan UTF-8-ympäristössä, on jokseenkin vaikeaa varmistua siitä, että 8-bit-koodit eivät koskaan näe UTF-8-merkkejä mitään kautta.

 

[JCSH]

Miten edes viitsit heittää tuollaista legendaa, ihan kuin organisaatioiden välinen tiedonsiirto olisi joku uusi juttu? Käsittääkseni OVT-protokollat määriteltiin 80-luvulla ja isojen organisaatioiden välillä data liikkui mm. X.25 pakettikytkentäisten siirtoyhteyksien yli ...tai lähetin viemällä nauhakelalla. Suomi oli näissä asioissa oikeasti edistyksellinen viime vuosituhannella. Olettaisin, että merkistöksi on riittänyt lokinsiipi-ääkköset.

Muistatko edes milloin olet saanut ensimmäisen esitäytetyn veroilmoituksen? Se ei ole mahdollista ilman, että data kulkee muutenkin kuin "pikku kuplassa".

Pointtina ei ole se, että se tiedonsiirto olisi muka uusi juttu. Pointtina on se, että sille tiedonsiirrolle on tullut uusia vaatimuksia sitä mukaa kun niiden tietojärjestelmien käyttö laajenee.
Toistan nyt ties kuinka monennen kerran:
Pelkästään EU:n sisällä tarvitaan 4 eri 8-bittistä legacymerkistöä. Tai siis tarvittaisin, jos ei olisi sitä Unicodea. Mutta koska se Unicode löytyy, niin sitä käytetään, ja sillä vältetään kaikki ne ongelmat, mitä monien eri 8-bittisten merkistöjen sekakäytöstä tuli aiemmin. Eli verottajankin softat ovat hyvä esimerkki paikasta, jossa sille Unicodelle on nykyaikana oikeasti tarvetta.

32-bittisyys näyttää niin toteutetulta, että kaikkien ei tarvitse olla siitä tietoisia. On vain 2k-kokoinen blokki, jonka voi rinnastaa ASCII-kontrollimerkkeihin. Toki symbolien koodaukset olisi syytä tarkistaa niin, että 32-bit avaruudessa olisi lähinnä harvoin tarvittavia erikoisuuksia. Esim. kuolleet ja marginaaliset kielet sekä historialliset merkit on syytä siivota kuikkaan 16-bit-avaruudesta.

Jos parsit UTF-16 sisältöä, niin tottakai sun pitää olla tietoinen siitä 32-bittisyydestä. Ne voivat olla harvinaisia, mutta niitä on silti siellä. Jos et huomioi niitä sun UTF-16 parserissa, niin se on silloin rikkinäinen komponentti.

Minäpä epäilen, että UTF-8-virus on räätälöity sellaiseksi, että sen saa syötettyä järjestelmiin niin, että päällisin puolin mikään ei näytä menevän rikki ja pikaisesti testattuna kaikki näyttää toimivan kuten ennenkin. Se ei herätä välitöntä oksennusrefleksiä ja ASCII-maailmalle se on yhdentekevä. "Big deal... ei vaikuta meihin".

ASCII-maailman ulkopuolella UTF-8-virus vaikuttaa eleettömästi ja se korruptoi dataa hiljaisesti jossain taustalla. On kai jossain määrin huonoa tuuria, jos koodi kaatuu, ja harvoin datan korruptoitumisellakaan on dramaattisia vaikutuksia. Yhtäkaikki, luotettavina pidetyt koodit alkavat tehdä UTF-8-ympäristössä sattumanvaraisia virheitä.

On sitten pahasti harhaista kuvitella, että kaikki käytössä olevat koodit olisivat nykyään UTF-8 yhteensopivia. Satuinpa vilkaisemaan NIST:n FDS-palosimulaatio-koodia: FDS-SMV
Se on 2000-luvulla kehitetty, Fortranilla toteutettu koodi, joka mallintaa erilaisia tulipaloprosesseja. Sitä voi ajaa yhdellä prosessorilla mutta myös tuhansien ytimien klustereilla. Kehittäjä ei ole nakkikiska, eikä koodi ole mikään opiskelijan harjoitustyö. Tästä huolimatta, User's Guide, April 8, 2024: "Make sure there are no non-ASCII characters being used, as can sometimes happen when text is cut and pasted from other applications or word-processing software".

Jos toimitaan UTF-8-ympäristössä, on jokseenkin vaikeaa varmistua siitä, että 8-bit-koodit eivät koskaan näe UTF-8-merkkejä mitään kautta.

Tuo puhe "UTF-8 viruksesta" alkaa kyllä jo kuulostamaan pahasti foliohattuilulta. Lisäksi tuo kuulostaa siltä, että kerta koko maailma on jo siirtynyt sinne UTF-8:n käyttöön, eikä siitä ole seurannut mitään massiivisia ongelmia, niin sun pitää maalailla jotain näkymättömiä ja toteutumattomia uhkakuvia.

Lisäksi kuten olen jo aiemmin sanonut, joo, kaikki vanhat legacykoodit eivät toimi Unicoden kanssa. Mutta tuo ei ole mikään syy olla käyttämättä sitä Unicodea uusissa järjestelmissä. Vanhat legacy softat sitten joko muutetaan Unicoden kanssa yhteensopiviksi tai käyttäjien täytyy tietää mitä tekevät.

 

[Karhu III]

On sitten pahasti harhaista kuvitella, että kaikki käytössä olevat koodit olisivat nykyään UTF-8 yhteensopivia. Satuinpa vilkaisemaan NIST:n FDS-palosimulaatio-koodia: FDS-SMV
Se on 2000-luvulla kehitetty, Fortranilla toteutettu koodi, joka mallintaa erilaisia tulipaloprosesseja. Sitä voi ajaa yhdellä prosessorilla mutta myös tuhansien ytimien klustereilla. Kehittäjä ei ole nakkikiska, eikä koodi ole mikään opiskelijan harjoitustyö. Tästä huolimatta, User's Guide, April 8, 2024: "Make sure there are no non-ASCII characters being used, as can sometimes happen when text is cut and pasted from other applications or word-processing software".

Tuo softa ei toimi kunnolla edes non-unicode ympäristössä. ASCII on 7-bittinen merkistö joka sisältää ainoastaan kirjaimet a-z. Eli edes tavanomaisia ä- ja ö-kirjaimia ei voi käyttää tuon ohjelmiston kanssa.

 

[Karhu III]

Jos 8-bit ei ihan oikeasti riitä, niin miksi ei käytetä 16-bittistä UTF-16:a? Vakiolevyisiä, 16-bittisiä merkkejäkin pystyy käsittelemään tehokkaasti. mutta muistinhallintaa ne toki kuormittavat 8-bittisiä enemmän.

16/32-bittisillä merkistöillä tulee endianess-ongelma. Eikä se ole oikeastaan tehokkaampi prosessoida, koska Unicode on käytännössä aina vaihtuvanpituinen.

UAX #15: Unicode Normalization Forms

Specifies the Unicode Normalization Formats

unicode.org

Toinen sitten on käytännöllisyys. 16/32-bittinen Unicode vaatii käsittelyyn omat kirjastokutsunsa. C-kirjaston perusfunktiot kuten printf(), strlen() tai strcmp() toimivat kuitenkin edes jollain tasolla UTF-8:n kanssa, ja jos pysytään ASCII-alueella, niin se on 100% yhteensopiva.