Ruby/CHISE

Ruby/CHISEとはなにか

Ruby/CHISEは、XEmacs CHISEにおけるChaon実装を
Rubyへ移植することを試みたモジュールである。

■Chaonモデルとはなにか

Chaonモデルとは、文字を符号ではなく属性によって扱う方法を意味する。

Ruby/CHISEではそれを拡張し、文字をオブジェクトとして扱っている。

■download & history

  • 2003-0110 テスト公開
  • 2003-0112 XString追加
  • 2003-0115 IDSの読み込み機能β版
  • 2003-0116 IDSの読み込み機能1.0
  • 2003-0117 XStringを廃止し、Stringに一本化。IDSの読み込み機能を強化。
  • 2003-0120 IDS_Treeの読み込み機能を追加。木構造の整合性checkを追加。
  • 2003-0130 IDSの逆変換機能などを追加。
  • 2003-0213 ruby-chise-20030213.tar.bz2
    名称をRuby/UTF-2000からRuby/CHISEへと変更。

■CVS

CVS access

■install

展開して、make installする。

通常、/usr/local/lib/ruby/site_ruby/以下にinstallされる。


■config

src/chise.rb

DB_DIR = '/usr/local/lib/xemacs-21.4.10/i686-pc-linux/char-db'
必要に応じて変更する。

IDS_DB_DIR = '/home/eto/work/chise/ids/''
IDSのテキストファイルが置かれているディレクトリーを指す。(下記の字形分解・合成についてを参照)


■依存関係

下記のパッケージが必要。

一般にRubyのパッケージは RAAを使って探すことができる。


■Unicode

現状では、Ruby/CHISEに渡す文字コードはUTF-8のUnicodeにしておくと便利である。

これは望ましいものではなく、将来的にはプログラム自体がSJIS、EUCなどで書かれていても 問題なく処理できるようにする予定である。

WindowsでUnicodeを使えるエディターとして、私はMeadow + Mule-UCSを使っている。

他、Windows付属のメモ帳を使うことができる。

また、見るだけであればIEに落すと表示される。

フリーのUnicode対応エディターとして他にYuditがあるが、まだよく使い方はわからない。

■使い方

■全体的な使い方

require 'chise'
include CHISE

str = "字" #Stringを拡張している。UTF8で与えること。
p str.ucs #とすると、その文字のucsの値が表示される
p str.total_strokes #画数が表示される
p str.chinese_gb2312 #などなど
str.char.alist.each {|a, v| #こんな感じで全属性を表示できる
  print a, ': ', v, "\n"
}
p str.inspect_x #Characterについての情報が表示される。
p str.inspect_all #持っている属性情報を全て表示する。

str = "文字列" #もちろん一文字でなく文字列も扱える。UTF-8で与える。
p str.inspect_x #各文字の情報が表示される。
p str.inspect_all #各文字の属性情報を全て表示する。

■様々な用例案

下記のような文章を入力、表示できるようになることを例として考える。

  • 「電話は中国繁体字だと電話と書き、中国簡体字だと電話と書く」
  • 「吉野屋の吉は、土吉の吉である。」
  • 「高橋さんは高橋さんと表記されるのを嫌う。」
  • 「日本語の骨を、中国簡体字だと骨と書く」

が、まだ入力できません。未完成です。

■字形分解・合成

Ruby/CHISEは、もともと字形分解・合成を扱うために作られたため、その機能が強化されている。

字形分解・合成は、現在はUnicodeにおけるIDS(Ideographic Description Structure)という仕様に準拠している。 U+2FF0〜U+2FFBで表わされるIDC(Ideographic Description Characters)によって合成方法を指定し、 これに続く二文字から三文字の文字を合成して表示する。

これは元々必要な漢字が文字コードに無い場合にその代替物として表記するために考えられた仕様だ。 もし文字表示機能が字形合成に対応している場合は、その合成された字を表示する。 もし字形合成の機能が無い場合は、IDC自体を目に見えるように表示し、 ユーザーの想像力に任せることになる。

実際のところ、IDSを使った字形合成機能を持つ文字表示エンジンが存在するとは聞いたことがない。 そのため現状ではこの仕様は絵に書いた餅になっている。

ここではその仕様を転用し、漢字の字形を指示するために使っている。

ちょっと想像してみればわかるが、IDSはまともな実装が存在していないことからもわかる通り、 普通には使えない仕様である。実際に漢字の字形を合成して表示するといっても、 縦とか横につらなるなどといった単純な情報だけでは不十分で、もっと多様な情報が必要である。 部品間の大きさのバランスなど、ついheuristicな方法で対処できるのではないかと考えてしまいがちだが、 実際に見ておかしくない字を作るためには現状ではまだ人手によってデザインする必要がある。 ここではその仕様を転じて、字形の成立ちを説明するために使っているが、 このような使い道なら使えるようだ。


■IDSを使うための準備

下記のようにして、IDSのテキストファイル群を持ってくる。

% cd ~/work/chise (このディレクトリーは適宜変更する)
% cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root login
password: (何も入れずにただもう一度return)

% cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/chise co -d ids ids

このようにすると、IDSのテキストファイル群を持ってくることができる。

