From: "NARUSE, Yui" Date: 2007-12-14T22:18:10+09:00 Subject: [ruby-dev:32602] 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/ > > このデータは ICU、iconv などとどのぐらい違いますか。 まず、iconv といっても主要なところで glibc iconv、GNU libiconv、Citrus iconv 等があり、それぞれ異なっています。 ICU の変換表は以下にあるのですが、glibc-*.ucm という名前が見えるように、 glibc の変換表もありますね。 http://source.icu-project.org/repos/icu/data/trunk/charset/data/ucm/ で、たとえば Shift_JIS の場合、glibc-SJIS-2.3.3.ucm だと、 \x5C |1 \x5C |0 となっています。Perl/Encode は先述のとおり、 \x5C |0 です。 CP932 の場合ですと、Perl/Encode の変換表は windows-932-2000.ucm と等し く、glibc-CP932-2.3.3.ucm とは延べ488個の相違があります。 >> eucJP-ms は EUC-JP の UNIX 系で用いられる亜種、CP51932 は Windows で用い >> られる亜種です。こちらは nkf のテストで使っている UCM データがあります。 >> http://nkf.sourceforge.jp/ucm/ > > 「悪種」でどのぐらい悪いですか。例えば eucJP-ms は EUC-JP とどのぐらい > 違うでしょうか。 「悪種」でなく「亜種」ですね、Subspecies とか revised version とか another vendor's version of convertion table というべきものです。 eucJP-ms と JIS による EUC-JP の変換表の場合、0xA1BD, 0xA1C1, 0xA1C2, 0xA1DD, 0xA1F1, 0xA1F2, 0xA2CC の7文字で相違があり、NEC特殊文字、IBM拡張 文字、ユーザー定義文字 が新たに含まれています。 http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html >> なお、現在の実装では常に一文字が一文字に対応することが前提のように見える >> のですが、MacJapanese 等では、MacJapanese 1文字が Unicode 複数文字に対応 >> したりするので、将来 M:N 変換が可能となるように考えておくとよいかと思い >> ます。 > > 現在確かにそういう制限がありますが、根本的なものではなく、割りと簡単 > に外せるものです。優先度でもうちょっと高いものもありますので、いつに > なるのかは未だいえません。windows-1258 とかの対応にも必要です。 将来的に可能でさえあれば、1.9.1 に間に合わせる必要はないと思います。 >> どう >> せマップテーブルから自動生成するのなら、せっかく Ruby 側がハッシュテーブ >> ルを持っているのですから、ハッシュにしてしまうのもありかもしれません。 > > 現在のやら方に比べてハッシュはどのぐらいメモリを多く食うのか > 考えたことがありませんが、多く食うのは間違いないでしょう。 最小完全ハッシュ (Minimal perfect hash) を使えば、32bit -> 32bit の変換 ですから、文字数 x 8byte + α でしょうか。 > windows-1258 見たいな限定されたユニコードの正規化は文字コード変換の > 枠内と考えていますが、一般的な正規化は別物として考えています。 わたしが懸念しているのは、「限定されたユニコードの正規化」が必要な場面が 将来的に思ったよりも多くなるのではないかということなのですが、M:N 変換を サポートするならばそれはそちらで対応できそうですね。 > 最終的には文字コード変換の一部に使えるようになるかと思いますが。 > 最終的にはルビプログラマから定義される文字コード変換ではハッシュ > を使うことになるかもしれませんが、そこでもハッシュの場合文字列の > prefix を扱うのが難しいという問題があります。 文字列の prefix ってなんでしょう？ -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA