我不是在问完整的电子邮件验证。
我只是想知道电子邮件地址的user-name
和server
部分中允许的字符是什么。 这可能过于简单,也许电子邮件地址可以采取其他形式,但我不在乎。 我只询问这个简单的形式: user-name@server
(例如[email protected])和两个部分允许的字符。
#1楼
检查@和。 然后发送电子邮件给他们验证。
我仍然无法在互联网上20%的网站上使用我的.name电子邮件地址,因为有人搞砸了他们的电子邮件验证,或者因为它早于有效的新地址。
#2楼
请参阅RFC 5322:Internet邮件格式,以及在较小程度上的RFC 5321:简单邮件传输协议 。
RFC 822也涵盖了电子邮件地址,但它主要涉及其结构:
addr-spec = local-part "@" domain ; global address
local-part = word *("." word) ; uninterpreted
; case-preserved
domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom ; symbolic reference
像往常一样,维基百科有一篇关于电子邮件地址的文章 :
电子邮件地址的本地部分可以使用以下任何ASCII字符:
- 大写和小写拉丁字母
A
到Z
和a
到z
;- 数字
0
到9
;- 特殊字符
!#$%&'*+-/=?^_`{|}~
;- 点
.
,除非引用,否则它不是第一个或最后一个字符,并且除非引用,否则它也不会连续出现(例如,[email protected]
不允许,但是“"John..Doe"@example.com
[email protected]
是允许);- 空格和
"(),:;<>@[\\]
字符允许有限制(它们只允许在带引号的字符串中,如下段所述,此外,必须在前面加上反斜杠或双引号反斜杠);- 本地部分两端的括号允许注释; 如
john.smith(comment)@example.com
和(comment)[email protected]
都等同于[email protected]
。
除ASCII字符外, 截至2012年,您可以使用U+007F
以上的国际字符 ,编码为UTF-8,如RFC 6532规范中所述,并在Wikipedia上进行了解释。 请注意,截至2019年,这些标准仍然标记为建议,但正在缓慢推出。 此规范中的更改实际上将国际字符添加为有效的字母数字字符(atext),而不会影响允许和限制的特殊字符(如!#
和@:
:)的规则。
有关验证,请参阅使用正则表达式验证电子邮件地址 。
domain
部分定义如下 :
协议的Internet标准(Request for Comments)要求组件主机名标签可以仅包含ASCII字母
a
到z
(以不区分大小写的方式),数字0
到9
以及连字符(-
)。 RFC 952中主机名的原始规范,强制标签不能以数字或连字符开头,并且不得以连字符结尾。 但是,后续规范( RFC 1123 )允许主机名标签以数字开头。 不允许使用其他符号,标点字符或空格。
#3楼
你可以从维基百科文章开始:
- 大写和小写英文字母(az,AZ)
- 数字0到9
- 人物! #$%&'* + - / =? ^ _` {| }〜
- 性格。 (点,句号,句号),条件是它不是第一个或最后一个字符,并且还提供它不连续出现两次或多次。
#4楼
维基百科有一篇很好的文章 , 官方规范在这里 。 来自Wikipdia:
电子邮件地址的本地部分可以使用以下任何ASCII字符:
- 大写和小写英文字母(az,AZ)
- 数字0到9
- 人物! #$%&'* + - / =? ^ _` {| }〜
- 性格。 (点,句号,句号),条件是它不是第一个或最后一个字符,并且还提供它不连续出现两次或多次。
另外,允许引用字符串(即:“John Doe”@ example.com),从而允许否则将被禁止的字符,但是它们不会出现在通常的实践中。 RFC 5321还警告说“希望接收邮件的主机应该避免定义Local-part需要(或使用)Quoted-string表单的邮箱”。
#5楼
小心! 在这个线程中有一堆知识腐烂(过去曾经是真的,现在却没有)。
为了避免在当前和未来世界以及世界任何地方误报实际电子邮件地址,您至少需要了解RFC 3490的高级概念“在应用程序中国际化域名(IDNA)”。 我知道美国和美国的人们往往不会这样做,但它已经广泛使用并且在世界范围内迅速增加 (主要是非英语主导的部分)。
要点是,您现在可以使用mason @日本.com和wildwezyr@fahrvergnügen.net等地址。 不,这还不兼容那里的所有东西(正如许多人在上面感叹,即使简单的qmail风格+身份地址也经常被错误地拒绝)。 但是有一个RFC,有一个规范,它现在得到了IETF和ICANN的支持,而且 - 更重要的是 - 支持这种改进的大量且越来越多的实现正在服务中。
在我回到日本并开始看到像hei @やる.ca这样的电子邮件地址以及像这样的Amazon URL之前,我对这个开发本身并不多了解:
http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/ B / REF = topnav_storetab_e即= UTF8&节点= 3210981
我知道你不希望链接到规范,但如果你完全依赖于互联网论坛上黑客的过时知识,你的电子邮件验证者最终会拒绝非英语用户越来越期望工作的电子邮件地址。 对于那些用户来说,这样的验证就像我们讨厌的普通脑死亡形式一样令人讨厌,无法处理+或三部分域名或其他任何东西。
所以我并不是说这不麻烦,但是“允许在某些/任何/无条件下”的完整字符列表(几乎)是所有语言中的所有字符。 如果你想“接受所有有效的电子邮件地址(以及许多无效的电子邮件地址)”那么你必须考虑IDN,这基本上使得基于字符的方法无用(对不起),除非你首先将国际化的电子邮件地址转换为Punycode 。
完成后,您可以遵循(大部分)上面的建议。
#6楼
可以在这个维基百科链接中找到
电子邮件地址的本地部分可以使用以下任何ASCII字符:
大写和小写拉丁字母
A
到Z
和a
到z
;数字
0
到9
;特殊字符
!#$%&'*+-/=?^_`{|}~
;点
.
,除非引用,否则它不是第一个或最后一个字符,并且除非引用,否则它也不会连续出现(例如,[email protected]
不允许,但是“"John..Doe"@example.com
[email protected]
是允许);空格和
"(),:;<>@[\\]
字符允许有限制(它们只允许在带引号的字符串中,如下段所述,此外,必须在前面加上反斜杠或双引号反斜杠);本地部分两端的括号允许注释; 如
john.smith(comment)@example.com
和(comment)[email protected]
都等同于[email protected]
。除了上述ASCII字符外, RFC 6531还允许使用编码为UTF-8的U + 007F以上的国际字符,但邮件系统可能会限制在分配本地部分时使用哪些字符。
带引号的字符串可以作为本地部分中的点分隔实体存在,或者当最外面的引号是本地部分的最外面的字符时可以存在(例如,
abc."defghi"[email protected]
或"abcdefghixyz"@example.com
是允许的。相反,abc"defghi"[email protected]
不是;abc\\"def\\"[email protected]
也不是。 但是,引用的字符串和字符并不常用。 RFC 5321还警告说“希望接收邮件的主机应该避免定义Local-part需要(或使用)Quoted-string表单的邮箱”。本地部分
postmaster
是专门处理它是不区分大小写的,并且应该被转发到域电子邮件管理员。 从技术上讲,所有其他本地部分都区分大小写,因此[email protected]
和[email protected]
指定不同的邮箱; 但是,许多组织将大写和小写字母视为等效字母。尽管在技术上有效的广泛的特殊字符; 实际上,组织,邮件服务,邮件服务器和邮件客户端通常不接受所有这些。 例如,Windows Live Hotmail仅允许使用字母数字,点(
.
),下划线(_
)和连字符(-
)创建电子邮件地址。 常见的建议是避免使用某些特殊字符以避免被拒绝的电子邮件的风险。
#7楼
Gmail仅允许+签名作为特殊字符,在某些情况下(。),但Gmail不允许使用任何其他特殊字符。 RFC表示您可以使用特殊字符,但应避免使用特殊字符向Gmail发送邮件。
#8楼
关于此事的好读。
摘抄:
These are all valid email addresses!
"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/[email protected]
\[email protected]
!def!xyz%[email protected]
[email protected]
#9楼
答案是(几乎) ALL
(7位ASCII)。
如果包含规则是“......允许在某些/任何/无条件下......”
只需在第17页顶部的RFC 5322的“域文本”部分中查看允许文本的几个可能包含规则之一,我们就会发现:
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
此描述中只有三个缺少的字符用于domain-literal []
,以形成引用对\\
和空格字符 (%D32)。 使用它,使用整个范围32-126(十进制)。 类似的要求显示为“qtext”和“ctext”。 许多控制字符也被允许/使用。 一个这样的控制字符列表出现在RFC 5322的第31页4.1节中,作为obs-NO-WS-CTL。
obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; characters that do not
%d12 / ; include the carriage
%d14-31 / ; return, line feed, and
%d127 ; white space characters
所有这些控制字符都是允许的,如第3.5节开头所述:
.... MAY be used, the use of US-ASCII control characters (values
1 through 8, 11, 12, and 14 through 31) is discouraged ....
因此,这样的包含规则“太宽”了。 或者,在其他意义上,预期的规则是“过于简单化”。
#10楼
在我的PHP中,我使用此检查
<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[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_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'[email protected]"
)){
echo "legit email";
} else {
echo "NOT legit email";
}
?>
亲自尝试http://phpfiddle.org/main/code/9av6-d10r
#11楼
在讨论电子邮件地址的有效本地部分时,接受的答案是指维基百科的文章,但维基百科不是这方面的权威。
IETF RFC 3696 是此问题的权威 ,应参阅第3节。电子邮件地址的限制在第5页:
当前电子邮件地址由“本地部分”组成,该“本地部分”通过符号(“@”)与“域部分”(完全限定的域名)分开。 域部分的语法对应于上一节中的语法。 该部分中关于过滤和名称列表的关注点也适用于电子邮件上下文中使用的域名。 域名也可以用方括号中的IP地址替换,但除了测试和故障排除之外,强烈建议不要使用该表单。
本地部分可能使用下面描述的引用约定出现。 引用的表格在实践中很少使用,但出于某些合法目的是必需的。 因此,它们不应该在过滤例程中被拒绝,而应该被传递到电子邮件系统以供目标主机评估。
确切的规则是任何ASCII字符(包括控制字符)都可以显示引号,或者带引号的字符串。 当需要引用时,反斜杠字符用于引用以下字符。 例如
Abc\\@[email protected]
是电子邮件地址的有效形式。 也可能出现空白,如
Fred\\ [email protected]
反斜杠字符也可用于引用自身,例如,
Joe.\\\\[email protected]
除了使用反斜杠字符引用之外,传统的双引号字符可用于包围字符串。 例如
"Abc@def"@example.com "Fred Bloggs"@example.com
是前两个例子的替代形式。 这些引用的表单很少被推荐,并且在实践中并不常见,但是,如上所述,必须由处理电子邮件地址的应用程序支持。 特别是,引用的形式经常出现在与来自其他系统和上下文的转换相关联的地址的上下文中; 那些过渡性要求仍然会出现,并且由于接受用户提供的电子邮件地址的系统无法“知道”该地址是否与遗留系统相关联,因此必须接受地址表并将其传递到电子邮件环境中。
如果没有引号,本地部分可以包含任何组合
字母字符,数字或任何特殊字符! # $ % & ' * + - / = ? ^ _ ` . { | } ~
句号(“。”)也可能出现,但可能不会用于开始或结束本地部分,也不会出现两个或多个连续的句号。 换句话说,除了at符号(“@”),反斜杠,双引号,逗号或方括号之外的任何ASCII图形(打印)字符都可能不带引号。 如果要显示任何排除字符列表,则必须引用它们。 形式如
[email protected] customer/[email protected] [email protected] !def!xyz%[email protected] [email protected]
是有效的,并且经常被看到,但允许使用上面列出的任何字符。
正如其他人所做的那样,我提交了一个适用于PHP和JavaScript的正则表达式来验证电子邮件地址:
/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i
#12楼
为简单起见,我通过在验证之前删除双引号内的所有文本以及相关的周围双引号来清理提交,根据不允许的内容提交电子邮件地址提交。 仅仅因为有人可以拥有约翰......“* $ hizzle * Bizzle”.. [email protected]地址并不意味着我必须在我的系统中允许它。 我们生活在未来,可能需要更少的时间来获得免费的电子邮件地址,而不是做好擦屁股的工作。 并不是说电子邮件标准没有贴在输入旁边说什么是允许的和不允许的。
在删除引用的材料后,我还清理了各种RFC特别不允许的内容。 特别不允许的字符和模式列表似乎是一个更短的测试列表。
不允许:
local part starts with a period ( [email protected] )
local part ends with a period ( [email protected] )
two or more periods in series ( [email protected] )
&’`*|/ ( some&thing`[email protected] )
more than one @ ( which@[email protected] )
:% ( mo:characters%mo:[email protected] )
在给出的例子中:
John.."The*$hizzle*Bizzle"[email protected] --> [email protected]
[email protected] --> [email protected]
在尝试添加或更改电子邮件地址时向剩余结果发送确认电子邮件消息是查看您的代码是否可以处理提交的电子邮件地址的好方法。 如果电子邮件在需要进行多轮清理后通过验证,则启动该确认。 如果请求从确认链接返回,则新电子邮件可以从持有|| temporary ||炼狱状态或存储中移动,以成为真实的,真实的头等存储电子邮件。
如果您想体谅,可以将电子邮件地址更改失败或成功的通知发送到旧电子邮件地址。 未经证实的帐户设置可能会在合理的时间内完全失败,因为失败的尝试完全失败。
我不允许在我的系统上发送恶作剧电子邮件,也许这只是丢钱。 但是,99.9%的时间人们只是做正确的事情并且使用边缘情况兼容性方案的电子邮件不会将符合性限制推向边缘。 注意正则表达式DDoS,这是一个你可以遇到麻烦的地方。 这与我做的第三件事有关,我限制了我愿意处理任何一封电子邮件的时间。 如果它需要减慢我的机器以进行验证 - 它没有超过我的传入数据API端点逻辑。
编辑:这个答案继续因为“糟糕”而被贬低,也许它应该得到它。 也许它仍然很糟糕,也许不是。
#13楼
电子邮件地址的格式为: local-part@domain-part
(最多64个@ 255个字符,总共不超过256个字符)。
local-part
和domain-part
可以有不同的允许字符集,但这不是全部,因为它有更多的规则。
通常,本地部分可以具有以下ASCII字符:
- 小写拉丁字母:
abcdefghijklmnopqrstuvwxyz
, - 大写拉丁字母:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
, - 数字:
0123456789
, - 特殊字符:
!#$%&'*+-/=?^_`{|}~
, - 点:
.
(不是第一个或最后一个字符或重复,除非引用), - 空格标点如:
"(),:;<>@[\\]
(有一些限制), - 注释:
()
(括号内允许,例如((comment)[email protected]
)(comment)[email protected]
)。
域名部分:
- 小写拉丁字母:
abcdefghijklmnopqrstuvwxyz
, - 大写拉丁字母:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
, - 数字:
0123456789
, - 连字符:
-
(不是第一个或最后一个字符), - 可以包含方括号括起来的IP地址:
jsmith@[192.168.2.1]
或jsmith@[IPv6:2001:db8::1]
。
这些电子邮件地址有效:
-
[email protected]
-
[email protected]
-
[email protected]
-
[email protected]
-
[email protected]
(一个字母的本地部分) -
"much.more unusual"@example.com
-
"[email protected]"@example.com
-
"very.(),:;<>[]\\".VERY.\\"very@\\ \\"very\\".unusual"@strange.example.com
-
[email protected]
-
admin@mailserver1
(没有顶级域名的本地域名) -
#!$%&'*+-/=?^_`{}|[email protected]
-
"()<>[]:,;@\\\\"!#$%&'-/=?^_`{}| ~.a"@example.org
-
" "@example.org
(引号之间的空格) -
example@localhost
(从localhost发送) -
[email protected]
(参见Internet顶级域名列表 ) -
user@com
-
user@localserver
-
user@[IPv6:2001:db8::1]
而这些无效的例子:
-
Abc.example.com
(没有@
字符) -
A@b@[email protected]
(只允许一个@
在引号外) -
a"b(c)d,e:f;gi[j\\k][email protected]
(本地部分的任何特殊字符都不允许在引号外) -
just"not"[email protected]
(引用的字符串必须以点分隔或构成本地部分的唯一元素) -
this is"not\\[email protected]
(空格,引号和反斜杠可能仅在引用的字符串中以反斜杠开头时才存在) -
this\\ still\\"not\\[email protected]
(即使转义(前面有反斜杠),空格,引号和反斜杠仍必须包含在引号中) -
[email protected]
(前双点@
); (注意事项:Gmail允许这样做) -
[email protected]
(后双点@
) - 带有前导空格的有效地址
- 带有尾随空格的有效地址
来源:维基百科的电子邮件地址
用于验证电子邮件的Perl的RFC2822正则表达式 :
(?:(?:\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*)
RFC2822地址的完整正则表达式仅为3.7k。
另请参阅: PHP中的RFC 822电子邮件地址解析器 。
电子邮件地址的正式定义如下:
- RFC 5322(第3.2.3和3.4.1节,废弃RFC 2822),RFC 5321,RFC 3696,
- RFC 6531(允许的字符)。
有关:
#14楼
我根据RFC准则创建了这个正则表达式:
^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$
#15楼
名称:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.
服务器:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.
#16楼
Google用他们的gmail.com地址做了一件有趣的事情。 gmail.com地址仅允许字母(az),数字和句点(被忽略)。
例如,pikachu @ gmail.com与[email protected]相同,两个电子邮件地址都将被发送到同一个邮箱。 [email protected]也会发送到同一个邮箱。
因此,为了回答这个问题,有时它取决于实施者他们想要遵循多少RFC标准。 Google的gmail.com地址样式与标准兼容。 他们这样做可以避免混淆,因为不同的人会采取类似的电子邮件地址,例如
*** gmail.com accepting rules ***
[email protected] (accepted)
[email protected] (bounce and account can never be created)
[email protected] (accepted)
D.Oy'[email protected] (bounce and account can never be created)
维基百科链接是关于电子邮件地址通常允许的一个很好的参考。 http://en.wikipedia.org/wiki/Email_address
#17楼
简短的回答是有2个答案。 你应该做什么有一个标准。 即行为是明智的,将使你摆脱困境。 对于你应该接受而不会制造麻烦的行为,还有另一个(更广泛的)标准。 这种二元性适用于发送和接收电子邮件,但在生活中具有广泛的应用。
为您创建的地址提供良好的指导; 请参阅: http : //www.remote.org/jochen/mail/info/chars.html
要过滤有效的电子邮件,只需传递一些可理解的内容即可看到下一步。 或者开始阅读一堆RFC,请注意,这里是龙。