その後、src/chise.rb
IDS_DB_DIR = '/home/eto/work/chise/ids/''
ここに、上記のIDSテキストファイル群を持ってきたディレクトリーを入れる。 必要であれば、再度make installする。 このようにして適切にIDS_DB_DIRを設定し、 ./tools/idsdbdumpall.rbを実行する。(かなり時間がかかる) これで、文字属性として新たにids, ids-decomposeが加わった。 それぞれ、IDSの文字列、それを再帰的に分解しきったものを意味する。

実用上は差し支えない範囲だが、IDSテキストファイルにはまだ入力されて いない字もある。./tools/idscheckintegrity.rbを実行する(かなり時 間がかかる)と、IDSの木構造の整合性をチェックし、整合性がとれていない字 を表示する。


■字形分解

Stringに、decompose, decompose_allという二つのメソッドがある。 decomposeは一段階だけ分解する。decompose_allはそれを再帰的に行う。

p "字".decompose
p "字".decompose_all
p "榊".decompose
p "榊".decompose_all
p "終了".decompose
p "終了".decompose_all
p "鬱".decompose
p "鬱".decompose_all

最初の説明から、字形分解されて出てきた結果の文字列には、 IDSキャラクターが含まれているため、場合によってはうまく表示されない。 メモ帳だと表示できるだろう。


■字形合成

分解の逆に合成することもできる。ことにしようと思っているが、まだできていない。

■説明

まじめなメソッドの説明を書く。(未完)

class String
	char	先頭の文字をCharacterに変換したものを返す
→method_missingで、存在しないmethodを指定すると、自動的に先頭の文字を
Characterに変換してそれへのmethodとして呼ぶ。

class Character
	get	ある文字をgetする。(flyweightパターン)
	[]	ある属性をgetする。get_char_attributeも使える。
		またmethod_missingも使える。
	[]=	ある属性をputする。put_char_attributeも使える。
		またmethod_missingによる入力も使える。
存在しない属性を参照したときは、nilが返る。

■tools

詳しくはtools/READMEを参照。

  • dbdumpall.rb, char-dbのBDBファイル群の中身をテキストとして展開する。
  • idsdumpall.rb, IDSのテキストファイル群を読みこみ、BDB化する。再帰的に展開したids-decomposeも作る。
  • idscheckintegrity.rb, IDSの木構造の整合性をチェックする。
  • mkdbtarball.rb, UNIXで作ったBDBファイル群をWindowsに持っていくときに使う。 Windowsでtar.gzを展開するには、eoがおすすめ。
  • trim_bom.rb, Unicodeファイルを作ったときの先頭についてくるBOM(byte order mark)を削除する。

■悩みどころ

iso-2022へのencodeはどう実現すればよいのか?
Characterはどうencodeするかの属性を持っていて、 XStringはその実際のencodeの処理を行うという分離でいいかな。
iso-2022-jpの処理はどうすればいいのか?
iso-2022-jpは行末ではASCIIに戻すという行単位の扱いが必要になるが、 XStringの中からはその判断はできない。 class IOを拡張するのがいいのか?

■字形合成

"+木木"(+はU+2FF0を意味する)という文字列が あるとして、しかしこれは実は"林"という一文字を表している。 この二重性をどう取り扱うか?
newされた時点で問答無用で"+木木"を"林"というCharacter一文字に変換 してしまうと、その時点で区別ができなくなってしまう。つまり必要に応じて composeするべきである。しかしその必要に応じてというのはどのように判定 すればいいのだろうか? 明示的に指定するしかないということか。
Unicode対応のeditorはどうとりあつかっているのだろうか? Unicodeの規定によれば、このIDSによって指定された文字列は、合成された文字そのものを 表すと規定されている。合成された文字を表示可能である場合は、IDS自体を表示してはいけない。 逆に合成した文字を表示できない場合は、IDS自体を見えるように表示しないといけない。 とすると、Unicode対応のeditorが適切な文字合成の機能を持っていた場合、 それは合成された結果の文字を表示するのがいいのか? 合成される前の文字列を 表示するのがいいのか? 結局ユーザーが明示して切り替えられるようにするのがいいのか?
もしエラーが含まれていた場合は?
"+木".to_x.compose_ids とした場合は、オペレータの対象が一文字しか無いので、処理できない。 これは例外をraiseするか、元の文字列をそのまま返すか、悩みどころ。
もし文字が存在しなかった場合は?
"+林林"とかした場合は、"木"が横に四つ並んでる漢字は存在しない(と思う)ので、 これも例外とするか、元の文字列をそのまま返すか悩みどころ。 どの文字コード体系にも存在しないような文字を表示できる字形合成エンジンがあると 仮定して、そのエンジンに手渡されるまでは、情報が失われないように処理 するべきである。
また、本来Chaonモデルはこのような「存在しない文字」をとりあつかえるように するためのモデルなので、こういった文字もシームレスに扱えるようにするべきである。 しかしどのようにすればいいのかわからない。

■Ruby/M17Nとの整合性

Ruby/M17Nとの整合性をどうとればいいか。

Ruby/M17Nブランチが本体に反映されるのは、ruby-1.8以降が予定されている。

ソースコード中のm17n.c, m17n.hが該当個所。 内部的にはUTF-8として扱えるので、それを拡張すればいいか? UTF-8の処理への追加という形で実装できる?

Kouichirou Eto, 2003 at eto.com