ugrás a tartalomhoz

Karakterkódolási probléma

sykorax · 2012. Aug. 11. (Szo), 04.07
Ü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.
 
1

HTTP?

Poetro · 2012. Aug. 11. (Szo), 07.54
És az oldalt milyen HTTP fejléccél küldöd ki? Az űrlapnak is megadhatsz karakterkódolást.
2

Bővebben?

sykorax · 2012. Aug. 11. (Szo), 13.51
Ez mit akar jelenteni?

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.
3

Kereső

Hidvégi Gábor · 2012. Aug. 11. (Szo), 14.21
5

Igen

sykorax · 2012. Aug. 11. (Szo), 14.38
A meta tag benne van, és a scriptek include tag-jében is szerepel az accept-charset is.

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.
6

header

Thom · 2012. Aug. 12. (V), 10.44
Ez a HTTP fejléc mi akar lenni?


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("Content-type: text/html; charset=utf-8");
A fejlécben érkező charset a böngészőben felülírja a meta utasítást. A meta charset-re ezzel együtt szükség lehet más helyzetben, tehát érdemes ott hagyni (pl. ha a teljes honlapoldalt lementik saját gépre, mert akkor ugye már nincs fejléc).
8

header...

sykorax · 2012. Aug. 12. (V), 18.44
Persze használom. Az egész oldal, gyakorlatilag egy index.php-ból és sok feldolgozó php-ból áll.
Az index, és egyéb php-ba is include-olom a mysql.php-t, melynek az első sorában ott bambul a:
header('Content-Type: text/html; charset=utf-8');
Minden működik, meglepően még a csv fájlt is megfelelően kezeli a db_update.php.
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.
7

header

Thom · 2012. Aug. 12. (V), 10.46
Ez a HTTP fejléc mi akar lenni?


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("Content-type: text/html; charset=utf-8");
A fejlécben érkező charset a böngészőben felülírja a meta utasítást. A meta charset-re ezzel együtt szükség lehet más helyzetben, tehát érdemes ott hagyni (pl. ha a teljes honlapoldalt lementik saját gépre, mert akkor ugye már nincs fejléc).

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.
4

Opera ready

sykorax · 2012. Aug. 11. (Szo), 14.28
Szerencsére megoldottam Operára. Vicces tortúra volt. Már csak az IE hibádzik. Fogalmam sincs miért rossz. De csak a bejövő php megy tönkre. MySql-ből rendesen írat ki, és a statikus megjelenés (HTML) is megfelelő, ékezetes. Az az érdekes, hogy a php valószínűleg nem utf-8-ban jelenik meg, mert még az "ó","é","á"... egyszerű ékezetes karakterek is rosszul jelennek meg. Az IE kockaként jeleníti meg, de tudjuk, hogy ez az az elcseszett kérdőjel :)
9

Menü

Hidvégi Gábor · 2012. Aug. 12. (V), 19.00
Ha jobb gombot nyomsz, és megnézed IE alatt az oldal kódolását, nincs véletlenül fix (nem UTF-8) karakterkészlet beállítva neki?
10

Ötletnek jó volt.

sykorax · 2012. Aug. 12. (V), 19.58
Érdekes, nem írja ki a querit sem ha ékezetes a lekérdezés. Komolyan, fejre fordulok lassan. És mi az, hogy nem látja minek állítottam be az oldalt? Eldobom az agyam. Ott a meta, a php header, a domain utf8-on. Minden egyes dokumentum utf-8 (DOM nélkül) mentve. Nem értem O.o

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?
11

Minden böngészőben lehetőség

Hidvégi Gábor · 2012. Aug. 12. (V), 20.26
Minden böngészőben lehetőség van fix karakterkódolást választani, amivel felüldefiniálhatod az oldal által megadottat.

Meg tudjuk esetleg nézni magát az oldalt valamilyen formában?
13

Benne van a topik nyitó

eddig bírtam szó nélkül · 2012. Aug. 12. (V), 21.11
Benne van a topik nyitó szövegében. :-)

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.
15

Benne van a topik nyitó

Hidvégi Gábor · 2012. Aug. 12. (V), 21.20
Benne van a topik nyitó szövegében.
A nyitószöveg nagyon rosszul olvasható, ha nem szólsz, magamtól nem olvastam volna el, ez egy hányás.

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.
16

Localhoston teljesen jól fut,

