Ékezetes karakterek JAVA VM-ben

Linux-kezdő

Ékezetes karakterek JAVA VM-ben

  • 7611 megtekintés

( thomek | 2005. 08. 23., k – 12:44 )

Áttettem ide ezt a problémát , hogy ne zavarjon be a másik topicba, meg engem is érint , nállam is SuSe 9.3 van és ugyanezzel a problémával küzdök, annyi volna a hozzászólásom hogy a karakterek kizárólag a JAVA által létrehozott (jojatek.hu, jatek.hu) oldalakon hibásak , olyan mint amikor egy FAT32 fáljrendszeren hibásan adom meg a karakterkódolást, és az ékezetek helyett kockát kapok, szóval szerintem a JAVA VM-nek kellene megmondani hogy nem jó kódlapot használ de hogyan?

huncutka írta:

Amit jó volna még tudni:
- minden java applet csinalja ezt, pl. a chat.hu is? (ha igen, akkor locale v. jre beállítás)

- milyen distro-t használsz, milyen platformon (pl. gentoo+ppc v. frugalware+amd64). Ez sokat számíthat, mert pl. regebbi UHU-ban Blackdown j2re volt, fw amd64 portjában szintén, ha nem tévedek stb.

A kurnik.org, és a chat.hu nem csinálja. Ott jó az ablak, és a privi is. Helyesek az ékezetek, én is látom, és mások is az enyémeket...
A jójáték, és a játék.hu az gáz... A jón a privi ablak pl megjelenik, de nincs szövegsor, nem lehet bele írni.
A böngészők: firefox 1.0.6, opera 8.0.2, mozilla 1.7, és a beépített konqi 3.4"level b".
A distro-m suse 9.3, és a YAST segítségével frissítettem a beépített 1.4.2-es java-t, 1.5 update 4-re.
A platform egy NF7-S + AMD 3200 + 512 DDR-rel megtámogatva.
Minden böngészőben hibásak a karakterek, de csak a nevek, és amiket írunk... A java által generált gombok, pl "üres szék" helyesen jelennek meg.

Remélem, így már könnyebben tudtok segíteni, mert fontos lenne, és viszonylag sürgős...

Ja! Smile)) És nem szabadultok kedveskéim olyan könnyen, mert ha ezt megoldjátok, lesz mégegy problémám...
A Mercury-val messengerezek, és a webkamerám nem műxik.... Smile) De még nem sikítok:)))

Pusszantás:

( huncutka | 2005. 08. 24., sze – 23:09 )

Na sziasztok :)

Nem mondjátok, hogy ennyire reménytelen a probléma, amit felvetettem!?!?!?!?
Azt gondoltam, hogy ennyi okos fickó majd összedugja a fejét, és hipp-hopp megoldják a helyzetet...:)
Ezek szerint nem igazán... ;-)
Hát jó....

Pusszantás mindenkinek! ;-)

Hunci :)

Milyen oprendszert hasznalsz es mi a default encodingja? Szerintem ez az appletek hibaja. Ha nem adnak meg default encodingot a JVM-nek, akkor az a system encoding-gal indul. Szerintem nalad UTF-8 (aze a jovo), mig Winen ez Windows-1250 (vagy vmi mas nem UTF-8). Es az appletek a wines encodingra vannak felkeszitve (hibasan).

Egy forumon talaltam megoldast:

"Hello!
Csak a karakterkódolással van a gond.
Nekem is ugyanez a problémám volt, de aztán rátaláltam a megoldásra.
Meg kell nyitni a Sun Java 6 Plugin Control Panelt (Rendszer->Beállítások) a Java fülön kattints a View... gombra, ezután a megjelenő ablakban a Runtime Parameters oszlopban lévő cellába írd be ezt: -Dfile.encoding=cp1250"

PS:Programozoi trehanysag, mert mindenki Win-t hasznal... (csak egy tipp)

Szerintem M$ trehanysag mivel:

Minden rongydozer verzio tudja az utf-8-at, csak eppen nem hasznlaja alapertelmezetten.
Mi magyarok 15 millioan 4 kulonbozo kodlapot hasznalunk, es mindegyikben mashol vannak a hosszu dupla maganhangzok (dos852,cp1250,8859-2,utf-8)

Mennyivel egyszerubb lenne, ha default utf-8 lenne az alapertelmezett es akkor nem kellene hulyere szivnunk a fejunket ilyen problemakkal.

Az eroforrasigeny magyarazatot nem tudom elfogadni, mivel a mai gepeknek mar nem okozhat ez gondot.

