報國挺身日記 このページをアンテナに追加 RSSフィード

2007/12/30

[] Joni 21:53

JoniのApplyCaseFold.javaを眺めてみると、5.9.1で追加した CASE_FOLD_IS_APPLIED_INSIDE_NEGATIVE_CCLASSがもう入っている。これは、/(?i:[^a-g])/と書いたときに ignore caseが否定より外側にあるのに先に適用される現状の仕様に疑問を持ったので、冗談半分で変更可能にしておいただけ。こんなところまでオリジナルを尊重しなくても良いと思うのだが。

2007/09/06

[] mbc_enc_len() (5) 00:32

ソースコードは読んだつもりですが、
チェックする関数を作る方法は分かりませんでした。

方法は、xxx_mbc_enc_len()に文字列の終了位置を引数に追加した形の関数を新しく作ります。その中で参照するバイトの位置が文字列の範囲に収まっているか、文字の終了位置が文字列の終了位置に収まっているかをチェックして、エラーを返せるようにします。

今は、範囲外のバイト値のチェックをしていませんが、チェックしたければそれも追加します。チェックしないのであれば、xxx_mbc_enc_len()と同じ長さを返します。

その関数をアプリケーションから呼び出して、文字列全体のチェックをします。

将来、何らかの手段を提供するようにします。

どういう方法になるか、いつになるかについては全くわかりませんが。

当初はmbc_to_codeした結果をcode_to_mbclenして
ゼロが返らないことをチェックするのかと思いましたが、
一番問題が起きそうなgb18030ではバイト列が壊れていても
code_to_mbclenはゼロを返さないようです。

チェックしていませんから。

前に以下のように書きました。

そもそも、鬼車のエンコーディング部分は、
正規表現ライブラリの実装に必要なものを
提供しているだけの「おまけ」ですから、
m17nの実装に利用しようとすること自体が間違いです。

しかし、松本さんにとっては安心して使えないものだということのようですので、使わないようにお願いします。

コメントも、これで終わりにして頂きたいと思います。

まつもとまつもと 2007/09/06 07:40 別件ですが鬼車5.9.0には/[^a-z]/iがアルファベット大文字にマッチしちゃうバグがあるようです。

まつもとまつもと 2007/09/06 23:10 私のところに書くと話題が分散しちゃうんで、ここでコメントにします。勘弁してください。

元の表現は「鬼車から継承した」と書いただけで、別に「鬼車に責任がある」というつもりはありませんでした(実際「責任」はないわけですし)。

現在のインタフェースになっている原因が「鬼車がそうなっていたから」であり、その理由は「まつもとがGB18030のようなエンコーディングへの対応に対する関心が薄かった」ということです。「だったら、最初からそう書けよ」と言われそうですが、すいません、言葉が足りませんでした。

というわけで、責任転嫁するつもりは最初からありませんでした。悪いのは私です。

2007/09/05

[] mbc_enc_len() (4) 00:05

鬼車が扱うことのできるエンコーディングについて
知っているのは結局は鬼車だけなので、少なくとも
鬼車の提供する関数を使って「不完全なバイトを含まない」
ことをチェックできないと安心して使えません。

ソースを見ればわかります。チェックする関数を作るのも難しくないので、もし必要ならやってください。

将来についてはわかりませんが、今のところそのようなものを追加する予定はありません。

安心して使えないということであれば、使わないようにお願いします。

まつもとまつもと 2007/09/05 00:49 ソースコードは読んだつもりですが、チェックする関数を作る方法は分かりませんでした。
当初はmbc_to_codeした結果をcode_to_mbclenしてゼロが返らないことをチェックするのかと思いましたが、一番問題が起きそうなgb18030ではバイト列が壊れていてもcode_to_mbclenはゼロを返さないようです。

2007/09/04

[][] 結合文字 23:51

将来にわたって鬼車がUnicode結合文字を1文字として
扱うことができない(するつもりがない)というのは、
いちユーザとして悲しい宣言です。

そのような宣言をした記憶はまったくありませんが?

反対に、サポートすると宣言した覚えもありません。

Unicode結合文字に関心がないので、そのような宣言はしていないつもりです。

分からないので推測ですが、mbc_enc_len()が終了位置のチェックをしないままではできないと思われたのかもしれませんが、何度も書いているように、鬼車の内部では不完全なバイト列は含まないことを条件にしているので関係ないと思います。仮に実装するとしても、mbc_enc_len()の中で結合文字の処理はしないでしょうから。

まつもとまつもと 2007/09/05 00:01 akrさんの

そうすると、Unicode の結合文字をひとつの文字として扱うのは難しそうですねぇ

に対して、

必要なら、鬼車に手を入れてもらうしかありません。

ということですから、「鬼車は結合文字に対応しない(つもり)」と読みました。
が、それは読み違いで「結合文字に対応するとも、しないとも言ってない。が、仮に対応するとしても、mbc_enc_len()でないところで対応するだろう」ということなのですね。

それでは私の誤読でした。失礼しました。

2007/09/03

[] mbc_enc_len() (3) 23:31

akr> そうすると、Unicode の結合文字をひとつの文字として
     扱うのは難しそうですねぇ。

必要なら、鬼車に手を入れてもらうしかありません。

終了位置もチェックする関数をOnigEncodingTypeに追加して、アプリケーションからはmbc_enc_len()の代わりに、そちらの関数を使うとかの方法で。(正規表現の結合文字対応まで要求しているのでなければ、鬼車については大きな変更にはならないと思います)

そもそも、鬼車のエンコーディング部分は、正規表現ライブラリの実装に必要なものを提供しているだけの「おまけ」ですから、m17nの実装に利用しようとすること自体が間違いです。

[] mbc_enc_len() (2) 00:02

「別の話」と言われればそうですが、鬼車に渡される文字列は、一文字を完成していない不完全なバイト列は含まないことを条件にしているので、バイト列の終了位置をチェックしなくてよいという意味では共通の話です。

不完全なバイト列を渡した場合の動作は保証しません。落ちることもあります。

鬼車を呼ぶ前に「一文字を完成していない不完全なバイト列は含まない」ことをチェックするのはかなりコストが高いのですが、

「コストが高い」というのは、実行コストですか、実装コストですか?

どちら側で実装しようが、コストがそんなに変わるとも思えませんが。

まつもとまつもと 2007/09/04 00:04 鬼車のエンコーディング周りのコードをm17nに利用しているのはRuby側の都合で勝手にしていることなので、それを押しつけるつもりはないのですが、将来にわたって鬼車がUnicode結合文字を1文字として扱うことができない(するつもりがない)というのは、いちユーザとして悲しい宣言です。

まつもとまつもと 2007/09/04 00:08 コストについてですが、これは「アプリ側の実装コスト」です。

鬼車が扱うことのできるエンコーディングについて知っているのは結局は鬼車だけなので、少なくとも鬼車の提供する関数を使って「不完全なバイトを含まない」ことをチェックできないと安心して使えません。
私の見落としで「この関数をこのように使えば不完全なバイトを含まないことをチェックできるよ」ということであれば、それで構わないのですが。