Az UHU-Linux rendszer használata során megfigyelhetjük, hogy az ékezeteket is tartalmazó fájlnevek bizonyos esetekben hibásan, vagy egyáltalán nem jelennek meg. Amelyik alkalmazással létrehozzuk a fájlt, azzal jól látjuk, viszont más alkalmazással nem mindig. Ebben a leírásban alaposabban megvizsgáljuk a probléma okát, valamint a különféle lehetőségeket a probléma ideiglenes kikerülésére.
Messze az a legegyszerűbb megoldás, ha nem használunk ékezeteket a fájlok nevében. Természetesen ez egy roppant banális megoldás, amire mindenki magától rájött. Sajnos, mint látni fogjuk, a számítástechnikai napjainkban még nem érett meg az ékezetes fájlnevek gond nélküli használatára, valószínűleg ehhez még néhány évre szükség lesz.
A fájlnév, legyen az akár a lemezen eltárolva, akár egy tömörített fájlon belül leadminisztrálva, akár továbbítva a hálózaton keresztül, nem más, mint byte-ok (256 alatti egész számok) sorozata. Például egy lehetséges fájlnév a lemezen egy 72-es, egy 101-es, majd 108-as, aztán még egy 108-as, végül egy 111-es szám. Nade ez minket, felhasználókat nem érdekel, mi egy olvasható értelmes szöveget szeretnénk fájlnévként látni. Ehhez szükség van valamiféle átalakításra a byte-ok és a betűk között.
A számítástechnika történetének kezdetén, a '60-as években megalkották az ASCII kódkészletet. Ez a karakterkészlet a 0-tól 127-ig terjedő értékeknek feleltette meg az angol ábécé kis- és nagybetűit, a számjegyeket, az alapvető fontosságú írásjeleket, valamint számos speciális vezérlő karaktert. Habár más ehhez hasonló karakterkészletek (például EBCDIC) is napvilágot láttak, az ASCII terjedt el világszerte, ma gyakorlatilag mindenütt ezt használják. Ebben például a 72-es értéknek a nagy "H", a 101-esnek a kis "e", a 108-asnak a kis "l", a 111-esnek a kis "o" felel meg. Nem kérdés tehát, hogy a fenti példában említett fájl nevét gyakorlatilag bármely számítógép, bármilyen operációs rendszer bármilyen beállítások mellett "Hello"-ként jeleníti meg a felhasználó előtt. Természetesen az átalakítás az ellenkező irányba is hasonlóan működik: ha a felhasználó a "Hello" szót gépeli be a fájl nevének, akkor az a fenti bytesorozattá alakul át.
Az ASCII kódkészlet egyáltalán nem alkalmas ékezetes betűk ábrázolására. Mivel egyre nagyobb szükség lett arra, hogy a szoftverek ékezetes betűket is meg tudjanak jeleníteni (és itt ne csak fájlnevekre gondoljunk, hanem tetszőleges szövegre), megjelentek az ékezetes betűket is támogató karakterkészletek. Ezek a 0-tól 127-ig terjedő értékek terén az ASCII kódtáblával megegyeznek, így garantálják az azzal való kompatibilitást, míg a 128-tól 255-ig terjedő értékekre különféle ékezetes betűket raknak.
Ezzel a megközelítéssel azonban van egy nagy gond. Nevezetesen az, hogy 128-nál lényegesen több ékezetes karaktert találni a különféle latin betűs nyelvekben, és ekkor még az egyéb írásokról nem is beszéltünk.
Megszületett az ISO-8859-1 (más néven Latin-1) karakterkészlet, amely a magyar nyelvből az ő és ű betűket nem tartalmazza, így alkalmatlan magyar szöveg ábrázolására. Megszületett az ISO-8859-2 (Latin-2), amely az összes magyar ékezetet tartalmazza. Születtek egyéb ISO-8859 kódlapok, a DOS által használt kódlapok (cp437, cp850, cp852 stb.), a Windows karakterkészletei (Windows-1250, Windows-1252 stb.), és sok-sok egyéb is.
A fentiek közül a Linux az ISO karakterkészleteket használta, így például a '90-es évek vége felé egy magyarra beállított Linux esetén teljesen természetes volt, hogy elvileg minden program a Latin-2 karakterkészletet használja, és így a fájlnevekben is egységesen ezt a kódolást használhatjuk. Gyakorlatilag már nem volt ennyire tökéletes a helyzet, hiszen azok a programok, amelyek figyelmen kívül hagyták a nyelvi beállításokat, Latin-1 karakterkészlettel dolgoztak, így például a magyar ő és ű betűk helyett az o betűre hullámvonalat, az u betűre pedig kalapot tettek. Ezek a programok sokszor a billentyűzetről sem fogadták el az ő és ű betűket.
A fenti rendszerrel két fő gond is van. Az egyik az, hogy képtelen az általunk kiválasztott karakterkészleten kívüli karakterek ábrázolására. Ha magyarul használjuk a rendszert, akkor is bármikor szükségünk lehet a Latin-2 karakterkészletből hiányzó szimbólumra is (például idegen tulajdonnévben lévő ékezetes betű, copyright jel, euró jel stb.). A másik gond az, hogy rengeteg helyen (például fájlnevekben) nincs meg a lehetőség a karakterkészlet megnevezésére. Még ha mi magunk tökéletesen is látunk minden magyar ékezetet, akkor sem megengedhető, hogy a fájlt elküldjük bárkinek, aki nem a közép-európai Latin-2 kódolást használja, és ő teljesen másmilyen karaktert lát legalább az ő és ű betű, de esetleg az összes ékezet helyén. Ezek nemcsak elvi síkon elképzelhető problémák, a gyakorlatban is mindennaposan jelentkeznek.
A nemzetköziséget is egyre jobban támogató szoftverek kifejlesztése során teljesen egyértelműen kiderült, hogy a fenti megközelítés a számítástechnika fejlődésének egyik hatalmas zsákutcája, hiszen nem képes kielégítő megoldást nyújtani számtalan problémára. A megoldást csakis egy olyan kódolás nyújthatja, amely egymagában képes az összes nyelv összes karakterét ábrázolni. Ez a kódolás az UTF-8, a Unicode egyik ábrázolási formája. Az UTF-8 kódolás a 0-tól 127-ig terjedő értékeken az ASCII szabványt követi, míg a 128-tól 255-ig terjedő byte-okból több egymást követő érték ír le egyetlen ékezetes betűt, ily módon lehetséges 128-nál sokkal több, körülbelül kétmilliárd írásjel megkülönböztetése. A gyakoribb karaktereket, így a magyar ékezetes betűket is mind két egymást követő byte írja le. A magyar tipográfiai szabályoknak megfelelő nyitó és záró idézőjel, valamint a nagykötőjel kódja például három byte-ból áll. A legritkább karakterek ábrázolása akár hat byte-ot is igényelhet.
Az UTF-8 kódolás tehát önmagában tökéletesen alkalmas bármely nyelv bármely szövegének ábrázolására. Semmilyen plusz kódkészlet-információ cipelésére nincs szükség, ha mindenki mindenütt UTF-8 kódolást használ, és megszűnik minden olyan probléma, mint például a magyar szövegben tévesen ő és ű betű helyett megjelenő hullámos o és kalapos u betű. A jövő egyértelműen az UTF-8 kódolásé. Az átállás már megkezdődött, most valahol félúton tartunk, ennek megfelelően hatalmas a kavarodás.
Van az UTF-8 kódolásnak még egy roppant fontos tulajdonsága. A régimódi kódolások 1 byte-nak 1 karaktert feleltettek meg, így tetszőleges bytesorozat érvényes, ábrázolható volt. Az UTF-8 kódolásra ez nem teljesül, hiszen néhány 128 fölötti byte-nak együtt kell egyértelműen leírnia egy ékezetes betűt. Így például UTF-8 szövegben 128 fölötti byte nem állhat egyedül, a konkrét értéktől függően legalább 1, de néha több 128-nál nagyobb byte-nak kell azt követnie. Így tehát bizonyos bytesorozatok nem érvényes UTF-8 kódolású szövegek, nem lehetséges őket UTF-8 kódolásként értelmezve megjeleníteni.
Mi történik, ha egy UTF-8 kódolást használó programmal létrehozunk egy ékezeteket is tartalmazó nevű fájlt, majd egy Latin-2 kódolást használó programmal próbáljuk azt megnyitni? Az ékezetes betűk két byte-ként vannak eltárolva, így a Latin-2-ben gondolkodó alkalmazás az ékezetes betű helyett két valamilyen jelet jelenít meg. Csúnyán néz ki, sokszor olvashatatlan, de a fájl gond nélkül elérhető, megnyitható.
Mi történik akkor, ha egy Latin-2 kódolást használó programmal hozunk létre egy fájlt, és azt egy UTF-8 kódolást feltételező programmal kívánjuk megnyitni? A Latin-2 kódolással létrehozott bytesorozat minden bizonnyal érvénytelen UTF-8 sorozat. Az alkalmazások nagy része meg sem jeleníti ezeket a fájlokat (hiszen nem tudja, hogy hogyan kell megjeleníteni), míg más részük valamilyen teljesen egyedi megoldást választ.
Az UHU-Linux 1.0-ban a GTK+ grafikus eszköztár 2-es változatát használó programok, így például az alapértelmezett Gnome környezet (szintén 2-es változat) használt UTF-8 kódolást, a többi program hagyományos Latin-2 kódolást használt. UHU-Linux 1.1-től kezdve az előzőn túl a QT grafikus eszköztárra, valamint a KDE környezetre épülő programok is UTF-8 kódolást használnak.
A közeli jövőben egyre több alkalmazás fog UTF-8 kódolást használni. Néhány disztribúció kísérleti jelleggel már a terminálban is ezt a kódolást használja, itt is csak idő kérdése, hogy az UHU-Linux mikor áll át.
Kétségtelen tehát, hogy egy átállás során felemás helyzet alakult ki, amely kellemetlenségekhez is vezethet.
A múlt a tiszta Latin-2 rendszer. A G_BROKEN_FILENAMES,
QT_BROKEN_FILENAMES, KDE_BROKEN_FILENAMES környezeti változók beállításával
a GTK+, QT és KDE alkalmazások is rábeszélhetők a régimódi ékezet
ábrázolásra. A fenti változókat például beállíthatjuk úgy, hogy az /etc/env.d
könyvtár alatt létrehozunk egy tetszés szerinti nevű fájlt ezzel a
tartalommal:
G_BROKEN_FILENAMES=1
QT_BROKEN_FILENAMES=1
KDE_BROKEN_FILENAMES=1
Ez tehát fél lépés visszafelé egy önmagában konzisztensebb, de hosszútávon
semmiképp sem életképes rendszer felé.
A jövő egyértelműen az UTF-8 kódolásé. Amennyiben fájljainkat szeretnénk ékezetes nevekkel archiválni és sok év múlva előkeresni, minden bizonnyal az UTF-8 kódolással járunk a legjobban.
A fent írtak tükrében akkor is az UTF-8 választása ajánlott, ha nem probléma az, ha bizonyos alkalmazások hibásan jelenítik meg a fájlnevet, de mindenképp gond, ha adódik olyan program, amely egyáltalán nem jeleníti meg ezeket a neveket.
Fájlok átnevezésére az egyik lehetőség egy olyan fájlkezelő keresése, amely az általunk kívánt új kódolásban gondolkodik, de a másik kódolással tárolt fájlneveket is valahogyan megjeleníti. Ebben átnevezhetjük a fájlokat, a hibás karaktereket kijavítva a megfelelő helyes ékezetre.
Parancssoros megoldások kedvelőinek a convmv programra érdemes vetniük egy pillantást.
Az utf8filename nevű programon keresztül régimódi alkalmazásokat indíthatunk, ezek az UTF-8 kódolásban tárolt fájlneveket konvertálva kapják meg, és így jól jelenítik meg. A programról a /usr/share/doc/Packages/utf8filename könyvtárban található leírás. Sajnos nem minden alkalmazás viselkedik tökéletesen vele, így használatát kritikus helyzetekben nem ajánljuk.