1

我越来越意识到浏览器解释正则表达式的方式肯定存在重大差异。
例如，一位同事编写了这个正则表达式，以验证上传的文件是否具有 PDF 扩展名：

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

这适用于 Internet Explorer 和 Google Chrome，但不适用于 Firefox。测试总是失败，即使是实际的 PDF。所以我认为额外的东西是无关紧要的，并将其简化为：

^.+\.pdf$

现在它在 Firefox 中运行良好，并且继续在 IE 和 Chrome 中运行。
这是 ASP.NET 中的 asp:FileUpload 和 RegularExpressionValidator 控件特有的怪癖，还是仅仅是因为不同的浏览器以不同的方式支持正则表达式？无论哪种方式，您遇到过哪些后者？

4

6 回答 6

4

关于实际问题：原始正则表达式要求该值以驱动器号或 UNC 设备名称开头。Firefox 很可能根本不将其包含在文件名中。另请注意，如果您有任何跨平台的意图，那么无论浏览器如何，该正则表达式都会在任何非 Windows 系统上失败，因为它们不使用驱动器号或 UNC 路径。您的简化正则表达式（“接受任何东西，只要它以 .pdf 结尾”）与您将获得的文件名检查一样好。

但是，乔纳森对原始问题的评论怎么强调都不过分。永远，永远，永远不要相信文件名是确定其内容的充分手段。或者 MIME 类型，就此而言。与您的 Web 服务器（甚至可能不是浏览器）通信的客户端软件可能会在任何事情上对您撒谎，除非您验证它，否则您永远不会知道。在这种情况下，这意味着将接收到的文件输入到一些可以理解 PDF 格式的代码中，并让该代码告诉您它是否是有效的 PDF。检查文件名可能有助于防止人们尝试提交明显不正确的文件，但这并不足以对收到的文件进行测试。

（我知道您可能知道需要进行额外验证，但下一个遇到类似情况并发现您的问题的人可能不知道。）

于 2008-11-08T01:47:53.140 回答
3

据我所知，Firefox 不会让您拥有完整的上传路径。在这种情况下，正则表达式的解释似乎无关紧要。我还没有看到现代浏览器在正则表达式执行方面的任何区别。

于 2008-11-08T00:32:24.993 回答
1

如果您使用的是 javascript，则不使用斜杠将正则表达式括起来会导致 Firefox 出错。

尝试做var regex = /^(([a-zA-Z]:)|(\\{2}\w+)\$?)(\\(\w[\w].*))(.pdf)$/;

于 2008-11-07T23:59:20.117 回答
1

正如 Dave 所提到的，Firefox 不提供路径，只提供文件名。正如他所提到的，它没有考虑操作系统之间的差异。我认为您可以做的最好的检查是检查文件名是否以 PDF 结尾。此外，这并不能确保它是有效的 PDF，只是文件名以 PDF 结尾。根据您的需要，您可能希望通过检查内容来验证它实际上是 PDF。

于 2008-11-08T02:04:37.367 回答
0

我没有注意到浏览器之间在模式语法方面的差异。但是，我注意到 C# 和 Javascript 之间的区别，因为 C# 的实现允许反向引用，而 Javascript 的实现则不允许。

于 2008-11-08T00:42:15.473 回答
0

我相信 JavaScript RE 是由 ECMA 标准定义的，我怀疑 JS 解释器之间存在许多差异。我没有在我的程序中找到任何内容，也没有在文章中看到任何内容。

您的消息实际上有点令人困惑，因为您将 ASP 东西扔在那里。当您谈论服务器端技术或生成的代码时，我不明白您如何得出结论是浏览器的错。实际上，我们甚至不知道您是在谈论浏览器上的 JS，上传字段的验证（您不能再这样做，至少以简单的方式，使用 FF3）还是在服务器端（FF 和 Opera 都不是） Safari也没有上传上传文件的完整路径。我很惊讶Chrome确实喜欢IE ...)。

于 2008-11-08T16:15:59.363 回答