Merkistöistä

[takomo]

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.

Erittäin suurelle osalle tietojenkäsittelyä 4 eri legacymerkistöä ei ole olennainen ongelma. Osaltaan kyse on siitä, että ongelmatilanteille on aikaa sitten kehitetty kelvolliset ratkaisut. Esim. meillä oli ensin lokinsiipi-ASCII, sitten/rinnalla PC-merkistö ja sitten ISO-Latin1. UTF-8 on perfektionistinen ratkaisu, jota ilmankin pärjää monessa. Toki silläkin on paikkansa aidosti kansainvälisessä toiminnassa.

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.

Ei kyse ole siitä, etteikö UTF-8:aa voisi toteuttaa oikein. Tietenkin voi, kunhan koodi tehdään alusta pitäen UTF:n ehdoilla mutta joka tapauksessa koodista tulee tehottomampaa kuin 8-bittisellä merkistöllä. Koodin tehottomuus on ihan oikea ongelma ja toinen oikea ongelma on se, että UTF rikkoo 8-bittiset koodit.

IT:n kuluttama raaka sähköteho alkaa olla konkreettinen ongelma. Osaltaan kyse on laskennasta mutta osansa on myös tekstimuotoisen datan käsittelystä, mm. big datan louhintaa ja AI:n opettamista. Jos aivan perustason tekstitoiminnot on rautatasolla tehottomampia, niin kyllä sille alkaa hintaa kertyä.

Länsimaat saavat kilpailuetua Aasiaan verrattuna, kun voivat käsitellä tekstit 8-bittisinä vaihtuvapituisen UTF:n sijaan. Miksi tämä etu heitetään romukoppaan vapaaehtoisesti?

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.

Miten Fortran tai COBOL tukevat UTF:aa? Koko vakiomuotoisen tietueen käsite menee romukoppaan, jos pitää varautua vaihtuvapituisiin merkkeihin.

COBOLissa näyttää jonkinlaista tukea olevan mutta miten sen käyttö vaikuttaa koodin tehokkuuteen?

Using UTF-8 data (Unicode) in COBOL

UTF-8 is a variable-width Unicode encoding that encodes each valid Unicode code point using one to four 8-bit bytes. UTF-8 has many desirable properties, including that it is backwards compatible with ASCII, often provides a more compact representation of Unicode data than UTF-16, and is...

www.ibm.com

Jos on kyse laskentaohjelmista, niin on muuten ihan jäätävä urakka konvertoida joku miljoonarivinen koodi UTF-yhteensopivaksi - ja miksi? Onko se todellakin tehokkaasti käytettyä aikaa, sen sijaan että kehittäisi algoritmeja paremmiksi?

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.

Pedantisti näin, mutta hyvin harvoin ohjelmisto tekee eroa 7- ja 8-bittisen tekstin välillä. Kun lähdekoodikin on saatavilla, niin voi jopa olla mahdollista osoittaa, että koodi on sellaisenaan 8-bit yhteensopiva.

Ihan triviana, miten kauas historiaan pitää mennä, että CPU olisi tehnyt eroa 7- ja 8-bittisen datan välillä? Esim. 36-bittinen PDP (1966) voisi kai pakata 5 ASCII merkkiä/sana. Tiedonsiirrossa 7bit+pariteetti on ollut yleisempi, mutta jo 80-luvulta lähtien 'historiallisista syistä'. 8bit+pariteetti olisi yhtä lailla mahdollinen, jos halutaan pariteettitarkistus.

 

[JCSH]

Erittäin suurelle osalle tietojenkäsittelyä 4 eri legacymerkistöä ei ole olennainen ongelma. Osaltaan kyse on siitä, että ongelmatilanteille on aikaa sitten kehitetty kelvolliset ratkaisut. Esim. meillä oli ensin lokinsiipi-ASCII, sitten/rinnalla PC-merkistö ja sitten ISO-Latin1. UTF-8 on perfektionistinen ratkaisu, jota ilmankin pärjää monessa. Toki silläkin on paikkansa aidosti kansainvälisessä toiminnassa.

Paitsi että ne eivät koskaan olleet mitään kelvollisia ratkaisuja. Ne aiheutti jatkuvasti kaikensorttisia yhteensopivuus ongelmia, rikkinäisiä tai hylättyjä inputteja, korruptoituneita outputteja, merkkien rendaukset päin vittua jne. jne. Tuon takia nykyään käytännössä kukaan ei enää käytä niitä, jos on mahdollisuus käyttää sitä Unicodea. Koska Unicode korjasi nuo ongelmat.
"Aidosti kansainvälinen toiminta". Koko IT-ala on aidosti kansainvälistä. Olen aika varma, että tuonkin viestin kirjoitit jollain kansainvälisille markkinoille tähdätyllä selaimella, jota ajat kansainvälisille markkinoille tähdätyllä käyttöjärjestelmällä, foorumille, joka pyörii kansainvälisille markkinoille tähdätyllä softastackillä.

