Comments on: Java kimenet UTF-8 kódolásban http://cubussapiens.hu/2008/04/java-kimenet-utf-8-kodolasban/ A Cubus Sapiens oldal Wed, 28 Dec 2011 13:46:30 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Stampie http://cubussapiens.hu/2008/04/java-kimenet-utf-8-kodolasban/comment-page-1/#comment-32 Stampie Wed, 30 Nov -0001 00:00:00 +0000 #comment-32 Tényleg gyönyörű dolgokat lehet a karakterkódolásokkal művelni. Külön röhej, hogy az Eclipse alapértelmezetten valamilyen közép-európai kódolást ajánl fel a forrásfájloknak. Windows-on az ISO változatot, Mac-en egy Mac CE típust. Szóval tényleg el lehet szórakozni vele szépen. Egyébként meg az oldal története során küzdöttem már párszor szintén a karakterkódolásokkal. Nem egy hálás téma, rengeteg szívás csak azért, hogy minden úgy menjen, ahogy az elvárható. Tényleg gyönyörű dolgokat lehet a karakterkódolásokkal művelni. Külön röhej, hogy az Eclipse alapértelmezetten valamilyen közép-európai kódolást ajánl fel a forrásfájloknak. Windows-on az ISO változatot, Mac-en egy Mac CE típust. Szóval tényleg el lehet szórakozni vele szépen.

Egyébként meg az oldal története során küzdöttem már párszor szintén a karakterkódolásokkal. Nem egy hálás téma, rengeteg szívás csak azért, hogy minden úgy menjen, ahogy az elvárható.

]]> By: Balage http://cubussapiens.hu/2008/04/java-kimenet-utf-8-kodolasban/comment-page-1/#comment-33 Balage Wed, 30 Nov -0001 00:00:00 +0000 #comment-33 Nálam az eclipse UTF-8-at használ alapértelmezetten, azzal nem volt soha problémám. De valóban általános ez a probléma. Szvsz ebből a szempontból átmeneti állapotban van az ipar, épp kihevertük az ascii megrázkódtatásait és az alternatívák alkotta káosz között lavírozva haladunk az UTF-8 felé, ami (talán) a megváltást hozza magával. Nálam az eclipse UTF-8-at használ alapértelmezetten, azzal nem volt soha problémám. De valóban általános ez a probléma. Szvsz ebből a szempontból átmeneti állapotban van az ipar, épp kihevertük az ascii megrázkódtatásait és az alternatívák alkotta káosz között lavírozva haladunk az UTF-8 felé, ami (talán) a megváltást hozza magával.

]]> By: Stampie http://cubussapiens.hu/2008/04/java-kimenet-utf-8-kodolasban/comment-page-1/#comment-34 Stampie Wed, 30 Nov -0001 00:00:00 +0000 #comment-34 Legkorábban akkor hoz megváltást, ha a Java-n belül is UTF-8 lesz, nem pedig a most használt UTF-16. Addig csak közelíthetjük az ideális állapotot, de el nem érhetjük. Az UTF-8 és az UTF-16 között elég alapvető különbség, hogy az UTF-16 fix szélességű (azaz minden karakter két bájt), míg az UTF-8 nem (karakterenként 1-3 byte). Szóval ebben még mindig vannak lehetőségek szívásra. Ezekkel a dolgokkal még sok játék lesz, a legkülönfélébb nyelvek UTF-támogatása is problémás, gondolok itt az egyik legelterjedtebb webes nyelvre, a PHP-ra. Legkorábban akkor hoz megváltást, ha a Java-n belül is UTF-8 lesz, nem pedig a most használt UTF-16. Addig csak közelíthetjük az ideális állapotot, de el nem érhetjük. Az UTF-8 és az UTF-16 között elég alapvető különbség, hogy az UTF-16 fix szélességű (azaz minden karakter két bájt), míg az UTF-8 nem (karakterenként 1-3 byte). Szóval ebben még mindig vannak lehetőségek szívásra.

Ezekkel a dolgokkal még sok játék lesz, a legkülönfélébb nyelvek UTF-támogatása is problémás, gondolok itt az egyik legelterjedtebb webes nyelvre, a PHP-ra.

]]> By: Balage http://cubussapiens.hu/2008/04/java-kimenet-utf-8-kodolasban/comment-page-1/#comment-35 Balage Wed, 30 Nov -0001 00:00:00 +0000 #comment-35 A PHP-val még mindig kevesebbet szívok, ugyanis az nemes egyszerűséggel nem törődik a kódolással, így olyan kódolású a kimenet, mint a bemenet. Ha minden UTF-8 lenne, akkor ezzel nem jelentene problémát. Csak azért hiányoznak a különböző kódolást támogató függvények, mert vannak különböző kódolások. (nem állítom, h az UTF-8-nak kell lennie a végső válasznak, de könyebb lenne az élet, ha csak egyféle kódolással kéne számolni) A PHP-val még mindig kevesebbet szívok, ugyanis az nemes egyszerűséggel nem törődik a kódolással, így olyan kódolású a kimenet, mint a bemenet. Ha minden UTF-8 lenne, akkor ezzel nem jelentene problémát. Csak azért hiányoznak a különböző kódolást támogató függvények, mert vannak különböző kódolások. (nem állítom, h az UTF-8-nak kell lennie a végső válasznak, de könyebb lenne az élet, ha csak egyféle kódolással kéne számolni)

]]> By: thsoft http://cubussapiens.hu/2008/04/java-kimenet-utf-8-kodolasban/comment-page-1/#comment-42 thsoft Wed, 30 Nov -0001 00:00:00 +0000 #comment-42 Arról nem is beszélve, hogy a PropertyResourceBundle fájlokat (ami a programok honosításához legegyszerűbben használható, beépített megoldás) latin-1 (!) kódolással hajlandó csakis és kizárólag beolvasni a Java, a többi karaktert escape kóddal kell belebuherálni. És mindezt az a Java teszi, amiben a core string típus támogatja a Unicode-ot, és mindezt pont abban a feature-ben, amit a legtöbben használnának i18n-re. Hackkel meg lehet oldani, h más kódolást is elfogadjon, de akkor az automatikus locale-resourcebundle hozzárendelés nem oldható meg. Szóval no comment... :( Arról nem is beszélve, hogy a PropertyResourceBundle fájlokat (ami a programok honosításához legegyszerűbben használható, beépített megoldás) latin-1 (!) kódolással hajlandó csakis és kizárólag beolvasni a Java, a többi karaktert escape kóddal kell belebuherálni. És mindezt az a Java teszi, amiben a core string típus támogatja a Unicode-ot, és mindezt pont abban a feature-ben, amit a legtöbben használnának i18n-re. Hackkel meg lehet oldani, h más kódolást is elfogadjon, de akkor az automatikus locale-resourcebundle hozzárendelés nem oldható meg. Szóval no comment… :(

]]> By: Stampie http://cubussapiens.hu/2008/04/java-kimenet-utf-8-kodolasban/comment-page-1/#comment-46 Stampie Wed, 30 Nov -0001 00:00:00 +0000 #comment-46 Az élet szép. Honosítani meg minek? Használjon mindenki kínait :) Na jó, lehet tört angol is :) Az élet szép. Honosítani meg minek? Használjon mindenki kínait :) Na jó, lehet tört angol is :)

]]>