[ruby-dev:11476] Re: Proposal of "Array of CharCode"

たけ(tk)です。

Yukihiro Matsumoto さん曰く。
》|　１６ビットを越える大きな文字コード系の内部データは、４バイトプレーンな
》|文字コードそのままにするのがいいのではないか、という提案です。
》
》この「内部データ」ってなんでしょう？
》Regexpの内部データ？ 文字列の内部データ？

　この「内部データ」というのは Regex が、与えられた文字列（バイト列）を 
re_compile_pattern でコンパイルして作った内部データの意味でした。「文字
列」ではありません。

　Regex.c の内部データでの文字コードの形式はというのは、「MBC2WC(c, p)」
マクロの定義部分を見れば分かります。そこで、与えられたバイト列を４バイト
のデータに変換しています。その逆方向、その内部データからバイト列へのエン
コードの様子は print_mcb を見ると分かります。それらを見ると、内部データ
は、

　（１）EUC と SJIS の場合には、２個のバイト列を単純に hi*256+lo で合成
した数値。（JIS の文字コードに戻しているわけではない）。

　（２）UTF8 の場合には、不定長のバイト列を UTF8 のエンコーディング方式
に従ってデコードして戻した文字コード。

になっています。

　従って、UTF8 の文字列（バイト列）は、Regex.c の内部で用意されたデコー
ダによって、３２ビットの文字コードそのものに復元して保存されています。

》|に変えるだけで、「とりあえずの文字コード取り出し」は終了してしまう。
》
》やはり文字列の内部データのつもりみたいですねえ。

　こちらの方は直接的には「Ruby から Regex に渡すデータの形式に関する提案」
です。

　上で見たのは Regex.c での UTF8 でエンコードされたバイト列の扱いなので
すが、そこでは、Regex.c でバイト列←→文字コードのエンコード／デコードの
ルーティンを持っている。しかしエンコード／デコードは本来、文字コード系に
属する事柄なので、その文字コード系を管理するクラスで行うべきこと。
Regex.c などの汎用ルーティンで行うべきことではない。

　なぜ、Regex.c で自前の UTF8 デコード／エンコードルーティンを持っている
かというと、エンコーディング／デコーディングというのは、アルゴリズムに属
することであって、データではないから、です。従って、Regex に渡すデータが
「エンコードされたデータ」であることを維持するなら、新たなエンコーディン
グ方式のバイト列を扱おうとすれば、Recex.c の中でそのアルゴリズムに対応し
たルーティンを追加するか、外部のルーティンを呼び出すほかないわけです。

　「本来のあり方」を実現する方法としては次の２通りが考えられる。

　（１）エンコードしたデータを Regex に渡して、Regex がデータの送り主の 
CharCodeType クラスのルーティンを呼び出してデコードする。

　（２）初めからデコードしたデータを Regex に渡す。

　最初「（１）エンコードしたデータを渡す」方法を工夫しようかと思ったので
すが、CharCodeType クラスを Ruby スクリプトでも扱えるようなクラスにする、
という（たけ(tk)の）方針からいくと、呼び出しのための手続きが複雑になりそ
うであり、オーバーヘッドも問題になりそう。

　後者の方法が可能であれば、Regex での処理は簡単になり、どんな文字コード
系でも統一された方法で扱えるようになる。

　そこで、「（２）初めからデコードしたデータを Regex に渡す」方法が可能
かどうか／妥当かどうかを検討するためには、何故エンコードするのか、という
問題に突き当たる。

　何故エンコードするのか。エンコーディングの目的は下記の通り。

（１）システムのＩＯがバイト単位のデータの配列（バイトストリーム）を前提
としている。

（２）バイトデータの中にＩＯの制御のためのデータも入れられるようになって
いる。

（３）１６ビット、３２ビットのデータをそのままの状態でストリームとしてシ
ステムに渡すと、制御コードが予期しない部分に入ってしまい、誤動作を起こす。

（４）それを防止するために、制御コードとバッティングするバイトデータを含
まないように注意して複数のバイト列に変換する。

ということ。

　そうであれば、アプリケーションの内部データや、アプリケーションの内部の
各モジュールの間でのデータ交換のためのデータは、エンコードしたバイト列で
ある必要はない。Regex と Ruby との間のデータのやりとりはアプリケーション
の部分どうしの関係でのデータのやりとりに属する。

　実際問題として Ruby から Regex にデータを渡す場合を考えると、Regex に
対して、「生の３２ビットの文字コードである」旨の通知をしておけば、Regex 
では上記のような簡単な「文字コード取得ルーティン」で受け取ることが出来る
ようになる。（もちろん、EUC でエンコードされたデータであることを通知して
から（mcbtype==MBCTYPE_EUC）、今まで通りのデータを渡しても良い）。

　−−

　もうちょっと別の視点から見てみると、ストリーム型のデータを渡すときの基
本単位を byte(INT8) にするか、INT32 にするか、という違いにすぎない、とも
言えます。

　現在のＯＳやネットワークは INT8 のストリームを基本にしているので、それ
らとのやりとりではエンコードしなければならない。しかし、アプリケーション
の内部でのストリームはエンコード／デコード不要のストリーム（Array of
INT32）でも良いのではないか。ということです。

》ある文字コード系が4バイトプレーンなのは当然許すわけですが、
》統一して内部データとして持つというのは前提から採用できないよ
》うな。

　具体的には次のような方法を想像しています。

（１）CharCodeType クラスのメソッドとして、エンコードされたバイト列から
デコードされた INT32 の配列に変換するメソッドを用意しておく。

（２）String クラス／Regex クラスの内部のデータはエンコードされたバイト
列とする。

（３）String::EUC クラス／Regex::EUC クラスのデータはデコードされた文字
コードの配列とすることが許される。（強制はしない。クラスの作成者の判断に
任される）。

（４）Ruby から Regex にデータを渡す場合には、re_mcbinit(MBCTYPE_EUC)で
今まで通りにバイト列で渡すか、re_mcbinit(MBCTYPE_INT32)で文字コードの配
列（Array of INT32）として渡すかを選択することが出来るようにする。

（５）Regex では re_mcbinit(MBCTYPE_INT32)が指定された場合には、上記の文
字コード取得ルーティンで文字コードを直接取り出す。

たけ(tk)　[e-mail]
http://member.nifty.ne.jp/take_tk