自2010年5月以来，互联网上存在非拉丁语（中文、阿拉伯文、希腊文、希伯来文、西里尔文等）域名。每个人都必须更改使用的电子邮件正则表达式，因为这些字符肯定不会被[a-z]/i或\w覆盖。他们都会失败。

毕竟，验证电子邮件地址的最佳方法仍然是向有问题的地址发送电子邮件以验证地址。如果电子邮件地址是用户身份验证（注册/登录等）的一部分，那么您可以将其与用户激活系统完美结合。即，发送带有指向指定电子邮件地址的唯一激活密钥的链接的电子邮件，并且仅当用户使用电子邮件中的链接激活了新创建的帐户时才允许登录。

如果正则表达式的目的只是在UI中快速通知用户指定的电子邮件地址格式不正确，那么最好还是检查它是否与以下正则表达式基本匹配：

^([^.@]+)(\.[^.@]+)*@([^.@]+\.)+([^.@]+)$

就这么简单。你到底为什么会在意名字和域名中使用的字符？输入有效的电子邮件地址是客户的责任，而不是服务器的。即使客户端输入语法上有效的电子邮件地址，如aa@bb.cc，这不能保证它是合法的电子邮件地址。没有一个正则表达式可以涵盖这一点。

如果你想改进一个多年来运行良好的正则表达式，那么答案就取决于你到底想要实现什么——哪些类型的电子邮件地址出现了问题。微调电子邮件正则表达式非常困难，我还没有找到一个完美的解决方案。

如果您的应用程序涉及一些非常技术性的内容（或组织内部的内容），那么您可能需要支持IP地址，而不是域名，或电子邮件地址“本地”部分的注释。如果您的应用程序是跨国的，我会考虑关注Unicode和UTF-8支持。

您问题的主要答案目前链接到“完全符合RFC‑822的正则表达式”。然而，尽管该正则表达式很复杂，并且假定它在RFC规则中注重细节，但它在Unicode支持方面完全失败。

我为大多数应用程序编写的正则表达式侧重于Unicode支持，以及对RFC标准的总体遵守：

