Closed
Bug 715833
Opened 13 years ago
Closed 7 years ago
Give iso-2022-jp some love
Categories
(Core :: Internationalization, defect)
Core
Internationalization
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
Comment 1•13 years ago
|
||
(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•13 years ago
|
||
OS X Lion's Mail sometimes send messages with ISO-2022-JP-2.
http://d.hatena.ne.jp/NAOI/20110905/1315217943 (Japanese)
Reporter | ||
Comment 3•13 years ago
|
||
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•9 years ago
|
||
(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•9 years ago
|
||
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
Assignee | ||
Comment 6•9 years ago
|
||
Intent to unship ISO-2022-JP-2: https://groups.google.com/forum/#!topic/mozilla.dev.platform/dt87ijrusmk
Comment 7•9 years ago
|
||
docs |
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
Updated•9 years ago
|
Keywords: site-compat
Assignee | ||
Updated•9 years ago
|
Depends on: encoding_rs
Assignee | ||
Comment 8•7 years ago
|
||
Fixed by bug 1261841. ISO-2022-JP-2 is gone.
Assignee: smontagu → hsivonen
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by encoding_rs]
Target Milestone: --- → mozilla56
Comment 9•7 years ago
|
||
I think there's no ISO-2022-JP-2 pages in the wild. Won't post a site compat note for this.
Comment 10•7 years ago
|
||
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!
Keywords: dev-doc-needed → dev-doc-complete
Comment 11•7 years ago
|
||
> 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)
Comment 12•7 years ago
|
||
(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.
Description
•