我越来越意识到，正则表达式将被浏览器解释的方式必定存在重大差异。
作为一个例子，一个同事写了这个正则表达式，以验证所上载的文件将有一个PDF扩展名：正则表达式：浏览器之间的差异
^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$
这个工作在Internet Explorer和谷歌浏览器，但不在Firefox中工作。测试总是失败，即使对于实际的PDF。所以我决定，多余的东西是不相关的，它简化为：
^.+\.pdf$
，现在，它在Firefox正常工作，以及继续在IE和Chrome的工作。
这是一个特定于asp：FileUpload和RegularExpressionValidator控件在ASP.NET中的怪癖，还是仅仅是由于不同的浏览器以不同的方式支持正则表达式？无论哪种方式，你遇到的后者有哪些？
据我所知，Firefox不会让你有一个上传的完整路径。正则表达式的解释在这种情况下似乎不相关。我还没有看到现代浏览器在正则表达式执行中的区别。
如果您使用的是JavaScript，而不是用斜线括起正则表达式会导致Firefox中的错误。
尝试做var regex = /^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$/;
我没有注意到模式语法方面的浏览器之间的区别。不过，我注意到C＃和Javascript之间的区别，因为C＃的实现允许反向引用，而Javascript的实现不允许。
关于实际问题：原始正则表达式要求值以驱动器号或UNC设备名称开头。 Firefox很可能只是不包含文件名。还要注意的是，如果您有任何跨平台的意图，那么无论浏览器如何，该正则表达式都将在任何非Windows系统上失败，因为它们不使用驱动器号或UNC路径。您的简化正则表达式（“接受任何东西，只要以.pdf结尾”）与您将要获得的文件名检查差不多。
但是，乔纳森对原始问题的评论怎么强调都不为过。从来没有，永远，永远信任文件名作为确定其内容的适当手段。或者就此而言，MIME类型。客户端软件与您的Web服务器（甚至可能不是浏览器）交谈可能会对您说谎，除非您验证，否则您永远不会知道。在这种情况下，这意味着将收到的文件馈送到某些能够理解PDF格式的代码中，并让该代码告诉您它是否是有效的PDF。检查文件名可能有助于防止人们尝试提交明显不正确的文件，但这不是对收到的文件的足够测试。
（我知道你可能知道需要额外的验证，但旁边的人谁也有类似的情况，并认为你的问题可能不是。）
戴维提到，Firefox不给的路径，只有文件名。同样如他所提到的，它并没有考虑操作系统之间的差异。我认为你可以做的最好的检查是检查文件名是否以PDF结尾。另外，这并不能确保它是有效的PDF，只是文件名以PDF结尾。根据您的需求，您可能希望通过检查内容来验证它是否为PDF。
我相信JavaScript REs是由ECMA标准定义的，我怀疑JS解释器之间有很多不同。我没有在我的程序中找到任何内容，也没有在文章中看到。
你的消息实际上有点混乱，因为你在那里扔ASP的东西。当你谈论服务器端技术或生成的代码时，我不明白你是如何得出结论的，这是浏览器的错误。实际上，我们甚至不知道你是否在浏览器上谈论JS，如何验证上传字段（至少以简单的方式，使用FF3）或在服务器端（既不是FF也不是Opera） Safari也没有上传上传文件的完整路径，我很惊讶地发现Chrome并不像IE那样）。
正则表达式控制的所有东西都是文件名以'.pdf'结尾（并且可能需要不区分大小写，因为它似乎是Windows）。它不保证对文件的内容进行任何排序 - 不要混淆区别。病毒编写者依赖于此。 – 2008-11-08 01:06:34
我不认为这与问题有很大关系。我会肢体语言，并说能够读/写正则表达式的“无人”足够愚蠢，认为文件扩展名验证内容。它做的是帮助避免浪费服务器带宽，存储和上传周期，甚至没有命名为正确的类型！ – Grank 2008-11-08 03:34:31
再一次，你很混淆......如果你想通过避免上传错误类型的文件来节省带宽，你必须在浏览器端进行验证......如果可能的话，在FF3中已经变得很难，就像我写的那样。 – PhiLho 2008-11-08 19:04:11