jquery - 为什么 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 超文本传输​​协议(protocol) - 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 中挑选要使用的定义。我还选择了要删除的内容(例如对评论的支持)。

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

使问题变得复杂的是，jQuery 验证插件中使用的正则表达式版本被进一步修改，以考虑规范有效地址和用户对有效地址的期望之间的差异。我不记得我做了哪些修改。我向 Jörn Zaefferer(验证插件的作者) promise ，我会编写一个更新的脚本来生成正则表达式。新脚本将允许您指定支持和不支持的选项(所需的 TLD、特定 TLD、IPv6、注释、过时的定义、引用的本地名称等)。那是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 互联网很好，但这并不是当前的情况。互联网在过去三十年中取得了一些进步，该 RFC 已被取代两次。我希望看到任何遵循最新标准的新作品。

<小时/>

更新:

一位 friend 问我为什么 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 也实际上无法使用，这毫无值(value)。直到 2010 年，ICANN 才批准了第一套 IDN。然而，即使在今天，如果您想使用 IDN，如果您确实希望电子邮件和 DNS 之类的东西在全局范围内运行，您几乎需要使用 Punycode 完全销毁您的域名。

更新2:

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