W3C home > Mailing lists > Public > public-webapi@w3.org > February 2007

Re: XHR: responseText encoding detection

From: Alexey Proskuryakov <ap-carbon@rambler.ru>
Date: Mon, 26 Feb 2007 13:29:28 +0300
To: Bjoern Hoehrmann <derhoermi@gmx.net>, <public-webapi@w3.org>
CC: Anne van Kesteren <annevk@opera.com>
Message-ID: <C2089138.357AE%ap-carbon@rambler.ru>

On 2/22/07 12:26 PM, "Bjoern Hoehrmann" <derhoermi@gmx.net> wrote:

> You have a similar situation e.g. for text/css and text/html, where the
> specifications similarily override their underlying protocols. It does
> not strike me as very likely that implementers will implement the draft
> so that including an external document using some markup and using XHR
> will result in widely different results.

  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.

  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>.

- WBR, Alexey Proskuryakov
Received on Monday, 26 February 2007 10:29:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT