2011-02-23 262 views
0

我在这里有RegEx,我需要知道它是否会100%省略任何不良的电子邮件地址,但我完全不了解它们,所以需要致电社区专家。任何人都可以向我详细解释这个正则表达式吗?

的字符串如下:

^[_a-zA-Z0-9-]+(.[_a-zA-Z0-9-]+)*@[a-zA-Z0-9-]+(.[a-zA-Z0-9-]+)*(.[a-zA-Z]{2,3})$ 

预先感谢您!

+2

不,不是100%的服用。 – BoltClock 2011-02-23 11:31:25

+0

你能给我比这更多的细节吗? – Yoda 2011-02-23 11:36:35

+5

虽然允许错误的电子邮件地址,它不会接受一个[RFC 3598(http://www.ietf.org/rfc/rfc3598.txt)的电子邮件地址,该地址是有效的。不要试图重新发明轮子;有任务的CPAN模块。 – Alessandro 2011-02-23 11:44:26

回答

8
^[_a-zA-Z0-9-]+(.[_a-zA-Z0-9-]+)*@[a-zA-Z0-9-]+(.[a-zA-Z0-9-]+)*(.[a-zA-Z]{2,3})$ 

一块一块

^Start of the string 

    [_a-zA-Z0-9-]+ One or more characters of "_" (no quotes), a letter (a-z, A-Z), a number (0-9), or "-" (no quotes) 
    (.[_a-zA-Z0-9-]+)* zero or more substrings of type .something, or .123, or .a123. The substring must be formed by a . and a letter (same group of letters as before). So "." is not valid. ".a" or ".1" or ".-" is. 

(到现在为止它会接受例如my.name12my.name12.surname34

@ a "@" (like [email protected]) 

    [a-zA-Z0-9-]+ One or more characters with the same pattern as before 
    (.[a-zA-Z0-9-]+)* Zero or more substrings of type ".something"... just as before 
    (.[a-zA-Z]{2,3}) A "." (dot) and 2 or 3 letters (a-z or A-Z) 

    $ The end of the string 

所以我们有一个电子邮件地址,在那里你可以没有[email protected](在@之前没有“悬挂”点)或[email protected](没有开始点)。域名必须以字母开头,并且不能在第一级域名(.com/.uk/??)之前有一个点,因此没有[email protected]。一级域名必须有2或3个字母(无数字)

有一个错误,.(点)必须转义,所以它应该是\.。根据不同的语言中,\必须在一个字符串进行转义(所以它可能是\\.

+5

如果你想知道有多少“难”是决定什么可以是一个正确的电子邮件地址:http://en.wikipedia.org/wiki/Email_address – xanatos 2011-02-23 11:44:28

+0

三江源,你非常详细的解释这段代码给我。 +1 – Yoda 2011-02-23 12:58:11

+1

regexbuddy的输出可能会有所帮助http://img62.imageshack.us/i/dpreciousregex.png/ – hpavc 2011-02-25 09:21:42

4

答案很简单:不会。

除了不好的电子邮件地址并不一定意味着它的格式错误([email protected]格式正确但仍然不好),RegEx也会接受一些不良地址。

例如,最右边的部分((.[a-zA-Z]{2,3})$)指出已验证的字符串应以点,然后是两个或三个字母结尾。这将接受非现有的顶级域名(例如.aa),并会阻止四个字母顶级域名(例如.INFO

2
  • 这个表达式将接受以下划线开始电子邮件地址。这是(大部分)不可接受的。
  • 您对“用户名”的大小(即“@”符号下面的部分)没有设置任何最小限制。因此,单个字符的用户名将绕过此。结合前面的例外情况,类型为[email protected]的email-id可能未被检测到。
  • The。 (点)运算符接受任何字符。因此,在“@”部分之后,@@。com等类型的(无效)域可能未被检测到。
  • 只接受2或3个字符的域名将被忽略。
+2

以下划线开头的电子邮件地址有什么问题? – CanSpice 2011-02-24 00:33:17

+0

拥有单个字符用户名有什么不对? – dolmen 2011-02-24 21:32:19

2
[_a-zA-Z0-9-] 

意味着你只需要这些字符(任何字母数字字符或“ - ”或“_”)在您的电子邮件地址,但它可以有效的与所有这些字符:! #$%&'* + -/=?^_`{| }〜

第一部分(@之前)最多可以有253个字符({1,253}),第二部分(可以在@之后)最多可以有64个字符max({4,64})。 (第一或第二组添加括号把({4,64})计数限制之前)

如果你想知道EmailAddress的规范,只要看看维基百科:The Article On Wiki

2

不,它不会排除100%的不良电子邮件地址。由于绝大多数语法有效地址都是针对不存在的帐户(如[email protected]),所以对于正则表达式来说,这是不可能完成的。

真正验证电子邮件地址合法性的唯一方法是尝试向其发送邮件 - 甚至只会告诉您邮件在该地址被接受,而不是由人类接收(如而不是被喂养到剧本或者被默默丢弃),即使它被人接收,你也不能保证它是声称拥有它的人。 (“您坚持要给我一个可交付的电子邮件地址?好的,我的电子邮件地址是[email protected]”)

16

请不要尝试使用正则表达式验证电子邮件地址;这是一个不需要重新发明的轮子,除非你写出一个可怕的毛茸茸的正则表达式,否则你将通过无效的电子邮件地址或拒绝有效的电子邮件地址。

CPAN上有很多模块,比如Email::Valid,它们将全部为您服务并经过测试。

简单的例子:

use Email::Valid; 
print (Email::Valid->address('[email protected]') ? 'yes' : 'no'); 

简单得多,而且将只是工作。

另外,使用Mail::RFC822::Address

if (Mail::RFC822::Address::valid('[email protected]')) { ...} 

对于一个正则表达式将如何毛茸茸必须成功地处理所有符合RFC822-地址的例子,看看this beauty

那些试图手动进行自己的电子邮件地址验证的人往往最终得到的代码会让语法无效的地址通过,甚至更糟的是拒绝完全有效的地址。

例如,有些人在他们的地址中使用+,如[email protected]--这被称为“地址标签”或“子地址”。在验证过程中,很多天真的尝试都会拒绝,客户最终会到别处去。

此外,过去有些人以前认为顶级域总是2或3个字符;当例如, .info已启动,在这些域名地址的人将被告知他们完全有效的电子邮件地址是不可接受的。

最后,还有一些病理情况下,如"Mickey Mouse"@example.com[email protected][1.2.3.4]这在语法上,有效的,但大多数人的手卷验证会拒绝。

+2

如果可以的话,一百个赞扬! – dsolimano 2011-02-23 15:22:28

+0

跳到它所属的顶部。 – daxim 2011-02-23 17:45:06

+0

始终有一个看看RT错误队列使用或推荐一个模块:邮件:: RFC822 ::地址接受太多的字符串https://rt.cpan.org/Ticket/Display.html?id=61288 – dolmen 2011-02-24 21:23:38

-2

对于上述所有确定.接受任何字符的作者,我发现在编写对另一个RegEx问题的响应时,此编辑捕获小部件会使用反斜杠。

(!这是一个问题)

好吧......让我们正确地写:

^\s*([_a-zA-Z0-9]+(\\.[_a-zA-Z0-9\\-\\%]+)\*)@([a-zA-Z0-9]+(\\.[a-zA-Z0-9\\-]+)\*(\\.[a-zA-Z]{2,4}))\s*$ 

这还采用了%字符作为允许-内在价值。这个套路的问题是,虽然它实际上做了很好的工作解析电子邮件地址,它也不是很有效的,因为正则表达式是“贪婪”和终止条件(这是应该匹配像.com.edu的东西)将冲过,那么需要回溯,耗费大量的CPU时间。

真正的答案是使用特定于这一点,因为其他海报建议的程序。但是如果你没有CPAN模块,或者目标环境没有,那么RegEx黑客可以接受。

+1

您仍然会丢失本地部分的不少有效标点符号。而且你仍然要限制你作为有效的顶级域名(TLD)匹配什么,请参阅[.museum](http://index.museum/) – 2011-02-23 20:34:51

相关问题