Weblabor

Gyakori és visszatérő probléma, hogy valakinek meggyűlik a baja egy oldal készítése során a karakterkódolás témakörével, pedig ha pár apróságot betartunk, akkor nem lesz vele gondunk. A nehézséget valószínűleg az okozza, hogy a helyes működéshez több tényező megfelelő összehangolása szükséges, és ha bármelyikük rossz, akkor csak annyit tapasztalunk, hogy "nem megy jól az oldal". Ez a cikk igazából csak egy válasznak indult, de már korábban is szerettem volna írni erről a témáról, mert fontosnak érzem, hogy tisztázzuk ezt a kérdést, ezért végül úgy döntöttem, hogy egy kicsit jobban körüljárom a témát.

Mint a bevezetőben említettem, a probléma nem bonyolult, csak fontos, hogy kialakítsuk a helyes szemléletmódot. Ennek szerintem egyik fontos eleme, hogy ne csak kövessünk egy ajánlott receptet, hanem játszunk el a lehetőségekkel, jöjjünk tisztába azokkal a mechanizmusokkal, amiknek jelen esetben jelentősége van, különben hiba esetén nehezen fogunk tudni rájönni a megoldás kulcsára.

Először is következzen egy alap forgatókönyv, hogyan járjunk el, ha nulláról indulunk. Tegyük fel, hogy azt szeretnénk, hogy az oldalunk az ISO-8859-2 karakterkódolással működjön. A következő teendőink lesznek:

• Amennyiben adatbázist használunk, akkor állítsuk be úgy, hogy tábláink a megfelelő karakterkódolást használják. Itt érdemes figyelni arra, hogy pl. MySQL esetén lehetőség van mezőnként meghatározni, ezért ha valamilyen generáló eszközt használunk, akkor ellenőrizzük le, hogy a mezőink tényleg az általunk kívánt beállítással jöttek létre.
  
• Legyenek a PHP fájljaink is ilyen kódolásúak, illetve nem is feltétlenül mind, hanem azok a fájlok, amik a kimenetben is megjelenő szövegeket tartalmaznak, és persze ez szintén vonatkozik a template állományainkra.
  
• A HTML kódban szerepelhet meta tagként is az adott kódolás, de ez nem annyira fontos, de az igen, hogy az oldal megfelelő Content-Type fejléccel legyen kiszolgálva, annak charset paramétere az általunk választott kódolást tartalmazza. Ezzel lehetne vitatkozni annyiban, hogy elég a meta tag, ha nincs ezzel ellentétes tartalmú fejléc, de ha mi kiadjuk a megfelelőt, akkor nem fogunk kétes szerver beállításoktól függeni.
  
• Ezután már csak arra kell figyelnünk, hogy az adatbázissal történő kommunikációnk során biztosítsuk, hogy a szerver a számára küldött parancsokat az általunk használt karakterkódolásnak megfelelően értelmezze. Ezt pl. MySQL használata esetén a SET NAMES latin2 parancs kiadásával érhetjük el.

Ha ezekre figyel az ember, akkor alap esetben nem lesz gondja. Az alap esetet arra értem, hogy nem lesz gond, ha az űrlapjainkba tényleg latin2 kódolású szövegeket írnak be. Ha mégis ez történik, akkor nem árt ha van nálunk egy kevés friss kakas vér, mert ugyan van lehetőségünk befolyásolni (_charset_, accept-charset), hogy a böngészők hogyan reagáljanak erre az esetre, de hogy ténylegesen mi fog történni, az eléggé megvalósítás függő.