Meg a Win7-ben is alapertelmezett a 1250-es kodlap:(

Az eredeti hiba leirásból kb nem derül ki semmi, de úgy tűnik elég sokan nincsenek képben a JVM-mel, és a karakter kódolásokkal. A JVM-ben a String-ek nem 8 bittes bájtok sorozataként, hanem 16 bittes karakterenként vannak reprezentálva. A leforditott bytekódban is lehet használni bármilyen unicode karaktert, tökéletesen kezeli (éppenséggel UTF-8-szerű kódolással van eltárolva, de ez teljesen mellékes a szempontunkból). Amit el lehet rontani egy applet-ben - amennyire vissza tudok emlékezni a 90-es évek végekbeli tapasztalataimra :
- nem biztos, hogy a font amit szeretnénk használni, az biztosit megfelelő karaktert a megjelenitéshez
- ha a gombok/feliratok szövegei nincsenek beégetve a kódba, akkor valószinűleg valami property fájlból jönnek, s itt a fejlesztők jó része hajlamos elfelejtkezni arról, hogy a beolvasásnál az alapértelmezett rendszer encoding-ra hagyatkozzon. Ez amúgy a platform függetlenség miatt van, ha bármilyen java program meg akar nyitni egy filet, amit az adott rendszeren szerkesztettek, elvárható, hogy tudja mi a rendszer encoding-ja, akár utf-8, cp1250, vagy EBCDIC legyen is az.
Kb annyira releváns egy applet alapján a jvm-et szidalmazni, mint egy gnome/kde segfault miatt a C/C++ halálát vizionálni.

" JVM-ben a String-ek nem 8 bittes bájtok sorozataként, hanem 16 bittes karakterenként vannak reprezentálva. A leforditott bytekódban is lehet használni bármilyen unicode karaktert, tökéletesen kezeli (éppenséggel UTF-8-szerű kódolással van eltárolva, de ez teljesen mellékes a szempontunkból)."
Ne keverjük itt a dolgokat, a charset meg az encoding baromira nem ugyanaz. Nyilván 8 bites bytesorozatként van ábrázolva a String a memóriában, MINDEN dolog 8 bites byte-ok sorozataként van reprezentálva.

A Unicode az egy charset, azaz bizonyos, a való világban előforduló karakterekhez rendel egy numerikus értéket (ún. Unicode code point).
Ezek a numerikus értékek ún. plane-kbe vannak szervezve, egy plane 64k karaktert tartalmaz. Jelenleg 17 ilyen plane van, azaz összesen 17*64k karaktert ismer a Unicode.
Belül a JVM a char adattípussal a 0-0xFFFF Unicode code pointokat tudja kezelni, azaz a Basic Multilingual Plane-t (BMP). Minden char 2 byteon, UTF-16 kódolással tartalmaz 1 BMP karaktert, a char[], CharSequence (és így a String is) ilyen karakterek rendezett sorozatát tárolja. Amennyiben a BMP-n kívüli karaktereket kell használni, akkor ún. surrogate párok segítségével, 2 char reprezentál 1-1 karaktert, UTF-16 kódolásban.
Egy int már minden Unicode karakter code point-ját tudja tárolni.
A java.lang.Character metódusai pedig így működnek: amelyik char értéket fogad paraméterül, az nem tudja támogatni a surrogate párokat, míg az, amelyik intet, az igen.

Az encoding meg azt jelentené, hogy 1-1 karaktert milyen bytesorozattal kell reprezentálni.
Nyilván nem lehet minden Unicode karaktert minden encodingban reprezentálni, mert az adott encoding nem Unicode (hanem pl. ASCII) karakterek bytesorozattá alakítására lettek kitalálva (pl. ASCII esetén nincs értelmezve a magyar ékezetek többsége, az ISO-8859-1 charsetben és kódolásban viszont igen, mivel ebben a charsetben a magyar ékezet karakterek értelmezve vannak - van hozzájuk code point).

Bonyolult dolog a karakterkódolás, főleg azért, mert a múlt tapasztaltai alapján sokak fejében a charset = encoding, mivel pl. ASCII, ISO-8859-1 és a többi , 256 karakteres karakterkészlet és 8 bites karakterkódolás 1:1 megfeleltetést tett a code point és a byte ábrázolás között.

IMHO a JRE API-jának is a hibája ez. A legtöbb esetben ugyanis platformfüggetlen formázásra van szükség, az API-k default működése viszont az, hogy locale-ből veszi az encodingot. Inkább ennek kellene explicit megadással előcsalogatható működésnek lenni, és nem fordítva. Bevallom én is rendszeresen beszívom ezt a hibát, pedig tudom, hogy létezik, és figyelek is rá. Amikor eszembe jut :-). Persze az automatikus tesztek kihozzák ezeket a hibákat, mielőtt a felhasználóhoz kerülnének.

