W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

[Bug 14676] For UTF-16, the oder of the steps in "change the encoding" doesn't seem right.

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Nov 2011 10:19:22 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RLXuk-0008Iy-Jh@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14676

KangHao Lu <kennyluck@w3.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennyluck@w3.org

--- Comment #1 from KangHao Lu <kennyluck@w3.org> 2011-11-02 10:19:22 UTC ---
s/oder/order/

Consider a simple test case like,
<script>alert(document.characterSet||document.charset)</script><meta
http-equiv="content-type" content="charset=utf-16"> . By the pre-scanning
algorithm, the first try should be utf-8. But then in step 1 of the "change the
encoding" uft-16 isn't at that moment equivalent to utf-8, so a reload is
possible depending on how you interpret the "may" in step 4.

Gecko doesn't reload in this case. IE first gives the default encoding (which
contradicts the pre-scanning algorithm but that's another issue), and then
"unicode" (but decodes the content in "utf-8").

Anyway, is allowing reloading in my example intentional? If not, I propose we
move step 3 before step 1.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 2 November 2011 10:21:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 November 2011 10:21:26 GMT