From: Martin Duerst <duerst@...>
Date: 2007-12-14T16:48:59+09:00
Subject: [ruby-dev:32594] Re: [ruby-cvs:21409] Ruby:r14172 (trunk):   *transcode.c: new file to provide encoding conversion features.

成瀬さん、こんにちは。

色々有力なアドバイスありがとうございます。

At 08:05 07/12/12, NARUSE, Yui wrote:
>成瀬です。
>
>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/

このデータは ICU、iconv などとどのぐらい違いますか。

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

「悪種」でどのぐらい悪いですか。例えば eucJP-ms は EUC-JP とどのぐらい
違うでしょうか。

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

現在確かにそういう制限がありますが、根本的なものではなく、割りと簡単
に外せるものです。優先度でもうちょっと高いものもありますので、いつに
なるのかは未だいえません。windows-1258 とかの対応にも必要です。

>また、おそらく 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 側がハッシュテーブ
>ルを持っているのですから、ハッシュにしてしまうのもありかもしれません。

現在のやら方に比べてハッシュはどのぐらいメモリを多く食うのか
考えたことがありませんが、多く食うのは間違いないでしょう。
windows-1258 見たいな限定されたユニコードの正規化は文字コード変換の
枠内と考えていますが、一般的な正規化は別物として考えています。
最終的には文字コード変換の一部に使えるようになるかと思いますが。
最終的にはルビプログラマから定義される文字コード変換ではハッシュ
を使うことになるかもしれませんが、そこでもハッシュの場合文字列の
prefix を扱うのが難しいという問題があります。

宜しくお願いします。     Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp