On 2012-04-18 22:34, Glenn Maynard wrote:
(It would be pretty neat if that could be changed to *always* using HTML escapes for non-ASCII, except when encoding to UTF-8, since that's not introducing anything new--you can already receive&x1234; escapes in POST data--and it would alleviate the "form submit encoding depends on the source page's encoding" problem. I guess this must break pages somehow, or vendors would have done this long ago.)
It naturally would break any page that's deliberately using a non-UTF encoding. Web applications do not - and should not be - HTML-character-reference-decoding their input because this would mangle literal use of & characters (which are *not* escaped to &). There is no way to correctly recover a value that has been through this form of lossy encoding.
The charref-encoding-fallback is an ugly legacy hack that confuses web authors and tempts them into using submitted strings directly without HTML-escaping, resulting in security holes. Its use should be minimised wherever possible.
-- And Clover mailto:[email protected] http://www.doxdesk.com/ gtalk:[email protected]
