Hi Tobias, Am 16.03.2007 um 15:55 schrieb Tobias Koller (GERMO GmbH):
>> Well, I'm afraid this is not really a solution. encodeURIComponent is >> the way to go! > > I know. But escape() is a quick solution for my problems till > someone could give me another one ;) > Selfhtml says: "encodeURICompontent will replace escape() in future" I'd say that's news from the past ;-) encodeURIComponent() has been available for quite some time (even in IE 5.5), and it should always be used instead of escape()! >> This is exactly what should be sent to the server. It's your _server_ >> code that should be changed (so it uses UTF-8 decoding for the >> params), not anything on the client side. > > Hm...i don't know if my server_code is the reason for my problems. > I'm using PHP...maybe I need to use utf8_decode()...i will try Yes, you could use utf8_decode when working with PHP, but that's still no long-term solution. Imagine a visitor to your site from Japan who enters some Japanese characters in an input field. utf8_decode is defined as returning an ISO-8859-1 string, so what should this function do with characters that have no ISO-8859-1 representation? The real solution is to use UTF-8 (or another unicode encoding) throughout your application. For example, when you store entries by users in a database, then simply store them as UTF-8. If you want to return them inside an HTTP response, just send the whole response as UTF-8 (with the correct HTTP header so the browser does the right thing). Ideally, you never need to use utf8_decode or encode (except when talking to broken APIs that can't deal with anything else than ISO-8859-1). Of course, you can just continue with escape() and leave the server as it is - but as I said, it will break as soon as your site gets an international visitor who enters non-latin characters in an input field. >> I don't understand what you mean by that. The server should clearly >> receive "test%C3%A4" (as this is what gets passed to setData). What/ >> how exactly did you check with firebug? > > It's the "POST-Param" I checked in firebug. > Check the details(params, post, headers, response) of the sent url > in the firebug-console. Under the "POST"-tab there are all sent > Post-Parameters and Values. That's where I saw "testä". Could this > really be a server-side-problem? It looks like Firebug decodes the %-escapes correctly, but interprets the result as ISO-8859-1. I can't blame it for that since it can't know the encoding expected by the server (it probably defaults to the page encoding). Regards, Andreas ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
