奇怪的是，您“不能”使用4个字符的TLD。您禁止人们使用.info和.name，以及长度限制stop、travel和.museum，但是的，它们比2个字符的TLD和3个字符的TLC更常见。

你也应该允许大写字母。电子邮件系统将规范本地部分和域部分。

对于域部分的正则表达式，域名不能以'-'开头，也不能以'-'结尾。Dash只能介于两者之间。

如果您使用PEAR库，请查看他们的邮件功能（我忘记了确切的名称/库）。您可以通过调用一个函数来验证电子邮件地址，它根据RFC 822中的定义验证电子邮件地址。

我不相信bortzmeyer所说的“语法（RFC 5322中指定的）太复杂了”（无法用正则表达式处理）。

这是语法（来自3.4.1。添加规范规范）：

addr-spec       =   local-part "@" domain
local-part      =   dot-atom / quoted-string / obs-local-part
domain          =   dot-atom / domain-literal / obs-domain
domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext           =   %d33-90 /          ; Printable US-ASCII
                    %d94-126 /         ;  characters not including
                    obs-dtext          ;  "[", "]", or "\"

假设点原子、带引号的字符串、obs局部部分、obs域本身是正则语言，这是一个非常简单的语法。只需将addr-spec产品中的本地部分和域替换为它们各自的产品，您就拥有了一种可直接转换为正则表达式的正则语言。

一个简单的正则表达式至少不会拒绝任何有效的电子邮件地址，它会检查某个内容，然后是@符号，然后是句点和至少2个东西。它不会拒绝任何东西，但在查看规范后，我找不到任何有效且被拒绝的电子邮件。

电子邮件=~/+@[^@]+\.[^@]{2,}$/

根据我的理解，它很可能会被。。。

/^([a-z0-9_-]+)(@[a-z0-9-]+)(\.[a-z]+|\.[a-z]+\.[a-z]+)?$/is

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

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

我要验证的电子邮件地址将由使用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;
    }
}