正規表現パターンを図示する正規表現チェッカーDebuggex
使い方は簡単です。
真ん中の入力枠にマッチさせたい正規表現パターン、一番下の入力枠に走査される文字列を入力します。
一番上の枠は入力欄ではなく、その下の正規表現パターン入力枠にある正規表現パターンを分析して図示したものが出力されています。
入力枠には自動的に行番号が表示されます。
正規表現はJavaScript、Python、PCREの3つに対応しています。
もうこれがあれば正規表現チェッカー（JavaScript版） | Softel labsもPyRegexも使わずに済みそうです。
右横にあるView Cheatsheetをクリニックすると一番下に移動して正規表現パターンの解説が読めます。
一番下にあるFull PCRE regex cheatsheetをクリックするともっと詳しい解説が表示されたページが開きます。
The Y'th captured groupの\Yは$1となっているときもあります(フォトアルバム作成のための写真の整理-p--qのrenameなど)。
正規表現パターンのどの部分に該当するかが示される
下にあるスライダーをスライドさせると走査される文字列にあるカーソルの位置が移動します。
スライダーを使わなくても走査される文字列をクリックしてもカーソルの位置を移動させることができます。
マッチしている文字が正規表現パターンのどこに該当するのかが正規表現パターンに示されます。
上の例では、「Button」の中の移動させている間は、正規表現パターンの「\w」の部分の両側にピンクの線がでていることがわかります。
\wは英数字の一文字を表し、+が表している貪欲(greedy)マッチは\wを回るループで表現されています。
貪欲(greedy)マッチと非貪欲(lazy)マッチの違いは図示では表現されないようです。
、、、昨日まで使えていたのに今日は502 Bad Gatewayで使えなくなっています、、、そのうちまた復活するでしょう、、、
正規表現のデメリット
パフォーマンスを意識して正規表現を書く - Shin x Blog
これを読んで正規表現は結構なコスト高であるし、走査される文字列が他から入力される状況ではセキュリティのリスクがあると知りました。
Online regex tester and debugger: PHP, PCRE, Python, Golang and JavaScript
このツールを使うと正規表現パターンが一致するまでそれほどのステップを踏むかを表示してくれます。
このツールは正規表現チェッカーでもあり、PCRE、JavaScript、Python、golangの正規表現をチェックできますが、正規表現パターンがマッチするまでのステップが見れるのはPCREだけです。
Perl Compatible Regular Expressions - Wikipedia
PCREはPerl Compatible Regular Expressionsの略で、いろいろなソフトで使えるようで、PCManFMやGeanyで使えました。
正規表現チェッカーregex101.com
Online regex tester and debugger: PHP, PCRE, Python, Golang and JavaScript
これも使い方は簡単で、左上のREGULAR EXPRESSIONに正規表現パターンを入力し、その下に走査される文字列を入力します。
左上のShow SidebarボタンをクリックするとPCRE、JavaScript、Python、golangが選択できます。
正規表現パターン入力欄の上に操作の結果とそれにかかったステップ数と消費時間が表示されます。
正規表現パターンが何をしているのかの解説が右のEXPLANATIONにでてきますし、正規表現パターンの上にマウスカーソルをもってくると正規表現のシンタックスがポップアップします。
マッチした結果は右のMATCH INFORMATIONにでてきます。
regex101.comでマッチするまでのステップを見る
左のサイドバーからpcre(php)を選択するとでてくるregex debuggerをクリックします。
マッチするまでの23の工程が表示されます。
最初の画面での表示よりも1ステップ少なくなっていますが、これはおそらく最初の画面のステップ数は最初のステップ番号が0になっているせいなのだと思われます。
match 2 failed in 2 step(s)を選択するとマッチしに失敗した行程が表示されます。
ステップ1はマッチしたときの最後のステップ23で走査した正規表現パターンを、操作された文字列の続きの部分を走査している場合です。
走査される文字列はもうないので失敗に終わります。
ステップ2は、正規表現パターンの最初から次のマッチする文字列を探しに行っています。
これも走査される文字列はもうないので失敗に終わります。
正規表現パターン入力欄の右端にある旗のアイコンをクリックして、globalのチェックを外すと、マッチした文字列をみつけた後はそれ以上は走査しないので、失敗したステップは表示されなくなります。
つまり1つだけマッチさせればよいときはglobalオプションを外しておけば2ステップ減ることになります。
globalにチェックを付けていても、$を正規表現パターンに付けておけば、走査される文字列の最後まできたあとはもう走査されないと思っていましたが、$も他のパターンと同様に走査されるのでかえってステップが増えるだけでした。
貪欲(greedy)マッチと非貪欲(lazy, non-greedy)マッチの違い
PCREでは?を付けると非貪欲(lazy, non-greedy)マッチになります。
まず貪欲(greedy)マッチの場合のステップをみてみます。
正規表現パターンは前から一つずつチェックされ、「UnoControl\w+」まできた時点で、とりあえずマッチします(ステップ12)。
しかしそのあとも正規表現パターンは続き、ステップ13からステップ17までみると「UnoControl\w+M」にマッチさせるために今度は「M」にマッチするまで後ろから走査していること(バックトラック)がわかります。
後ろから操作してすでに最後に「Model」であることがわかったので、ステップ17で終わりになるように思いますが、正規表現パターンは1文字ずつしか走査されないので、ステップ18からまた「Model」について一文字ずつ操作して、さらに6ステップが追加されて全部で23ステップになります。
次に?をつけて非貪欲(lazy, non-greedy)マッチにしてみます。
非貪欲マッチではステップ12からでもバックトラックは発生しません。
「UnoControlButtonModel」に対して「UnoControl\w+Model」で走査すると貪欲マッチでも非貪欲マッチでもたまたま同じステップ数になっていますが、「\w+」にマッチする部分がバックトラックするステップより長い時は貪欲マッチの方が非貪欲マッチよりもステップ数が少なくて済みます。
逆に「\w+」にマッチする部分がバックトラックするステップより短い時は非貪欲マッチの方が貪欲マッチよりもステップ数が少なくて済みます。
なので、貪欲マッチでも非貪欲マッチでも同じ結果が得らえる場合は、どちらを使った方がよいのかは走査される文字列がどっちのパターンが多いのかを考える必要があります。
linuxBean14.04でファイルの内容を正規表現パターンで検索する
LibreOffice SDKのexampleフォルダを「UnoControl\w+Model」で検索してみます。
ファイルマネージャ PCManFM(1.2.0)でLibreOffice SDKのexampleフォルダ(/opt/libreoffice5.2/sdk/examples)を開いた状態で、ツール→ファイルを検索する。
今回はファイル内を検索するのでファイル名のパターンは*.*にしておきます。
「内容」タブをクリックして正規表現パターンを入力して、「正規表現を使う」にチェックを入れます。
いくつかのjavaファイルがでてきました。
これらのうちの一つをGeany(1.30.1)で開いて今度はファイル内を正規表現で検索します。
検索→検索。
「検索文字列」に正規表現パターンを入力し、「正規表現を使用」にチェックして「次へ」。
「UnoControlFixedTextModel」がヒットしました。
ちなみにWindows10にインストールしたGeany 1.29でも正規表現で検索できました。
しかしエクスプローラで正規表現パターンを使ってファイル内を検索する方法はわかりませんでした。
たぶんエクスプローラではできません。
LibreOfficeドキュメント内の検索で正規表現パターンを使う
odtやodsファイルをそれぞれWriterやCalcで開いた状態で、ファイル内を正規表現パターンで検索できます。
編集→検索と置換。
「他のオプション」の中にある「正規表現」にチェックをつければ正規表現パターンで検索できました。
LibreOfficeで使える正規表現パターンは正規表現リスト - LibreOffice Helpに解説があります。
PCREとよく似ていますが、使える表現はかなり少ないです。
貪欲(greedy)マッチしかないようです。
LibreOfficeドキュメントの複数ファイルを横断的検索
LibreOfficeドキュメントの複数ファイルを横断的に検索するためにlinuxBean14.04にDocFetcher - Fast Document Searchをインストールしてみましたが、ドットで結合した文字列の一部が検索で出てきませんでした。
例えば「"com.sun.star.awt.UnoControlFixedTextModel"」を走査したときに、com.sun.star.awt.UnoControlFixedTextModelではヒットしましたが、UnoControlFixedTextModelはヒットしませんでした。
正規表現も使えるとのことですが、うまくヒットさせれませんでした。
Recoll text search finds your documents
これも試してみましたが、LibreOfficeのドキュメントの内容の検索はうまくいきませんでした。
#856605 - recoll does not index the new Libreoffice file format in flat plain xml: FODPT, FODP, etc - Debian Bug report logs
v1.23.0以上ならできるのかもしれません.
試してみたPPAにあるtrustyのリポジトリにある最新版はv1.22.3でした。
参考にしたサイト
Debuggex: Online visual regex tester. JavaScript, Python, and PCRE.
JavaScript, Python, PCRE対応している正規表現チェッカー。
正規表現チェッカー（JavaScript版） | Softel labs
JavaScriptの正規表現チェッカー。
PyRegex
Pythonの正規表現チェッカー。
パフォーマンスを意識して正規表現を書く - Shin x Blog
正規表現でもコストとかセキュリティを考えないといけないと気が付きました。
Online regex tester and debugger: PHP, PCRE, Python, Golang and JavaScript
マッチする過程を視覚的に見れる正規表現チェッカー。
Perl Compatible Regular Expressions - Wikipedia
PCREは結構いろいろなファイルに組み込まれている正規表現パターンのようです。
正規表現リスト - LibreOffice Help
LibreOfficeの検索に使える正規表現。
DocFetcher - Fast Document Search
LibreOfficeドキュメント横断的に検索できるはずですが、私の環境ではうまく動きませんでした。
#856605 - recoll does not index the new Libreoffice file format in flat plain xml: FODPT, FODP, etc - Debian Bug report logs
recoll v1.23.0以上だとLibreOfficeファイルの横断的検索が可能かもしれません。
0 件のコメント:
コメントを投稿