文字と文字列

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In [chise-ja : No.00161] 
>>>>>	"江渡さん" = Kouichirou Eto <2003 ＠ eto.com> wrote:

江渡さん> 文字、文字列問題で具体的にRuby/CHISEで悩んでる問題を書いてみます。

（略）

江渡さん> p "文字".ucs #[25991, 23383]

江渡さん> などというように、配列が返ってくるようにしようか? とも考えま
江渡さん> したが、やっぱりやめました。

これはこれで奇麗だけども有用かどうかが疑問なんですね？

江渡さん> Characterに対して使えるクラスは、全てStringに対しても使える
江渡さん> ようにとか考えだすと、破綻しそうに思います。

江渡さん> 今考えているのはむしろ、Characterのinstanceへの自動変換はやめて、
江渡さん> attributeにアクセスしたい場合は明示的にCharacterに変換するように
江渡さん> しようかと思います。つまりこのショートカットを廃止する。

江渡さん> ということで、"字"のucs値を知りたいときは、一旦それを
江渡さん> Characterに変換してからucsメソッドを実行するようにしようと思
江渡さん> います。

江渡さん> p "字".char.ucs #23383
江渡さん> "字".charというのは、Character.get("字")の省略形。

江渡さん> このようにして、StringとCharacterとを分けて、使えるメソッドも
江渡さん> わけていこうと思います。

私も、なんとなく、この方が良いような気がします。配列が欲しければ map
みたいなのをかければ良いんでしょうから。


江渡さん> 文字と文字列問題は、単にRuby、Perlからの問題ではなく、C言語
江渡さん> からlibchiseを使うためのAPIはどうするのかという問題でもあり
江渡さん> ます。

libchise では文字オブジェクトを導入するつもりです。というか、当面、文
字列オブジェクトに関する API は基本的には提供しないと思います。とはい
え、C の文字列と libchise の文字列の変換は必要かなと思うようになったの
で（第２層の文字列も CHISE 的文字の列として扱われるべきだろうから）、
当初言ってたように CES 変換関連の API を一切提供しないというのはまずい
だろうと思うようになりました。


江渡さん> > ところで、ちょっと違った問題かも知れませんが、私が疑問に思っ
江渡さん> > ている問題の一つに、文字列に付けられた属性と文字に付けられ
江渡さん> > た属性は同一視できるかというものがあります。これは、XML で
江渡さん> > マークアップされたり Emacs Lisp の text-property で付けら
江渡さん> > れたような属性をその領域中の文字の属性と思って良いかという
江渡さん> > ことです。
江渡さん> > 
江渡さん> > 例えば、
江渡さん> > 
江渡さん> > 	<書体="明朝体">漢字</書体>
江渡さん> > 
江渡さん> > のようなものだと多分文字の属性と思っても良い気がします。言
江渡さん> > 語とかでもそうかも知れません。でも、
江渡さん> > 
江渡さん> > 	<コードネーム>漢字</コードネーム>
江渡さん> > 
江渡さん> > みたいにその文字列が不可分であるようなものだとその属性を文
江渡さん> > 字列中の文字は継承しない気がします。
江渡さん> > 
江渡さん> > そして、もし、この仮定が真である、ないしは、そう考えた方が
江渡さん> > 都合が良いことが多いならば、文字列の属性と文字の属性は区別
江渡さん> > した方が良い訳で、その場合、必然的に『文字列』とは別な『文
江渡さん> > 字』を導入した方が良いという結論になる気がします。
江渡さん> > 
江渡さん> > ;; でも、実をいえば、この結論が正しいかどうかはあんまり自
江渡さん> > ;; 信がないです。

江渡さん> これは議論が混乱しているような気がします。
江渡さん> 太田さん的に言えば、plain textにおける扱いにしぼるべきだと思
江渡さん> います。

;; 太田さんって mohta さんのことで、plain text とは「いま日本語が危な
;; い」における「平文」のことで良いですよね？以下、そうだと仮定します。

テキストの属性の構造が正規文法ならば、太田さん的には平文となります。

また、テキストの属性の構造が文脈自由文法（あるいは、文脈依存文法や 0型
文法だとしても）、それを文字単位に Chaon モデル的文字属性に展開すれば、
太田さん的平文を構成可能だと思います。

という訳で、「平文」という概念は、文字属性に関する制約としては機能しな
いのではないかと思います。（正規表現がばりばり使える文字処理システムを
構成する上での制約としては機能すると思います。それがどの程度うれしいか
はともかくとして）

一方、一般的用語での plain text は文字符号列ということだと思うので、こ
れに相当する概念を文字符号という概念を用いずに述べないと Chaon モデル
的にはあんまり意味がないと思われます。で、深く追求しないと、単に文字オ
ブジェクト列ということになり、この場合もやっぱり文字属性に関する制約に
ならないと思います。

思うに、mohta さんの言う所の文字コードの操作的定義は文字列オブジェクト
の性質について述べているものであって、文字オブジェクトの性質については
述べてないのでしょう。「つまり、文字に関する高度に文化的な事項は、文字
コードの定義には影響しない」という訳で。

一方、CHISE 的には「文字に関する高度に文化的な事項」もできれば扱いたい
訳で、そうした場合には出典とか用例とかも重要になってくると思います。そ
こで、文字の使用状況を扱いたいという話になって、Chaon モデルにつながっ
てくる訳で、テキストのマークアップ情報も場合によっては文字の性質に関す
る重要な情報源になり得ると思う訳です。とはいえ、なんか制約はあるような
気がするというか、なんか制約を設けた方が都合が良い気がするのですが、そ
れがなんだか判らないのです。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======