It's a bug in IE. There is (was?) a similar bug in Safari. What happens is that the browser does not re-parse all the information it has on the page when loading it from the cache, and so it creates the form control in a different way than the first time. What it boils down to is exactly what you see: you put some non-ASCII character in a field, submit, back, and your characters are mangled or gone. There is nothing you can do to fix it, you can only work around it.
I'd second the suggestion of giving the error together with the form, pre-filled with the submitted values.
| [reply] |
What happens when you hit the back button in the browser should not be affected by anything the script does (nor can it be influenced by it). That would be a purely client-side (browser) issue.
I am not sure how this has anything to do with the characters being UTF-8 or not. Does it display non-UTF8 characters correctly? In any case, you have to make sure that you have the character set correctly specified in the HTTP headers and/or the HTML file itself. Different browsers have different logic to figure out the character set, and if the problem you describe only happens with non-Ascii characters, it could be caused by the browser getting things mixed up.
| [reply] |
There several ways to suggest the character encoding of an HTML page presented by a browser. The two that immediately spring to mind are the content-type HTTP header with a character set and the equivalent meta tag. The latter has the advantage that it is actually part of the page and should be available at any time.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
update: The following reference may be useful - http://www.w3.org/International/O-charset
| [reply]
[d/l] |
| [reply] |