From: Tanaka Akira Date: 2008-09-16T12:50:08+09:00 Subject: [ruby-dev:36318] Re: 合成文字の2コードポイント目 In article , Yukihiro Matsumoto 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]