Expressions régulières: Différences entre les navigateurs

Question

Je prends de plus en plus conscience qu'il doit exister d'importantes différences dans l'interprétation des expressions régulières par les navigateurs.
Par exemple, un collègue a écrit cette expression régulière pour confirmer qu'un fichier en cours de téléchargement aurait une extension PDF:

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

Cela fonctionne dans Internet Explorer et dans Google Chrome, mais PAS dans Firefox. Le test échoue toujours, même pour un PDF réel. J'ai donc décidé que le matériel supplémentaire était hors de propos et je l'ai simplifié:

^.+\.pdf$

et maintenant cela fonctionne bien dans Firefox, tout en continuant à fonctionner dans IE et Chrome.
S'agit-il d'une bizarrerie spécifique aux contrôles asp: FileUpload et RegularExpressionValidator dans ASP.NET ou est-ce simplement dû au fait que différents navigateurs prennent en charge la regex de différentes manières? De toute façon, quelles sont certaines de ces dernières que vous avez rencontrées?

Answer 1

Pour autant que je sache, firefox ne vous laisse pas connaître le chemin complet du téléchargement. L'interprétation des expressions régulières ne semble pas pertinente dans ce cas. Je n'ai pas encore vu de différence entre les navigateurs modernes dans l'exécution des expressions régulières.

Answer 2

Concernant la question réelle: la regex d'origine requiert que la valeur commence par une lettre de lecteur ou un nom de périphérique UNC. Il est tout à fait possible que Firefox n'inclue tout simplement pas cela avec le nom de fichier. Notez également que, si vous avez l’intention d’être multiplate-forme, cette expression rationnelle échouera sur tout système non-Windows, quel que soit le navigateur, car il n’utilise pas de lettres de lecteur ou de chemins UNC. Votre expression rationnelle simplifiée ("n'acceptez rien, tant qu'elle se termine par .pdf") correspond à peu près à la vérification du nom de fichier que vous allez obtenir.

Cependant , le commentaire de Jonathan sur la question initiale ne saurait être surestimé. Jamais, jamais, jamais ne faites confiance au nom de fichier comme moyen adéquat de déterminer son contenu. Ou le type MIME, d'ailleurs. Le logiciel client qui communique avec votre serveur Web (qui peut ne même pas être un navigateur) peut vous mentir à propos de n'importe quoi et vous ne le saurez jamais à moins que vous ne le vérifiiez. Dans ce cas, cela signifie que le fichier reçu doit être introduit dans un code comprenant le format PDF et que ce code vous indique s'il s'agit d'un PDF valide ou non. Vérifier le nom du fichier peut aider à empêcher les utilisateurs d’essayer de soumettre des fichiers manifestement incorrects, mais ce n’est pas un test suffisant des fichiers reçus.

(Je réalise que vous êtes peut-être au courant de la nécessité d'une validation supplémentaire, mais que la prochaine personne qui se trouve dans une situation similaire et trouve votre question ne le sait pas.)

Answer 3

Si vous utilisez du javascript, ne pas entourer la regex de barres obliques provoque une erreur dans Firefox.

Essayez de faire var regex = /^(([a-zA-Z]:)|(\\{2Buch\w+)\$?)(\\\\\\\\\\. )) (. pdf) $ /;

Answer 4

Comme Dave l’a mentionné, Firefox ne donne pas le chemin, mais uniquement le nom du fichier. Aussi, comme il l'a mentionné, cela ne tient pas compte des différences entre les systèmes d'exploitation. Je pense que la meilleure chose à faire serait de vérifier si le nom du fichier se termine par PDF. En outre, cela ne garantit pas qu'il s'agit d'un PDF valide, mais simplement que le nom du fichier se termine par PDF. En fonction de vos besoins, vous pouvez vérifier qu'il s'agit bien d'un PDF en vérifiant le contenu.

Answer 5

Je n'ai pas remarqué de différence entre les navigateurs en ce qui concerne la syntaxe du motif. Cependant, j'ai remarqué une différence entre C # et Javascript, car l'implémentation de C # permet les références arrière, contrairement à l'implémentation de Javascript.

Answer 6

Je crois que les RE JavaScript sont définies par la norme ECMA et je doute qu'il existe de nombreuses différences entre les interpréteurs JS. Je n'en ai trouvé aucun dans mes programmes ou mentionné dans un article.

Votre message est en fait un peu déroutant, puisque vous y ajoutez des éléments ASP. Je ne vois pas comment vous concluez que c'est la faute du navigateur lorsque vous parlez de la technologie côté serveur ou du code généré. En fait, nous ne savons même pas si vous parlez de JS dans le navigateur, de validation du champ de téléchargement (vous ne pouvez plus le faire, du moins de manière simple, avec FF3) ou du côté serveur (ni FF ni Opera). ni Safari ne charge le chemin complet du fichier téléchargé. Je suis surpris d'apprendre que Chrome aime IE ...).