PHP hosszú ő ű utf-8 urldecode (megoldva)

Internet: PHP, CGI, stb.

MEGOLDVA

Sziasztok!

Napok óta szenvedek egy problémával. Leírom, hátha valaki tud segíteni...

Formból nem tudok se POST-tal se GET-tel helyesen átadni a form action szkriptjének kicsi vagy nagy hosszú ő-t és ű-t :-(

pl. a kis ő helyett ez megy át : %u0151
vagy a nagy Ű helyett ez: %u0170

Submit után már az URL-ben is ezek a karakterek jelennek meg:
...kereses_feldolg.php?szo=%u0151&miben=targy&ev=2006...

UHU 2.0

Apache:
Server version: Apache/2.2.3
Server built: Sep 4 2006 18:37:06

httpd.conf:
AddDefaultCharset utf-8

PHP:
PHP 5.1.4 (cli) (built: Aug 9 2006 02:59:43)

php.ini:
mbstring.language = Neutral
mbstring.internal_encoding = UTF-8
mbstring.http_input = ASCII,ISO-8859-2,UTF-8
mbstring.http_output = UTF-8
mbstring.encoding_translation = On

Kell még valamit állítanom?

  • 27039 megtekintés

( jokeman | 2006. 12. 19., k – 10:53 )

Ez igy teljesen jol van, ugyanis az URL-ben nem mennek at a specialis karakterek, hanem %-jel utan szamkoddal vannak azonositva. Azok, amiket te is lattal, az őű megfeleloi.
PHP-ben urldecode() fv-t kell meghivni ra, ami visszaadja a rendes szoveget.

nem lehet hogy itt a baj? 


mbstring.http_input = ASCII,ISO-8859-2,UTF-8

ugyertem, a latin2 (iso-8859-2) kodolasban az _osszes_ magyar ekezetes betu benne van, kiveve az o" meg az u", az csak az utf8-ban. viszont ha ilyen sorrentben (ascii - latin2 - utf) bontja ki, akkor az o" meg az u" kivetelevel a latin2 mindent kibont jol, viszont az o" meg az u" utf kodolasa ertelmezheto _mas_ ekezetes (vagy egyeb specialis) karakterkodolasban latin2 alatt, es ez bekavar.

ez csak egy otlet. egyebkent nem hasznalok utf8-at, soha ;]

> a latin2 (iso-8859-2) kodolasban az _osszes_ magyar ekezetes betu benne van, kiveve az o" meg az u", az csak az utf8-ban

A latin2 (iso-8859-2) kódolásban az összes magyar ékezetes betű benne van, az ő Ő ű Ű betűk is.

> viszont az o" meg az u" utf kodolasa ertelmezheto _mas_ ekezetes (vagy egyeb specialis) karakterkodolasban latin2 alatt

Micsoda??? Ne haragudj, de ezen mondatodat totál értelmetlennek találom. "Az ő meg ű utf kódolása" – ezt még értem, ez egy bizonyos bytesorozat. Ezt rossz esetben lehet másképp is értelmezni. Na de mi az, hogy "más ékezetes karakterkódolásban latin2 alatt"? Értelmezhetek egy bytesorozatot mondjuk koi8-r kódolásban latin2 alatt? Vagy hogy??? Totál nem értem a mondatot.

( egmont | 2006. 12. 19., k – 13:17 )

A php.ini-beli változtatásokat nem értem. Én hozzá sem nyúltam a php.ini-hez, és nekem minden ékezet tökéletesen megy automatikusan. Próbáld ki Te is!
Az URL-ben tök oké hogy escape szekvenciát látsz, tudtommal ott nem érvényes közvetlenül ékezetes betűket megadni. A php ezt magától visszaalakítja megfelelően.
Hogyan nyered ki php-ből a kapott értékeket? Gondolom $_GET vagy $_POST tömb, ugye?

Sajna alap php.ini-vel "kérdőjelek-fekete-rombuszba-foglalva" vannak az ékezetes karakterek helyén :-(
Ezért néztem utána, hogy mit lehet ilyenkor tenni és jutottam el a multibyte string functions című fejezetig a php manualban. Ha be van kapcsolva az mbstring.encoding_translation és meg vannak adva azok a beállítások amiket a topik nyitásakor említettem, akkor automatikusan oda-vissza konvertálódnak a karakterek
Akár POST-tal, akár GET-tel megy, TamperData-val látom, hogy már "rosszul" (%u0151) utaznak a formot feldolgozó szkripthez az input tag-ek értékei, ami úgy tűnik teljesen rendben is van, de a visszaalakításkor %u0151-ből nem lesz újra ő betű :-(

Látom nekem kell majd "manuálisan" konvertálni őket, csak azt hittem van esetleg egy egyszerű, beépített megoldás, ami részben jó, de ezek szerint nem teljes :-(

( NevemTeve | 2006. 12. 19., k – 14:21 )

Azzal hogy UTF-8 -at választottál kódolásnak egy kicsit bonyolultabbá tetted a dolgodat... %u szekvenciákat az urldecode nem fordítja vissza, lásd itt a megjegyzéselet:
http://hu.php.net/urldecode

Igen, igen. Pont most akartam írni, és írom is, hogy egy "visszafordító" függvény használata erősen javallott :-)
pl itt egy ilyen: http://hu.php.net/manual/hu/function.urldecode.php#71211

Ismét bebizonyosodott, mielőtt az ember kétségbe esik, olvasson manualt :-)

Kössz mindenkinek probléma megoldva!

És most úgy sejtem, hogy van egy olyan megoldásod, ami tartalmaz körülbelül 3 csavart, holott ha egyet sem tartalmazna, akkor is minden jó lenne.

Én is UHU 2.0-t használok, és éppen (többek között) php-ban fejlesztgetek ezt-azt. A php.ini fájlom teljes mértékben az eredeti. Mindenütt utf-8 karakterkészletet használok.

Csinálok egy html-t, benne egy form. Beleírok mindenféle ékezetes betűket, ő és ű betűt is, € jelet, stb. Kattintok az elküld gombra. Egy php szkript fogadja a választ, amelyik az utf8 karakterkészlet megnevezését követően a print_r függvénnyel kiírja a $_GET vagy $_POST tömb tartalmát. Az összes ékezetes betűt változatlanul, jól kapom vissza, mindenféle egyéb mágia, unescape-elés stb. nélkül, mind get, mind post metódus esetén.

Ami kell: eredeti php.ini, és az, hogy mindkét html oldal (a formot tartalmazó, és a php által generált) is megnevezze, hogy utf8 a kódolása. Tudni kell ugyanis, hogy amikor egy formot kitöltesz, akkor a böngésző az általad beírt adatokat abban a kódolásban küldi el, amelyikben az a html oldal áll, amelyikben a formot kitöltöd. Gyanítom, inverz kérdőjeleket azért láthattál, mert az adatokat fogadó php-ben utf8-at használtál, de a formot tartalmazó html oldal nem nevezte meg, hogy ő is utf8-as, így a böngésző latin1-et feltételezett, és az abból kilógó betűket %u módon escape-elte. A html oldalban kétféleképp tudod megnevezni az utf8-at, vagy a fejléccel, vagy az apache konfigban az AddDefaultCharset UTF-8 szabállyal.

Teljes mértékben igazad van...

Végigbogarásztam mindent, proba formokat barkácsoltam és teljesen jól működik az általad leírt dolgokkal. Akár a $_POST, akár a $_GET tömbben adom át a form adatait, mindkét esetben hibátlan.

És úgy látszik tényleg elérkeztünk a problémához, mert mi van ha a formnak van egy onsubmit eseménye, ami végzi a form feldolgozása után visszaadott tartalom betöltését egy adott div-be. Szóval, ahogy ezt használnám és beteszem a formba, rögtön probléma van.

A szkript egyébként elérhető itt:
http://www.twinhelix.com/javascript/htmlhttprequest/

Sajnos azonban nem értek annyira a JavaScript-hez, hogy alaposan átbogarásszam és esetleg megoldást találjak a problémára...

egmont: Hogy zajlik le a kérés-válasz folyamat ebben az esetben? Egyszerre van jelen az action szkript es egy onsubmit esemény...

Ezzel a htmlhttprequest-tel mit kezdjek, merre menjek tovább?

Utolsó kérdésedben az "action szkript" mit jelent? Ha szerver oldali szkriptre gondolsz (tehát hogy action="valamiurl.php"), nem pedig valami kliens oldali javascript kódra, akkor az történik, hogy először az onsubmit javascript fut le, és ha az nem false-szal tért vissza, akkor utána küldi el a böngésző a form tartalmát a valamiurl.php-nek. Ez többek közt arra jó, hogy fel tudsz dobni javascriptből egy "Tényleg?" ablakot (confirm()) és ha a felhasználó meggondolja magát, akkor mégsem küldi fel az adatokat.

Igen, igen. Form tag egyik attributumára gondoltam.
Köszi, erre voltam kiváncsi.

Akkor szerintem tutti az onsubmit script a ludas, hiszen az fut le eloszor és csak aztán megy a form input elemeinek erteke tovább az "action szkriptre"

Szerintem azzal a htmlhttprequest-tel ne foglalkozz.. Ha lesz időm utánanézek hogy működik, most egyenlőre elég, ha működik :-(

Köszönöm

( NevemTeve | 2006. 12. 19., k – 15:01 )

Próba-programot barkácsoltam, amiben UTF-8 kódolást írtam elő, de nem tudtam reprodukálni a problémát, '%C5%91 %C5%90 %C5%B1 %C5%B0' lett az 'őŐűŰ' (Mozillával és MSIE-vel tesztelve).

Így van (lásd előző post-om). Ha a form-ot tartalmazó html már megnevezi, hogy utf8-as, akkor az URL (get esetén) így fog kinézni, amit a php automatikusan visszaalakít nyers utf8-ra a $_GET tömbben. A problémák akkor kezdődnek, ha a form-ot tartalmazó html nem utf8, hanem valami más (például latin1 vagy latin2) kódolású, de a felhasználó (aki mitsem tud a karakterkészletekről – nem is szabad, hogy tudjon róla vagy hogy érdekelje) véletlenül leüt egy abba nem illeszkedő karaktert.

Látom Te sem tudsz aludni :-)

Szerintem teljesen biztos, hogy a JS miatt van. Ha használom a docClickLoader.submitInto()-t, megadom onsubmit eseménynek, hogy hová töltse be a feldolgozás eredményét, már problémás az ékezetes karakterek kezelése. Ha nincs onsubmit, akkor rendben megy minden az alap UHU-s php.ini-vel.