W3C home > Mailing lists > Public > www-international@w3.org > October to December 2013

[Bug 23927] ASCII-incompatible encoder error handling

From: <bugzilla@jessica.w3.org>
Date: Tue, 26 Nov 2013 16:33:39 +0000
To: www-international@w3.org
Message-ID: <bug-23927-4285-2TRVBpCNL8@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23927

Addison Phillips <addison@lab126.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |addison@lab126.com

--- Comment #4 from Addison Phillips <addison@lab126.com> ---
If the mode is URL, emitting 0x3F might make some sense. Normally, though, a
utf-16-encoder would emit U+FFFD when it errors in this way. I think I would
prefer if the resulting UTF-16 actually had U+FFFD instead of 0x3F (and
actually, if this is a UTF-16 *encoder*, emitting the single byte 0x3F would
result in the string not be valid UTF-16).

Emitting an HTML entity makes sense when encoding HTML text (the resulting
isolated surrogate code point still shows in the output, but the text is now
validly UTF-16).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 26 November 2013 16:33:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:35 UTC