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.