MT-I18N with Encode.pm
Jcode.pmではなく、Encode.pmを使って実現したMT::I18Nモジュール。
{i} Movable Type 3.2日本語版では、Perl 5.8.1以降を使っている場合にはEncode.pmを利用するようになっていますので、このモジュールを使う必要はありません。
更新履歴
- 0.01(2004.07.17):
- (ろくに動作確認もせず)公開。
- 0.02(2004.07.31):
- wrap_textの動作をオリジナルに従うように変更。
- 0.03(2004.08.17):
- guess_encodingのコード判定を多少はrobustになるように修正。
- substr_textの第3引数省略時の動作を変更。
- 0.04(2005.03.26):
- guess_encodingのredefine warning出力を抑制するようにプラグマ指定を追加。
概要
Movable Type 3.0/3.1日本語版で利用可能な、Encode.pmを使って実現したMT::I18Nモジュールです。標準のMT::I18NモジュールはJcode.pmを使っています。
Perl 5.8.0以降を使っている場合、I18N-encode.zipに含まれるI18N-encode.pmでlib/MT/I18N.pmを置き換えるとEncode.pmを使うことができます。Movable TypeのShift_JIS、EUC-JP、UTF-8以外の非ASCII charsetへの対応を視野に入れると、このI18N-encode.pmがひとつの叩き台になるのではないかと期待しています。
チャレンジャーは使ってみてください。ちなみにPerl 5.8.0に付属していたEncode 1.75だと変換テーブルにバグがありました(UTF-8の「～」と「～」 - Ogawa::Memoranda)。せめて1.8X以上であるかどうかを確認してから利用することをお勧めします。
モジュール作成の意図
このモジュール作成の意図は、かなり多くの人がMovable TypeでPublishCharsetにUTF-8を指定しているにも関わらず、Jcodeを使うのは無駄が多いのではないかということです。例えば、substrを実行する場合、いちいちEUC-JPに変換してまた元のcharsetに逆変換するという処理が発生します。それよりも以下のようにした方がずっと高速なのではないかと思われます。
encode("utf-8", substr(decode("utf-8", $_), $start, $length))
また、EUC-JPが扱う文字領域の少なさも問題です。日本語版Windows(CP932)で「～」を入力したとき、この文字はFULLWIDTH TILDE(U+FF5E, EFBD9E)として扱われますが、このコードに対応するEUC-JPのコードは存在しません。したがって「～」を含む文字列をJcodeを使ってsubstrしようとすると、EUC-JPに変換した時点「～」がstripされてしまい、substr後の文字列が不正確なものにものになってしまいます。他にも文字実体参照や数値実体参照で入力される文字の中には正しく処理されない文字があります。より一般的には中文やハングルを含む日本語・英語以外の文字も正常に処理されません。
これに対して、Encode.pmが扱うコードセットはJcode.pm(EUC-JP)に比べてずっと広範であるため、このような問題は起きません。
性能
実際試してみると、手元の環境(SUSE Linux 9.1 on VMWare 4.5)では450エントリのRebuildが55秒から45秒に縮まります(18%速度向上)。Lolipopの環境だと886エントリのRebuildが170秒から168秒に縮まるだけ(わずか1.2%速度向上)です。
手元の環境のEncode.pmのバージョンが1.99であるのに対して、lolipopは1.83であるとか、lolipopのMySQLのI/Oが実はボトルネックであるとか、いろいろな要因が考えられます。Jcodeも0.85以降(?)はメモリを消費する代わりに高速になりました。
