为什么 jQuery 的电子邮件验证正则表达式如此简单？

Question

我们都知道正确验证电子邮件的正则表达式是quite complicated。然而，jQuery 的验证插件有一个较短的正则表达式 _{（由Scott Gonzalez 提供）}，只跨越几行：

/^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])
+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|
((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|
[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]
|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?
(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*
([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])
([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$/

与更知名的怪物相比，为什么它如此“简单”？是否存在一个正则表达式失败而另一个成功的情况（这些案例是有效的还是无效的电子邮件）？

Answer 1

正则表达式是以下的自定义组合：

• RFC 2234 ABNF
• RFC 2396 URI 通用语法（被 RFC 3986 淘汰）
• RFC 2616 超文本传输​​协议 -- HTTP/1.1
• RFC 2822 互联网消息格式
• RFC 3987 IRI
• RFC 3986 URI 通用语法

我在起草 Web Forms 2.0 并且 RFC 5322 不存在时编写了正则表达式。如果您查看 RFC 的编写顺序，您会注意到 IRI 和 URI 的定义在编写 Internet 消息格式后发生了变化。这意味着 RFC 2822 不支持当前的 IRI 定义。不幸的是，仅替换定义并不是一项简单的任务，因此我必须从 RFC 中挑选要使用的定义。我还选择了要删除的内容（例如对 cme​​ts 的支持）。

正则表达式不是完全手写的。虽然我确实手动编写了正则表达式的每个部分，但我编写了“胶水”脚本。 RFC 中的每个定义都存储在一个变量中，复合定义利用存储更简单定义的变量（@Walf：这就是为什么有这么多子模式和 ors）。

更复杂的是，jQuery Validation 插件中使用的正则表达式版本被进一步修改，以解决规范有效地址和用户对有效地址的期望之间的差异。我不记得我做了什么修改。我向 Jörn Zaefferer（验证插件的作者）承诺，我会编写一个更新的脚本来生成正则表达式。新脚本将允许您为您支持和不想支持的内容指定选项（必需的 TLD、特定的 TLD、IPv6、cmets、过时的定义、引用的本地名称等）。那是5年前的事了。我开始了一次，但从未完成。也许有一天我会的。我目前所拥有的托管在 GitHub 上：https://github.com/scottgonzalez/regex-builder

如果您想要一个用于验证电子邮件地址的正则表达式，我建议您使用 HTML5 specification 中包含的以下正则表达式：

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

如果您使用 regex-builder 并关闭所有选项，您会得到类似的结果。但是自从我看到它以来已经大约一年了，所以我不记得有什么不同。

---

我还想指出，原始问题中的链接特别提到了 RFC 822。虽然 RFC 822 将我们从 Arpanet 推进到 ARPA Internet，这很棒，但这并不是最新的。在过去的三年中，Internet 取得了一些进步，并且该 RFC 已被两次取代。我希望看到任何符合最新标准的新作品。

---

更新：

一位朋友问我为什么 HTML5 正则表达式不支持 UTF-8。我从来没有问过 Hixie，但我认为这就是原因：尽管一些 TLD 在 2000 年开始支持 IDN（国际域名）并且 RFC 3987 (IRI) 是在 2005 年编写的，而 RFC 5322 是在 2008 年编写的它仅将 33-90 和 94-126 范围内的字符列为有效 dtext（允许在域文字中使用的字符）。 HTML5 基于 RFC 5322，因此不支持 UTF-8。 RFC 5322 不考虑 IDN 确实看起来很奇怪，但即使在 2008 年 IDN 也实际上不可用，这毫无价值。直到 2010 年 ICANN 才批准了第一组 IDN。但是，即使在今天，如果您想使用 IDN，如果您确实希望电子邮件和 DNS 之类的东西在全球范围内工作，您几乎需要使用 Punycode 完全销毁您的域名。

更新 2：

更新了 HTML5 正则表达式以匹配更新后的规范，将标签长度限制从 255 个字符更改为 63 个字符，如 RFC 1034 section 3.5 中所指定。

Answer 2

看起来不对：Unicode 是怎么回事？这是针对哪个 RFC 进行验证的？

有关正确的 RFC5322 验证正则表达式，请参阅 this answer。