From: Tanaka Akira Date: 2008-09-16T10:25:59+09:00 Subject: [ruby-dev:36316] Re: 合成文字の2コードポイント目 In article , Yukihiro Matsumoto writes: > ごめんなさい、実際になにができるようになったのか完全には把握 > していないのですが、正規表現を含め文字列操作がコードポイント > 単位ではなく、「文字(extended grapheme cluster)」単位にできる > ようになった、という理解で構いませんか。 はい。 > 私が思いつくのは以下のようなものですが > > * UTF-8などUnicode系全般で対応するのか、それとも特別なエン > コーディング(UTF-8-MAC?)を用意するのか 現在、UTF-8 でやっています。 UTF-16 や UTF-32 もやるべきかもしれません。 コードポイント単位のものが必要なのであれば、むしろ UTF-8-CODEPOINT とかを導入するのがいいのではないかと思ってい ます。 > * Unicode系以外のエンコーディングはどうするのか(Shift_JISに > おける濁点付きカナとか) JIS X 0201 の濁点は独立した文字として定義されているのでそう はしません。 というか、Unicode 以外に合成文字を使っている規格を私は知りま せん。 GB18030 は中に Unicode が入っているので、これはやるべきかも しれません。 > * each_codepointなどの導入のタイミングは 今月。 > 仮にそうであった場合、導入にあたっての懸念がありますか。 いくつかありますが、実装というより仕様の問題で、どうにかした ければ UTF-8-CODEPOINT を使うということになります。 * unicode 文字列に対する regexp による codepoint 単位の操作 が base character に対するものになる (プロパティの検査とか) 必要なら UTF-8-CODEPOINT を導入する * regexp における character class の動作が文字の中の最初のコー ドポイントに対するものになる。 幸いにして Unicode においては最初のコードポイントが base character なのでそんなに変なことにはならないようで す * IO#getc で、(制御文字以外では) 次のコードポイントがこない と文字の終端が判断できない まだそうなってしまうようには実装していませんが、する予定で す。ただ、line buffering な端末なら気がつきません。 (base character が最後に来るように並んでればこういうことに はならずに済んだんですが) -- [田中 哲][たなか あきら][Tanaka Akira]