sykorax · 2012. Aug. 12. (V), 21.23
Localhoston teljesen jól fut, ha a saját gépemen ügyködöm vele.
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.)
17

Nálam egyforma jó/rossz FF és

eddig bírtam szó nélkül · 2012. Aug. 12. (V), 21.24
Nálam egyforma jó/rossz FF és IE9 alatt is.
18

Érdekes. És mi rossz

sykorax · 2012. Aug. 12. (V), 21.29
Érdekes. És mi rossz konkrétan? A stíluslap, vagy a kereső?
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...
19

Közben látom, javítottad:

eddig bírtam szó nélkül · 2012. Aug. 12. (V), 21.29
Közben látom, javítottad: kettővel feljebb leírtam, hogy mi jelent meg rosszul. Most rendben van mindenhol az ékezet.
20

Na akkor most próbáld meg

sykorax · 2012. Aug. 12. (V), 21.32
Na akkor most próbáld meg azt, amiről beszéltem.
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.
21

Aham... ez tényleg nem jó.

eddig bírtam szó nélkül · 2012. Aug. 12. (V), 21.40
Aham... ez tényleg nem jó. Nem is kell beírni, ha a listából választom, akkor is hibás.
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)
22

Na látod. :( már hetek óta

sykorax · 2012. Aug. 12. (V), 21.52
Na látod. :( már hetek óta szenvedek vele.
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.
24

Nem tudod megnézni, milyen

eddig bírtam szó nélkül · 2012. Aug. 12. (V), 22.21
Nem tudod megnézni, milyen headerek közlekednek a böngésző és a szerver között?
Mintha az URL-be írt ékezetek miatt vadulna meg IE alatt...
27

header('Content-Type:

sykorax · 2012. Aug. 12. (V), 22.43
header('Content-Type: text/html; charset=utf-8');
mysql_query("SET NAMES 'utf8'");
Mindenhol ezek vannak include-olva. Minden egyes php fájlban.
34

Nem erre gondoltam, hanem a

eddig bírtam szó nélkül · 2012. Aug. 13. (H), 07.16
Nem erre gondoltam, hanem a ténylegesen átmenő adatforgalomra a kliens és a szerver között, de amint látom, már megoldódott a gond.
ui: legalább én is tanultam valami újat. Nem tudtam, hogy form nélkül ennyire gázos lehet a karakter kódolás.
35

Nem a form volt a baj. A Form

sykorax · 2012. Aug. 13. (H), 13.25
Nem a form volt a baj. A Form csak ahhoz kellett, hogy kiderüljön, ténylegesen a httprequest szúrja el a dolgot IE alatt. Mivel IE latin1-et használ, borul az egész. A get után nem kódolja vissza rendesen. Találtam egy megoldást:
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...
12

Mivel csak IE alatt nem

tgr · 2012. Aug. 12. (V), 20.54
Mivel csak IE alatt nem működik jól, nyilván az IE nem megfelelő kódolással küldi el a mező tartalmát. Első körben megpróbálnék egy form elemet tenni köré és abban specifikálni az utf-8-at.
14

És azt hogyan tegyem, ha az

sykorax · 2012. Aug. 12. (V), 21.17
És azt hogyan tegyem, ha az egész össze vissza van. Egy httprequestel kapom el az adott elementek valuejét.
-----
(... = getElementById('valami').value);
(... = $('#valami').attr('value'));
-----
Természetesen az IE Activexobject-et használ. Nem kizárt, hogy ezen hal be:
		if (window.XMLHttpRequest)//IE7+, Firefox, Chrome, Opera, Safari
			xmlhttp=new XMLHttpRequest();
		else//IE6, IE5
			xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
			
		xmlhttp.onreadystatechange=function(){
			if (xmlhttp.readyState==4 && xmlhttp.status==200)
				document.getElementById("items_name").innerHTML=xmlhttp.responseText;

		}
Tehát abban van logika, hogy a GET metódus által történő változóátadáskor meghal az egész történet. Mivel az url-ben nem lehet ékezetes karakter ezért dekódolni is kellene. Ebben az esetben, egy httprequestel viszont nem az url-be írom, hanem egy cache-be kerül vagy a memória legmélyebb bugyraiba. De a másik felmerülő kérdés, ahogyan azt a kommentben látni is lehet IE6, IE5 esetén használatos az activexobject.

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:
		xmlhttp.onreadystatechange=function(){
			if (xmlhttp.readyState==4 && xmlhttp.status==200)
				document.getElementById("items_name").innerHTML=xmlhttp.responseText;

		}
Belepakolja egy items_name div-be azt, ami a php-ból visszajön, amit itt küld el a php-nak a java:
		xmlhttp.open("GET","keresomotor.php?marka="+marka+"&modell="+modell+"&kategoria="+kategoria+"&evjarat="+evjarat+"&kulcsszavak="+kulcsszavak+"&rendezes="+rendezes+"&checked="+checked,true);
		xmlhttp.send();
Lehet összevissza beszélek, ha igen, akkor elnézést, és örülök ha kijavítotok, de a csökött agyammal így tudom felfogni a jelenlegi helyzet menetelét :)
23

Az AJAX requestben semmi

tgr · 2012. Aug. 12. (V), 22.07
Az AJAX requestben semmi nemtriviális karakterkódolás nincsen, kap egy Javascript stringet (a Javascript stringek mindig UTF-8-ban vannak), azt percent-encode-olja, ami egy egyszerű bájtonkénti kódolás, és elküldi a szervernek. Jó eséllyel már a szövegmezőből kiolvasáskor elromlik a dolog. (Persze teszteld le, hogy tényleg így van-e -> encodeURIComponent.) Erre javasoltam a formos dolgot.
25

Értem. Bár folyamatosan

sykorax · 2012. Aug. 12. (V), 22.41
Értem. Bár folyamatosan kiírattam alert-el a változókat. Vagy az semmit nem tesz?
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.
26

Egy kicsit találomra állsz

tgr · 2012. Aug. 12. (V), 22.43
Egy kicsit találomra állsz ehhez a kódolás dologhoz. Miért számítana, hogy mi a javascript forrásfájl kódolása? Legalább az alapokkal érdemes tisztába jönni, különben csak vaktában vagdalkozni tudsz.

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.
28

Nehezen hihető, hogy a

tgr · 2012. Aug. 12. (V), 22.44
Nehezen hihető, hogy a Firefox által küldött helyes kódolású AJAX requestet jól olvassa a PHP, az IE által küldött helyes kódolásút meg nem. Valahol a böngészőoldalon kell eltérésnek lennie.
29

Ezt a kódolást ismerem, csak

sykorax · 2012. Aug. 12. (V), 22.49
Ezt a kódolást ismerem, csak nem névről. De igen, mindenen működik, csak IE-n nem. Lehet köze a domain-hez? az apache-ban elrejtette ini-hez?
30

IE alatt más domaint

tgr · 2012. Aug. 12. (V), 22.56
IE alatt más domaint használsz? Vagy más apache beállításokat? (Elvileg megoldható, a gyakorlatban soha senki nem csinálja, csak egész nagy projekteknél, ahol pontosan tudják, hogy mit akarnak, úgyhogy nem hinném.) Ha nem, akkor mégiscsak böngészőoldalon lesz az eltérés.
31

Az általad linkelt oldalt

sykorax · 2012. Aug. 12. (V), 23.44
Az általad linkelt oldalt hasznosnak találtam. Érdekes volt, nehezen találni ilyen precíz és komoly oldalakat, pláne ami leköt - nameg engem angolul. De sajnos sokkal nem jutottam előrébb.
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.
32

Az apache configban is csak

tgr · 2012. Aug. 13. (H), 01.38
Az apache configban is csak azt állítod, hogy milyen Content-Type fejlécet küldjön, ha kézzel megadsz valamit PHP-ben, az felülírja.

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.
33

Hát rendben. Nekifutok még

sykorax · 2012. Aug. 13. (H), 03.18
Igazad van. Sikerült. A formmal tökéletesen megy. Nem lehet beállítani valami headert az xmlhttrequestnek?

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
36

Kódolás

Hidvégi Gábor · 2012. Aug. 13. (H), 17.21
Megnéztem, hogy én mit használok AJAX-os formküldésre, és ott a paramétereket nem az escape(), hanem az encodeURIComponent() 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.
37

Az escape() is teljesen jó

sykorax · 2012. Aug. 13. (H), 21.02
Az escape() is teljesen jó volt. Feljebb linkeltem egy megoldást. Végül is sokféle módon meglehetett oldani, de örülök, hogy egyet megtudtam valósítani :D
Azért köszönöm, fejben tartom :)