715833 - Give iso-2022-jp some love

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Anne (:annevk)]

1. Remove support for iso-2022-jp-2 as no other browser supports it and the reasons for adding it in the first place were academic.

2. Merge identical states. There are two states that boil down to ASCII, the jis0208 states are identical (apart from a comment in one).

In other words, much can be simplified.

I wrote this specification for decoding iso-2022-jp: http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html#iso-2022-jp

Comment 1

[Simon Montagu :smontagu]

(In reply to Anne van Kesteren from comment #0)
> 1. Remove support for iso-2022-jp-2 as no other browser supports it

Do other mail clients support it? (that said, it might be time to rethink the idea of having a more modular architecture in intl/uconv so that we can support different encodings in browser and mail client. I suggested this some years ago and it was turned down, but I'm not sure that the reasons given still apply)

> and the
> reasons for adding it in the first place were academic.

What does this mean?

Comment 2

[Masatoshi Kimura [:emk]]

OS X Lion's Mail sometimes send messages with ISO-2022-JP-2.
http://d.hatena.ne.jp/NAOI/20110905/1315217943 (Japanese)

Comment 3

[Anne (:annevk)]

Simon, I just meant that when it was added in bug 72468 there did not seem to be any reason given other than "I'd like to implement this".

Comment 4

[Masatoshi Kimura [:emk]]

(In reply to Masatoshi Kimura [:emk] from comment #2)
> OS X Lion's Mail sometimes send messages with ISO-2022-JP-2.
> http://d.hatena.ne.jp/NAOI/20110905/1315217943 (Japanese)

FYI, this bug seems to be fixed since Mountain Lion (see the comment in the linked article).

Mail.app dropped the support for the text encoding selection UI since OS X Marvericks (10.9). It will use non-UTF-8 encodings only when it replies to a non-UTF-8 encoded message.

Comment 5

[Masatoshi Kimura [:emk]]

Hm, even Marvericks/Yosemite sometimes use ISO-2022-JP-2.
https://oku.edu.mie-u.ac.jp/~okumura/macosx/
http://qiita.com/ykirishima/items/1a6ca0590f9b91314e16

Comment 6

[Henri Sivonen (:hsivonen)]

Intent to unship ISO-2022-JP-2: https://groups.google.com/forum/#!topic/mozilla.dev.platform/dt87ijrusmk

Comment 7

[Jean-Yves Perrier [:teoli]]

Adding dev-doc-needed. The only docs needed would be to update TextDecoder() and TextEncoder() with a compat note about iso-2022-jp including iso-2022-jp-2 up to a given release; as well as a Fx for devs entry.

Comment 8

[Henri Sivonen (:hsivonen)]

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

Comment 9

[Kohei Yoshino [:kohei]]

I think there's no ISO-2022-JP-2 pages in the wild. Won't post a site compat note for this.

Comment 10

[Chris Mills [:cmills]]

I've documented this, by adding a note into the Decoder() constructor page about iso-2022-jp-2:

https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder/TextDecoder

I've also added a note to the Fx56 rel notes:

https://developer.mozilla.org/en-US/Firefox/Releases/56#DOM

Let me know if this looks OK. Thanks!

Comment 11

[Masatoshi Kimura [:emk]]

> Note: iso-2022-jp-2 was available as a label value in Firefox, however it was removed in version 56 to simplify the API, as no other browsers support it and no pages seem to use it.

This is wrong. Gecko has never accepted "iso-2022-jp-2" as a label. It accepted iso-2022-jp-2 sequences silently when an iso-2022-jp (no -2) decoder was instantiated.

Comment 12

[Chris Mills [:cmills]]

(In reply to Masatoshi Kimura [:emk] from comment #11)
> > Note: iso-2022-jp-2 was available as a label value in Firefox, however it was removed in version 56 to simplify the API, as no other browsers support it and no pages seem to use it.
> 
> This is wrong. Gecko has never accepted "iso-2022-jp-2" as a label. It
> accepted iso-2022-jp-2 sequences silently when an iso-2022-jp (no -2)
> decoder was instantiated.

OK, thanks. I've updated the notes to use your text.