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

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

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

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


当前回答

对于PHP,我使用Nette框架中的电子邮件地址验证器:

/* public static */ function isEmail($value)
{
    $atom = "[-a-z0-9!#$%&'*+/=?^_`{|}~]"; // RFC 5322 unquoted characters in local-part
    $localPart = "(?:\"(?:[ !\\x23-\\x5B\\x5D-\\x7E]*|\\\\[ -~])+\"|$atom+(?:\\.$atom+)*)"; // Quoted or unquoted
    $alpha = "a-z\x80-\xFF"; // Superset of IDN
    $domain = "[0-9$alpha](?:[-0-9$alpha]{0,61}[0-9$alpha])?"; // RFC 1034 one domain component
    $topDomain = "[$alpha](?:[-0-9$alpha]{0,17}[$alpha])?";
    return (bool) preg_match("(^$localPart@(?:$domain\\.)+$topDomain\\z)i", $value);
}

其他回答

我也有类似的愿望:希望快速检查电子邮件地址中的语法,而不要过分使用电子邮件发送实用程序(邮件::RFC822::地址答案显然是正确的答案)。我同意这个(我是一个POSIX正则表达式的人,所以我通常不会使用PCRE中的\d等,因为它们让我看不清楚):

preg_match("_^[-!#-'*+/-9=?A-Z^-~]+(\.[-!#-'*+/-9=?A-Z^-~]+)*@[0-9A-Za-z]([-0-9A-Za-z]{0,61}[0-9A-Za-z])?(\.[0-9A-Za-z]([-0-9A-Za-z]{0,61}[0-9A-Za-z])?)*\$_", $adr)

这是RFC正确的,但它明确排除了过时的表单以及直接IP地址(IP地址和传统IP地址),而该实用程序的目标组中的某些人(主要是:在IRC上的#sendmail中打扰我们的人)通常不希望或不需要这些地址。

IDN(国际化域名)明确不在电子邮件范围内:地址如“foo@cäcilenchor bonn.de“必须写”foo@xn--ccilienchor-bonn-vnb.de而在网络上(这包括HTML中的mailto:links和这样的乐趣),只允许GUI向用户显示(并接受然后转换)这样的名称。

[更新]我整理了我所知道的有关电子邮件地址验证的所有信息http://isemail.info,它现在不仅可以验证,还可以诊断电子邮件地址的问题。我同意这里的许多意见,即验证只是答案的一部分;看看我的文章什么是有效的电子邮件地址?。

据我所知,is_email()仍然是唯一一个能明确告诉您给定字符串是否为有效电子邮件地址的验证器。我已在上载了新版本http://isemail.info/

我整理了来自Cal Henderson、Dave Child、Phil Haack、Doug Lovell、RFC 5322和RFC 3696的测试用例。总共275个测试地址。我对我能找到的所有免费验证器进行了所有这些测试。

我会尽量让这个页面保持最新,因为人们会增强他们的验证器。感谢Cal、Michael、Dave、Paul和Phil在编译这些测试时的帮助和合作,以及对我自己的验证器的建设性批评。

人们应该特别注意RFC 3696的勘误表。其中三个典型示例实际上是无效地址。地址的最大长度是254或256个字符,而不是320个字符。

根据我所看到的,一个完全符合标准的正则表达式是允许的:

/^(?!(^[.-].*|.*[.-]@|.*\.{2,}.*)|^.{254}.+@)([a-z\xC0-\xFF0-9!#$%&'*+\/=?^_`{|}~.-]+@)(?!.{253}.+$)((?!-.*|.*-\.)([a-z0-9-]{1,63}\.)+[a-z]{2,63}|(([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])\.){3}([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9]))$/gim

演示/调试分析(交互式)

拆分:

^(?!(^[.-].*|.*[.-]@|.*\.{2,}.*)|^.{254}.+@)
([a-z\xC0-\xFF0-9!#$%&'*+\/=?^_`{|}~.-]+@)
(?!.{253}.+$)
(
    (?!-.*|.*-\.)
    ([a-z0-9-]{1,63}\.)+
    [a-z]{2,63}
    |
    (([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])\.){3}
    ([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])
)$

分析:

(?!(^[.-].*|.*[.-]@|.*\.{2,}.*)|^.{254}.+@)

对以。,以一结尾,有。。或超过254个字符的最大长度


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

匹配一个或多个允许的字符,并应用负面外观


(?!.{253}.+$)

域名部分的负前瞻性,总共限制为253个字符


(?!-.*|.*-\.)

每个域名的负前瞻性,不允许以开头或结尾。


([a-z0-9-]{1,63}\.)+

域名中允许的字符的简单组匹配,每个字符限制为63个字符


[a-zA-Z]{2,63}

允许的顶级域的简单组匹配,该域目前仍仅限于字母,但确实包含4个字母以上的TLD。


(([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])\.){3}
([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])

域名的替代方案:这将IP地址中的前3个数字与匹配。然后是IP地址中没有的第四个数字。在它背后。

互联网上有很多这样的例子(我认为甚至有一个完全验证RFC的例子——但如果内存可用的话,它有几十/几百行)。

人们倾向于对这类事情进行验证。为什么不检查它是否有@和至少一个。并且满足一些简单的最小长度?输入一封假电子邮件并仍然匹配任何有效的正则表达式是很简单的。我猜假阳性比假阴性好。

完全符合RFC 822的正则表达式由于其长度而效率低下且晦涩难懂。幸运的是,RFC 822被两次取代,当前的电子邮件地址规范是RFC 5322。RFC 5322产生了一个正则表达式,如果研究几分钟就可以理解,并且对于实际使用来说足够有效。

一个符合RFC 5322的正则表达式可以在页面顶部找到:http://emailregex.com/但使用的IP地址模式在互联网上浮动,错误是允许点分隔地址中的任何无符号字节十进制值为00,这是非法的。它的其余部分似乎与RFC 5322语法一致,并通过了几个使用grep-Po的测试,包括域名、IP地址、坏域名以及带引号和不带引号的帐户名。

纠正了IP模式中的00错误,我们获得了一个有效且相当快的正则表达式。(抓取呈现的版本,而不是markdown,以获取实际代码。)

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

or:

(?:[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])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-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])+)\])

