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

/^("(?:[!#-\[\]-\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为域名定义了一个允许的语法，允许当前已知的名称无效。这也允许域名将来成为合法的。这不应该是一个问题，因为这应该以与不存在的域名相同的方式处理。

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

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

没有人提到本地化问题（i18n）。如果你的客户来自世界各地呢？

然后，您需要按国家/地区对正则表达式进行分类，我看到开发人员最终构建了一个大型字典或配置。检测用户的浏览器语言设置可能是一个很好的起点。

我想提出我的方法，它相对简单，同时确保正确的电子邮件结构和限制禁止字符。对拉丁字符有效。

/^(?![\w\.@]*\.\.)(?![\w\.@]*\.@)(?![\w\.]*@\.)\w+[\w\.]*@[\w\.]+\.\w{2,}$/

没有一个是真正有用的。我在回答“是否有用于电子邮件地址验证的PHP库？”时讨论了一些问题？，它也在电子邮件地址的正则表达式识别难吗？中讨论？。

简而言之，不要期望一个可用的正则表达式能够完成正确的工作。最好的正则表达式将验证语法，而不是电子邮件的有效性(jhohn@example.com是正确的，但它可能会反弹…）。

我总是使用下面的正则表达式来验证电子邮件地址。它涵盖了基于英语字符的所有电子邮件地址格式。

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

下面是一个C#示例：

添加程序集引用：

using System.Text.RegularExpressions;

并使用下面的方法传递电子邮件地址并得到一个布尔值

private bool IsValidEmail(string email) {
    bool isValid = false;
    const string pattern = @"\A(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?)\Z";

    isValid = email != "" && Regex.IsMatch(email, pattern);

    // Same above approach in multiple lines
    //
    //if (!email) {
    //    isValid = false;
    //} else {
    //    // email param contains a value; Pass it to the isMatch method
    //    isValid = Regex.IsMatch(email, pattern);
    //}
    return isValid;
}

此方法验证传入参数的电子邮件字符串。对于param为null、空字符串、未定义或param值不是有效电子邮件地址的所有情况，它都将返回false。只有当参数包含有效的电子邮件地址字符串时，它才会返回true。

我知道这个问题是关于正则表达式的，但我猜，在阅读这些解决方案的所有开发人员中，90%都在尝试验证浏览器中显示的HTML格式的电子邮件地址。

如果是这种情况，我建议查看新的HTML5<inputtype=“email”>表单元素：

HTML5：

 <input type="email" required />

CSS 3：

 input:required {
      background-color: rgba(255, 0, 0, 0.2);
 }

 input:focus:invalid {
     box-shadow: 0 0 1em red;
     border-color: red;
 }

 input:focus:valid {
     box-shadow: 0 0 1em green;
     border-color: green;
 }

它是在HTML5表单验证没有JS-JSFidle代码游乐场。

这有两个优点：

自动验证，无需定制解决方案：简单易实现没有JavaScript，如果禁用了JavaScript也不会出现问题没有服务器需要为此计算任何东西用户有即时反馈旧浏览器应自动回退到输入类型“文本”移动浏览器可以显示专用键盘（@-键盘）使用CSS 3，表单验证反馈非常简单

明显的缺点可能是缺少对旧浏览器的验证，但这会随着时间的推移而改变。比起这些疯狂的正则表达式杰作，我更喜欢这个。

另请参见：

没有JS的HTML5表单验证-JSFiddle-代码游乐场Web表单-深入HTML5。疯狂的一种形式SUMO上的HTML5表单验证