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

Re: XHR: responseText encoding detection

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 26 Feb 2007 13:21:41 +0100
To: "Alexey Proskuryakov" <ap-carbon@rambler.ru>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, public-webapi@w3.org
Message-ID: <op.tocvafxi64w2qv@id-c0020.driveway.uu.nl>

On Mon, 26 Feb 2007 11:29:28 +0100, Alexey Proskuryakov  
<ap-carbon@rambler.ru> 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  

>   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
Received on Monday, 26 February 2007 12:22:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC