Tag: utf8

Java kimenet UTF-8 kódolásban – második felvonás

Ezt nem lehet megunni, újra és újra hasonló problémákba ütközök. Most kivételesen nem parancssorban kellett UTF-8 kimenetet generálnom, hanem a Java 6 beépített HTTP szerveréről a kliens felé adott generált válaszban merült fel ugyanez a probléma. A különös az volt, hogy működött, mindenféle konverzió nélkül, tehát teljesen nyugodt voltam, hogy ez a kódrészletet jól írtam meg. Órákba tellet rájönnöm, hogy ez a feltételezés hibás volt.

Ezt nem lehet megunni, újra és újra hasonló problémákba ütközök. Most kivételesen nem parancssorban kellett UTF-8 kimenetet generálnom, hanem a Java 6 beépített HTTP szerveréről a kliens felé adott generált válaszban merült fel ugyanez a probléma. A különös az volt, hogy működött, mindenféle konverzió nélkül, tehát teljesen nyugodt voltam, hogy ez a kódrészletet jól írtam meg. Órákba tellet rájönnöm, hogy ez a feltételezés hibás volt.

A problémakör egyszerű, bár érdekes. Widget-alapú AJAX-os webalkalmazást fejlesztek az önálló laboromhoz, de erről később. A lényeg az, hogy amikor a felhasználó csatlakozik a szerverhez, az egy generált HTML oldallal válaszol, és minden további feladatra JavaScript kódot küld, amit a kliens lefuttat. A javascript kódban a szövegeket előrelátóan Base64 kódolásban vittem át, így ezekkel probléma nem volt. Nem ez volt a helyzet azonban a generált HTML kóddal. Arra lettem figyelmes, hogy a webalkalmazást megváltoztatva a böngészőben nem jelenik meg semmi..

A helyzet felettébb furcsa volt, a generálás során nem merült fel hiba, sőt, a generált kimenet a szerver oldalon jó volt és az átvitel sem dobott kivételt. A kliens oldalon megérkeztek a fejléc sorai, de nem kapott kimenetet. Nem értettem a problémát, hiszen addig jó volt, és azon a részen nem változtattam. Hosszas próbálgatás és debugolás után rájöttem, hogy a hiba megjelenése erősen korrelál azzal a ténnyel, hogy a generált kimenetben szerepel-e ékezetes karakter. Ekkor merült fel bennem, hogy a probléma a kódolással van.

Tehát, a megoldás az, hogy előkeresem a [intlink id=”556″ type=”post”]korábbi cikkemet[/intlink], és az ott szereplő megoldást extrapolálom az én esetemre. Azaz, amikor a HttpExchange kimeneti adatfolyamát lekérem, egy egyszerű PrintStream helyett a következő módon wrappolom, és a böngészőt is értesítem róla, hogy milyen kódolásban kap adatot:


PrintStream out = new PrintStream(arg0.getResponseBody(),true,"UTF-8");
arg0.getResponseHeaders().add("Content-Type","text/html; charset=UTF-8");

A nagyobbik fejtörést az okozta, hogy még így se működött, a hiba ugyanaz maradt, csak annyi változott, hogy a Web dev toolbar már kijelezte az újonann beadott header sort is. Ekkor megakadt a szemem a következő soron:


arg0.sendResponseHeaders(200, text.toCharArray().length);
out.print(text);

Ezzel ugye elküldöm a kliensnek hibakódot (200 = OK), illetve a küldött tartalom hosszát. Ez automatikusan hozzáad egy “Content-Length” sort a header-ekhez. Amikor ezt írtam, jó ötletnek tünt. De! A java belső UCS kódolásában a karakterek száma nem egyezik meg a byte-ok számával a karakterlánc UTF-8 -beli kódolásában. A megoldás: a sendResponseHeaders() metódus második argumentuma legyen 0. Ez azt jelenti, hogy tetszőleges hosszúságú tartalmat küldhetünk el, a bytesorozat végét az jelzi, hogy bezárjuk a kapcsolatot.

Így tényleg működik. csak az érdekesség kedvéért egy rövid idézet a HttpExchange dokumentációjából:

"If the call to sendResponseHeaders() specified a fixed response body length, then the exact number of bytes specified in that call must be written to this stream. If too many bytes are written, then write() will throw an IOException. If too few bytes are written then the stream close() will throw an IOException. In both cases, the exchange is aborted and the underlying TCP connection closed."

Hogy mi ezzel a probléma? Csak az, hogy a dokumentáció szerint kivételt kellett volna kapnom, amikor úgy zárom le, hogy a küldött byte-ok száma nem egyezik az előre megadottal. Ez viszont nem történt meg, hanem egy furcsa, és visszakövethetetlen hibajelenségbe ütköztem. Talán gyorsabban megtalálom a hibát, ha kapok egy értelmes hibaüzenetet.

Java kimenet UTF-8 kódolásban

Csalódtam a rendszeremben. Pár nappal ezelöttig abban a szent meggyőződésben voltam, hogy a Kubuntu tetőtől talpig UTF-8 kódolással dolgozik. Nos ez többnyire igaz. A java VM esetén az stdout alapértelmezett kódolása latin-1, ami normális esetben nem tűnik fel. Önálló labor feladatom során merült fel, hogy egy java program kimenetét kellett böngészőben megjeleníteni. A program bemenetként egy UTF-8 kódolású XML fájlt kapott, fel sem merült bennem, hogy gond lehet a kódolással.

Csalódtam a rendszeremben. Pár nappal ezelöttig abban a szent meggyőződésben voltam, hogy a Kubuntu tetőtől talpig UTF-8 kódolással dolgozik. Nos ez többnyire igaz. A java VM esetén az stdout alapértelmezett kódolása latin-1, ami normális esetben nem tűnik fel. Önálló labor feladatom során merült fel, hogy egy java program kimenetét kellett böngészőben megjeleníteni. A program bemenetként egy UTF-8 kódolású XML fájlt kapott, fel sem merült bennem, hogy gond lehet a kódolással.

Meglepetésemre a program kimenetén minden ékezetes karaktert szorgalmasan kicserélt egy-egy kérdőjelre. Néhány óra bogarászás és kutatás után kiderült, hogy a Java belső kódolásként [[http://hu.wikipedia.org/wiki/UCS|UCS]]-t használ, minden bemenetet erre konvertál, és ebből alakítja át a kimenetet a megfelelő kódolásra.

További kutatással sikerült egy egyszerű módot találnom, amivel beállíthatom a sztandard kimenet kódolását. UTF-8 beállításához a következő néhány sorral kell kezdeni a main() függvényt:


try{
PrintStream out = new PrintStream(System.out,true,"UTF-8");
System.setOut(out);
}catch(Exception e){}

Rövid magyarázat: a PrintStream osztály egy egyszerű szűrőként dolgozik, ami a bemenetét UTF-8-ra átkódolva adja tovább a megadott Stream-re (jelen esetben a System.out). Ezután beállítjuk a létrehozott Stream-et alapértelmezett kimenetként. Voilá. Minden további kimenet UTF-8 kódolású lesz.