Closed Bug 715833 Opened 8 years ago Closed 3 years ago

Give iso-2022-jp some love

Categories

(Core :: Internationalization, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla56

People

(Reporter: annevk, Assigned: hsivonen)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, Whiteboard: [fixed by encoding_rs])

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
(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?
OS X Lion's Mail sometimes send messages with ISO-2022-JP-2.
http://d.hatena.ne.jp/NAOI/20110905/1315217943 (Japanese)
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".
Blocks: encoding
(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.
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.
Keywords: dev-doc-needed
Keywords: site-compat
Depends on: encoding_rs
Fixed by bug 1261841. ISO-2022-JP-2 is gone.
Assignee: smontagu → hsivonen
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by encoding_rs]
Target Milestone: --- → mozilla56
I think there's no ISO-2022-JP-2 pages in the wild. Won't post a site compat note for this.
Keywords: site-compat
OS: Mac OS X → All
Hardware: x86 → All
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!
> 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.
Flags: needinfo?(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.
Flags: needinfo?(cmills)
You need to log in before you can comment on or make changes to this bug.