SkRegExp version 3.0 は大文字小文字を区別しない検索も Unicode 標準に対応しました。
従来、大文字小文字を区別しない検索は、小文字を大文字に変換して比較していました。
小文字を大文字に変換する方法は、UnicodeData.txt の大文字の情報を使っていました。
しかし、この方法には問題があります。
ヨーロッパの言語では一つの大文字が複数の小文字に対応したり、またその逆だったりします。
UnicodeData.txt の情報ではこうした文字を取りこぼしてしまいます。
もっとも、日本人は別に困りませんけどね。
とは言っても SkRegExp の野望は世界進出です。
世界に出るためにはヨーロッパを無視できません。
というわけで重い腰を上げました。
このような用途のためには CaseFolding.txt を使えばいいのだそうです。
CaseFolding.txt とは、こんなのが書かれているテキストファイルです。
1E9E; F; 0073 0073; # LATIN CAPITAL LETTER SHARP S
1E9E; S; 00DF; # LATIN CAPITAL LETTER SHARP S
1EA0; C; 1EA1; # LATIN CAPITAL LETTER A WITH DOT BELOW
CaseFolding.txt を読むと、シンプルセットなら C と S を、フルセットなら C と F をサポートすればいいとのこと。
TRegEx はシンプルセットのようなので SkRegExp はフルセットをサポートしました。
同じだったら SkRegExp を使う意味はないですからね。
ちなみに「速度が落ちるかな？」と思ったらそうでもありませんでした。
まあ、落ちたことは落ちたんですが最適化の見直しもあって影響はゼロでした。
ヨーロッパの言語を使う機会がある方は SkRegExp がお勧めです。
大文字小文字を区別しない検索も Unicode 標準フルセットへ対応した SkRegExp version 3.0 はこちらからダウンロードできます。
記事と直接関係ない内容ですみませんが、
Thread: The Delphi PCRE library is 1000 times slower than Python’s PCRE code
https://forums.embarcadero.com/thread.jspa?messageID=495830
こんな話題が盛り上がっているみたいです。
内部的なUTF8関連の問題が原因みたいですが、SkRegExpの場合はどうですかね？
最近SkRegExpを更新できてないので、自分ですぐに試せないのですが。
＃このスレッドにSkRegExpを紹介すれば、かなりユーザーが増えるかもしれません:-)
benok さん、いつもいろいろ教えていただき、ありがとうございます。
つたない英語力でちょっと見ただけですが…
TRegEx のような問題は発生しないので、標準の TRegEx よりは間違いなく速いでしょう。
でも、たぶん、pythonほどのスピードは出ないと思います。
と言うのも、SkRegExp、実はこのようなパターンと検索文字列の組み合わせが苦手です。
この種の単純なパターンは別処理に回して高速化を図るのがセオリーです。
でも、SkRegExp ではその種の細工をしていません。
理由は「現実的でないから」なんですが、でもこれで速度を比較する人がいるんですね。
ベンチマーク対策としても取り組む必要がありそうです。
いえ、私は実用スピードを重んじる、小宮さんの開発方針は良いと思います。
ベンチマークばかり早くても仕方ないですし、
良くわかっている方が書いていないコードなのではないかと思います。
pythonの実装が本当に優秀なのであれば、実装を眺めてみると、
小宮さんレベルの方でしたら、得るものがあるのでは？と思います。
また、関係ないですが、下記のような記事が上がっていました。
実装毎の正規表現の差異が知りたい時には良いかもしれません。
http://www.regexguru.com/2013/10/regular-expressions-reference-tables-updated/
http://www.regular-expressions.info/reference.html
ご参考まで。
benokさん、ご賛同いただき、ありがとうございます。
それでもデモンストレーションとして考えたらこの種の対策も必要かな？とは思いました。
このパターンとテキストッて、わかりやすいですからね。