NARUSE, Yui
narus****@airem*****
2006年 4月 6日 (木) 03:04:08 JST
はじめまして、成瀬と申します。
わたしは Legacy Encoding Project でターゲットに挙げられている、
nkf、Ruby/NKF、Encode::EUCJPMS をメンテナンスしています。
OSC2006 発表資料にもある通り、
これらではすでにこのプロジェクトとは独立に
CP932, CP51932, eucJP-ms には対応しておりまして、
この作業はそれなりに考えがあって行ったのですが、それについて。
わたしは今更レガシーエンコーディングに対応する必要性は、
ただ過去の資産の継承及び、
既存システムが残っている間の相互運用だと考えています。
そこで、日本語テキストを扱う場合に、
過去の資産及びシステムが使っている文字コードは、
* ISO-2022-JP
* Shift_JIS
* CP932
* EUC-JP
* eucJP-ms
* CP51932
だと考えました。
CP932 が Shift_JIS と別にあるのは、
* CSS が CP932 の方が大きい
* Unicode との対応が異なる
* そのような CP932 を用いた資産が相当数存在する
からです。
同様に、CP51932 は、
* CSS が EUC-JP と異なる
* eucJP-ms には CSS 的に含まれるが、
CP51932 の NEC選定IBM拡張文字 の領域が eucJP-ms ではユーザ定義文字
* よって、CP51932 のテキストを eucJP-ms とみなすと化ける
$ perl -e'print"\xEE\xEC"'| iconv -f cp932 -t cp51932 \
| iconv -f euc-jp -t cp932
-> iconv: (stdin):1:0: cannot convert
$ perl -e'print"\xEE\xEC"'| iconv -f cp932 -t cp51932 \
|iconv -f eucJP-ms -t cp932
-> 化ける
* Unicode との対応が異なる (eucJP-ms とも一部異なる)
* そのような CP51932 を用いた資産が相当数存在する
(IEから投げられた「日本語 (EUC)」をそのまま保存しているシステム）
という理由からこれも追加しました。
同様に、eucJP-ms も MySQL 周辺をはじめとして用いられているので、
これを追加しました。
風間さんはこの CP932, CP51932, eucJP-ms も必要ないし、
ユーザは使い分けることが難しいと考えていらっしゃるようですが、
eucjpms を Google で検索して 17000 件ヒットすることからも考えて、
相当の人が必要性を感じ、使い分けていると考えます。
（CP51932 はまだ少ないですが、今後 UTF-8 への移行の過程で、
はまった人の blog 等がひっかかるようになると予想します）
一方で今回提案された ISO-2022-JP-MS は、
* CSS が ISO-2022-JP (RFC1468) と異なる
* そのような「ISO-2022-JP-MS で扱える符号化文字列」の
資産は相当数存在する
ため、その類のものに対する必要性は一定あるでしょう。
（例えばMLのアーカイブの Unicode 化に用いる）
しかし、それならば CP502xx で十分でしょう。
ユーザ定義文字が ISO 2022 から逸脱するのは、
確かに問題だとも思いますが、
すでに逸脱した形でエンコードされたデータが
相当数存在するシステムで用いられるのですし、
ユーザ定義文字を出力しない CP50221 でいい気もします。
ユーザ定義文字をメールで送信するために、
当事者同士で合意の上 ISO-2022-JP-MS で送る余裕があるのならば、
CP932 で添付ファイルにするなり、UTF-8 で送るべき、
というのは当然の批判でしょう。
ISO-2022-JP-MS の謳う、CP932 との相互運用性は、
レガシーエンコーディングへの対応意義である、
「過去の資産の継承」からは外れるのではないか、
というのがわたしの考えです。
--
NARUSE, Yui <narus****@airem*****>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA