以下是验证电子邮件地址的正则表达式：

^.+@\w+(\.\w+)+$

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个字符。

互联网上有很多这样的例子（我认为甚至有一个完全验证RFC的例子——但如果内存可用的话，它有几十/几百行）。

人们倾向于对这类事情进行验证。为什么不检查它是否有@和至少一个。并且满足一些简单的最小长度？输入一封假电子邮件并仍然匹配任何有效的正则表达式是很简单的。我猜假阳性比假阴性好。

这是电子邮件的正则表达式之一：

^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$

这是我做的。它不是防弹版，但它“简单”，几乎可以检查所有内容。

[\w+-]+(?:\.[\w+-]+)*@[\w+-]+(?:\.[\w+-]+)*(?:\.[a-zA-Z]{2,4})

我认为已经有了解释，因此您可以根据需要进行修改：

（e） [\w+-]+匹配a-z、a-z、_、+、-至少一次

（m） （？：\.[\w+-]+）*匹配a-z、a-z、_、+、-0或更多次，但需要以a开头。（点）

@ = @

（i） [\w+-]+匹配a-z、a-z、_、+、-至少一次

（l） （？：\.[\w+-]+）*匹配a-z、a-z、_、+、-0或更多次，但需要以a开头。（点）

（com）（？：\.[a-zA-Z]{2,4}）匹配a-Z，a-Z 2到4次，从a开始。（点）

给出e（-m）@i（.l）.com，其中（.m）和（.l）是可选的，但也可以重复多次。

我认为这会验证所有有效的电子邮件地址，但会阻止潜在的无效地址，而不使用在大多数情况下不需要的过于复杂的正则表达式。

请注意，这将允许+@-.com，但这是保持简单的折衷方案。

根据我所看到的，一个完全符合标准的正则表达式是允许的：

/^(?!(^[.-].*|.*[.-]@|.*\.{2,}.*)|^.{254}.+@)([a-z\xC0-\xFF0-9!#$%&'*+\/=?^_`{|}~.-]+@)(?!.{253}.+$)((?!-.*|.*-\.)([a-z0-9-]{1,63}\.)+[a-z]{2,63}|(([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])\.){3}([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9]))$/gim

演示/调试分析（交互式）

拆分：

^(?!(^[.-].*|.*[.-]@|.*\.{2,}.*)|^.{254}.+@)
([a-z\xC0-\xFF0-9!#$%&'*+\/=?^_`{|}~.-]+@)
(?!.{253}.+$)
(
    (?!-.*|.*-\.)
    ([a-z0-9-]{1,63}\.)+
    [a-z]{2,63}
    |
    (([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])\.){3}
    ([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])
)$

分析：

(?!(^[.-].*|.*[.-]@|.*\.{2,}.*)|^.{254}.+@)

对以。，以一结尾，有。。或超过254个字符的最大长度

([a-z\xC0-\xFF0-9!#$%&'*+\/=?^_`{|}~.-]+@)

匹配一个或多个允许的字符，并应用负面外观

(?!.{253}.+$)

域名部分的负前瞻性，总共限制为253个字符

(?!-.*|.*-\.)

每个域名的负前瞻性，不允许以开头或结尾。

([a-z0-9-]{1,63}\.)+

域名中允许的字符的简单组匹配，每个字符限制为63个字符

[a-zA-Z]{2,63}

允许的顶级域的简单组匹配，该域目前仍仅限于字母，但确实包含4个字母以上的TLD。

(([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])\.){3}
([01]?[0-9]{2}|2([0-4][0-9]|5[0-5])|[0-9])

域名的替代方案：这将IP地址中的前3个数字与匹配。然后是IP地址中没有的第四个数字。在它背后。