A gond akkor szokott kezdődni, amikor az ember azt tapasztalja, hogy nem jól jelennek meg a karakterek az oldalán (mert eredetileg nem a fentieknek megfelelően járt el), és kezdődik a kanosszajárás, ugyanis pl. a fenti leírásnak megfelelően elkezdi a különböző recepteket (ész nélkül) alkalmazni, és probléma mégsem akar megoldódni. ("Én már mindent beállítottam, de ...") Ilyenkor a hiba az, hogy úgy próbálunk meg javítani valamit, hogy nem győződünk meg a hiba okáról. Hiába kezdjük el kiadni mondjuk a megfelelő fejlécet, ha az adatbázisban rossz adatok vannak, vagy éppen a template fájljaink karakterkódolása más, mint amit használni szeretnénk. Hiába változtatjuk meg a tábla karakterkódolását, ha csatlakozáskor nem állítjuk be a megfelelő kliens oldal karakterkódolást, és az adatbázisból a tábla típus ellenére nem a számunkra kívánt formában kapjuk meg az adatokat. És még lehetne folytatni a sort, hogyan tudunk saját magunknak keresztbe tenni, és bosszúságot okozni, hogy ha nem szisztematikusan járunk el a hiba elhárítása érdekében.

Az ilyen esetekben nekem általában az a véleményem, hogy készítsünk egy apró teszt oldalt, ami semmi mást nem csinál, csak a problémás részre koncentrál. Gyakori eset, hogy egy hibakeresés azon bukik el, hogy igazából a hiba egy másik hiba mellékhatásaként jelentkezik, ezért nehezen találjuk meg az eredeti, teljes rendszerben. Fontos hogy ne feltételezésekből induljunk ki, hanem győződjünk meg a tényekről. Nagyon gyakori, amikor menetközben kiderül, hogy az a fránya fájl van rosszul kódolva, az az egy mező valamiért más karakterkódolást kapott, és így tovább.

Mint láttuk, nagyjából három dologra kell figyelni a helyes működés érdekében, ennek megfelelően ha hiba adódik, akkor ezen tényezőknek kell utána járnunk. A legegyszerűbb a megfelelő fejléc küldésének az ellenőrzése, amit könnyedén megtehetünk például a LiveHttpHeaders vagy a(z új kedvenc) TamperData nevű Firefox kiterjesztések használatával. Ha továbbra is fennáll a hiba, akkor mehetünk tovább, de figyeljünk arra, hogy amikor ellenőrizzük, hogy a változtatásaink jó működést eredményeznek-e, akkor "friss" adatokat használjunk, nehogy előforduljon az az eset, hogy már igazából minden jól van konfigurálva, csak az adatbázisban lévő, még a régebbi, rossz konfiguráció alatt felvitt adatok tréfálnak meg minket.

A hiba kijavítása során mindvégig legyünk nagyon alaposak, ez esetben fokozottan érvényes a "lassan jársz, tovább érsz" mondás. Nézzünk pár tipikus hibát:

• "A böngészőben jól jelenik meg, de ha a DB-ben nézem, akkor mindenféle kirksz-krakszok vannak." Ez jellemzően akkor fordul elő, amikor nem adunk ki egy űrlap esetén megfelelő fejlécet (pl. egy magyar oldal esetén nincs vagy latin1), ezért a böngésző bizonyos ékezetes karaktereket HTML entity-ként küld el a szervernek, vagy pl. Internet Explorer esetén egy másik, tetszőlegesen választott karakterkódolást használva.
  
• "Az adatbázisban biztosan jók az adatok, mert ilyen-olyan kliensben jól jelenik meg." Fontos, hogy meggyőződjünk arról, hogy tényleg milyen formában van letárolva az adat. Például a MySQL automatikusan konvertálja az adatokat a kliens (jelen esetben a PHP) karakterkódolása és az adott mező tényleges karakterkódolása között.
  
• "Minden jól be van állítva, a mező is latin2, a fejléc is latin2, mégis eltűnik az ő, ű betű." Na ez itt már egy érdekesebb téma. Amikor a PHP-ból kapcsolódunk a MySQL-hez, akkor alap esetben a kliens oldali karakterkódolás a szerver alapértelmezett karakterkódolása lesz, ami többnyire latin1 szokott lenni, hacsak külön nem állítják át egy másik értékre. Kapcsolódik a PHP, a character_set_client latin1 lesz. Beszúrjuk szépen a böngészőből kapott latin2-es szöveget, de a MySQL úgy tudja, hogy mi latin1-et fogunk neki adni, ezért elcsodálkozik az ő, ű karakteren, és mivel ilyen nincs a latin1-ben, ezért lecseréli őket. Ennek elkerülése végett célszerű kiadni a SET NAMES latin2 parancsot, így alkalmazásunk függetlenné válik az éppen használt MySQL szerver beállításaitól.

