Koodasin blogisoftaan mahdollisuuden sisällyttää kirjoitus useampaan luokkaan (ja uudelleennimesin sen; kategoria on vähän tyhmä). Näin tuosta luokka-käsitteestä on jotain iloakin.

Yllättävän paljon muutoksia, kun piti tietokannan rakennetta, käsittelyä ja käliä muokata. Melkein joka funktioon tai ainakin tiedostoon muutoksia.

$ svn -r52:54 diff|wc -l
576

Ei pointtia tänään, tämä postaus on testi.

Ei olisi kuvitellut, että yksi suosituimmista web-ohjelmointiin käytetyistä kielistä, PHP, ei oletusarvoisesti osaa UTF-8-merkistökoodausta vuonna 2007, maailmassa, jossa aika suuri osa netin käyttäjistä on äidinkieleltään muita kuin englanninkielisiä.

UTF-8 on Unicode-merkistön tavallisin merkistökoodaus, joka esittää jokaisen merkin yhden–neljän tavun sarjoina. Sillä voidaan esittää karkeasti ottaen kaikkien kielten kaikki merkit, minkä voisi kuvitella olevan aika iso juttu monikielisessä maailmassa. Unicode on aika laaja merkistö.

World Wide Webin perusprotokollan, HTTP:n, oletusmerkistö on kuitenkin ISO Latin 1 (ISO-8859-1). Se on käytännössä webissä de facto -standardin asemassa, ainakin jos asiaa tarkastellaan läntien Euroopan vaikutuspiirin näkökulmasta.

ISO Latin 1 on laajempi kuin pelkän englannin esittämiseen soveltuva ASCII, ja sillä voidaan esittää oivasti esimerkiksi skandinaaviset merkit å, ä ja ö. Muitakin merkkejä on, mutta tuoreempi €-merkki tai š vaatii jo ISO Latin 9 (ISO-8859-15) -merkistön, jos halutaan pysyä Latin-merkistöissä. Unicode-merkistöllä nämä kaikki sujuvat ongelmitta. Merkistöistä erinomaista lisätietoa löytyy kaimani Korpelan sivuilta. 

PHP:ssa kuitenkin ollaan jumituttu tilanteeseen, jossa kieleen on rakennettu omituisia oletuksia. PHP:ssa yksi merkki on aina yksi oktetti (tavu), ja monitavuiset merkistöt, kuten UTF-8, ovat perustavanlaatuisesti rikki. Suurin osa PHP:n string-funktioista laskee tai ymmärtää merkkijonot väärin. Esimerkiksi strlen() tai substr() laskevat merkkijonojen pituudet väärin, ja tästä seuraa omituisia bugeja.

Näin siis, mikäli PHP-tulkkiin ei ole käännetty mbstring-laajennosta päälle. PHP:ssa on siis olemassa laajennos, joka kuormittaa ongelmalliset funktiot samannimisillä, mutta multibyte-yhteensopivilla versioilla. Tästä seuraa kuitenkin ongelmia koodin siirrettävyyden näkökulmasta. Kuluneen kevään aikana suorittamamme ohjelmistotuotantoprojektin kehittämässä tuotteessa ehkä keskeisin bugi johtui tästä. Sitä oli mahdollisesti testattu PHP-ympäristössä, jossa mbstring oli käännetty päälle. Ratkaisimme ongelman käyttämällä ulkoista kirjastokomponenttia, joka tarjoaa ehjät versiot PHP:n rikkinäisten funktioiden tilalle. Se käyttää myös mbstring-laajennosta, mikäli se on saatavilla. Tulipahan ainakin siirrettävää koodia.

Tämä on siis syytä ottaa huomioon aina PHP:lla koodatessa, jos on  olemassa pienikin mahdollisuus, että joudutaan käsittelemään UTF-8-koodattuja merkkijonoja. Ja tämä mahdollisuushan on erittäin todennäköinen, koska UTF-8:n käyttöön siirrytään koko ajan kiihtyvällä tahdilla. Mikä on sinänsä erinomaista. Harmi, ettei maailma ole siihen viel ä valmis. Kannattaa ainakin tarkistaa, mitä kaikkia funktioita ongelma koskee.