Ei kyse ole siitä, etteikö UTF-8:aa voisi toteuttaa oikein. Tietenkin voi, kunhan koodi tehdään alusta pitäen UTF:n ehdoilla mutta joka tapauksessa koodista tulee tehottomampaa kuin 8-bittisellä merkistöllä. Koodin tehottomuus on ihan oikea ongelma ja toinen oikea ongelma on se, että UTF rikkoo 8-bittiset koodit.

IT:n kuluttama raaka sähköteho alkaa olla konkreettinen ongelma. Osaltaan kyse on laskennasta mutta osansa on myös tekstimuotoisen datan käsittelystä, mm. big datan louhintaa ja AI:n opettamista. Jos aivan perustason tekstitoiminnot on rautatasolla tehottomampia, niin kyllä sille alkaa hintaa kertyä.

Länsimaat saavat kilpailuetua Aasiaan verrattuna, kun voivat käsitellä tekstit 8-bittisinä vaihtuvapituisen UTF:n sijaan. Miksi tämä etu heitetään romukoppaan vapaaehtoisesti?

AI/ML on esimerkki siitä, miten se Unicode on helvetin tärkeä asia. Jos meillä olisi vielä legacy 8-bittiset merkistöt käytössä, niin tekstipohjaiset ML-mallit pitäisi kouluttaa erikseen jokaiselle eri merkistölle. Sen sijaan, että meillä olisi yksi malli, joka ymmärtää sitä UTF-8 syötettä, meillä olisi se pari tusinaa eri malleja, joista jokainen ymmärtää vain sitä omaa syötemerkistöään. Tuo vasta olisi ajan ja energian tuhlausta.
Lisäksi koska ML:ssä merkkaa se koulutusdatan määrä ja monimuotoisuus, niin kun se koulutusdata jakautuu eri 8-bittisiin merkistöihin, niin jokaisen yksittäisen 8-bittistä tekstiä ymmärtävät mallin koulutusdata suppenee. Joka mitä todennäköisemmin tekee siitä mallista huonommin toimivan. Oikeastaan jos joku ML-malleja treenaava devaaja joutuisi käsittelemään eri 8-bittisiä inputteja, niin olen aika varma, että hän ensimmäisenä ottaisin kaikki ne eri 8-bittiset merkistöt, konvertoisi sen datan Unicodeksi ja sitten kouluttaisi mallinsa sillä.

Taaskin väite kilpailuedusta on täysin irrallaan todellisuudesta. Miten helvetissä me saataisiin kilpailuetua siitä, että tehdään hommat vaikeammin ja vähemmän yhteensopivasti muun maailman kanssa? Nyt kun me länsimaissa käytetään Unicodea, niin me voidaan erittäin helposti myydä ne meidän tekemät softat myös sinne Kiinaan, Japaniin, Koreaan, arabimaihin, jne. jne. jne. Jos me käytettäisiin omissa softissa 8-bittisiä merkistöjä, niin tuo tulisi helvetisti vaikeammaksi.
Kun taaskin sitä Unicodea käyttävä muu maailma pystyisi myymään softaansa niin muuhun maailmaan kuin myös länsimaihinkin. Kerta se Unicode kuitenkin toimisi myös länsimaissa.

Miten Fortran tai COBOL tukevat UTF:aa? Koko vakiomuotoisen tietueen käsite menee romukoppaan, jos pitää varautua vaihtuvapituisiin merkkeihin.

COBOLissa näyttää jonkinlaista tukea olevan mutta miten sen käyttö vaikuttaa koodin tehokkuuteen?

Using UTF-8 data (Unicode) in COBOL

UTF-8 is a variable-width Unicode encoding that encodes each valid Unicode code point using one to four 8-bit bytes. UTF-8 has many desirable properties, including that it is backwards compatible with ASCII, often provides a more compact representation of Unicode data than UTF-16, and is...

www.ibm.com

Jos on kyse laskentaohjelmista, niin on muuten ihan jäätävä urakka konvertoida joku miljoonarivinen koodi UTF-yhteensopivaksi - ja miksi? Onko se todellakin tehokkaasti käytettyä aikaa, sen sijaan että kehittäisi algoritmeja paremmiksi?

Kuinka monta kertaa tämä pitää sanoa?
Jos niitä vanhoja softia ei pystytä/ei kannata muuttaa Unicodea tukeviksi, niin sitten niitä ei muuteta. Se ei tarkoita, etteikö uusia softia kannattaisi tehdä Unicoden päälle.