Unicodeのことしか考えていなかったが、今回の変更は他の文字エンコーディングにも影響する。といっても、0xdf=>ssだけであり、関係する文字エンコーディングもISO-8859-XXだけなので、殆ど影響はないと思う。

5.4.0をリリース。 ONIGENC_CASE_FOLD_MULTI_CHARを廃止して、常にmulti-charへのfoldingを有効に変更

検討の結果、ONIGENC_CASE_FOLD_MULTI_CHARによる指定を無くして、何も指定しなくても常にstatus fieldがFの処理を実行することにした。

Unicodeのcase fold処理が正しくなかったことが判明した。 http://www.unicode.org/Public/UNIDATA/CaseFolding.txtのstatus fieldがCとFをデータとして取り込んでいるのだが、Sは捨てていた。Fは鬼車ではONIGENC_CASE_FOLD_MULTI_CHARを指定しているときだ…

日本語のページも作ってみたが... http://www.geocities.jp/kosako3/oniguruma/index_ja.html 全く意味がなかったとしか言いようがない。

上記の仮説が正しいという保証は全くない(まだPHPのconfigure/makeをやったことがないので)のだが、それぐらいの可能性しか思い付かなかったので、今日のリリース(5.3.0)で、その場合の対処を入れている。 つまり、鬼車のヘッダファイルのうちconfig.hをイン…

PHP6のコードを少しだけ見てみる。 見落としがあるかもしれないが、oniguruma.hの中に #include "php_onig_compat.h" が追加された程度しか手は入っていないようにみえる。php_onig_compat.hの中身を見たが、これは関係なさそうだ。 PHPのどこかのファイルで…

問題というのは、oniguruma.hをインクルードするよりも手前でONIG_ESCAPE_UCHAR_COLLISIONを定義する(それをどこのファイルでやるのかは知らないのだが)と、今度は鬼車のコンパイルでエラーになるということらしい。

5.3.0をリリース。 EUC-JP/Shift_JISで、Hiragana/Katakanaプロパティ追加

それで、PHPのソースをダウンロードして見てみた。 意外なことに、PHP5.2ではONIG_ESCAPE_UCHAR_COLLISIONをどこにも定義していない。ということは、私が用意した対処方法を使っていないということか？UCharを使っているのもmbstring内しかない。結局、事情…

それで今回の問い合わせに対しても、前回こちらで行った対処について説明して終わりだと思っていた。しかし、それでは駄目だと言われてしまった。こちらはPHPのコードを見ていないので、対処方法は相手に任せることにしたのだが、どうも気になる。

やっぱり、長音記号も濁点記号も含めないことにした。Unicode Propertyに合わせる。泣く子とUnicodeには勝てない。

PHP6で、他のライブラリで定義しているUChar型と、鬼車のUCharの定義が衝突して困るというメールを先週受け取った。これと同様のメールを、一年半前に別の人から貰ったことがある。このときはPHP5.0で、別のライブラリというのはICUのこと。 そのときには、o…

カナ文字のプロパティに濁点記号を含めるかどうかはともかく、長音記号は含めたい気がする。「ストーブ」にマッチするために、/[\p{Katakana}ー]+/と書かなければいけないのでは、あまり使う気がしない。でもUnicodeと違うことをすると怒られるかも？

4.5.1をリリース。 バグ修正 リファクタリング

5.2.0をリリースしたので、次に何をするか考えてみる。 リクエストされているのは、日本語文字エンコーディング(EUC-JP, Shift_JIS)で、Hiragana、Katakanaプロパティを使えるようにするというもの。 他に考えられるのは、 ひらがなとカタカナの曖昧マッチ …

Hiragana/Katakanaプロパティを実装するとした場合、濁点、半濁点、長音記号の各文字を含めたほうが良いのかどうかがわからない。Unicode Propertyでは含まれていないので、同じにしたほうが良いのだろうか？

5.2.0をリリース。 CP1251を追加 [:punct:]が正しくないバグ修正

CP1251エンコーディングのコードを送ってもらったので、次のリリース(5.2.0)で追加する。

5.1.0では、Rubyでの動作テストスクリプト(test.rb)を外した。 以前から書いているように、5.0以降はRubyと無関係になることを目的にしているのだが、まだRuby組込み用のコードが残っている。これは今後削除していく。

2.5.8をリリース。 Ruby 1.8.5用のパッチを追加 細かいバグ修正

5.1.0をリリース。 ONIGENC_CASE_FOLD_MULTI_CHARの残件の対応 ONIG_OPTION_FIND_LONGESTを最左最長から最長マッチに変更 細かいバグ修正

今日5.1.0をリリースするつもりだったが、事情があって断念。

4.5.0をリリース。 ONIGENC_AMBIGUOUS_MATCH_COMPOUND廃止 ONIG_OPTION_FIND_LONGESTを最左最長から最長に変更

4.4.6のONIGENC_AMBIGUOUS_MATCH_COMPOUNDは、次のリリースで廃止しようと考えている。これは、5.0のONIGENC_CASE_FOLD_MULTI_CHARに相当するが、4.XではU+00DFだけしか対応していないので、あまり意味がない。

Rubyのように自前で文字列をscanする場合もあるアプリケーションに対しては、正規表現ライブラリの側で最長マッチを探索するのはやり過ぎかもしれない。最左最長と最長マッチのどちらにするかを、コンパイル時点で切り替えられるようにしよう。デフォルトは…

本当の最長マッチにするパッチを送ったら、「今の仕様で正しいから変更しなくていい」と言われた。

あまりテストはしていないが、とりあえず本当の最長マッチができるようになった。折角なので、この変更は4.X, 5.Xの両方に取り入れようか。

鬼車の検索時オプションONIG_OPTION_FIND_LONGESTとONIG_OPTION_FIND_NOT_EMPTYをRubyから指定できるようにパッチを書いている人がいるらしい。 そのことはどうでもよいのだが、ONIG_OPTION_FIND_LONGESTの振る舞いに疑問をもたれてしまった。(f:not empty, …

5.0.1で積み残しの問題(ONIGENC_CASE_FOLD_MULTI_CHAR)は、解決方法は見つかったのだが実装が物凄く面倒でまだできていない。早く出したいのに、来週以降になってしまいそう。 新しい機能追加については、さらにその後になる。