_charset_, accept_charset

Fentebb már szóba került, hogy külön kezelnünk kell azt az esetet, amikor a felhasználó az oldalunkon szereplő űrlapba olyan karaktert ír be, amely nem szerepel az oldalunkhoz rendelt kódlapban. Először is lássuk, hogy a különböző böngészők mit is tesznek ebben az esetben. A Firefox és Opera úgy jár el, hogy az adott kódtáblában nem megtalálható karaketereket lecseréli azok NCR megfelelőjére, az Internet Explorer ezzel szemben önkéntesen megváltoztatja az elküldendő adatok karakterkódolását, és abban a formában küldi az adatokat. Ezt követően nézzük, hogy egyáltalán milyen mankókat használhatunk az ilyen esetek elleni védekezéshez.

Az egyik segítség egy _charset_ nevű rejtett input mező elhelyzése az úrlapon, melyben a böngésző (amennyiben támogatja ezt a módszert) jelzi, hogy valójában milyen karakterkódolású is a küldött adat. Jelenleg mindhárom a cikkben már említett böngésző támogtja ezt, valamint ez a megoldás a Web Froms 2.0 ajanlás része is. Ha például Internet Explorer alatt nem határozom meg az oldal karakterkódolását, akkor ha az elküldött adat az "abc" szöveg, akkor a _charset_ értéke ISO-8859-1 lesz, de ha már tartalmaz a szöveg mondjuk egy ő betűt, akkor Windows-1250. A fentiek fényében használhtajuk ezt az értéket arra, hogy a kapott adatot az általunk használt kódtáblára konvertáljuk. Egy több országban futó oldal esetén például az volt a tapasztalat, hogy hiába fért bele az összes érintett nyelv minden karaktere a használt kódlapba, mégis néha előfordult, hogy az Explorer kódlapot váltott (valószínűleg copy-paste szövegek esetén), és ilyenkor nagy segítség volt az _charset_ által nyújtott információ.

A másik mankónk a form tag accept-charset attribútuma. Ebben azt tudjuk jelezni a böngésző számára, hogy szerver oldali űrlap feldolgozó scriptünk milyen karakterkódolásokat képes kezelni. Hmm, miért hasznos ez számunkra? Mindjárt látni fogjuk részletesen, de előzetesen annyit, hogy ha itt megadunk egy karakterkódolást, akkor a böngészőknek ezt kéne használni az adatok küldésekor szemben az oldal számára megadottal. Azért írtam, hogy kéne, mert a vizsgált böngészők közül az Internet Explorer ezúttal is tartogat számunkra némi meglepetést.

Vizsgálódásom alapját a következő kérdések képezték:

• Mi az adott böngésző esetén az alapértelmezett kódlap?
  
• Mi történik, ha olyan karaktert ütök le, amely része az oldal kódlapjának?
  
• Mi történik, ha olyan karaktert ütök le, amely nem része az oldal kódlapjának?
  
• Mi történik, az előző esetben, ha van accept_charset megadva, és az érintett karakter része az itt megadott kódlapnak?
  
• Mi történik, az előző előtti esetben, ha van accept_charset megadva, de az érintett karakter nem része az itt megadott kódlapnak?
  

A vizsgálat során a következő kis scriptecskét használtam, melyet működés közben is kipróbálhatunk.A script nagyon egyszerű, lehetőségünk van meghatározni az oldal kódlapját, majd pedig különböző accept-charset beállítások mellett karaktereket küldeni feldolgozásra. Ebben az esetben a script kiírja az _charset_ változó értékét, valamint jelzi, hogy a böngésző karaktert vagy NCR-t küldött-e. Ezenkívül még megjelenít három karaktert, melyeket billentyűzetről nehezen tudnánk bevinni az input mezőbe, de így könnyedén kijelölhetőek és beilleszthetőek. Ezek jelentősége, hogy a mellettük szereplő kódlapban azonos az értékük, és mindegyiküket csak az adott kódlap tartalmazza, így jó alanyai lesznek a tesztelésnek.

