对于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);
}

[更新]我整理了我所知道的有关电子邮件地址验证的所有信息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个字符。

这是我做的。它不是防弹版，但它“简单”，几乎可以检查所有内容。

[\w+-]+(?:\.[\w+-]+)*@[\w+-]+(?:\.[\w+-]+)*(?:\.[a-zA-Z]{2,4})

我认为已经有了解释，因此您可以根据需要进行修改：

（e） [\w+-]+匹配a-z、a-z、_、+、-至少一次

（m） （？：\.[\w+-]+）*匹配a-z、a-z、_、+、-0或更多次，但需要以a开头。（点）

@ = @

（i） [\w+-]+匹配a-z、a-z、_、+、-至少一次

（l） （？：\.[\w+-]+）*匹配a-z、a-z、_、+、-0或更多次，但需要以a开头。（点）

（com）（？：\.[a-zA-Z]{2,4}）匹配a-Z，a-Z 2到4次，从a开始。（点）

给出e（-m）@i（.l）.com，其中（.m）和（.l）是可选的，但也可以重复多次。

我认为这会验证所有有效的电子邮件地址，但会阻止潜在的无效地址，而不使用在大多数情况下不需要的过于复杂的正则表达式。

请注意，这将允许+@-.com，但这是保持简单的折衷方案。

我要验证的电子邮件地址将由使用System.NET.Mail命名空间的ASP.NET web应用程序用于向人员列表发送电子邮件。

因此，我不使用一些非常复杂的正则表达式，而是尝试从地址创建一个MailAddress实例。如果地址格式不正确，MailAddress构造函数将引发异常。通过这种方式，我知道我至少可以把邮件拿到门外。当然，这是服务器端验证，但至少您需要这样做。

protected void emailValidator_ServerValidate(object source, ServerValidateEventArgs args)
{
    try
    {
        var a = new MailAddress(txtEmail.Text);
    }
    catch (Exception ex)
    {
        args.IsValid = false;
        emailValidator.ErrorMessage = "email: " + ex.Message;
    }
}

电子邮件地址的正则表达式为：

