Ruby/UTF-2000

Ruby/UTF-2000とはなにか

Ruby/UTF-2000は、XEmacs UTF-2000実装におけるUTF-2000モジュール、
CHISEモジュールのRubyへの移植を試みたモジュールである。

■UTF-2000モデルとはなにか

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

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

■download & history

■install

展開して、make installする。

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


■config

src/utf2000.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のエディターとして、私は Meadow + Mule-UCSを使っている。

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

また、IEに落して見る方法もある。

■使い方

■全体的な使い方

require 'utf2000'
include UTF2000

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 #各文字の属性情報を全て表示する。

■IDS

Ruby/UTF-2000は、IDSを操作する機能を強化している。

適切にIDS_DB_DIRを設定した後に、 tools/idsdbdumpall.rbを実行する。(かなり時間がかかる)

文字属性として新たにids, ids-decomposeが作られる。 これはそれぞれ、IDSの文字列、それを再帰的に分解しきったものである。

Stringに対しては、decompose, decompose_allという二つのメソッドがある。

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

IDSのテキストファイルにはまだいろいろと間違っているところがあり、 分解できない文字もあります。

逆変換、compose機能はまだできていません。


■様々な用例案

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

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


■tools

詳しくはtools/READMEを見てください。

■説明

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

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が返る。

■悩みどころ

いろいろ悩みどころがあるのですが、適当に書いてみます。

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するか、元の文字列をそのまま返すか、悩みどころ。
もし文字が存在しなかった場合は?
"+林林"とかした場合は、"木"が横に四つ並んでる漢字は存在しない(と思う)ので、 これも例外とするか、元の文字列をそのまま返すか悩みどころ。 どの文字コード体系にも存在しないような文字を表示できる字形合成エンジンがあると 仮定して、そのエンジンに手渡されるまでは、情報が失われないように処理 するべきである。
また、本来UTF-2000モデルはこのような「存在しない文字」をとりあつかえるように するためのモデルなので、こういった文字もシームレスに扱えるようにするべきである。 しかしどのようにすればいいのかわからない。

■Ruby/M17N

Ruby/M17Nはすでにできているらしく、それとの整合性をどうとればいいか。

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

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

■link

■CHISE project

■Ruby

Kouichirou Eto, 2003 at eto.com