A következő táblázatok azt fogják tartalmazni, hogy az egyes böngészők adott beállítások és adott kódlapba tartozó input esetén milyen formátumban és kódlappal küldik a beírt adatokat a szervernek.Lássuk, hogy mit tudunk a fentiekből kihámozni. Az Explorer esetében az alapértelmezett kódlap az ISO-8859-1 (pedig a területi beállításom magyar). A küldendő karakterek szempontjából azt a logikát követi, hogy ha az nem fér bele az oldal kódlapjába, akkor megpróbál találni egy olyan kódlapot, amelynek része, és ebben küldi el. Amennyiben nem talál ilyet, akkor elvileg ő is NCR-t küld, de ezt az esetet nem sikerült kikényszeríteni belőle. Az accept_charset kezelése elég sajátos a másik két böngésző viselkedéséhez képest. Egyrészről fura, hogy bizonyos esetekben figyelembe veszi azt, máskor nem. Ha például egy ISO-8859-1-es oldalunk van, amin egy ISO-8859-2-es karaktert próbálunk küldeni, akkor ha megnézzük a táblázatot, azt látjuk, hogy az accept_charset ISO-8859-2-es értéke esetén a Windows-1250-es kódlapot választja, viszont az UTF-8-as értéket már figyelembe veszi, és azt használja. Másrészről azzal a felfogással is lehet vitatkozni, hogy ha a beírt karakter belefér az oldal kódlapjába, akkor teljes mértékben figyelmen kívül hagyja az accept_charset beállítást, hiszen ez azt mondja meg, hogy a fogadó script milyen kódolásokat képes megérteni, és egyáltalán nem biztos, hogy ennek összhangban kell lennie az oldal kódlapjával (pl. egy magyar oldalról adatokat küldünk egy angol oldalnak).A Firefox esetében is az alapértelmezett kódlap az ISO-8859-1. A karakterek küldésének kezelése letisztultabbnak és logikusabbnak mondható. Ha adtunk meg accept_charset-et, akkor abban a kódlapban próbálja meg elküldeni az adatokat, ha nem akkor az oldaléban. És bármely esetben ha a karakter nem fér bele az érintett kódlapba, akkor helyette a böngésző NCR-t küld.Az Opera teljesen úgy működik, mint a Firefox kivéve, hogy az alapértelmezett kódlap az én konfigomon az ISO-8859-2.

A fentiek alapján láthatjuk, hogy ha az oldalunk UTF-8 kódolást használ, akkor sok gondunk nincs, ellenkező esetben viszont érdemes valamilyen stratégiát kialakítanunk a problémás esetek kezelésére. Döntésünk meghozatalakor még azt vegyük figyelembe, hogy lehetőleg kerüljük azokat az eseteket, amikor NCR-eket kaphatunk vissza, ugyanis ezekkel van egy komoly gond: nem tudjuk eldönteni, hogy egy NCR azért szerepel a szövegben, mert a böngésző helyezte el benne egy problémás karaktert lecserélve, vagy pedig ténylegesen része kéne legyen a szövegnek. Hogy ez jobban érthető legyen: mind az "őő", mind az "őő" input alapján a szerverre "őő" fog megérkezni, és nem tudjuk eldönteni, hogy a felhasználó mit is gépelt be. Ezen információk fényében én azt javaslom, hogy amennyiben nem UTF-8 az oldalunk kódolása, akkor helyezzünk el egy _charset_ nevű rejtett input elemet űrlapjainkon, és állítsuk be az accept_charset attribútumot UTF-8-ra, és a bejövő adatokon a kapott _charset_ érték alapján szükség esetén végezzük el a számunkra megfelelő konverziót (például az iconv PHP kiterjesztés segítségével).