From: "NARUSE, Yui" <naruse@...>
Date: 2007-12-12T08:05:41+09:00
Subject: [ruby-dev:32545] Re: [ruby-cvs:21409] Ruby:r14172 (trunk):  * transcode.c: new file to provide encoding conversion features.

成瀬です。

Martin Duerst wrote:
> 追加したものがあれば教えてください。Shift_JIS と euc-jp は
> 準備中です。

日本語ですと、最重要なのが Shift_JIS と EUC-JP で、ISO-2022-JP と CP932
が次点、続いて eucJP-ms、CP51932、CP5022x といったところでしょうか。

Shift_JIS と EUC-JP、CP932 は Perl/Encode が ICU 互換の UCM 形式のデータ
を持っているので、それをいただくのが無難かと思います。
http://search.cpan.org/src/DANKOGAI/Encode-2.23/ucm/

eucJP-ms は EUC-JP の UNIX 系で用いられる亜種、CP51932 は Windows で用い
られる亜種です。こちらは nkf のテストで使っている UCM データがあります。
http://nkf.sourceforge.jp/ucm/


なお、現在の実装では常に一文字が一文字に対応することが前提のように見える
のですが、MacJapanese 等では、MacJapanese 1文字が Unicode 複数文字に対応
したりするので、将来 M:N 変換が可能となるように考えておくとよいかと思い
ます。

また、おそらく Shift_JIS -> EUC-JP する場合は一度 Unicode を経由すると思
うのですが、Shift_JIS -> UTF-8 -> EUC-JP だとコストが大きいように感じま
す。テーブルを UTF-8 バイト列で持つのは nkf でもやっているのですが、一見
メモリが節約できるようで UTF-8 でも意外とスカスカだったり、たどるコスト
が意外と大きかったりで、結局コードが複雑になるデメリットの方が大きいよう
に感じました。ついでにいえば、UTF-8-MAC のように文字コード変換が Unicode
正規化を含む場合に死にます。以上から、いきなり UTF-8 にするのではなく、
内部では Unicode scalar value で持っておいたほうが無難ではないかと。どう
せマップテーブルから自動生成するのなら、せっかく Ruby 側がハッシュテーブ
ルを持っているのですから、ハッシュにしてしまうのもありかもしれません。

-- 
NARUSE, Yui  <naruse@airemix.com>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA