[ruby-dev:11393] Re: Ruby I18N

たけ(tk)です。　・・　長文ご注意。

　Ruby（本体）では特定の文字コード系にとらわれない、という視点でつらつら
想像してみました。

  【文字コード系の機能的分類】

  スクリプト言語の実装における文字コード系は次のように分類される。

  （１）Ruby 本体が扱う文字コード系
  （２）処理モジュールが扱う文字コード系

  （３）処理系の（デフォルトの）文字コード系
  （４）プラットフォームで表示可能な文字コード系
  （５）処理系の内部コード（処理モジュールが処理する内部コード）
  （６）スクリプト記述の文字コード系  「-Ks」
  （７）入出力データの文字コード系

  （８）文字列における文字コード系
  （９）文字(Fuxnum)として取り出したときの文字コード系

  −−

  それぞれの意味。

  （１）Ruby 本体が扱う文字コード系
  （２）処理モジュールが扱う文字コード系

  Ruby 本体が扱う文字コード系は「ない」。Ruby 本体からみた内部コード
は「ない」。すなわち Ruby 本体からみれば「単なるバイト列」として扱う。
ただし、Ruby の文字列はオブジェクトであり、 そのプロパティとして処理
モジュールへのポインタを持つ。

  Ruby 本体としては「単なるバイト列」として扱う、ということは、 文字
列としての処理は文字コード系に応じた処理モジュールに任せる、というこ
とを意味する。入出力、１文字(Fixnum)の取り出し、文字数の計算、検索、
パタンマッチング、シソーラス、ソート、などの文字列・文字として扱うた
めの具体的な処理はすべて処理モジュールが担当する。他の文字コード系と
の間のコード変換もそれぞれのモジュールが担当する。（coerce  変換も考
慮する）。

  Ruby  本体としては各処理モジュールへのインターフェースを定義して、
そのインターフェースを通じて処理を行う。

  処理モジュールは、対象となる文字コード系ごとに、Ruby  本体とは別に
作成する。処理モジュールは定義されたインターフェースに対応する処理を
行うように作成する。当面は、SJIS、EUC など既存の Ruby で扱える文字コ
ード系に対応した処理を処理モジュールとして分離して形を整える。その後、
対象とする文字コード系を増やしていく。

　＊　処理モジュールは StringType クラスとする。
　＊　StringType クラス。String#string_type, IO#string_type。

  （３）処理系の（デフォルトの）文字コード系

  処理系というのは各プラットフォーム用にインプリメントされた Ruby の
こと。ＵＮＩＸ系のプラットフォームの Ruby ではＥＵＣをデフォルトの文
字コード系とする。日本語ＷＩＮであればＳＪＩＳをデフォールトとする。

  これはコンパイルの時点で指定する。実行時に Ruby へのオプションで変
更可能にする。

  （４）プラットフォームで表示可能な文字コード系

  実行マシンが Unicode の文字コードを表示できる環境にあれば、 それで
表示したい。文字鏡のフォントが入っているマシンであれば文字鏡の文字コ
ード系のモジュールで表示したい。

  これもコンパイルの時点でデフォルトを指定し、実行時に Ruby へのオプ
ションで変更可能にする。

　＊　STDOUT.string_type で指定する

  （５）処理系の内部コード（処理モジュールが処理する内部コード）

  Ruby の内部での文字コードは、あるがまま、入力されたまま、 スクリプ
トに記述されたまま保存されるのを原則とする。生のデータに応じた文字コ
ード系処理モジュールへのポインタを、「文字列オブジェクトの処理系プロ
パティ」にセットする。

  （６）スクリプト記述の文字コード系  「-Ks」

  スクリプトの中に記述された文字列の扱いは原則として入出力データと同
様であるが、スクリプトの先頭に 「-Kx」オプションで指定しておけば間違
いが少なくなる。

  ＥＵＣで記述されたスクリプトをＳＪＩＳマシンで実行すれば、出力はＳ
ＪＩＳになる。逆も同じ、という仕組みが欲しい。

  （７）入出力データの文字コード系

  入出力データにおける文字コード系は「シリアライズされたバイト列」で
