| Page 2 of 3 | [ 22 posts ] | Go to page Previous1, 2, 3 Next |
|
I wish I knew enough about this character encoding issue. I admit that I don't even know what steps I went through to have my stuff working, which is quite pathetic. Of course it helps that my ISPs are Spanish so they have their servers set up to handle diacritical marks and Euro signs, I guess part of the merit goes to them since I really can't tell how I've managed.
All this makes me believe there is something that you can do on the server side to have everything working fine. Since my forms and AJAX data go to the same servers that served those pages, if the server knows the character encoding of the pages it serves, it should expect the data coming back from those pages to be in that same encoding. After all, you can manipulate the headers on an XDR connection, but you can't in a plain <form> so, how do you manage? I know I do because I have it working, but I don't know how. I wish I knew. |
|
Satyam,
Re: there is something that you can do on the server side to have everything working fine. Umm, not really. (While it can work in specific cases, it won't work in the "everything" case.) Your servers and browsers are all W Europe and could be set to use either 8859.1 or utf-8. You don't know which and either will work (as long as both the server and client match). But if you want your server software to work with a browser in the Japan locale/character set, then you need to get everything right. Which is easy to do--just set the character set, explicitly, to utf-8. Or if you want things to work and the browser is utf-8 while the server framework is 8859.1 (the original poster's situation), then you also need to set the character set explicitly. What you can do on the server side is to change the web framework's character encoding default to be utf-8. But doing so is NOT recommended: it is framework-dependent and will not work if other clients of the framework are counting on the default being ascii or 8859.1. The correct answer is to follow the specifications: specify the character set to be used for each request/reply. That's why correct web pages (responses) specify their character set. And why correct requests (eg datasource requests) also specify their char set. Depending on the client's and server's character set defaults matching correctly is a mug's game. While it can work correctly, it is a "last-century solution" and tends to break in weird ways at unexpected times. Re: plain forms: the browsers use the character encoding of the page that holds the form. Though you can explicitly set it if you want to via accept-charset <form accept-charset="utf-8"> To see what the page's encoding is, ask the browser. Eg, in Firefox, see Tools > Page Info: Encoding See http://htmlpurifier.org/docs/enduser-utf8.html and http://www.phpwact.org/php/i18n/charsets for more info. Last edited by larryk on Wed Jun 16, 2010 9:01 am, edited 1 time in total. |
|
Testing if your web application's character encoding is set up correctly:
Using a web browser, store the string Iñtërnâtiônàlizætiøn into your system, into your database. It should look like this: ![]() Then retrieve the information. Does it still look correct? Or if it turned into something like: Iñtërnâtiônà lizætiøn then you have a problem. Note that Iñtërnâtiônàlizætiøn is 20 characters long, but takes up 27 bytes in memory using UTF-8 encoding. |
|
Here's an additional idea from Stackoverflow: you should also test your app by trying some right-to-left text.
Here's the test: enter שלום ירושלים (by copying/pasting this text) Then see if it appears correctly on output. It should look like: ![]() Note: This YUI library forum software is implemented correctly for international characters. So if the above text does not match the above image, the problem is somewhere on your browser, os, perhaps a proxy, etc. |
|
I'll go and read the articles you reference right away and do the tests you mention, but I have just read your messages and just wanted to say right away: wow! Can you put it down for the YUI Blog so it stays there as a reference? It would really be great!
Thanks |
|
Thanks for your replies!
I tried to set the charset like this: Code: dataSource = new YAHOO.util.DataSource(form.action + "?page=search&"); var connect = dataSource.connMgr; connect.initHeader('Content-Type', 'text/html;charset=UTF-8', true); connect.setDefaultPostHeader(false); But the charset is still ISO-8859-1. What am I doing wrong? |
|
I think that the Content-type applies to post data, not to the arguments after the ? in the URL. I'm still reading the documents Larry suggested so I'm still quite clueless about all this.
|
|
Lisa,
How do you know that the charset is 8859.1? Can you use the "Net" window of firefox to see what is being sent from the YUI component? |
|
The character set for the get parameters ("query string") seems to usually go by the encoding for the current page. But FF may be the exception.
Some info here: http://jira.codehaus.org/browse/JETTY-113 ADDED: Some more info: http://kb.mozillazine.org/Network.stand ... ncode-utf8 It appears to be a bug in IE's implementation that then caused a mismatch between the standard (use UTF8) and the common practice (use the page's encoding). The standard is section 2.5 (near the end) of rfc3986 You should be sure to test with different browsers including IE, FF, Safari, etc. |
|
Here's a brand new post on the topic.
http://www.456bereastreet.com/archive/2 ... s_in_urls/ My thoughts: 1) This needs testing. 2) It's looking like the encoding used for characters in the query string may be browser dependent. -- needs to be confirmed. 3) Sending via post is starting to look pretty attractive... |
| Page 2 of 3 | [ 22 posts ] | Go to page Previous1, 2, 3 Next |
| You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum |
© 2006-2013 Yahoo! Inc. All rights reserved.
All code on this site is licensed under the BSD License unless stated otherwise.
About This Site · Security Contact Info
Powered by phpBB® Forum Software © phpBB Group