/^(?!\.)((?!.*\.{2})[a-zA-Z0-9\u0080-\u00FF\u0100-\u017F\u0180-\u024F\u0250-\u02AF\u0300-\u036F\u0370-\u03FF\u0400-\u04FF\u0500-\u052F\u0530-\u058F\u0590-\u05FF\u0600-\u06FF\u0700-\u074F\u0750-\u077F\u0780-\u07BF\u07C0-\u07FF\u0900-\u097F\u0980-\u09FF\u0A00-\u0A7F\u0A80-\u0AFF\u0B00-\u0B7F\u0B80-\u0BFF\u0C00-\u0C7F\u0C80-\u0CFF\u0D00-\u0D7F\u0D80-\u0DFF\u0E00-\u0E7F\u0E80-\u0EFF\u0F00-\u0FFF\u1000-\u109F\u10A0-\u10FF\u1100-\u11FF\u1200-\u137F\u1380-\u139F\u13A0-\u13FF\u1400-\u167F\u1680-\u169F\u16A0-\u16FF\u1700-\u171F\u1720-\u173F\u1740-\u175F\u1760-\u177F\u1780-\u17FF\u1800-\u18AF\u1900-\u194F\u1950-\u197F\u1980-\u19DF\u19E0-\u19FF\u1A00-\u1A1F\u1B00-\u1B7F\u1D00-\u1D7F\u1D80-\u1DBF\u1DC0-\u1DFF\u1E00-\u1EFF\u1F00-\u1FFFu20D0-\u20FF\u2100-\u214F\u2C00-\u2C5F\u2C60-\u2C7F\u2C80-\u2CFF\u2D00-\u2D2F\u2D30-\u2D7F\u2D80-\u2DDF\u2F00-\u2FDF\u2FF0-\u2FFF\u3040-\u309F\u30A0-\u30FF\u3100-\u312F\u3130-\u318F\u3190-\u319F\u31C0-\u31EF\u31F0-\u31FF\u3200-\u32FF\u3300-\u33FF\u3400-\u4DBF\u4DC0-\u4DFF\u4E00-\u9FFF\uA000-\uA48F\uA490-\uA4CF\uA700-\uA71F\uA800-\uA82F\uA840-\uA87F\uAC00-\uD7AF\uF900-\uFAFF\.!#$%&'*+-/=?^_`{|}~\-\d]+)@(?!\.)([a-zA-Z0-9\u0080-\u00FF\u0100-\u017F\u0180-\u024F\u0250-\u02AF\u0300-\u036F\u0370-\u03FF\u0400-\u04FF\u0500-\u052F\u0530-\u058F\u0590-\u05FF\u0600-\u06FF\u0700-\u074F\u0750-\u077F\u0780-\u07BF\u07C0-\u07FF\u0900-\u097F\u0980-\u09FF\u0A00-\u0A7F\u0A80-\u0AFF\u0B00-\u0B7F\u0B80-\u0BFF\u0C00-\u0C7F\u0C80-\u0CFF\u0D00-\u0D7F\u0D80-\u0DFF\u0E00-\u0E7F\u0E80-\u0EFF\u0F00-\u0FFF\u1000-\u109F\u10A0-\u10FF\u1100-\u11FF\u1200-\u137F\u1380-\u139F\u13A0-\u13FF\u1400-\u167F\u1680-\u169F\u16A0-\u16FF\u1700-\u171F\u1720-\u173F\u1740-\u175F\u1760-\u177F\u1780-\u17FF\u1800-\u18AF\u1900-\u194F\u1950-\u197F\u1980-\u19DF\u19E0-\u19FF\u1A00-\u1A1F\u1B00-\u1B7F\u1D00-\u1D7F\u1D80-\u1DBF\u1DC0-\u1DFF\u1E00-\u1EFF\u1F00-\u1FFF\u20D0-\u20FF\u2100-\u214F\u2C00-\u2C5F\u2C60-\u2C7F\u2C80-\u2CFF\u2D00-\u2D2F\u2D30-\u2D7F\u2D80-\u2DDF\u2F00-\u2FDF\u2FF0-\u2FFF\u3040-\u309F\u30A0-\u30FF\u3100-\u312F\u3130-\u318F\u3190-\u319F\u31C0-\u31EF\u31F0-\u31FF\u3200-\u32FF\u3300-\u33FF\u3400-\u4DBF\u4DC0-\u4DFF\u4E00-\u9FFF\uA000-\uA48F\uA490-\uA4CF\uA700-\uA71F\uA800-\uA82F\uA840-\uA87F\uAC00-\uD7AF\uF900-\uFAFF\-\.\d]+)((\.([a-zA-Z\u0080-\u00FF\u0100-\u017F\u0180-\u024F\u0250-\u02AF\u0300-\u036F\u0370-\u03FF\u0400-\u04FF\u0500-\u052F\u0530-\u058F\u0590-\u05FF\u0600-\u06FF\u0700-\u074F\u0750-\u077F\u0780-\u07BF\u07C0-\u07FF\u0900-\u097F\u0980-\u09FF\u0A00-\u0A7F\u0A80-\u0AFF\u0B00-\u0B7F\u0B80-\u0BFF\u0C00-\u0C7F\u0C80-\u0CFF\u0D00-\u0D7F\u0D80-\u0DFF\u0E00-\u0E7F\u0E80-\u0EFF\u0F00-\u0FFF\u1000-\u109F\u10A0-\u10FF\u1100-\u11FF\u1200-\u137F\u1380-\u139F\u13A0-\u13FF\u1400-\u167F\u1680-\u169F\u16A0-\u16FF\u1700-\u171F\u1720-\u173F\u1740-\u175F\u1760-\u177F\u1780-\u17FF\u1800-\u18AF\u1900-\u194F\u1950-\u197F\u1980-\u19DF\u19E0-\u19FF\u1A00-\u1A1F\u1B00-\u1B7F\u1D00-\u1D7F\u1D80-\u1DBF\u1DC0-\u1DFF\u1E00-\u1EFF\u1F00-\u1FFF\u20D0-\u20FF\u2100-\u214F\u2C00-\u2C5F\u2C60-\u2C7F\u2C80-\u2CFF\u2D00-\u2D2F\u2D30-\u2D7F\u2D80-\u2DDF\u2F00-\u2FDF\u2FF0-\u2FFF\u3040-\u309F\u30A0-\u30FF\u3100-\u312F\u3130-\u318F\u3190-\u319F\u31C0-\u31EF\u31F0-\u31FF\u3200-\u32FF\u3300-\u33FF\u3400-\u4DBF\u4DC0-\u4DFF\u4E00-\u9FFF\uA000-\uA48F\uA490-\uA4CF\uA700-\uA71F\uA800-\uA82F\uA840-\uA87F\uAC00-\uD7AF\uF900-\uFAFF]){2,63})+)$/i

我将避免复制粘贴完整的答案，所以我只将此链接到我在这里提供的类似答案：如何验证unicode电子邮件？

上面的正则表达式也有一个现场演示：http://jsfiddle.net/aossikine/qCLVH/3/

对于Angular2/Angular7，我使用以下模式：

emailPattern=“^[a-zA-Z0-9-_.+-]+@[a-zA-APP-GW-9-]+[.]+[a-zA-62-9-.]+（\\s）*”；私有createForm（）{this.form=this.formBuilder.group({email:[''，[Validators.required，Validators.pattern（this.emailPattern）]]});}

它还允许在结尾处添加额外的空间，在将其发送到后端之前，应该将其截断，但某些用户，特别是移动用户，很容易在结尾处错误地添加空间。

对我来说，检查电子邮件地址的正确方法是：

检查符号@是否存在，在它之前和之后是否有一些非@符号：/^[^@]+@[^@]+$/尝试用一些“激活码”向该地址发送电子邮件。当用户“激活”他/她的电子邮件地址时，我们将看到一切都是正确的。

当然，当用户键入一封“奇怪”的电子邮件时，您可以在前端显示一些警告或提示，以帮助他/她避免常见错误，如域名部分没有圆点或名称中没有空格而没有引号等。但您必须接受地址“hello@world“如果用户真的想要它。

此外，您必须记住，电子邮件地址标准过去和将来都会发展，因此您不能总是只键入一些“标准有效”的正则表达式。而且你必须记住，一些具体的互联网服务器可能会在一些常见标准的细节上失败，事实上，它们可以使用自己的“修改标准”。

所以，只需检查@，在前端提示用户，并在给定地址发送验证电子邮件。

HTML5规范建议使用一个简单的正则表达式来验证电子邮件地址：

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

这故意不符合RFC 5322。

注意：这一要求是故意违反RFC 5322的，RFC 5322为电子邮件地址定义了一种语法，该语法同时太严格（在@字符之前）、太模糊（在@符号之后）和太松散（允许注释、空白字符和引用字符串以大多数用户不熟悉的方式），在这里无法实际使用。

根据RFC 3696勘误表1690，总长度也可以限制为254个字符。

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