왜이 정규 표현식이 작동하지 않습니까?

일부 IIS URL 다시 쓰기에서 사용할 정규식을 설계하고 있습니다. 의도는 URL을 캡처하는 것입니다 : 루트 디렉토리 (기간을 포함로 식별)왜이 정규 표현식이 작동하지 않습니까?

그냥 파일되지 않습니다, 그리고
는 쿼리 문자열을 포함하지 말고,
이에 속하지 않는 특정 하위 디렉토리의 설정, 특히 "계정"과 "공공"

나의 현재 정규식 보이는 같은 :

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

이

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

내 정규식이 올바르게 처음 두 경우를 무시하지만 여전히 세 번째 경우에 일치한다 :의 테스트 세트와 RegexPal 사용. 여기에 미리보기가 잘못 되었나요?

출처

2012-04-20 Jeffrey Blake

이것은 ... 나를 위해 RegexPal에서 예상대로 작동하는 것 같습니다. 당신은 당신의 예제에서 마지막 3 개만을 일치시키고 싶습니다. – climbage

수정. 나를 위해 그것은 2, 3, 5, 6, 7을 맞 춥니 다. –

좋습니다. 정말 이상합니다. 내 실제 테스트에서 예제를 띄워 놓았습니다. 각 예제 사이에 빈 줄을 삽입했습니다. 빈 줄을 제거하면 원하는 결과를 얻을 수 있습니다. –

sln에 의해보고 된 것처럼 RegexPal에서 이러한 테스트의 문제점은 다중 회선 테스트를 실행하면 그렇지 않은 경우 여러 회선을 그룹화하여 단일 일치를 만들 수 있다는 것입니다.

정규 표현식은 그것이 성취 될 목적으로 적합합니다. 실제로 과잉입니다. IIS Rewrites 및 Redirects의 경우 IIS URL Rewrite Module을 사용하는 경우 일치 여부를 지정할 수있는 옵션이 있습니다. 이러한 옵션 중 일부는 다음과 같습니다

항목
항목
항목이 수행하는 실제 디렉터리가 아닌 실제 파일없는 (또는하지 않습니다)이 달성 보조 패턴을

일치 부정적인 선견자보다 더 완벽하게 원하는 효과.

출처

2012-04-20 20:40:07

아마 ^(?!Account|Public)([^\.\/]+\/[^\?]*)$ 정규식을 사용하고 싶었을 것입니다.

것은 여기를보세요 : http://ideone.com/q3lAv이

그리고 올바른 RegExPal 패턴이 될 것 ^(?!Account|Public)([^\.\/]+\/[^\?\n]*)$

[업데이트]

파일 이름의 이름에 점 .을 포함하지 않고 반면에 폴더/디렉토리 이름은 그 이름에 점 .을 가질 수 있지만 7 번째 줄에서도 긍정적 인 일치를 원한다면 암탉은 ^(?!Account|Public)([^\.\/]+(?:\/[^\?]*|[^\.\?]*))$ 패턴으로 가야하며 RegExPal 패턴으로도 작동해야합니다.

은 여기를보세요 : http://ideone.com/VcmEP는

출처

2012-04-20 21:59:47

이는 7 번째 항목에서 일치하지 않습니다. 또한, 당신은'/'도망 갈 필요가없고'[] '안에'.'을 벗어날 필요가 없다고 확신합니다. –

@JeffreyBlake -'/'와'.'를 이스케이프하는 것이 더 안전합니다. 일부 언어에서 필요로하는 정규식 (예 : * Perl *)처럼 꽤 표준 적입니다. 그 외에, 왜 7 번째 아이템을 맞추고 싶습니까? 파일 이름에 도트가 필요하지 않습니다. 그러나 ... 그것이 당신이 찾고있는 것이라면 위의 업데이트 된 대답을보십시오. 제 대답을 고맙게 생각합니다. –

내가 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

출처

2012-04-20 22:29:03 alan

나는 루트에있는 파일들이 마침표로 끝나야한다고 생각하는데, 이것은 틀린 것이다. 마침표는 사실상 문자열의 끝에있을 수 없습니다. 종종 3자를 포함하지만 때로는 더 많고 때로는 적습니다. –

@ JeffreyBlake : 아니요, 선견자가 어떻게 작동하는지가 아닙니다. 그것이 부정적인 예측이기 때문에 마침내 마침표를 만나면 일치하고 실패합니다. 이것은 당신이 원하는 것입니다. 기간이 끝나야 할 필요는 없습니다. 그것을 시도하고 볼 수 있습니다. – alan

JeffreyBlake : @sln에서 답을 읽은 후 RegExPal에서 어떤 일이 벌어지고 있는지 확인할 수 있습니다. 귀하의 정규식은 실제로 하나의 일치 항목 (예 : 3 개의 모든 행이 하나의 일치 항목으로 구성됨)으로 샘플 입력의 마지막 세 줄을 일치시키고 '여러 줄 앵커'를 선택하지 않으면 RegExPal은 일치 항목을 표시하지 않습니다 (색상). sln의 대답이 이유를 설명합니다.내 대답이나 sln의는 당신이 필요로하는 일을 할 것이지만, 확실히 끝나지 않는 라인 엔딩이기 때문에 어떤 점에서는 정규 표현식이 실패 할 수도 있습니다. sln의 대답은 내 것보다 일반적이기 때문에 더 나을 수도 있지만 생산 환경에서 사용하기를 주저합니다. – alan

RegexPal은 혼란 스럽지만 실제 문제는 정규 표현식이 올바르게 설계되지 않았다는 것입니다.

당신이 일을하려고하지만 당신은 특별히 그런 식으로 설계하지 않는 한, 정규식 내에서 멀티 라인 모드와 앵커 ^$
를 사용하면된다 무엇인지는주의가
오버 플로우 앵커하지 않도록해야하지. 이는 욕심/비 욕심쟁이 한정 기호 둘 다에 적용됩니다.
부정적인 선견문 조건을 혼합에 던지면 악화됩니다.

이 경우 RegexPal이 다시 공격을 받아야하고 다시 재평가하지 않고 ^
전에 다시 추적해야합니다. JavaScript 문제는 아닙니다.

소비 클래스에 개행을 추가하면 모든 문제가 해결됩니다. 두 클래스 모두에
이 추가되어야합니다.

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

출처

2012-04-21 00:36:45 sln

+1 문제가 발생한 이유를 설명합니다. 실제로 리다이렉트 시스템은 단일 URL을 처리하기 때문에 개행 문제는 문제가되지 않습니다. –

왜이 정규 표현식이 작동하지 않습니까?

답변

관련 문제