Expresiones regulares: diferencias entre navegadores

Question

Cada vez me doy cuenta de que debe haber grandes diferencias en la forma en que los navegadores interpretan las expresiones regulares.
Como ejemplo, un compañero de trabajo había escrito esta expresión regular, para validar que un archivo que se carga tendría una extensión PDF:

^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$

Esto funciona en Internet Explorer y en Google Chrome, pero NO funciona en Firefox. La prueba siempre falla, incluso para un PDF real. Así que decidí que las cosas adicionales eran irrelevantes y lo simplifiqué para:

^.+\.pdf$

y ahora funciona bien en Firefox, además de seguir funcionando en IE y Chrome.
¿Es esta una peculiaridad específica para asp: los controles FileUpload y RegularExpressionValidator en ASP.NET, o simplemente se debe a que diferentes navegadores admiten regex de diferentes maneras? De cualquier manera, ¿cuáles son algunos de los últimos que ha encontrado?

Answer 1

Hasta donde yo sé, Firefox no te permite tener la ruta completa de una carga. La interpretación de expresiones regulares parece irrelevante en este caso. Todavía no he visto ninguna diferencia entre los navegadores modernos en la ejecución de expresiones regulares.

Answer 2

Con respecto a la pregunta real: la expresión regular original requiere que el valor comience con una letra de unidad o un nombre de dispositivo UNC. Es muy posible que Firefox simplemente no incluya eso con el nombre del archivo. Tenga en cuenta también que, si tiene alguna intención de ser multiplataforma, esa expresión regular fallará en cualquier sistema que no sea Windows, independientemente del navegador, ya que no usan letras de unidad o rutas UNC. Su expresión regular simplificada (" aceptar cualquier cosa, siempre que termine con .pdf ") es tan buena como la verificación de un nombre de archivo que va a obtener.

Sin embargo , el comentario de Jonathan a la pregunta original no puede enfatizarse demasiado. Nunca, nunca, nunca confíe en el nombre del archivo como un medio adecuado para determinar su contenido. O el tipo MIME, para el caso. El software del cliente que habla con su servidor web (que puede que ni siquiera sea un navegador) puede mentirle sobre cualquier cosa y nunca lo sabrá a menos que lo verifique. En este caso, eso significa alimentar el archivo recibido en algún código que comprenda el formato PDF y que ese código le diga si es un PDF válido o no. Verificar el nombre del archivo puede ayudar a evitar que las personas intenten enviar archivos obviamente incorrectos, pero no es una prueba suficiente de los archivos que se reciben.

(Me doy cuenta de que puede saber acerca de la necesidad de una validación adicional, pero la siguiente persona que tenga una situación similar y encuentre su pregunta puede que no.)

Answer 3

Si está usando javascript, no encerrar la expresión regular con barras diagonales causa un error en Firefox.

Intenta hacer var regex = /^(([a-zA-Zfont>:)|(\\{2}\w+)\$?)(\\(\w[\wfont>.* )) (. pdf) $ /;

Answer 4

Como Dave mencionó, Firefox no da la ruta, solo el nombre del archivo. Además, como mencionó, no tiene en cuenta las diferencias entre los sistemas operativos. Creo que la mejor verificación que podría hacer sería verificar si el nombre del archivo termina con PDF. Además, esto no garantiza que sea un PDF válido, solo que el nombre del archivo termina con PDF. Dependiendo de sus necesidades, es posible que desee verificar que en realidad es un PDF comprobando el contenido.

Answer 5

No he notado una diferencia entre los navegadores con respecto a la sintaxis del patrón. Sin embargo, he notado una diferencia entre C # y Javascript ya que la implementación de C # permite referencias y la implementación de Javascript no.

Answer 6

Creo que los RE de JavaScript están definidos por el estándar ECMA, y dudo que haya muchas diferencias entre los intérpretes JS. No he encontrado ninguno, en mis programas, o visto mencionado en un artículo.

Su mensaje es realmente un poco confuso, ya que arroja cosas ASP allí. No veo cómo concluyes que es culpa del navegador cuando hablas de la tecnología del lado del servidor o del código generado. En realidad, ni siquiera sabemos si está hablando de JS en el navegador, validación del campo de carga (ya no puede hacerlo, al menos de manera simple, con FF3) o en el lado del servidor (ni FF ni Opera ni Safari carga la ruta completa del archivo cargado. Me sorprende saber que a Chrome le gusta IE ...).