JRE API-t viszont megváltoztatni nem lehet, csak kibővíteni, úgyhogy ez a hiba a porondon marad még egy darabig mindenkinek a jobb szándéka ellenére is.

...mert nem ertesz hozza.

Egyertelmu, hogy ha vki platformfuggetlen alkalmazast akar irni, akkor vagy explicit definialja az encodingot, timezone-t, locale-t vagy felkeszul ra, hogy ez userenkent elter.
Azt, hogy az appletek iroja erre nem keszult fel, nem a JVM hibaja.

Eeeeeeemberek!

Az megvan, hogy a "vacak" HTML ezt megoldotta az appletek szuletese elott??

A JVM hibaja, bocs, ill. nem a VM-e, mert API szinten van elcs.ve az egesz, de hal' egnek eltunt mar a webrol nagyreszt ez a teljesen eszement borzalom,amit Appletnek hivtunk.

"Az megvan, hogy a "vacak" HTML ezt megoldotta az appletek szuletese elott??"
Fejtsd ki, hogy mire gondolsz itt, mert sztem megint erdobe vagy.

A JVM api lehetoseget biztosit, hogy ugy olyan encodingot hasznaljon a programozo amilyet akar (pl.: UTF-8-at). Egy alkalmazason belul akar tobbet is. Sot at lehet allitani globalisan, hogy az egesz JVM mit hasznaljon defaultnak. Nem igazan ertem mi rossz ezen. Az, hogy a systemhez alkalmazkodik, ha a programozo nem csinal semmit? Hat ez ket rosszabb kozul a kisebbik rossz valasztasa volt gondolom 10+ evvel ezelott.

Dolgoztam en vele, csak soha nem vettem be a marketing hype-ot, es mindig utaltam mint a sz.rt. De nem faparaszt vagyok belole, egy idoben - a felvetelik miatt - fejbol vagtam a Java Language Specification, 3rd Edition-t, a J2EE 2.1-gyel egyutt (kulonos tekintettel az Entity Bean-ekre).

Nyilvan ha nem hanynek amikor ranezek egy Java kodra, biztos tobb tapasztalatom lenne benne, igy azonban csak kovetem a hireket (mert muszaj), es igyekszem tuzzel-vassal irtani ezt a COBOL-szintu remalmot.

Igen, nyilvan ezert van ma is rengeteg ekezethibasan megjeleno oldal. Ugyanis a kovetkezok befolyasoljak az encodingot:
1. Maga a file kodolasa (azaz a karakterek milyen bytesorozatkent kerultek tarolasra)
2. A fileban szereplo encoding meghatarozas
3. A szerver altal elkuldott Content-Encoding header.
Ez a harom barmikor ellentmondhat egymasnak
Itt a logika, ami szerint a bongeszoknek figyelembe kellene vennie ezeket:
http://blog.whatwg.org/the-road-to-html-5-character-encoding
A HTML ezt annyira megoldotta az appletek elott, hogy a HTML5 a HTML 4 modszeret meg egy lepessel egesziti ki, azaz meg most sincs megoldva a problema.

Nice try, HTML fanboy.

Mikor talalkoztal legutoljara olyannal, hogy linuxon mas encodinggal jelent meg a weboldal mint windowson? Edesmindegy hany lepes a rezolucio, a vegen a user egy oldallal fog talalkozni, ami jo encodingban lesz.

A java fanboyok ritkan userorientaltak, csak azt nem ertem, attol a szintaktikatol hogy nem tunik fel, hogy fejleszteni is szar, dehat ilyen a szerelem.

Ugye amig nem volt Android, javat csak ott hasznaltak, ahol alapvetoen azt hasznaltal amit akartal, a userelmenyt max a sebessegben tudta befolyasolni (web szerveroldal)

De úgy tűnik (többen jelezték) az a probléma, hogy a programozó volt trehány, aki az adott kódot előállította. Abban amúgy egyetértünk, hogy elég szomorú, hogy a probléma még mindig fennáll. Azaz, hogy 7 év alatt nem találtak olyan embert, aki ki tudná javítani a kódot, illetve hogy az elmúlt sok évben még mindig nagyon sok programozó nem tanult meg helyesen programozni.