positive - ¿Por qué no funciona este Regex Lookahead?

regex positive lookahead example

Question

Estoy diseñando una expresión regular para usar en algunas Reescrituras de Url de IIS. La intención es capturar URL que:

1. No son solo un archivo (como se identificó al contener un punto) en el directorio raíz, y
2. No contiene una cadena de consulta, y
3. No pertenece a un conjunto específico de subdirectorios, específicamente "Cuenta" y "Público"

Mi expresión regular actual se ve así:

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

Usando RegexPal con el conjunto de prueba de:

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

Mi expresión regular ignora correctamente los dos primeros casos, pero aún coincide en el tercer caso. ¿Qué hay de malo con la búsqueda aquí?

Answer 1

No pude resistirme a tratar de encontrar algo que funcionara en RegExPal (no tuvo éxito - Editar: simplemente verificado y esto sí funciona en RegExPal ) pero pensé que lo lanzaría como otra forma de hacer lo que necesitabas, eso puede ser un poco más fácil de entender:

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

Explicado:

^                   # 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 2

RegexPal está confundido, pero el problema real es que la expresión regular no está diseñada correctamente.

No estoy seguro de lo que está tratando de hacer, pero al usar el modo multilínea y las anclas ^$
dentro de una expresión regular, a menos que específicamente lo diseñe de esa manera, se debe tener cuidado de NO
desborda los anclajes. Esto se aplica a los cuantificadores codiciosos / no codiciosos.
Es aún peor cuando arrojas condiciones negativas de anticipación a la mezcla.

En este caso, causó que RegexPal se volviera loca y aparentemente retrocediera antes ^
sin reevaluar ^ nuevamente. Sin embargo, probablemente este no sea un problema de JavaScript.

Agregar líneas no nuevas a tus clases de consumo corrige todos los problemas. Debe ser
agregado a ambas clases.

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

Answer 3

Tal vez quería usar ^(?!Account|Public)([^/.//]+//[^/?]*)$ Regex.

Eche un vistazo aquí: http://ideone.com/q3lAv

Entonces, corrige el patrón RegExPal sería ^(?!Account|Public)([^/.//]+//[^/?/n]*)$

[ACTUALIZAR]

El nombre de archivo no tiene que incluir punto . en su nombre y, por otro lado, el nombre de la carpeta / directorio puede tener punto . en su nombre, pero si desea tener una coincidencia positiva también en la 7ma línea, entonces debe ir con el patrón ^(?!Account|Public)([^/.//]+(?://[^/?]*|[^/./?]*))$ y debería funcionar también como el patrón RegExPal.

Eche un vistazo aquí: http://ideone.com/VcmEP

Answer 4

Según lo informado por sln , el problema con estas pruebas en RegexPal es que ejecutar una prueba de múltiples líneas permite que varias líneas se agrupen para crear una coincidencia única cuando de otro modo no deberían.

La expresión regular está bien para los fines que está diseñado para cumplir. En realidad es excesivo. Para las reescrituras y redireccionamientos de IIS, si está utilizando el módulo de reescritura de URL de IIS , tiene la opción de especificar las condiciones en las que aceptará o no las coincidencias. Algunas de esas opciones incluyen:

• El artículo no es un archivo físico
• El artículo no es un directorio físico
• El artículo no coincide (o no) con un patrón secundario

Estos lograrán el efecto deseado más completamente que el negativo-lookahead.