From code inspection, it appears that the ISO-2022-JP decoder supports nested GB18030 (the GB2312 constructor now maps to the GB18030 constructor) and EUC-KR decoders: http://mxr.mozilla.org/mozilla-central/source/intl/uconv/ucvja/nsJapaneseToUnicode.cpp#766 I don't see anything about this in the Encoding Standard. Gecko bug or spec bug?

I forgot the complete story, but not everyone supported this and it seemed very bad.

It is used to implement the ISO-2022-JP-2 decoder. See bug 715833. The ISO-2022-JP decoder will restrict the range to A1A1-FEFE when it pass the input to the GB decoder, so merging to GB18030 should have no effect. (The GB2312 decoder was the GB18030 decoder before bug 801402, after all.)

(In reply to Masatoshi Kimura [:emk] from comment #2) > It is used to implement the ISO-2022-JP-2 decoder. See bug 715833. So it looks like the ISO-2022-JP-2 part should move to comm-central. > The ISO-2022-JP decoder will restrict the range to A1A1-FEFE when it pass > the input to the GB decoder, so merging to GB18030 should have no effect. OK. Thanks.

Do we even expose a contract id for ISO-2022-JP-2? If it has been unexposed to c-c for this long, shouldn't we just remove it?

We should just remove it. As I pointed out in the other bug the only reason we added it was because it seemed like a fun project to someone. There was no actual requirement from either mail or the web to support it.

The ISO-2022-JP decoder will silently decode ISO-2022-JP-2 sequences.

Fixed by bug 1261841. ISO-2022-JP-2 is gone.