下面是上述正则表达式的有限状态机图,它比正则表达式本身更清楚

Perl和PCRE中更复杂的模式(例如PHP中使用的正则表达式库)可以正确地解析RFC 5322而不会出现问题。Python和C#也可以做到这一点,但它们使用的语法与前两种不同。然而,如果您被迫使用许多功能较弱的模式匹配语言之一,那么最好使用真正的解析器。

同样重要的是要理解,根据RFC验证它绝对不会告诉您该地址是否确实存在于所提供的域中,或者输入该地址的人是否是其真正的所有者。人们总是以这种方式向其他人注册邮件列表。修复这一问题需要一种更高级的验证,包括向该地址发送一条消息,该消息包含一个确认令牌,该令牌与该地址在同一网页上输入。

确认令牌是知道您获得输入者地址的唯一方法。这就是为什么现在大多数邮件列表都使用该机制来确认注册。毕竟,任何人都可以放下president@whitehouse.gov,这甚至会被解析为合法,但不太可能是另一端的人。

对于PHP,您不应该使用“用PHP验证电子邮件地址”中给出的模式,我引用的正确方法是:

常见的用法和广泛的草率编码可能会为电子邮件地址建立一个事实上的标准,这比记录的正式标准更具限制性。

这并不比其他所有非RFC模式更好。它甚至不足以处理RFC 822,更不用说RFC 5322了。然而,这一个是。

如果你想变得花哨和迂腐,就实现一个完整的状态引擎。正则表达式只能充当基本过滤器。正则表达式的问题是,从用户的角度来看,告诉某人他们完全有效的电子邮件地址是无效的(假阳性),因为你的正则表达式无法处理它,这是粗鲁和不礼貌的。用于此目的的状态引擎可以验证甚至纠正电子邮件地址,否则这些地址将被视为无效,因为它根据每个RFC分解电子邮件地址。这可能会带来更愉悦的体验,比如

指定的电子邮件地址'myemail@address,com'无效。你是说myemail@address.com'?

另请参阅验证电子邮件地址,包括注释。或比较电子邮件地址验证正则表达式。

Debugex演示