Closed Bug 1506049 Opened Last year Closed Last year

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: Last year
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.