On Mon, 26 Feb 2007 11:29:28 +0100, Alexey Proskuryakov
<[EMAIL PROTECTED]> wrote:
In my testing, I have found that existing implementations already deduce
the charset for XHR response in a way that's drastically different from
normal page loading.
But should we really make it be like that? Once HTML5 is there we probably
want .responseXML to work for text/html documents as well and we probably
want the encoding to be derived the same way HTML5 specifies it should be
derived.
The default is indeed UTF-8 in all cases (rather than us-ascii or the
browser default). The content is only examined for encoding information
if it's XML, so an encoding specified in an Http-Equiv meta or a CSS
@charset is ignored. An XML declaration does have an effect if the
response is XML.
The above is a generalization, of course, as the behavior is not very
consistent between browsers (for example, IE sometimes uses different
encodings for responseText and responseXML!). Firefox behavior looks the
most logical to me, and Safari/WebKit nightly builds implement it now.
I have some ad hoc tests at
<http://nypop.com/~ap/webkit/xmlhttprequestenc/001.html> and
<http://nypop.com/~ap/webkit/xmlhttprequestenc/xmlhttprequestenc.html>.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
