Testiohjelmaa käynnistäessäni törmäsin erikoiseen virheilmoitukseen: The folder contents could not be displayed - Invalid byte sequence in conversion input.
Kummallisinta asiassa oli se, että ohjelma toimi kahdessa koneessa normaalisti, mutta antoi kaikissa muissa tämän ilmoituksen. Koneet olivat lähes samanlaisia, kaikissa oli Windows XP, ja ohjelma oli kopioitu niihin kaikkiin samalta muistitikulta. Miksi ihmeessä ohjelma toimi kahdessa koneessa, mutta ei muissa?
Pikainen googlaus ei antanut vastausta. Lopulta itselläni alkoi raksuttaa: niissä koneissa, missä ohjelma toimi, oli englanninkielinen Windows. Niissä missä se ei toiminut oli suomenkielinen.
Ja kas, syy selvisi: olin kopioinut testiohjelman koneiden työpöydälle, jonka hakemistonimi suomalaisessa versiossa on työpöytä. Polussa olleet ääkköset riittivät sotkemaan ohjelman. Siirsin ohjelman ja työtiedoston c:\temp-hakemistoon ja kaikki alkoi toimia.
Millään ohjelmalla ei pitäisi enää olla vaikeuksia ääkkösten kanssa - eikä varsinkaan, kun ääkköset ovat polussa eivätkä tiedostonimessä, ja tiedostoa avataan oletushakemistosta (siis ilman edeltävää polkumääritystä). Mutta kaikki on näköjään yhä mahdollista...
Kyse oli muuten glib2-kirjastoa käyttävästä open source -ohjelmasta, joten ongelman korjaamisen luulisi olevan helppoa. Mutta eipä vain kukaan ole korjannut.
Jos joku törmää samaan ongelmaan, hän toivottavasti löytää googlaamalla tämän sivun ja selityksen.
Virhe johtunee siitä, että glib2 odottaa tiedostonimen/polun olevan UTF-8 -muotoista tekstiä. Muuntaessaan nimeä järjestelmään omaan localeen se törmää "outoihin merkkeihin" (l. windows-ääkköset) ja antaa ylen.
VastaaPoistaOngelman voi kiertää asettamalla ympäristömuuttujan G_FILENAME_ENCODING sopivaan arvoon, esim ISO-8859-1.
En tiedä/muista mitä merkistökoodausta windows käyttää joten se jääköön kotitehtäväksi.
Juuri tästä on kyse. Virheilmoitus saisi kyllä olla selkeämpi ja kertoa, mihin homma tökkää ja miksi.
VastaaPoistaWindows-ääkkösten ei sinällään pitäisi olla outoja, vaan ISO Latin-standardin mukaisia.
Kun Windowsissa harvemmin (!) noita UTF-8 tiedostonimiä näkee, olisiko fiksua jos ohjelma itse olettaisi merkkikoodauksen käyttöjärjestelmän perusteella? Nyt asia on hoidettu nörttityyliin ("me teemme asian uuden standardin mukaisesti ja on käyttäjän päänsärky jos homma ei hänellä toimi"). Totta kai ongelma järjestyy jollain G_FILENAME_ENCODING-loitsulla, oma vika jos ei sitä tiedä.
Toivoisi, että vaikka UTF-8 onkin tarpeen globaalissa maailmassa ja vaikka ääkkösten (kuten muidenkin aksenttien, umlautien ym.) koodaus on vaihtunut ISO Latinista UTF-8:ään siirryttäessä, käyttäjän ei enää 2000-luvulla tosiaankaan tarvitsisi tapella tiedostonimien ääkkösten kanssa.