小心这条线索中有一堆知识腐烂（以前是真的，现在不是了）。

为了避免在当前和未来世界以及世界任何地方对实际电子邮件地址的误报拒绝，您至少需要了解RFC 3490“应用程序中的域名国际化（IDNA）”的高级概念。我知道美国和A的人通常对此并不感兴趣，但它已经在世界各地广泛使用并迅速增加（主要是非英语为主的部分）。

要点是你现在可以像梅森一样使用地址@日本.com和wildwezyr@fahrvergn不，这还不能与现有的一切兼容（正如许多人在上面所感叹的那样，即使是简单的qmail样式+ident地址也经常被错误地拒绝）。但有一个RFC，有一个规范，它现在得到了IETF和ICANN的支持，而且更重要的是，目前有大量且越来越多的实现支持这种改进。

直到我搬回日本，开始看到像hei这样的电子邮件地址，我自己才对这一发展了解很多@やる.ca和Amazon URL如下：

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e？即=UTF8&节点=3210981

我知道你不希望链接到规范，但如果你完全依赖互联网论坛上黑客的过时知识，你的电子邮件验证器最终会拒绝非英语用户越来越希望使用的电子邮件地址。对于这些用户来说，这种验证将与我们都讨厌的常见的脑死亡形式一样令人讨厌，这种形式无法处理一个+或三部分域名或其他任何东西。

所以我并不是说这不麻烦，但“在某些/任何/无条件下允许”的完整字符列表几乎是所有语言中的所有字符。如果你想“接受所有有效的电子邮件地址（也有许多无效的）”，那么你必须考虑IDN，这基本上使基于字符的方法变得无用（抱歉），除非你首先将国际化的电子邮件地址转换为Punycode（自2015年9月以来就已经过时了，以前是这样一种有效的替代方法）。

做完这些之后，你可以（大部分）遵循上面的建议。

谷歌用他们的gmail.com地址做了一件有趣的事情。gmail.com地址只允许字母（a-z）、数字和句点（忽略）。

例如。，pikachu@gmail.com与pi.kachu@gmail.com，两个电子邮件地址将发送到同一邮箱。PIKACHU@gmail.com也发送到同一邮箱。

因此，要回答这个问题，有时取决于实现者希望遵循多少RFC标准。谷歌的gmail.com地址样式与标准兼容。他们这样做是为了避免不同的人使用类似的电子邮件地址时产生混淆。

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

维基百科链接是关于电子邮件地址通常允许的内容的一个很好的参考。http://en.wikipedia.org/wiki/Email_address

在讨论电子邮件地址的有效本地部分时，公认的答案是维基百科的一篇文章，但维基百科并不是这方面的权威。

IETF RFC 3696是这一问题的权威，应在第3节中查阅。第5页对电子邮件地址的限制：

当代电子邮件地址由“本地部分”组成，与由at符号（“@”）表示的“域名部分”（完全限定的域名）。域部分的语法与前面的部分本节中确定的关于过滤和名称列表适用于电子邮件上下文中使用的域名好域名也可以替换为中的IP地址方括号，但除了测试和故障排除目的。本地部分可能使用所描述的引用约定出现在下面引用的表格在实践中很少使用，但却是必需的出于某些正当目的。因此，不应在过滤例程，但应改为传递到电子邮件系统以供目标主机评估。确切的规则是任何ASCII字符，包括控件字符，可以出现在引号中，也可以出现在带引号的字符串中。当报价为需要，反斜杠字符用于引用以下内容性格例如Abc公司\@def@example.com是电子邮件地址的有效形式。空白也可能出现，如中所示弗雷德\Bloggs@example.com反斜杠字符还可以用于引用自身。，乔\\Blow@example.com除了使用反斜杠字符引用外双引号字符可用于环绕字符串。例如"Abc@def“@example.com”“Fred Blogs”@example.com是上述前两个示例的替代形式。这些引用的表单很少被推荐，在实践中也不常见，但是必须由正在处理的应用程序支持电子邮件地址。特别是，引用的表格经常出现在与来自其他系统的转换相关联的地址上下文和背景；这些过渡要求仍然存在，因为接受用户提供的电子邮件地址的系统不能“知道”该地址是否与旧系统关联地址表格必须被接受并传递到电子邮件环境中。如果没有引号，本地部分可以由以下任意组合组成字母字符、数字或任何特殊字符! # $ % & ' * + - / = ? ^ _ ` . { | } ~句点（“.”）也可能出现，但不能用于开始或结束也不能出现两个或多个连续周期。换句话说，除了at符号（“@”）、反斜杠、双引号、逗号或方括号可能出现而不引用。如果排除了要显示字符，必须引用它们。表单，如用户+mailbox@example.com客户/部门=shipping@example.com$A12345@example.com!定义！xyz%abc@example.com_somename@example.com是有效的，并且很常见，但任何字符允许使用上面列出的。

正如其他人所做的，我提交了一个既适用于PHP又适用于JavaScript的正则表达式来验证电子邮件地址：

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

我根据RFC指南创建了这个正则表达式：

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

简单的答案是有两个答案。你应该做什么有一个标准。对于你应该接受而不制造麻烦的行为，还有一个（更广泛的）标准。这种双重性适用于发送和接收电子邮件，但在生活中有着广泛的应用。

为您创建的地址提供良好的指南；参见：https://www.jochentopf.com/email/chars.html

要过滤有效的电子邮件，只需传递任何足以理解的信息，以查看下一步。或者开始阅读一堆RFC，小心，这里有龙。

检查@和。然后发送电子邮件让他们验证。

我仍然不能在互联网上20%的网站上使用我的.name电子邮件地址，因为有人搞砸了他们的电子邮件验证，或者因为它早于新地址的有效期。