From: Martin Duerst <duerst@...>
Date: 2007-12-24T16:29:03+09:00
Subject: [ruby-dev:32702] Re: ISO-2022-JP output for transcode

成瀬さん、こんにちは。

At 15:30 07/12/24, NARUSE, Yui wrote:
>成瀬です。
>
>ISO-2022-JP の入力を加えたパッチです。これもまだすべて transcode.c に
>つっこんでいます。
>
>Martin Duerst wrote:
>> At 13:04 07/12/24, Nobuyoshi Nakada wrote:
>>> At Mon, 24 Dec 2007 10:10:28 +0900,
>>> NARUSE, Yui wrote in [ruby-dev:32695]:
>>>> transcode を ISO-2022-JP の出力に対応させるパッチを書いてみました。同様
>>>> に preprocessor で入力にも対応できますし、ISO-2022-JP 以外の ISO/IEC
>>>> 2022 シリーズにも対応できるようになっています。
>>> できれば、transcode_data_japanese.cのほうにお願いしたいです。
>> 
>> これは自動的に作成しているので、余り好ましくないです。でも
>> (下のようにたいてありますように) 未だ変更する予定なので、
>> こちらでもいいです。
>
>transcode_data_japanese.c は自動生成な気がした

まさにそうです。

>のと、transcode.c の構造体
>に依存しているので、下手に分けずにとりあえず transcode.c に入れておきま
>した。
>transcoding と transcoder を transcode_data.h いれればいいのですかね。作
>業しつつとりあえずこの状態で投稿しておきます。

以前に中田さんに書きましたが、transcode_data.h はデータファイル
と transcode.c の間のものだけです。将来にはこれと別途に transcode.h
を作る予定です。

>>>> とりあえずクリ
>>>> スマスリリースに入れる程度の品質は出ると思いますがいかがでしょう。
>> 
>> リリースにいれていいですが、明日とか明後日当たりで HEAD でまだ取り出し、
>> 違う方針でよかったらいいですよ。
>
>とりあえず 1.9.1 でも ISO-2022-JP が動いてほしかったからなので、それで結
>構です。
>
>>>  # transcode_data_one_byte.cという名前はわかりにくいので、
>>>  # japanese.cと同じ伝でいえばeuropean.cかなぁと思ったりしますが。
>> 
>> こちらでもそう思いましたが、iso-8859-6 はアラビア語で、iso-8859-8
>> はヘブライ語で、iso-8859-11 はタイ語で、どちらともヨーロッパと
>> 縁が薄いです。しばらくそのままいいではないでしょうか。
>
>iso_8859.c じゃないかなぁと。

以前は transcode_data_iso_8859.c でしたが、将来に例えば
windows-... とか追加する予定なので、名前を変えました。

>>> * MAX_TRANSCODERSの制限をなくす
>>>  # というか、このパッチだとオーバーしてませんか?
>> 
>> 外してもいいですが、余り大きな変更はしない方がいいと思います。
>
>オーバーしていますね。

一番簡単なのは MAX_TRANSCODERS を合わせすということです。
手作業なのでちょっとこわいけど。

>>> * transcode_data_*.cを拡張ライブラリ形式にする。
>>>  必要な構造体とプロトタイプをヘッダに入れて、各transcoderでは
>>>  Init関数を追加することになります。
>> 
>> こちらでは次のように考えました:
>> - transcoder の登録を transcode.c に残す。
>> - 登録の際、ファイル名も登録する。
>>   (例:
>>        register_transcoder("ISO-8859-1",  "UTF-8", &rb_from_ISO_8859_1, 2, 0);
>>    の変わり
>>        register_transcoder("ISO-8859-1",  "UTF-8", &rb_from_ISO_8859_1, 
>2, 0, "transcode_data_one_byte");
>> - transcoder が呼ばれたら、データのファイルをロードする。
>
>一応参考までに他の実装ですが、
>Citrus iconv は 文字コードの一覧を
># EUC
>EUC-CN                          EUC/EUC-CN.esdb
>EUC-JP                          EUC/EUC-JP.esdb
>EUC-JP-MS                       EUC/EUC-JP-MS.esdb
>EUC-KR                          EUC/EUC-KR.esdb
>EUC-TW                          EUC/EUC-TW.esdb
>という形で持っておいて、呼ばれたら読みに行っていたような。

似たような構造みたいですね。こちらで考えているデータ構造だと
日本語の文字コード同士では共通するデータがいっぱいありますので、
同じファイルにすることになります。

>Perl/Encode は拡張ライブラリ方式でした。ある拡張ライブラリを読み込むと、
>それが対応している文字コードの変換がサポートされます。そして、デフォルト
>で読み込む、文字コード変換拡張ライブラリをいくつか登録されていました。
>（デフォルトで読み込む文字コード変換ライブラリはユーザが後で追加可能）

中田さんと考えたのは require は必要ないようにしたいということです。
勿論将来的にユーザーが自分で追加したいときはあるだろうからこれにも
対応したいですが、先ずはリリースの後に文字コードの数を増やすことです。

>Martin さんが考えていらっしゃるのはおそらく Citrus に近い方式で、なかだ
>さんが考えていらっしゃるのは Perl/Encode に近い方式でしょうか。Citrus 方
>式だと各変換を最適化しやすく、Perl/Encode はモジュールの追加がしやすかっ
>たように記憶しています。

こちらでは「各変換」よりも「似たような変換同士」の最適化に力を入れようと
思っています。

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


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