Karakterkódolási probléma
Üdvözletem mindenkinek!
Nos, nem tudom a problémám mennyire specifikus, de megérzéseim szerint nem annyira.
Igazából írhattam volna más fórumra is ezt a kérdést, de eléggé átfogónak tűnik számomra. A problémám a következő:
Egy weboldalt írok megrendelésre, ez lenne az első "komoly" - inkább nem annyira komolytalan - weboldal, melyet készítek. A problémát bárcsak leszűkíthetném egy adott böngészőre, de nem tudom.
Első sorban, helyileg készítettem el a weboldal 3/4-ét a saját gépemen helyi apache futtatásával. Használtam én már 8869-2 (Latin-2), UTF-8 kódolástól kezdve egészen az UTF-32-ig mindent. Természetesen sok tutorialon túlestem már, mind angol, mind magyar nyelvűn egyaránt. A jelenlegi helyzet szerint UTF-8-ra van állítva minden:
MySql egybevetés: utf8-hungarian-ci
MySql táblázat: utf8-hungarian-ci (oszloponként -> longtext)
Meta tag : <META http-equiv="Content-Type" content="text/html; CharSet=utf-8"/>
Probléma 1:
Jelenleg Chrome-on, FF-en, valamint Safarin tökéletesen működik az oldal és a kereső.
Azonban Opera esetén kicsit érdekes a weboldal megjelenése: http://volkswagenaudi.hu
Mintha nem is érdekelné őt különösebben, hogy én utf8-at próbálnék használni.
Mielőtt a mindenféle különleges kérdésekkel kerülnék a sortűz közepébe: igen, a domain utf8-ra van állítva, igen végignéztem az opera beállításait, alapértelmezetten van - automatikus kiválasztás, de az utf8-ra sem javul meg -, és igen próbáltam a php header(..) script használatát is, sikertelenül. Gyakorlatilag teljesen elkódolja az opera az egész weboldalt. Míg nálam volt a weboldal, helyi apache-on, tisztességesen futott, de a domainen teljesen megzavarodik szerencsétlen.
Minden egyes fájl UTF-8 BOM mentesen lett elmentve (Notepad++). Ezek mellett egy
mysql_query("SET NAMES 'utf8'"); csodálatos sor is ékesíti a mysql.php fájlomat is, mely elméletileg az egybevetést határozza meg a query(k)-hez.
Probléma 2:
IE (internet explorer) barátunk megint sikereset alkotott. Nem is tudom, talán én nem tudom kezelni a buta állatokat, de nem szereti túlságosan a kódolásomat.
A keresés a következőképpen néz ki - ha megnézitek az oldalt az előbb megadott linken, akkor látni is fogjátok: A keresőből kinyert adatokat egy Xmlhttprequest-el küldöm el egy php-nak. Ez eddig rendben. Utánajártam, természetesen nem a javascript borítja meg a változókat. A GET metódus használata után, az átadás elég sikertelennek bizonyul mind IE mind az opera használata alatt. A jelen álláspont szerint, az IE sikeresen, szépen olvas a DB-ből, HA nem ékezetes a lekérdezés. Ez azt jelenti, hogy:
SELECT * FROM items esetén kiírja a "Ő" karaktert tartalmazó termékeket teljesen szépen, hibátlanul. Azonban, ha én rákeresnék a következő betűcskére: "Ő", már borul az egész, mert ő egy szép kis négyzetet akar lekérdezni, valahogy így: SELECT "négyzetféle-izé" FROM items.
Összefoglalva. A stíluslap Opera esetén teljes káosz a domainen. Operánál borul a MySql, a php, a html.
IE esetén az ékezetes lekérdezés nem akar működésképessé válni.
Tehát, tudnom kellene valamit? Elsiklok valami fölött? Az opera nem szereti ezt meg azt? Esetleg más karakter set, struktúrával, kódolással kellene próbálkoznom?
Köszönöm a megtisztelő figyelmeteket és várom a kérdéseket, válaszokat. További szép reggelt/napot/estét!
UI: http://weblabor.hu/cikkek/karakterkodolasiproblemakkikuszobolese
hasznos cikknek találtam, de nem sokat segített sajnos.
■ Nos, nem tudom a problémám mennyire specifikus, de megérzéseim szerint nem annyira.
Igazából írhattam volna más fórumra is ezt a kérdést, de eléggé átfogónak tűnik számomra. A problémám a következő:
Egy weboldalt írok megrendelésre, ez lenne az első "komoly" - inkább nem annyira komolytalan - weboldal, melyet készítek. A problémát bárcsak leszűkíthetném egy adott böngészőre, de nem tudom.
Első sorban, helyileg készítettem el a weboldal 3/4-ét a saját gépemen helyi apache futtatásával. Használtam én már 8869-2 (Latin-2), UTF-8 kódolástól kezdve egészen az UTF-32-ig mindent. Természetesen sok tutorialon túlestem már, mind angol, mind magyar nyelvűn egyaránt. A jelenlegi helyzet szerint UTF-8-ra van állítva minden:
MySql egybevetés: utf8-hungarian-ci
MySql táblázat: utf8-hungarian-ci (oszloponként -> longtext)
Meta tag : <META http-equiv="Content-Type" content="text/html; CharSet=utf-8"/>
Probléma 1:
Jelenleg Chrome-on, FF-en, valamint Safarin tökéletesen működik az oldal és a kereső.
Azonban Opera esetén kicsit érdekes a weboldal megjelenése: http://volkswagenaudi.hu
Mintha nem is érdekelné őt különösebben, hogy én utf8-at próbálnék használni.
Mielőtt a mindenféle különleges kérdésekkel kerülnék a sortűz közepébe: igen, a domain utf8-ra van állítva, igen végignéztem az opera beállításait, alapértelmezetten van - automatikus kiválasztás, de az utf8-ra sem javul meg -, és igen próbáltam a php header(..) script használatát is, sikertelenül. Gyakorlatilag teljesen elkódolja az opera az egész weboldalt. Míg nálam volt a weboldal, helyi apache-on, tisztességesen futott, de a domainen teljesen megzavarodik szerencsétlen.
Minden egyes fájl UTF-8 BOM mentesen lett elmentve (Notepad++). Ezek mellett egy
mysql_query("SET NAMES 'utf8'"); csodálatos sor is ékesíti a mysql.php fájlomat is, mely elméletileg az egybevetést határozza meg a query(k)-hez.
Probléma 2:
IE (internet explorer) barátunk megint sikereset alkotott. Nem is tudom, talán én nem tudom kezelni a buta állatokat, de nem szereti túlságosan a kódolásomat.
A keresés a következőképpen néz ki - ha megnézitek az oldalt az előbb megadott linken, akkor látni is fogjátok: A keresőből kinyert adatokat egy Xmlhttprequest-el küldöm el egy php-nak. Ez eddig rendben. Utánajártam, természetesen nem a javascript borítja meg a változókat. A GET metódus használata után, az átadás elég sikertelennek bizonyul mind IE mind az opera használata alatt. A jelen álláspont szerint, az IE sikeresen, szépen olvas a DB-ből, HA nem ékezetes a lekérdezés. Ez azt jelenti, hogy:
SELECT * FROM items esetén kiírja a "Ő" karaktert tartalmazó termékeket teljesen szépen, hibátlanul. Azonban, ha én rákeresnék a következő betűcskére: "Ő", már borul az egész, mert ő egy szép kis négyzetet akar lekérdezni, valahogy így: SELECT "négyzetféle-izé" FROM items.
Összefoglalva. A stíluslap Opera esetén teljes káosz a domainen. Operánál borul a MySql, a php, a html.
IE esetén az ékezetes lekérdezés nem akar működésképessé válni.
Tehát, tudnom kellene valamit? Elsiklok valami fölött? Az opera nem szereti ezt meg azt? Esetleg más karakter set, struktúrával, kódolással kellene próbálkoznom?
Köszönöm a megtisztelő figyelmeteket és várom a kérdéseket, válaszokat. További szép reggelt/napot/estét!
UI: http://weblabor.hu/cikkek/karakterkodolasiproblemakkikuszobolese
hasznos cikknek találtam, de nem sokat segített sajnos.
HTTP?
Bővebben?
Ha magáról a kereső formról beszélünk, ott nincs semmi ilyesmi. Mert az nem egy form. Csak egy rakás input, select, és egy keresőgomb, ami meghívja ezt a httprequestet. De nem ott száll el a dolog. Kiírattam alert-el minden esetben a változókat, ott még helyesek voltak. A php-ban szúródik el az egész.
Ez a HTTP fejléc mi akar lenni? Megkérhetlek, hogy bővebben is írj erről? :)
szerk: Ha most csak az IE-ről beszélünk, akkor ott a négyzetes probléma áll fenn. Szerintem azért követi el ezt a mocskos bűnt, akárhányszor használom a php-t, mert valami karakterkódolási-konverzión megy keresztül az adat, és így teljesen meghal. Csak kérdés ezt honnan szedi? Magától? Vagy én siklottam el valami fölött? Aúgy a web-server.hu a megnevezett domain. Nem tudom segít-e ez bármit is.
De bármikor nyomon követhető a probléma a fent linkelt weboldalon. Próbáljátok meg a keresőt megbombázni pár ékezettel. Az SQL utasítást kiíratom, úgy jobban fog látszódni mi is történik valójában.
Kereső
Igen
Köszönöm a linket, hasznos, de igazából a php-val lesz a probléma. Minden megfelelően működik, DB-ből kiíratás, statikus megjelenés (html), csak a php-ba kerülő változó átadása során lesz valami teljesen rossz.
header
Szerintem Poetro arra gondolt, hogy adsz-e ki chatset utasítást a fejlécben. A webszerverek alapértelmezetten ISO-8859-1 karatkerkódolással küldik el a kimenetet. Ha a teljes oldalad UTF-8-at használ, érdemes minden PHP feldolgozás elején kiadni ezt a fejlécet:
header...
Az index, és egyéb php-ba is include-olom a mysql.php-t, melynek az első sorában ott bambul a:
Ugyanis a rendszer a következőképpen működik:
Írtunk Visualc#-ban egy termékkezelőt, amely egy termekek.csv fájlt tölt fel ftp-n keresztül a domainre. Magát a csv fájlt ez az un. db_update.php intézi el egy egyszerűbb függvénnyel. Ezt a php-t egy Cronjobs meghívja x periodicitással.
De ez csak mellékesen.
http://volkswagenaudi.hu/
itt látni mindent. Ha bármilyen böngészővel megnézi az ember, flottul működik, kivéve az IE-t. IE esetén a stíluslap is szétesik. Alapértelmezettként latin-1-et használ, de ha a buta állatjának megmondom, hogy utf-8 for ever van, akkor sem mozdul.
Ha esetleg (kedves Thom, vagy bárki) megnéznéd, vagy valaki megnézné az oldalt, talán szembetűnőbb a probléma. Mivel az egész karakterkódolási-rendszer kicsit átláthatatlan számomra nem egészen tudom körülírni. Már ott tartottam, hogy .htaccess fájlokkal próbáltam javítani a hibán.
header
Szerintem Poetro arra gondolt, hogy adsz-e ki chatset utasítást a fejlécben. A webszerverek alapértelmezetten ISO-8859-1 karatkerkódolással küldik el a kimenetet. Ha a teljes oldalad UTF-8-at használ, érdemes minden PHP feldolgozás elején kiadni ezt a fejlécet:
szerk: bocs, egy küldésre 2* ment be ugyanaz a komment. Ha egy moderátor erre jár, kéremszépen az egyiket törölni.
Opera ready
Menü
Ötletnek jó volt.
ilyen kis cukikat ír ki.
Nem tudom mennyire fog másoknak - nektek - látszódni.
SELECT * FROM items WHERE kulcsszavak LIKE '%ablakt�%'
szerk: van értelme a base64_decode/encode használatának explorer esetén?
Minden böngészőben lehetőség
Meg tudjuk esetleg nézni magát az oldalt valamilyen formában?
Benne van a topik nyitó
Egyébként nekem van egy olyanom, hogy a többi tesztelt böngészőben van fixen beállítva az UTF8, mert nálam FF14 alatt is rosszak az ékezetek.
Hát ez érdekes... Ugyanazzal a headerrel, de UTF-8-ban írt szöveggel jól jelenik meg a linuxom apache szerveréről megjelenített szöveg.
Amit tőle kérek le, abban hibásak az ékezetek, de nem mind.
Az "Üdvözöljük..." kezdetű sor rendben van.
De alatta, a "Volkswagen..." kezdetűben már hibásak az ékezetes karakterek.
Benne van a topik nyitó
Megnéztem a forrást, a HTML-be eleve rosszul kerülnek bele az UTF-8 karakterek, mintha duplán kódolnád. Olyan, mint amikor BOM nélkül küldöd ki az UTF-8-as fájlokat, és ANSI-ban nézed meg.
Offtopic: az oldalon semmi sem indokolja, hogy IE9-nél régebbi böngészőkön ne működjön.
Localhoston teljesen jól fut,
Azonban a domainen nem.
A nyitószöveg azért rossz, mert nem volt kedvem 635235-jére is átírni. Csak átkonvertáltam ANSI-ból utf-8 BOM nélkülibe és elcseszte. Majd kijavítom. De a menün látni lehet, hogy jó a stíluslap kódolás.
(szerk: javítva.)
Nálam egyforma jó/rossz FF és
Érdekes. És mi rossz
Amúgy web-server domaint használ a megrendelő. Azon belül is belehet állítani a kódolást a domainre. Na most az semmit nem jelent, kipróbáltam mindenre. Semmit sem ér...
Közben látom, javítottad:
Na akkor most próbáld meg
Nyisd meg az oldalt IE9-el. Keress rá a "motorháztető" szövegre a tematikus (select) keresővel. Nem lesz eredmény. Ezután tedd mindegyre és írd bele a keresőbe, hogy "motorháztető".
Na ez az egyetlen baj van az IE-vel. Ha ez javítva lenne, kész lennék a motor oldalával.
Aham... ez tényleg nem jó.
Passz.
Ami biztos: ha automatára állítom az IE-t, akkor nem utf-8-nak detektálja az oldalt. (úgy fest, win7 alatt valamiért fix utf8 az alapértelmezett kódolás)
Na látod. :( már hetek óta
Na meg igen.. ha lapértelmezett detektálásra teszem akkor borul az egész. Akkor nyugodtam meg, mikor a google-t is alapértelmezetten nyitottam meg és elcsesződött, szóval van hivatkozási alapom arra, hogy a google is elcseszi vagy, hogy az MS sz*r :)
Bár, talán a régiótól függően beállítja. Bár lehet nem. Mert egy tutorialban azt olvastam, hogy szereti a latin-1-et.
Szóval most ez a probléma. És fogalmam sincs mit tegyek. Gondoltam a base64_encode/decode-ra, csak az a baj vele, hogy már a .... = $_GET['valami']-nél elszállnak az ékezetek. R-go nem lehet vele dolgozni. Nem tudom átkódolni. Legalábbis szerintem.
Nem tudod megnézni, milyen
Mintha az URL-be írt ékezetek miatt vadulna meg IE alatt...
header('Content-Type:
Nem erre gondoltam, hanem a
ui: legalább én is tanultam valami újat. Nem tudtam, hogy form nélkül ennyire gázos lehet a karakter kódolás.
Nem a form volt a baj. A Form
ITT
egyszerűen escape-eli a változókat az uri beírása előtt majd utána visszakódolja utf8-ra. Nem egy nagy szám, de mire megtaláltam...
Mivel csak IE alatt nem
És azt hogyan tegyem, ha az
-----
Természetesen az IE Activexobject-et használ. Nem kizárt, hogy ezen hal be:
Tehát, nem értem mitől változna ha az egész mindenséget belepakolnám egy formba, ha nem az küldi el a változókat az x-y.php-nak, hanem egy javascript pumpálja az értékeket bele egy változóba. és ugye visszatéréskor:
Az AJAX requestben semmi
Értem. Bár folyamatosan
Mellesleg, akkor nem érdekes, ha a .js fájl ansi-ban van. Mert akárhogy próbálnám átrakni utf8 bom nélkülire, nem rakja át, mindig ansi marad.
szerk: és ezt a syntax-ba hova és hogy pakoljam bele? utánanéztem, de nem egészen látom át, hogy ez a script hogy megy. hol kéne kódolni és dekódolni az uri-t?
szerk2: az ajax teljesen jó. nem a request tolja el. a php-ban esik szét. nem csak az "ő" hanem minden ékezetes karakter.
Egy kicsit találomra állsz
A decodeURIComponent percent-encodingot csinál, ami egy egyszerű megoldás arra, hogy lásd, pontosan milyen bájtokat tartalmaz a Javascript string. Ha már ott baj van, akkor az input mező kiolvasásával kell valamit kezdeni; máskülönben az XmlHttpRequest objektumban romlik el valami.
Nehezen hihető, hogy a
Ezt a kódolást ismerem, csak
IE alatt más domaint
Az általad linkelt oldalt
Nos a domain egy és ugyan az. Belehet állítani egy, az egész domainre kiterjedő alapkódolást. Ez lehet "alapértelmezett", utf, latin-1 és latin-2. De érdektelen, bármit állítgatok rajta nem változik, tehát már felülírja a header. Biztosan böngésző-oldali lesz a probléma, de nem tudom, hogy mi. Az inputból mindent helyesen szed ki.
Jah és megjegyzésként. Mikor a lokális kis apache-omon futtattam a dolgot, még latin-2re volt állítva minden. Akkor ment az IE, csak az opera haldoklott.
szerk: köszönöm még egyszer az oldalt, nehéz ilyeneket találni. Akárhol, akármilyen tutorialt nézek, vagy ellentmondásba kerülök, vagy dezinformációk tömkelege fogad, amikről persze nem tudok.
szerk2: megpróbáltam urikódolni a változókat a java-ban és azt visszakódolni php-ban, de eredménytelenül.
szerk3: butaság is volt, mert a get megcsinálja. Érthetetlen, minden böngészőn jó, csak ezzel nem. Ha azonban megadom neki a szó szerinti utasítást: SELECT * FROM items WHERE kategoria ='ablaktörlő' akkor működik. Szóval mindenképpen azzal a get-el lesz a baj.
Az apache configban is csak
A $_GET tartalma egyszerűen az URL kérdőjel utáni részének megfelelő szakasza. A PHP nem ismeri a karakterkódolás fogalmát, a PHP stringek egyszerűen bájtsorozatok, pontosan azok a bájtok szerepelnek bennük, amik az URL-ben is; ha UTF-8 kódolású stringeket akarsz, akkor az URL-nek is UTF-8-nak kell lennie. (Amit a legtöbb böngésző alapból használ, de az IE nem; ha például kézzel beírsz valamit a címsorba, az operációs rendszer nyelvéből vett kódolást fog használni, magyar Windows esetében pl. ISO-8859-t. Form nélküli input elemnél a józan ész azt diktálná, hogy a dokumentum kódolását használja, de hát az IE meg a józan ész...)
Továbbra is a formos dologgal próbálkoznék.
Hát rendben. Nekifutok még
szerk: 1x próbáltam az xmlhttrequest headert, de nem nagyon akart működni. És nem kellett a formra accept charset-et állítani. Ahogy mondtad.
Mintha az inputokból kijövő adat nem tartalmazná a kódolási header-t
Kódolás
escape()
, hanem azencodeURIComponent()
függvénnyel kódolom. Egy próbát megér.Szerkesztve: most látom, hogy tgr már javasolta.
Szerkesztés 2: egy másik projektben az adatokat tartalmazó objektumot a
json_stringify()
-vel alakítom karakterlánccá, és azt küldöm POST-tal. Mindkét esetben gond nélkül működik IE7-en is a dolog.Az escape() is teljesen jó
Azért köszönöm, fejben tartom :)