E.g. new TextDecoder('shift-jis').decode(Uint8Array.of(0x5C)) is \, not ¥ per spec and in all major browsers.
But test data has <span data-cp="A5" data-bytes="5C">
The mismatch is also noticeable in the test runner, on the very second row -- symbols are different + assert shows not a ¥ sign:
Also e.g. new TextDecoder('iso-2022-jp').decode(Uint8Array.of(0x1B, 0x24, 0x42, 0x21, 0x5D, 0x1B, 0x28, 0x42)).codePointAt().toString(16) is ff0d and not 2212 as in tests:
|
<span data-cp="2212" data-bytes="1B 24 42 21 5D 1B 28 42">�$B!]�(B</span> |
Those don't cause failures because the test runner doesn't test bytes -> charcode decoding.
What it tests here is that html decoding of bytes matches decoder decoding of the same bytes, but nothing compares them to the codepoint in the test data:
|
assert_equals( |
|
nodes[i].textContent, |
|
decoder(nodes[i].dataset.bytes) |
|
); |
(cc @domenic?)
E.g.
new TextDecoder('shift-jis').decode(Uint8Array.of(0x5C))is\, not¥per spec and in all major browsers.But test data has
<span data-cp="A5" data-bytes="5C">The mismatch is also noticeable in the test runner, on the very second row -- symbols are different + assert shows not a
¥sign:Also e.g.
new TextDecoder('iso-2022-jp').decode(Uint8Array.of(0x1B, 0x24, 0x42, 0x21, 0x5D, 0x1B, 0x28, 0x42)).codePointAt().toString(16)isff0dand not2212as in tests:wpt/encoding/legacy-mb-japanese/iso-2022-jp/iso2022jp_chars.html
Line 177 in 4f21b11
Those don't cause failures because the test runner doesn't test bytes -> charcode decoding.
What it tests here is that html decoding of bytes matches decoder decoding of the same bytes, but nothing compares them to the codepoint in the test data:
wpt/encoding/resources/decode-common.js
Lines 32 to 35 in 2a1fdfa
(cc @domenic?)