ある。ＳＪＩＳなどでは一文字のバイト数も可変である。ＪＩＳやＴＲＯＮ
であればステータスコード（KI/KO 、表番号など）が付加されている。また、
ＸＭＬ流のタグ「𞉀」（Unicode）、 「&M123456;」（文字鏡）で一
文字が表されている場合もある。

  入力されたバイト列は、その文字コード系はそのままでは確定できない。
そこで、いったん、内部バッファに「そのままの形で」文字列を保存し、処
理モジュールプロパティは「不明」としておく。デフォルトの処理モジュー
ルにそのバイト列の点検を依頼し、処理可能であれば（※１）、文字列オブ
ジェクトの処理モジュールプロパティをセットして、その処理モジュールに
渡す。受け取った処理モジュールは、原則として何も変換せずに受領通知を
返す（※２）。

  しかし、簡単な変換は許されるべきだと思う（※３）。ここでの変換は通
常の変換（文字コード系の間の変換）とは区別して、アンシリアライズ変換
としておく。シリアライズされたバイト列をその文字コード系モジュールで
扱いやすい内部コードに変換することを意味する。変換した場合には新しい
バッファに文字列オブジェクトをコピーしてその旨を Ruby 本体に通知する。
また、変換可能な場合には処理可能性の点検依頼でＯＫを返す。どんな変換
をするかは処理モジュールの設計に任せられる。また、変換しなくてもよい。

  出力データはシリアライズして出力する。これも、原則として「入出力時
に文字コード系の変換」をしない。ただし、入力時にアンシリアライズされ
ている場合には必ずシリアライズ変換をしなければならない。また、指定が
あれば、別の文字コード系に変換して出力する。

  ※１  デフォルトの処理モジュールで処理不能のバイト列であれば、指定
      された順番（※４）で次のモジュールに処理可能かどうかの点検を依
      頼する。

  ※２  「入出力時に文字コード系の変換がない」（[ruby-dev:11372] ）。

  ※３  その文字コード系で扱いやすい形に変換する。たとえば可変長文字
      コードを32ビットにそろえてしまう、ＥＵＣのプラットフォームでＳ
      ＪＩＳのデータを受け取ったときにはＥＵＣに変換してしまう、とか、
      ＸＭＬ形式のタグを一文字の内部データとして変換する、など。

  ※４  ＸＭＬタグが含まれているような場合、始めに「UFT-2000」の処理
      モジュールで点検すれば、Unicode 文字列として扱えるようになるが、
      始めに「ASCII」で点検してしまうと、単なるASCII文字列扱いになっ
      てしまう、というような違いが出てくるだろう。

　＊　STDIN.string_type は nil にしておき、固定しないようにする。
　　　STDIN.string_types に点検順に処理モジュールの配列が入る。
　＊　STDOUT.string_type にはそのプラットフォームに適した処理モジュール
を入れる。

  （８）文字列における文字コード系
  （９）文字(Fuxnum)として取り出したときの文字コード系

  文字列においては、文字列オブジェクトのプロパティとして「処理モジュ
ールプロパティ」を持つ。これはＶＭＴ（バーチャルメソッドテーブル）へ
のポインタでよい。これにより文字列は自分自身を操作する文字コード系の
モジュールを知ることが出来る。

  文字列からの文字の取り出し、入れ替え、挿入も対象となる文字列の処理
モジュールが行う。

  しかしながら、文字列から一文字(Fixnum)を取り出してしまうと、その数
値にどの文字集合の文字番号であるか／どの文字コード系の文字コードであ
るか、の情報が付加されないかぎり、その数値がどの文字を示すかを特定す
ることは出来なくなる。

  そこで、１文字の文字コードは、 Fixnum の有効ビット数が３１ビットと
して、上位７ビットに文字コード系のＩＤを入れて、下位２４ビットにその
文字コード系での文字コードを入れて返すというのはどうか？。

  文字コードが２４ビットであれば１６００万字分である。その１０％程度
使うとしても１６０万字程度は確保できる。ＴＲＯＮコードのように文字面
番号＋１６ビットコードの構成の場合でも２５６面確保できる。文字コード
系の種類も１２０種類程度の枠を確保することが出来る。

  ＊  ２４ビットでは文字を特定できないような文字コード系もあるかもし
    れない。何らかの変換を行えば、不可能ではないと思うが、どうするか
    はそのモジュールの設計者に任せればよい。

  文字コード系ＩＤが０の場合には「デフォルトの文字コード系」を意味す
るようにすれば、現状との互換性が保たれるのではないか？。

  −−

  【処理モジュールが用意すべき機能（関数）】

  思いついたまま列挙したもの。

  （１）バイト列点検機能。（入力時）
  （２）文字列引受機能。（入力時、アンシリアライズ）。
  （３）シリアライズ機能。（外部出力用データ作成機能）。
  （４）文字数カウント機能。  ・・  バイト数は本体の管理機能。
  （５）部分文字列取り出し機能。
  （６）文字列挿入・入れ替え機能。
  （７）一文字取り出し機能。  ・・  バイト取り出しは本体機能。
  （８）一文字挿入・入れ替え機能。
  （９）文字列間の比較、ソート、パタンマッチング機能、パタンマッチン
        グに必要な文字情報を返す機能。
  （10）他の文字コード系への／からの変換
  （11）クラス化のための機能。（StringType クラス）

  StringType クラス。処理モジュールに対応する Ruby  スクリプトから見
たクラス。

  p "文字列".string_type                #  "SJIS" or "EUC" or ..
  p "文字列𞉀。".string_type     #  "Unicode" or "UFT-2000" or ..
  p "文字列𞉀。".string_type.charset     #  "iso-8859-2" or ..

  s = "文字列"                          #
  p s.string_type                       #  "SJIS"
  s.string_type = StringType_EUC.new    #  EUC に内部コードを変換する。
  p s.string_type                       #  "EUC" 
  STDOUT.string_type = nil              #   nil なら変換しない。
  p s                                   #  "EUC" で文字化け表示

  p STDOUT.string_type          #   表示のとき変換する。nil なら変換しない。
  p STDIN.string_type           #   nil。特定のものに固定しない。
  p STDIN.default_string_type   #   ＝ string_types[0]
  p STDIN.string_types          #   判定順序を示す処理モジュールクラスの配列

  −−

  【文字コード系の変換とシソーラス】

  （１）シリアライズ変換／アンシリアライズ変換（入出力時の変換）
  （２）文字列の文字コード系と文字の文字コードの変換。

  （３）同一文字集合の文字コード系の間の変換（エンコード変換）
  （４）文字集合が異なる文字コード系の間の変換（文字集合変換）（※３）

  （５）シソーラス（※１）の代表値への変換。

  Ruby 本体は変換には関与しない。すべて処理モジュールで行う。

  出来る限り変換せずに、生のままのデータで高速に処理する。

  Ruby 本体は変換自体には関与しないが、 変換のためのインターフェース
を定義しておく必要がある。

  漢字のシソーラスの扱いはスクリプト言語の手に余るが（※２）、いずれ
必要になるので考えておく必要がある。アルファベットの「Ａ」と「ａ」と
を同一の文字とみなすのもシソーラスの一種である、と考えておくと、あと
でよいことがあるかもしれない。

  ＊  シソーラスにはレベルの設定が必要。比較的厳密か、ゆるく広くか、
    とか、外国語の対応文字も含むかとか・・（英語の「ａ」とギリシャ語
    の「α」？）。

  ※１  シソーラスというのはもともとは 「類語辞典」の意味であるが、
      「斉藤」「齊藤」「斎藤」「齋藤」のように、「厳格に言えば異なる
      が、大雑把に言えば同じもの」を同じものとして扱うための仕組み、
      ないしそのための「類字辞典」を意味するものとする。

  ※２  シソーラスデータの作成は文字集合の作成者がすべきこと。

  ※３  文字集合が異なる場合の変換に必要なデータも文字集合の作者にお
      願いするしかないだろう。

　−−

　長文で失礼しました。

たけ(tk)＝熊谷秀武