多年来,我慢慢地开发了一个正则表达式,它可以正确验证大多数电子邮件地址,假设它们不使用IP地址作为服务器部分。

我在几个PHP程序中使用它,而且大多数时候都可以使用。然而,不时有人与我联系,他们对使用它的网站有问题,我最终不得不做出一些调整(最近我意识到我不允许四个字符的TLD)。

你有或见过验证电子邮件的最佳正则表达式是什么?

我见过几种使用函数的解决方案,这些函数使用了几个较短的表达式,但我宁愿在简单函数中使用一个长的复杂表达式,而不是在更复杂的函数中使用几个短表达式。


当前回答

我不知道什么是最好的,但这一条至少是正确的,只要地址的注释被删除并用空格替换。

认真地您应该使用已编写的库来验证电子邮件。最好的方法可能是向该地址发送验证电子邮件。

其他回答

为这个问题发布的正则表达式现在已经过时了,因为新的通用顶级域(gTLD)即将到来(例如,伦敦、篮球、。通販). 要验证电子邮件地址,有两个答案(这将与绝大多数人相关)。

正如主要答案所说,不要使用正则表达式。只需通过向该地址发送电子邮件来验证它(捕获无效地址的异常)使用一个非常通用的正则表达式,至少确保他们使用的是一个类似于{something}@{some}的电子邮件结构。{一些}。使用一个详细的正则表达式是没有意义的,因为你不会全部抓住它们,几年后会有一个新的批处理,你必须再次更新正则表达式。

我决定使用正则表达式,因为不幸的是,有些用户没有读取表单,并将错误的数据放在错误的字段中。这至少会在他们试图将非电子邮件的内容输入到电子邮件输入字段时提醒他们,这样可以为您节省一些时间来支持用户处理电子邮件问题。

(.+)@(.+){2,}\.(.+){2,}

我不相信bortzmeyer所说的“语法(RFC 5322中指定的)太复杂了”(无法用正则表达式处理)。

这是语法(来自3.4.1。添加规范规范):

addr-spec       =   local-part "@" domain
local-part      =   dot-atom / quoted-string / obs-local-part
domain          =   dot-atom / domain-literal / obs-domain
domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext           =   %d33-90 /          ; Printable US-ASCII
                    %d94-126 /         ;  characters not including
                    obs-dtext          ;  "[", "]", or "\"

假设点原子、带引号的字符串、obs局部部分、obs域本身是正则语言,这是一个非常简单的语法。只需将addr-spec产品中的本地部分和域替换为它们各自的产品,您就拥有了一种可直接转换为正则表达式的正则语言。

我使用

^\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$

这是RegularExpressionValidator在ASP.NET中使用的值。

我找到了一个符合RFC 2822的正则表达式。RFC 5322的先前标准。这个正则表达式表现得相当好,将覆盖大多数情况,但是随着RFC 5322成为标准,可能会有一些漏洞需要堵塞。

^(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])$

文档中说,您不应该使用上面的正则表达式,而是倾向于这种风格,这有点容易管理。

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

我注意到这是区分大小写的,所以我实际上对这个平台做了修改。

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

根据W3C HTML5规范:

^[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])?)*$

上下文:

有效的电子邮件地址是与ABNF生产[…]匹配的字符串。注意:这一要求故意违反了RFC 5322,RFC 5322为电子邮件地址定义了一种语法,该语法同时太严格(在“@”字符之前)、太模糊(在“@”字符之后)和太松散(允许注释、空白字符和引用字符串以大多数用户不熟悉的方式),在这里无法实际使用。以下JavaScript和Perl兼容的正则表达式是上述定义的实现。/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9]?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/