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

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

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

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


当前回答

这个问题被问了很多,但我认为你应该退后一步,问问自己为什么要从语法上验证电子邮件地址?真正的好处是什么?

它不会捕捉常见的拼写错误。它并不阻止人们输入无效或虚构的电子邮件地址,或输入其他人的地址。

如果您想验证电子邮件是否正确,您别无选择,只能发送确认电子邮件并让用户回复。在许多情况下,出于安全原因或道德原因(例如,您不能违背某人的意愿签署服务),您必须发送确认邮件。

其他回答

我使用多步骤验证。由于没有任何完美的方法来验证电子邮件地址,因此无法创建完美的电子邮件地址,但至少您可以通知用户他/她做错了什么-以下是我的方法:

我首先使用非常基本的正则表达式进行验证,它只检查电子邮件是否只包含一个@符号,并且在该符号之前或之后不为空。例如/^[^@\s]+@[^@\s]+$/如果第一个验证器没有通过(对于大多数地址来说,它应该通过,尽管它不是完美的),那么警告用户电子邮件无效,不允许他/她继续输入如果通过,则使用更严格的正则表达式进行验证,这可能会禁止有效的电子邮件。如果未通过,将警告用户可能发生错误,但允许用户继续。与步骤(1)不同,因为这是一个明显的错误,所以不允许用户继续。

换言之,第一次自由验证只是去除明显的错误,它被视为“错误”。人们键入了空白地址、没有@符号的地址等等。这应该被视为错误。第二个更严格,但它被视为“警告”,用户可以继续输入,但至少要检查他/她是否输入了有效的条目。这里的关键在于错误/警告方法——错误是在99.99%的情况下不能成为有效电子邮件的东西。

当然,您可以调整使第一个正则表达式更自由和第二个正则表达式更加严格的因素。

根据您的需要,上述方法可能适用于您。

根据RFC 2821和RFC 2822,电子邮件地址的本地部分可以使用以下任意ASCII字符:

大写和小写字母数字0到9字符!#$%&'*+-/=^_`{|}~字符“.”,前提是它不是本地部分中的第一个或最后一个字符。

比赛:

一个&d@somedomain.com一个*d@somedomain.com一个/d@somedomain.com

不匹配项:

.abc@somedomain.comabc.@somedomain.coma>b@somedomain.com

对于符合RFC 2821和2822的,可以使用:

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

电子邮件-符合RFC 2821、2822

我将代码转换为Java以匹配编译器:

String pattern = "(?:[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*|\"(?:[\\x01-\\x08\\x0b\\x0c\\x0e-\\x1f\\x21\\x23-\\x5b\\x5d-\\x7f]|\\\\[\\x01-\\x09\\x0b\\x0c\\x0e-\\x7f])*\")@(?:(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-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-zA-Z0-9-]*[a-zA-Z0-9]:(?:[\\x01-\\x08\\x0b\\x0c\\x0e-\\x1f\\x21-\\x5a\\x53-\\x7f]|\\\\[\\x01-\\x09\\x0b\\x0c\\x0e-\\x7f])+)\\])";

我也有类似的愿望:希望快速检查电子邮件地址中的语法,而不要过分使用电子邮件发送实用程序(邮件::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向用户显示(并接受然后转换)这样的名称。

几乎我见过的每一个正则表达式(包括一些Microsoft使用的正则表达式)都不允许通过以下有效电子邮件:simon-@hotmail.com

我刚刚有一个真正的客户,他的电子邮件地址是这种格式的,他无法下订单。

以下是我的决定:

不会有假阴性的最小正则表达式。或者,使用MailAddress构造函数进行一些附加检查(见下文):检查常见的拼写错误.cmo或.gimal.com,并要求确认“您确定这是正确的电子邮件地址吗?看起来可能有错误。”如果用户确定,请允许他们接受键入的内容。在实际发送电子邮件时处理反弹,并手动验证它们以检查是否存在明显错误。


try
{
    var email = new MailAddress(str);

    if (email.Host.EndsWith(".cmo"))
    {
        return EmailValidation.PossibleTypo;
    }

    if (!email.Host.EndsWith(".") && email.Host.Contains("."))
    {
        return EmailValidation.OK;
    }
}
catch
{
    return EmailValidation.Invalid;
}