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

[Bug 23927] New: ASCII-incompatible encoder error handling

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

            Bug ID: 23927
           Summary: ASCII-incompatible encoder error handling
           Product: WHATWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encoding
          Assignee: annevk@annevk.nl
          Reporter: simon.sapin@exyr.org
        QA Contact: sideshowbarker+encodingspec@gmail.com
                CC: mike@w3.org, www-international@w3.org

http://encoding.spec.whatwg.org/#encodings

[[
Otherwise, if encoder's error handling mode is URL, emit byte 0x3F.

Otherwise, emit the result of running utf-8 encode on U+0026, U+0023, followed
by the shortest sequence of ASCII digits representing c in base ten, followed
by U+003B.
]]

Is it intentional to emit bytes for the ASCII representation of `?` or
`&#nnn;`, even if the encoding being used is not ASCII-compatible?

rust-encoding’s current implementation instead uses the current encoder to
encode `?` or `&#nnn;` to bytes, and aborts if that fails (which I’m not
convinced can ever happen, even in weird non-web encodings that this
implementation supports.)

If this is intentional, I’ll file a bug on rust-encoding.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 26 November 2013 15:45:08 UTC

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