Closed Bug 1506049 Opened 6 years ago Closed 6 years ago

TextDecoder returns wrong result for ISO-2022-JP text

Categories

(Core :: Internationalization, defect, P3)

63 Branch
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: kzmizzz, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: I entered the following lines on Firefox 63.0.1 console window. ------------------------------------------------ dec = new TextDecoder("ISO-2022-JP"); // Case A (good) // 0x1b, 0x24, 0x42 : <ESC $ B> select JIS X 0208-1983 to be used // 0x30, 0x42 : character "安" (JIS X 0208-1983) // 0x3b, 0x4f : character "始" (JIS X 0208-1983) // 0x1b, 0x28, 0x42 : <ESC ( B> select ASCII to be used dec.decode(new Uint8Array([0x1b, 0x24, 0x42, 0x30, 0x42, 0x3b, 0x4f, 0x1b, 0x28, 0x42])); // Case B (wrong) // 0x1b, 0x24, 0x42 : <ESC $ B> select JIS X 0208-1983 to be used // 0x30, 0x42 : character "安" (JIS X 0208-1983) // 0x1b, 0x28, 0x42 : <ESC ( B> select ASCII to be used // 0x1b, 0x24, 0x42 : <ESC $ B> select JIS X 0208-1983 to be used // 0x3b, 0x4f : character "始" (JIS X 0208-1983) // 0x1b, 0x28, 0x42 : <ESC ( B> select ASCII to be used dec.decode(new Uint8Array([0x1b, 0x24, 0x42, 0x30, 0x42, 0x1b, 0x28, 0x42, 0x1b, 0x24, 0x42, 0x3b, 0x4f, 0x1b, 0x28, 0x42])); Actual results: The result of Case A is: "安始" The result of Case B is: "安[?]始" ([?] is U+FFFD REPLACEMENT CHARACTER) Expected results: The result of Case B must be the same with Case A. <ESC $ B> or <ESC ( B> are not "header of fragment". They are just "selectors" that designate character-set to be used for the following codes.
Priority: -- → P3
The spec makes zero-length content between escape sequences into an error. Firefox conforms to the spec. The spec issue where this was most recently discussed is https://github.com/whatwg/encoding/issues/115 . If you have information that would motivate a spec change, let's discuss it over in the spec's issue tracker. This is loosely duplicate of bug 1374149, but since this wasn't reported as a Thunderbird bug, resolving invalid in the sense that while the allegation of behavior is accurate, the alleged behavior conforms to the spec.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.