なぜこの正規表現ルックアヘッドは機能しませんか？

Question

いくつかのIIS URLリライトで使用する正規表現を設計しています。

1. は、クエリ文字列が含まれていない、と
2. はに属していない（ピリオドを含むことで識別される）ルートディレクトリに単にファイルされておらず、
3. ：意図は、URLをキャプチャすることです特定のサブディレクトリのセット、特に「アカウント」と「公開」

私の現在の正規表現は次のようになります。

^(?!(Account)|(Public))([^./]+)(/[^?]*)?$ 

のテストセットとRegexPal使用：

file.aspx 
Account/otherfile.aspx 
Public/otherfile.aspx 
otherfolder1/otherfile.aspx?stuff=otherstuff 
otherfolder2/otherfolder/otherfile.aspx 
otherfolder3/ 
otherfolder4 

私の正規表現は、正しく最初の二つのケースを無視し、それはまだ第三の場合に一致します。ここで先読みに何が間違っていますか？

Answer 1

slnで報告されているように、RegexPalのこれらのテストでの問題は、複数行のテストを実行すると、複数の行をまとめてグループ化して、そうでなければ単一の一致を作成できることです。

regexは、それが実現するように設計されているため、問題ありません。それは実際に過労です。 IISリライトとリダイレクトの場合、IIS URL Rewrite Moduleを使用している場合、一致するかどうかを指定するオプションがあります。これらのオプションのいくつか含まれます：

• 項目が物理ファイルではありません
• 項目が物理ディレクトリではありません
• 項目がする（またはしない）、これらが達成する二次パターン

と一致ネガティブ・ルックアヘッドよりも完全に望ましい効果を発揮します。

Answer 2

^(?!Account|Public)([^\.\/]+\/[^\?]*)$正規表現を使用したかったでしょうか。

こちらをご覧ください：http://ideone.com/q3lAv

を次に正しいRegExPalパターンが^(?!Account|Public)([^\.\/]+\/[^\?\n]*)$

---

だろう[UPDATE]

ファイル名は、その名前にドット.を含める必要はありません。また、一方、フォルダ/ディレクトリ名には、その名前にドット.が含まれていますが、7行目にも肯定的な一致が必要な場合は、tあなたはパターン^(?!Account|Public)([^\.\/]+(?:\/[^\?]*|[^\.\?]*))$を持っていて、RegExPalパターンとしても機能するはずです。

こちらをご覧ください：http://ideone.com/VcmEP

Answer 3

を私はRegExPalで働く何かを思い付くしようとしたレジスト（成功しませんでした - 編集を：ちょうど検証し、これはRegExPalでは動作しない）ことができませんでしたが、私それは理解し少し楽かもしれ、私はあなたが必要なものを行うための別の方法として、そこにこれを投げるだろうと思った：

^(?!Account|Public|[a-zA-Z_0-9]+\.)[a-zA-Z_0-9/.]+$ 

を説明：

^     # start 
(?!     # open a negative lookahead 
Account|Public|  # ignore both Account and Public 
[a-zA-Z_0-9]+\.  # ignore files in root (i.e., letters/numbers, followed by period) 
)     # close negative lookahead 
[a-zA-Z_0-9/.]+  # now match anything with letters/numbers, periods and slashes, but no '?' (ignores URLs with query string) 
$     # end 

を

Answer 4

RegexPalは混乱しますが、本当の問題は正規表現が正しく設計されていないことです。

ないあなたがやろうとしているのかわからなく、マルチラインモードと正規表現内のアンカー^$
を使用しているときは、特にそのように設計していない限り、介護ではない
オーバーフローアンカーに注意する必要があります。これは、欲張り/非貪欲の量指定子の両方に適用されます。
ミックスに否定的な先読み条件を投げ込むと、さらに悪化しました。この場合

、それはRegexPalは狂気に行くと明らかに再び^再評価せずに^
前に後戻りさせました。これはおそらくJavaScriptの問題ではありません。

消費クラスに改行を追加すると、すべての問題が修正されます。両方のクラスに
が追加されている必要があります。

^(?!Account|Public)[^./\n]+(?:/[^?\n]*)?$