- From: <bugzilla@jessica.w3.org>
- Date: Tue, 26 Nov 2013 15:45:02 +0000
- To: www-international@w3.org
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