我最近在某个地方读过写一个正则表达式来匹配一个电子邮件地址,考虑到标准的所有变化和可能性是非常困难的,并且比最初假设的要复杂得多。
任何人都可以提供一些有关原因的见解吗?
是否有任何已知且经过验证的regexp实际上完全执行此操作?
使用regexp匹配电子邮件地址有哪些好的替代方法?
答案 0 :(得分:58)
对于正式的电子邮件规范,是的,由于注释等内容的递归,在技术上不可能通过Regex(特别是如果你不首先删除对空格的注释),以及各种不同的格式(电子邮件地址并不总是someone@somewhere.tld)。你可以接近(有一些大规模和难以理解的正则表达式模式),但更好的检查电子邮件的方法是做一个非常熟悉的握手:
当他们点击您知道的链接时:
远比盲目地接受电子邮件地址好。
答案 1 :(得分:20)
有许多Perl模块(例如)可以执行此操作。不要尝试编写自己的正则表达式来执行此操作。看看
Mail::VRFY
将进行语法和网络检查(并且SMTP服务器在某处接受此地址)
https://metacpan.org/pod/Mail::VRFY
RFC::RFC822::Address
- 递归下降电子邮件地址解析器。
https://metacpan.org/pod/RFC::RFC822::Address
Mail::RFC822::Address
- 基于regexp的地址验证,值得关注疯狂的正则表达式
http://ex-parrot.com/~pdw/Mail-RFC822-Address.html
其他语言也有类似的工具。疯狂的正则表达式......
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)
答案 2 :(得分:10)
无论如何,验证电子邮件地址确实不是很有用。它不会捕获常见的拼写错误或虚构的电子邮件地址,因为它们在语法上看起来像有效地址。
如果您想确定地址有效,您别无选择,只能发送确认邮件。
如果您只是想确保用户输入的内容看起来像电子邮件而不仅仅是“asdf”,那么请检查@。更复杂的验证并没有真正带来任何好处。
(我知道这不能回答你的问题,但我认为无论如何都值得一提)
答案 3 :(得分:8)
我现在整理了来自Cal Henderson,Dave Child,Phil Haack,Doug Lovell和RFC 3696的测试用例。总共有158个测试地址。
我针对我能找到的所有验证器运行了所有这些测试。比较如下:http://www.dominicsayers.com/isemail
我会尝试让这个页面保持最新状态,因为人们会增强验证器。感谢Cal,Dave和Phil在编写这些测试和my own validator的建设性批评方面提供的帮助和合作。
人们应该特别注意errata against RFC 3696。其中三个规范示例实际上是无效地址。并且地址的最大长度为254或256个字符,不 320。
答案 4 :(得分:7)
BNF中有一个无上下文语法,用于描述RFC-2822中的有效电子邮件地址。这很复杂。例如:
" @ "@example.com
是有效的电子邮件地址。我不知道有任何完全正确的正则表达式;通常给出的示例需要先删除注释。我写了一个递归下降解析器来完成一次。
答案 5 :(得分:7)
虽然允许诸如“+”之类的字符对于打击垃圾邮件的用户非常有用,但这并非全是无稽之谈。 myemail+sketchysite@gmail.com (instant disposable Gmail addresses)。
仅在网站接受时才会接受。
答案 6 :(得分:6)
在我看来,是否接受奇怪的,不常见的电子邮件地址格式取决于人们想要用它们做什么。
如果您正在编写邮件服务器,那么您必须非常准确,并且在接受的内容方面要极其正确。因此,上面引用的“疯狂”正则表达是合适的。
对于我们其他人来说,我们主要只是想确保用户在Web表单中输入的内容看起来合理,并且没有某种sql注入或缓冲区溢出。
坦率地说,在注册邮件列表,简报或网站时,有人真的关心让某人输入带有评论,换行,引号,空格,括号或其他乱码的200个字符的电子邮件地址吗?对这些小丑的正确回应是“稍后当你的地址看起来像username@domain.tld时回来”。
我做的验证包括确保只有一个'@';没有空格,空格或换行符; '@'右边的部分至少有一个点(但不是一行中有两个点);并且没有引号,括号,逗号,冒号,感叹号,分号或反斜杠,所有这些都比实际电子邮件地址的部分更可能是hackery的尝试。
是的,这意味着我拒绝有人可能尝试在我的网站上注册的有效地址 - 也许我“错误地”拒绝了多达0.001%的真实地址!我可以忍受。
答案 7 :(得分:4)
引用和各种其他很少使用但有效的RFC部分使其变得困难。除了“很难”之外,我对这个主题的评论还不够明确,但幸运的是other人们written对此进行了详细评论。
对于它的有效正则表达式,Perl Mail :: Rfc822 :: Address模块包含a regular expression which will apparently work - 但仅当任何注释已被空格替换时。 (电子邮件地址中的评论?你明白为什么它比人们预期的更难......)
当然,在其他地方比比皆是的简化版本将验证几乎所有真正使用的电子邮件地址......
答案 8 :(得分:3)
一些正则表达式实际上可以匹配嵌套括号(例如,Perl兼容的)。也就是说,我看到一个声称正确匹配RFC 822的正则表达式,它是两页没有任何空格的文本。因此,检测有效电子邮件地址的最佳方法是向其发送电子邮件,看它是否有效。
答案 9 :(得分:3)
在Java中检查电子邮件地址的一种简单而好的方法是使用Apache Commons Validator库的EmailValidator。
在发送电子邮件之前,我总是会在输入表格中检查一个电子邮件地址,即使您只是收到一些错别字。您可能不想为“发送失败”通知邮件编写自动扫描程序。 : - )
答案 10 :(得分:3)
只是添加一个比@mmaibaum列出的那个更没有疯狂的正则表达式:
^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)?@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$
它不是防弹的,当然也不包括整个电子邮件规范,但它确实能够很好地覆盖大多数基本要求。更好的是,它有点易于理解,可以编辑。
来自HouseOfFusion.com的讨论,这是一个世界级的ColdFusion资源。
答案 11 :(得分:2)
如果您在.NET Framework上运行,只需尝试实例化MailAddress
对象并在FormatException
爆炸时捕获它,或者如果成功则拔出Address
。没有任何关于捕获异常的性能的废话(实际上,如果这只是在单个Web表单上,它不会产生那么大的差别),.NET框架中的MailAddress
类将通过一个非常完整的解析过程(它不使用RegEx)。打开Reflector并搜索MailAddress
和MailBnfHelper.ReadMailAddress()
以查看它所做的所有花哨的事情。比我聪明的人花了很多时间在Microsoft构建解析器,当我实际向该地址发送电子邮件时我会使用它,所以我也可以用它来验证传入的地址。 / p>
答案 12 :(得分:2)
这很难,因为根据电子邮件规范RFC 2822,电子邮件地址中有很多东西可以有效。你通常不会看到的东西如+是完全有效的电子邮件地址字符..根据规范。
在 http://regexlib.com,有一整段专门介绍电子邮件地址,这是一个很好的资源。我建议您确定哪些标准对您很重要并找到匹配的标准。大多数人真的不需要完全支持规范允许的所有可能性。
答案 13 :(得分:1)
这个Java类有一个验证器: http://www.leshazlewood.com/?p=23
这是由Shiro的创建者(正式Ki,正式JSecurity)
撰写的测试电子邮件地址有效性的利弊:
有两种类型的正则表达式可以验证电子邮件:
正则表达式不可能匹配所有有效的电子邮件地址,也不可能没有无效的电子邮件地址,因为某些字符串可能看起来像有效的电子邮件地址,但实际上并没有发送到任何人的收件箱。测试电子邮件是否真正有效的唯一方法是向该地址发送电子邮件,看看是否得到某种响应。考虑到这一点,在匹配电子邮件方面过于严格的正则表达似乎并没有太多的目的。
我认为大多数要求使用电子邮件正则表达式的人都在寻找第一个选项,即松散的正则表达式。他们想测试一个字符串,看看它是否像电子邮件,如果它绝对不是电子邮件,那么他们可以对用户说:“嘿,你应该在这里发一封电子邮件,这绝对是不是一封有效的电子邮件。也许你没有意识到这个字段是用于发送电子邮件,也可能是一个错字“。
如果用户输入的字符串看起来很像有效的电子邮件,但它实际上不是一个,那么这是一个应该由应用程序的不同部分处理的问题。
答案 14 :(得分:1)
许多人尝试过,很多人都接近了。您可能需要阅读wikipedia article和some others。
具体来说,您需要记住,许多网站和电子邮件服务器已经放宽了对电子邮件地址的验证,因此基本上它们没有完全实现标准。电子邮件一直在工作,这已经足够了。
答案 15 :(得分:1)
试试这个:
"(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])"
详细了解here。
但是,不是实施RFC822标准,也许最好从另一个角度来看待它。如果邮件服务器没有镜像标准,那么标准所说的并不重要。所以我认为最好模仿最流行的邮件服务器在验证电子邮件地址时所做的事情。
答案 16 :(得分:0)
尝试创建正则表达式来验证电子邮件时,似乎总是无法解释格式。尽管有些字符在电子邮件中无效,但基本格式为local-part @ domain,本地部分最多约64个字符,而域上最多253个字符。除此之外,它就像荒野的西部。
我认为答案取决于您对经过验证的电子邮件地址的定义以及您的业务流程可以容忍的内容。正则表达式非常适合确保电子邮件的格式正确,并且众所周知,它们可以使用多种变体。这里有几个变体:
变种1:
(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
Variant2:
\A(?:[a-z0-9!#$%&'*+/=?^_‘{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_‘{|}~-]+)*| "(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])\z
仅仅因为电子邮件在语法上是正确的,并不意味着它是有效的。
电子邮件可以遵循RFC 5322并通过正则表达式,但是对电子邮件的实际可传递性没有真正的了解。如果您想知道该电子邮件是虚假电子邮件,还是一次性或不可交付或已知的自动程序,该怎么办?如果您想排除低俗的电子邮件或某些虚假或有问题的电子邮件怎么办?顺便说一句,众所周知,我在一家数据验证公司工作,我只想提供我在Service Objects工作的全部信息,但是作为电子邮件验证领域的专家,我认为我们提供的解决方案可以提供更好的解决方案比正则表达式更有效。请随意看一下,我认为它可以提供很多帮助。您可以在我们的dev guide中查看有关此信息的更多信息。实际上,它进行了大量很棒的电子邮件检查和验证。
这是一个例子:
电子邮件:mickeyMouse@gmail.com
{
"ValidateEmailInfo":{
"Score":4,
"IsDeliverable":"false",
"EmailAddressIn":"mickeyMouse@gmail.com",
"EmailAddressOut":"mickeyMouse@gmail.com",
"EmailCorrected":false,
"Box":"mickeyMouse",
"Domain":"gmail.com",
"TopLevelDomain":".com",
"TopLevelDomainDescription":"commercial",
"IsSMTPServerGood":"true",
"IsCatchAllDomain":"false",
"IsSMTPMailBoxGood":"false",
"WarningCodes":"22",
"WarningDescriptions":"Email is Bad - Subsequent checks halted.",
"NotesCodes":"16",
"NotesDescriptions":"TLS"
}
}
答案 17 :(得分:0)
添加 Wayne 的答案,还有一个专门针对电子邮件的www.regular-expressions.info部分,其中包含一些示例。
你总是可以质疑它是否值得,或者实际上任何低于100% - 正在使用的regexp只会导致错误的安全感。
最后,实际上发送电子邮件将提供真正的最终验证。 ( - 你会发现你的邮件服务器是否有错误; - )
答案 18 :(得分:0)
为了完成这篇文章,对于PHP,还有一个语言内置函数来验证电子邮件。
对于PHP使用具有特定EMAIL验证类型的nice filter_var:)
在php中没有更多疯狂的电子邮件正则表达式:D
var_dump(filter_var('bob@example.com', FILTER_VALIDATE_EMAIL));
答案 19 :(得分:0)
任何人都可以提供一些有关原因的见解吗?
是的,这是一个非常复杂的标准,允许许多今天没有人真正使用过的东西。 :)
是否有任何已知且经过验证的regexp实际上完全执行此操作?
这是一次完全解析整个标准的尝试......
http://ex-parrot.com/~pdw/Mail-RFC822-Address.html
使用正则表达式匹配电子邮件地址有哪些好的替代方法?
使用现有的框架,我猜你用的是哪种语言?虽然那些可能会在内部使用regexp。这是一个复杂的字符串。 Regexp旨在解析复杂的字符串,因此这是您的最佳选择。
编辑:我应该补充一点,我链接到的正则表达式只是为了好玩。我并不支持使用像这样的复杂正则表达式 - 有些人说“如果你的正则表达式超过一行,那么它肯定会在某个地方出现错误”。我联系它来说明标准的复杂程度。