いがらしです。
ぜんぜんまとまっていませんが、思っていることをいくつか。

At Sun, 18 Jun 2000 02:37:25 +0900,
in [ruby-list:23330] Re: UTF-8 in RubyBook,
kjana / os.xaxon.ne.jp (YANAGAWA Kazuhisa) wrote:
> 
> もうちょっとまじめな事を考えれば,コード変換標準 API を使う(iconv と
> か)とか,新たにコードコンバータを実装する,っていう事になるでしょう.
> でも iconv ってまだどこにでもあるっていうものじゃなかったりはする.

そうなんですよね。ほんとはiconvライブラリをrubyに標準添付して
欲しいのですが、まだ環境によっては使えないことも。

それでiconvがなくても他のライブラリでも代替できるように、
iconvを含めたコンバータを登録・探索する手段を提供したらどうか、
なんて考えています。

まずユーザが設定ファイル等にライブラリ名を列挙しておきます。
# ライブラリのインストール時に書き込まれるようにしてもいい。
そしてアプリの起動時、コンバータのデータベースは列挙された
ライブラリを順次requireします。
各コンバータライブラリはrequireされたら、自分自身についての情報
  * サポートする変換元・変換先CESの組
  * コンバータの生成方法
      (コンバータのクラスオブジェクト あるいは
       コンバータのインスタンスを返すブロック)
をデータベースに登録することにします。

するとユーザはこんな感じで使えるかな、と。

    converter = I18N::CES::Conveter.resolve("utf-8", "iso-2022-jp")
    to_str = converter.conv(from_str)
    # ...
    rest = converter.flush
    
converterには指定したコード系を変換できるコンバータが返ってきます。

これを実現するには、nkf,uconv,iconv,lvなどそれぞれ変換メソッドの
引数が異なるので、まずそれを統一しないといけませんね。

Javaではsun.io.ByteToCharConverter/sun.io.CharToByteConverterといった
抽象クラスで定義されていますが、rubyでも相当の約束事が欲しい気がします。
ただJava内部コードはUnicode固定だけど、rubyはどうするのか? という問題が
あります。

> # coco を組み込むっていうのもおもしろいかも.mule-ucs から引っ張ってく
> # れば各種 UTF や Unicode に加えて mule の内部表現だって扱える?

その昔mule 2.3のcocoをベースにMule::convを作ったんですが、
いつだかマシンのリプレースをしたとき以来見つからなくなってしまって。
また探してみます。

で、mule-ucsまで使うようになるとちょっと重いように思います。
またあれを動かすにはelisp環境を用意しないといけないですよね。
emacsをrubyにリンクできないかあれこれ画策したのですが、emacsは
undump対応の独自のスタートアップルーチンをリンクしていたりして
僕の手には余りました。

cocoの場合似非elisp環境をあてがっているのですが、
LispオブジェクトがGCされていないんではないかと思います。
また変換速度はnkfの倍くらい遅かった記憶があります。


ところで。
コンバータをサーバとして提供すれば各アプリでの
変換テーブルの読み込み時間などが削減できますよね。
プロセス間通信のオーバーヘッドは大きいでしょうけど、
変換する文字列が少なければそういう手もありかなと。
たとえサーバがelispで動いていようとクライアントはお構いなしですし。
そういう試みはすでに行なわれていたりしないのでしょうか。

--
五十嵐  宏  (Hiroshi IGARASHI)