电子邮件地址允许使用哪些字符?
我没有询问完整的电子邮件验证。
我只想知道电子邮件地址的user-name
和server
部分中允许的字符。 这可能过于简单了,也许电子邮件地址可以采取其他形式,但我不在乎。 我只询问这个简单的表单: user-name@server
(例如wild.wezyr@best-server-ever.com)并允许两部分中的字符。
请参阅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
; !#$%&'*+-/=?^_`{|}~
; .
,除非引用它不是第一个或最后一个字符,并且还规定它不会连续出现,除非被引用(例如John..Doe@example.com
不被允许,但是“ "John..Doe"@example.com
John..Doe@example.com
是允许); "(),:;<>@[]
字符允许有限制(它们只允许在带引号的字符串中,如下面段落中所述,另外,反斜杠或双引号必须以反斜杠); john.smith(comment)@example.com
和(comment)john.smith@example.com
都等同于john.smith@example.com
。 除了ASCII字符外,截至2012年,您可以使用U+007F
以上的国际字符,编码为UTF-8。
有关验证,请参阅使用正则表达式验证电子邮件地址。
domain
部分定义如下:
用于协议的因特网标准(征求意见)要求组件主机名标签只能包含ASCII字母a
到z
(以不区分大小写的方式),数字0
到9
以及连字符( -
)。 RFC 952中主机名的原始规范要求标签不能以数字或连字符开头,并且不得以连字符结尾。 但是,随后的规范(RFC 1123)允许主机名标签以数字开头。 不允许使用其他符号,标点符号或空格。
小心! 在这个线程中有一堆知识腐烂(以前是真的,现在不是)。
为避免在当前和未来世界以及世界任何地方对实际电子邮件地址进行错误肯定的拒绝,您至少需要了解RFC 3490“应用程序中的域名国际化(IDNA)”的高级概念。 我知道美国和A的人往往不在这方面,但它已经在世界范围内广泛且迅速增加的使用 (主要是非英语为主的部分)。
要点是你现在可以使用像mason @日本.com和wildwezyr@fahrvergnügen.net这样的地址。 不,这还不符合那里的所有东西(正如许多人在上面感叹的那样,即使简单的qmail-style + ident地址经常被错误地拒绝)。 但是有一个RFC,有一个规范,它现在由IETF和ICANN支持,而且更重要的是,有越来越多的支持这种改进的实现正在服务中。
直到我回到日本开始看到像hei @やる.ca和亚马逊网址这样的电子邮件地址之前,我对自己的这种发展并不了解。
http://www.amazon.co.jp/エレクトロニクス - デジタルカメラ - ポータブルオーディオ/ B / REF = topnav_storetab_e即= UTF8&节点= 3210981
我知道你不想要规范的链接,但是如果你完全依赖在互联网论坛上过时的黑客知识,那么你的电子邮件验证器最终会拒绝非Enlish用户越来越期望工作的电子邮件地址。 对于那些用户来说,这样的验证就像我们都讨厌的常见的大脑死亡形式一样烦人,无法处理+或三部分域名或其他任何问题。
所以我并不是说这不是一件麻烦事,但是“在某些/任何/没有条件下允许的”字符的完整列表(几乎)是所有语言中的所有字符。 如果你想“接受所有有效的电子邮件地址(也有许多无效的)”,那么你必须考虑IDN,这基本上使基于字符的方法无用(对不起),除非你首先将国际化的电子邮件地址转换为Punycode。
这样做后,你可以遵循(大部分)上面的建议。
维基百科在这方面有一篇很好的文章,官方的规格在这里。 来自Wikipdia:
电子邮件地址的本地部分可以使用以下任何ASCII字符:
此外,允许使用带引号的字符串(即:“John Doe”@ example.com),从而允许以其他方式被禁止的字符,但这些字符不会在惯例中出现。 RFC 5321还警告说:“期望接收邮件的主机应该避免在本地部分需要(或使用)引用字符串表单的情况下定义邮箱”。
链接地址: http://www.djcxy.com/p/2711.html