多年来，我慢慢地开发了一个正则表达式，它可以正确验证大多数电子邮件地址，假设它们不使用IP地址作为服务器部分。
我在几个PHP程序中使用它，而且大多数时候都可以使用。然而，不时有人与我联系，他们对使用它的网站有问题，我最终不得不做出一些调整（最近我意识到我不允许四个字符的TLD）。
你有或见过验证电子邮件的最佳正则表达式是什么？
我见过几种使用函数的解决方案，这些函数使用了几个较短的表达式，但我宁愿在简单函数中使用一个长的复杂表达式，而不是在更复杂的函数中使用几个短表达式。
当前回答
[更新]我整理了我所知道的有关电子邮件地址验证的所有信息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个字符。
其他回答
电子邮件地址的正则表达式为：
/^("(?:[!#-\[\]-\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为域名定义了一个允许的语法，允许当前已知的名称无效。这也允许域名将来成为合法的。这不应该是一个问题，因为这应该以与不存在的域名相同的方式处理。
始终考虑用户键入的电子邮件地址有效，但他们无法访问的可能性。验证电子邮件地址的唯一简单方法是发送电子邮件。
这是改编自我的文章电子邮件地址和语法。
问题标题相当通用，但是问题的主体表明它是关于基于PHP的解决方案的。将尝试解决这两个问题。
一般来说，对于所有编程语言：典型的验证“带有reg ex的电子邮件地址是任何基于互联网的服务提供商都应该避免的事情。域名和电子邮件地址种类的可能性已经大大增加，任何验证尝试都可能会导致拒绝某些有效用户进入您的系统。为了避免这种情况，最好的方法之一是向用户发送电子邮件确认它被接收。“普遍接受指导小组”的好朋友们编制了一份按语言排列的库列表，发现这些库符合/不符合与国际化域名和国际化电子邮件地址相关的各种参数。请在这里和这里找到这些文档的链接。
具体来说PHP：
PHP中有一个很好的库，即EmailValidator。它是一个电子邮件地址验证器，包括许多验证方法，如DNS验证。特别推荐的验证器称为RFCValidator，并根据多个RFC验证电子邮件地址。它在包容IDN和国际化电子邮件地址方面具有良好的合规性。
这一切都取决于你想要的准确度。出于我的目的，我只是想避开bob@aol.com（电子邮件中的空格）或steve（完全没有域名）或mary@aolcom（在.com之前没有句点），我使用
/^\S+@\S+\.\S+$/
当然，它会匹配不是有效电子邮件地址的内容，但这是一个常见的简单错误问题。
可以对该正则表达式进行任意数量的更改（其中一些在这个答案的注释中），但它很简单，易于理解，是一个很好的第一次尝试。
以下是验证电子邮件地址的正则表达式：
^.+@\w+(\.\w+)+$
自2010年5月以来，互联网上存在非拉丁语（中文、阿拉伯文、希腊文、希伯来文、西里尔文等）域名。每个人都必须更改使用的电子邮件正则表达式，因为这些字符肯定不会被[a-z]/i或\w覆盖。他们都会失败。
毕竟，验证电子邮件地址的最佳方法仍然是向有问题的地址发送电子邮件以验证地址。如果电子邮件地址是用户身份验证（注册/登录等）的一部分，那么您可以将其与用户激活系统完美结合。即，发送带有指向指定电子邮件地址的唯一激活密钥的链接的电子邮件，并且仅当用户使用电子邮件中的链接激活了新创建的帐户时才允许登录。
如果正则表达式的目的只是在UI中快速通知用户指定的电子邮件地址格式不正确，那么最好还是检查它是否与以下正则表达式基本匹配：
^([^.@]+)(\.[^.@]+)*@([^.@]+\.)+([^.@]+)$
就这么简单。你到底为什么会在意名字和域名中使用的字符？输入有效的电子邮件地址是客户的责任，而不是服务器的。即使客户端输入语法上有效的电子邮件地址，如aa@bb.cc，这不能保证它是合法的电子邮件地址。没有一个正则表达式可以涵盖这一点。
