From: Yukihiro Matsumoto <matz@...>
Date: 2008-09-16T11:37:47+09:00
Subject: [ruby-dev:36317] Re: 合成文字の2コードポイント目

まつもと ゆきひろです

In message "Re: [ruby-dev:36316] Re: 合成文字の2コードポイント目"
    on Tue, 16 Sep 2008 10:25:59 +0900, Tanaka Akira <akr@fsij.org> writes:

|>  * UTF-8などUnicode系全般で対応するのか、それとも特別なエン
|>    コーディング(UTF-8-MAC?)を用意するのか
|
|現在、UTF-8 でやっています。
|UTF-16 や UTF-32 もやるべきかもしれません。

でしょうね。まあ、「やる」と決めればおいおい作業すればよいで
しょうが。

|コードポイント単位のものが必要なのであれば、むしろ
|UTF-8-CODEPOINT とかを導入するのがいいのではないかと思ってい
|ます。

もうちょっと良い名前が欲しい気もします。自分では思いつかない
んですけど。

|>  * Unicode系以外のエンコーディングはどうするのか(Shift_JISに
|>    おける濁点付きカナとか)
|
|JIS X 0201 の濁点は独立した文字として定義されているのでそう
|はしません。

了解しました。

|>  * each_codepointなどの導入のタイミングは
|
|今月。

では、こちらは私が作業します。もうパッチはもらっているので当
てるだけですけど。

|* unicode 文字列に対する regexp による codepoint 単位の操作
|  が base character に対するものになる (プロパティの検査とか)
|  必要なら UTF-8-CODEPOINT を導入する

ごめんなさい。「codepoint 単位の操作が base character に対す
るものになる」を十分に理解していないかもしれません。
「\p{Katakana}」とかのマッチの対象がbase charactetrに基づいて
行われる(が、マッチは合成文字全体が対象になる)という理解は正
しいですか？

|* regexp における character class の動作が文字の中の最初のコー
|  ドポイントに対するものになる。
|  幸いにして Unicode においては最初のコードポイントが
|  base character なのでそんなに変なことにはならないようで
|  す

これは文字クラスの両端はコードポイントに直接対応する「文字」
しか来ることができないという意味でしょうか。仮にそうだとする
と、正規表現リテラル/[○-●]/の「まる」のいずれかが合成文字
であった場合にはエラーになりますか？

|* IO#getc で、(制御文字以外では) 次のコードポイントがこない
|  と文字の終端が判断できない
|  まだそうなってしまうようには実装していませんが、する予定で
|  す。ただ、line buffering な端末なら気がつきません。
|  (base character が最後に来るように並んでればこういうことに
|  はならずに済んだんですが)

そうですね。が、濁点にしても、アクセント記号にしても、人間っ
てのは修飾するものを後ろに置く「本能」みたいのがあるんですか
ねえ。

                                まつもと ゆきひろ /:|)