/^("(?:[!#-\[\]-\u{10FFFF}]|\\[\t -\u{10FFFF}])*"|[!#-'*+\-/-9=?A-Z\^-\u{10FFFF}](?:\.?[!#-'*+\-/-9=?A-Z\^-\u{10FFFF}])*)@([!#-'*+\-/-9=?A-Z\^-\u{10FFFF}](?:\.?[!#-'*+\-/-9=?A-Z\^-\u{10FFFF}])*|\[[!-Z\^-\u{10FFFF}]*\])$/u

此正则表达式与RFC 5321、RFC 5322和RFC 6532中指定的非过时电子邮件地址的地址规范ABNF 100%相同。

此外，您必须验证：

电子邮件地址格式为UTF-8（或ASCII，如果无法发送到国际化电子邮件地址）地址不超过320个UTF-8字节用户部分（第一个匹配组）不超过64个UTF-8字节域部分（第二个匹配组）不超过255个UTF-8字节

完成所有这些的最简单方法是使用现有函数。在PHP中，请使用filter_VALIDATE_EMAIL和filter_FLAG_EMAIL_UNICODE（如果可以发送到国际化电子邮件地址）查看filter_var函数：

$email_valid = filter_var($email_input, FILTER_VALIDATE_EMAIL, FILTER_FLAG_EMAIL_UNICODE);

然而，也许您正在构建这样一个函数，实际上实现这一点的最简单方法是使用正则表达式。

记住，这只验证电子邮件地址不会导致语法错误。验证地址是否可以接收电子邮件的唯一方法是实际发送电子邮件。

接下来，我将讨论如何生成此正则表达式。

---

我写了一个新的答案，因为这里的大多数答案都犯了这样一个错误：要么指定了一个限制性太强的模式（因此没有很好地老化）；或者它们呈现一个正则表达式，该表达式实际上与MIME消息的标头匹配，而不是电子邮件地址本身。

只要没有递归部分，从ABNF生成正则表达式是完全可能的。

RFC 5322规定了在MIME消息中发送什么是合法的；将此视为合法电子邮件地址的上限。

然而，完全遵循ABNF将是一个错误：这种模式在技术上表示了如何在MIME消息中编码电子邮件地址，并允许字符串不属于电子邮件地址，如折叠空格和注释；它还支持不合法生成的过时表单（但服务器出于历史原因读取）。电子邮件地址不包括这些。

RFC 5322解释了：

原子和点原子都被解释为单个单元，包括组成它的字符串。语义上，可选其余角色周围的评论和FWS不属于原子；原子只是一个原子中的一行文本字符，或点原子中的atext和“.”字符。

在某些定义中，将有非终端的名称以“obs-”开头。这些“obs-”元素是指在第4节中过时的语法。在所有情况下，这些产品为了生成合法的互联网信息，不得用作此类信息的一部分。

如果您从RFC 5322中的addr规范中删除CFWS、BWS和obs-*规则，并对结果执行一些优化（我使用了“green”），则可以生成此正则表达式，用斜线引用并锚定（适用于ECMAScript和兼容方言，为清晰起见，添加了换行符）：

/^("(?:[!#-\[\]-~]|\\[\t -~])*"|[!#-'*+\-/-9=?A-Z\^-~](?:\.?[!#-'*+\-/-9=?A-Z\^-~])*)
@([!#-'*+\-/-9=?A-Z\^-~](?:\.?[!#-'*+\-/-9=?A-Z\^-~])*|\[[!-Z\^-~]*\])$/

这只支持ASCII电子邮件地址。要支持RFC 6532国际化电子邮件地址，请将~字符替换为\u｛10FFFF｝（PHP，带u标志的ECMAScript）或\uFFFF（用于UTF-16实现，如.NET和旧版ECMAScript/JavaScript）：

/^("(?:[!#-\[\]-\u{10FFFF}]|\\[\t -\u{10FFFF}])*"|[!#-'*+\-/-9=?A-Z\^-\u{10FFFF}](?:\.?[!#-'*+\-/-9=?A-Z\^-\u{10FFFF}])*)@([!#-'*+\-/-9=?A-Z\^-\u{10FFFF}](?:\.?[!#-'*+\-/-9=?A-Z\^-\u{10FFFF}])*|\[[!-Z\^-\u{10FFFF}]*\])$/u

这是有效的，因为我们使用的ABNF不是递归的，因此形成了可以转换为正则表达式的非递归正则语法。

它是这样分解的：

用户部分（@之前）可以是点原子或带引号的字符串“（[！#-\[\]-~]|\\[\t-~]）*”指定用户的引号字符串形式，例如root@home“@example.com。它允许双引号内的任何非控制字符；但空格、制表符、双引号和反斜杠必须用反斜杠转义。[！#-'*+\-/-9=？A-Z\^-~]是用户点原子的第一个字符。（\.？[！#-'*+\-/-9=？A-Z\^-~]）*与点原子的其余部分匹配，允许点（除了在另一个点之后或作为最终字符）。@表示域。域部分可以是点原子或域文字。[！#-'*+\-/-9=？A-Z\^-~]（\.？[！#-'*+\-/-9=？A-Z \^-~]）*与上面的点原子形式相同，但这里它表示域名和IPv4地址。\[[！-Z\^-~]*\]将匹配IPv6地址和主机名的未来定义。

此正则表达式允许所有符合规范的电子邮件地址，并且可以在MIME消息中逐字使用（除了行长度限制，在这种情况下必须添加折叠空格）。

这还设置了非捕获组，使得match[1]将是用户，match[2]将是主机。（但是，如果匹配项[1]以双引号开头，则过滤掉反斜杠转义符以及开头和结尾双引号：“root”@example.com和root@example.com识别同一收件箱。）

最后，请注意，RFC 5321对电子邮件地址的长度设置了限制。用户部分最多可为64字节，域部分最多为255字节。包括@字符在内，整个地址的限制为320字节。地址是UTF-8编码后的字节数；而不是字符。

注意，RFC 5322 ABNF为域名定义了一个允许的语法，允许当前已知的名称无效。这也允许域名将来成为合法的。这不应该是一个问题，因为这应该以与不存在的域名相同的方式处理。

始终考虑用户键入的电子邮件地址有效，但他们无法访问的可能性。验证电子邮件地址的唯一简单方法是发送电子邮件。

这是改编自我的文章电子邮件地址和语法。

我将代码转换为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])+)\\])";