[ruby-dev:36318] Re: 合成文字の2コードポイント目

In article <[e-mail]>,
  Yukihiro Matsumoto <[e-mail]> writes:

> |コードポイント単位のものが必要なのであれば、むしろ
> |UTF-8-CODEPOINT とかを導入するのがいいのではないかと思ってい
> |ます。
>
> もうちょっと良い名前が欲しい気もします。自分では思いつかない
> んですけど。

まぁ、いい名前が見つかったらでいいんじゃないでしょうか。

> |>  * each_codepointなどの導入のタイミングは
> |
> |今月。
>
> では、こちらは私が作業します。もうパッチはもらっているので当
> てるだけですけど。

rb_enc_mbclen がコードポイント単位ではなくなっているので、そ
のままでは動きません。

rb_enc_codepoint でなく、rb_enc_mbc_precious_codepoint を使っ
て、長さを得る必要があります。valid でないものを途中で見つけ
たら例外ですかね。

あー、String#codepoints なんてものが入っているんですね。これ
は?

> |* unicode 文字列に対する regexp による codepoint 単位の操作
> |  が base character に対するものになる (プロパティの検査とか)
> |  必要なら UTF-8-CODEPOINT を導入する
>
> ごめんなさい。「codepoint 単位の操作が base character に対す
> るものになる」を十分に理解していないかもしれません。
> 「\p{Katakana}」とかのマッチの対象がbase charactetrに基づいて
> 行われる(が、マッチは合成文字全体が対象になる)という理解は正
> しいですか？

はい。

% ./ruby -e 'p /\A\p{Katakana}a\z/u =~ "\u30AB\u3099a"'
0

となります。U+30AB は「カ」、U+3099 は合成用の濁点です。

この場合でいえば、合成用濁点 U+3099 のプロパティを検査したり
することができない、ということです。

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

エラーにはなりません。濁点などが無視されます。

% ./ruby -e 'p /[\u{30BB 309A}-\u30BF]/ =~ "\u30BB"'
0

U+30BB U+309A は「セ」と合成用半濁点で、アイヌ語のカナ表記で
使う文字です。それが「セ」にマッチします。

エラーにしたいのであれば oniguruma 側に検査を入れることにな
ります。コードポイントを得ているところで、文字の長さとコード
ポイントの長さが等しくなければ、というような条件になります。

まぁ、範囲の場合はそもそもどのように動作すべきか明らかでない
のでいいんですが、(Unicode 的にはコードポイントで済まさない
場合は collation みたいですがそれは locale 依存でスコープか
ら外れるので) 現実的な問題は範囲でない場合ですね。

% ./ruby -e 'p /[\u{30BB 309A}\u30BF]/ =~ "\u30BB"'
0

そのうち、/[\u{30BB 309A}\u30BF]/ は /\u{30BB 309A}|[\u30BF]/
に変換する処置をいれるべきかもしれません。そのへんの話は
Unicode TR #18 に書いてあるので、気が向いたら。
http://unicode.org/unicode/reports/tr18/

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

(昔?) ISO/IEC 6937 というのがあってこれはアクセントを先にお
くようです。べつに本能とかではなく、おそらくなんらかの得失が
検討されたのではないかと思います。しかし、瞬時符号であること
を越える利点というのは本当にあるのか、という疑いが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]