Legjobb emlékeim szerint a Qt-os alkalmazások nem nyávognak és böfögik tele a konzolt/.xsession-errors-t, hogyha egy-egy filenév úgy tartalmaz 8 bites karaktereket, hogy pl. a latin2-es kódtáblát használtam hozzá. A GTK2 ezt simán megteszi és finoman szólva is idegesítő.
Olvasd el a gtk2 forrásán belüli README fájlt. Sokat fogsz tanulni belőle. Segítek: keresd a G_BROKEN_FILENAMES környezeti változót. Ez kell neked. "The assumption of GLib and GTK+ by default is that filenames on the filesystem are encoded in UTF-8 rather than the encoding of the locale; the GTK+ developers consider that having filenames whose interpretation depends on the current locale is fundamentally a bad idea." Teljesen egyetértek velük. Nehogymár én létrehozok egy fájlnevet magyar ű betűvel, mire azt Jean-Paul haverom kalapos u-ként látja... nem, az nem kalapos u, az akkor is maradjon magyar ű, ha valaki nem magyarul használja a rendszert. Erre csak unicode alapú (leginkább utf8) karakterkészlet képes.
Csak egy kis adalék: míg a Gnome világ következetesen locale-től függetlenül utf8-at használ a fájlnevekben, addig a KDE szépen kavar. Épp tegnap találkoztam azzal a hibával, hogy k3b-ből nem lehet ékezetes fájlokat CD-re írni, mert a fájlnevet (ami valid utf8 az én esetemben) ő átalakítja latin2-re és így adja oda az mkisofs-nek, amelyik így nyilván nem találja meg a fájlt. Most akkor bocsi, de melyik is a jobb? :-)
Valóban sok szoftver még nem tudja kezelni ezt és van emiatt az UTF8-nak egy olyan hátránya, ami a latin2-es kódtáblával pl. nem jelentkezik: egy síkhülye szövegszerkesztőben is tudod szerkeszteni a latin2-es szöveget, nem kell hozzá az UTF8 több byte-os entitásait dekódolni. Legföljebb kalapos ő-t látsz a magyar helyett, de az kibírható, a lényeg az, hogy látod. Vagy pl. hogyan nézel meg more-ral v. less-szel egy UTF8-as szöveget?
Na, akkor egy kis körkép. Az UHU 2.0-ban ugyanis UTF-8-at fogunk használni, de az átállás igen jelentős részét már most, a készülő 1.2-re megtettük. Lássuk...
vim, emacs, joe, mutt, lynx, w3m, more - mainstream tök jól kezeli az utf8-at.
ne, le és még jópár szinte-soha-senki-nem-hallott-róla típusú konzolos szövegszerkesztő szintén jól kezeli az utf8-at.
less - mainstream majdnem tökéletesen kezeli az utf8-at, a keresés mező hibás, de van rá patch, alkalmaztuk.
nano - dolgoznak rajta a fejlesztők, az alapjai már megvannak az 1.3-as sorozatban, 1.4-re igérik a véglegesítést.
mc, mcedit, mcview, pico, pine - létezik hozzájuk patch, már alkalmaztuk őket.
Annyi megjegyzés, hogy a szövegszerkesztők és fájlkezelők némelyike csak olyan kódolású szövegfájlt tud szerkeszteni, ami megegyezik a terminál kódolásával. Az okosabbak (például vim, joe) tudnak utf8 terminál fölött latin2 szöveget és latin2 terminál fölött utf8 szöveget is szerkeszteni.
Némely más programokat mi magunk véges mennyiségű munkával fel tudunk készíteni utf8 használatára.
Csak azért nyújtottam egy ilyen kis körképet, mert tudom, hogy az elmúlt 1-2 évben nagyon sokat fejlődtek ilyen téren a szoftverek, tényleg amikor a redhat behozta az utf8 konzolt akkor még nagyon sok probléma volt vele. Ugyanakkor mostanra már igencsak biztató a helyzet.
Ha van egy kis időd, rakj fel egy 1.2 snapshotot, /etc/env.d/locale-ben írd át hu_HU.UTF-8-ra a nyelvet, és nézz körül a grafikus felületen, illetve grafikus terminálon belül is (a linux konzolt bonyolultabb átállítani), keress hibásan működő programokat. Én most körülbelül 5-öt tudnék felsorolni: gmplayer, dselect/dpkg, man, és most hirtelen elakadtam. Szóval nem kell ám parázni az utf8-tól.
Legföljebb kalapos ő-t látsz a magyar helyett, de az kibírható
Ez ízlés kérdése. Szerintem nem bírható ki, én ugyanis hányingert kapok tőle. Az utf8 pont arról szól, hogy ilyen _soha_ ne fordulhasson elő.
A kódolás meg nem probléma, amit írsz, mert egyszerűen csak (pl. az adott e-mail fejlécében, ugye) el kell tárolni, hogy az milyen kódlappal történt.
Az olyan helyeken, ahol használsz valami kódolást, és azt meg is tudod nevezni, mint például e-mailekben, html oldalakon, ott ez tényleg nem gond, és a latin2 is tök jó. A gondok inkább ott vannak, ahol nincsen lehetőséged eltárolni a használt kódolást, például fájlnevekben, sima plain text fájlokban.
IMHO ezen a kódoláson is meglátszik (mint eddig az összesen), hogy olyan nyelvterületen kezdték kidolgozni, ahol nincsenek ékezetes betűk és fogalmuk sincs az ottani nyelvet beszélőknek a mi bajainkról.
Fogalmam sincs, ezt mire alapozod, ugyanis baromira nincs így. Egyszer kell felkészíteni a szoftvereket utf8-ra, és onnan kezdve tökéletesen megfelelel szinte minden nyelv beszélői számára. Persze vannak még csiszolnivalók rajta (mármint a unicode-on), folyamatosan fejlesztik is, de ugyan, szerinted mi az benne, ami nem felelne meg például a magyar ajkúaknak? A történet épp fordítva fest. A 8 bites kódolások idején általában még magasról letojták a többnyelvűség kérdését a fejlesztők, és ilyen szempontból ***** minőségű szoftverek készültek. Később felmerült az igény a korrekt többnyelvűségre, de rájöttek, hogy a sok-sok locale tarkasága technikailag megoldhatatlan problémák tömkelegéhez vezet, így merült fel az igény egy egységes kódolási rendszerre. A Unicode-ot, utf8-at valós igény szülte és ezeket az igényeket jól ki is elégítik.