我并不是在询问完整的电子邮件验证。
我只想知道电子邮件地址的用户名和服务器部分允许使用哪些字符。这可能过于简单化,也许电子邮件地址可以采取其他形式,但我不在乎。我只问这个简单的表格:user-name@server(例如。wild.wezyr@best-server-ever.com)以及两部分中允许的字符。
我并不是在询问完整的电子邮件验证。
我只想知道电子邮件地址的用户名和服务器部分允许使用哪些字符。这可能过于简单化,也许电子邮件地址可以采取其他形式,但我不在乎。我只问这个简单的表格:user-name@server(例如。wild.wezyr@best-server-ever.com)以及两部分中允许的字符。
当前回答
维基百科对此有一篇很好的文章,官方规范在这里。来自Wikipdia:
电子邮件地址的本地部分可以使用以下任意ASCII字符:大写和小写英文字母(a-z,a-z)数字0至9字符!#$%&'*+-/=?^ _ `{ | } ~性格(点、句号、句号),前提是它不是第一个或最后一个字符,并且不连续出现两次或多次。此外,允许使用带引号的字符串(例如:“John Doe”@example.com),因此允许使用否则将被禁止的字符,但这些字符通常不会出现。RFC 5321还警告“希望接收邮件的主机应避免定义本地部分需要(或使用)引号字符串格式的邮箱”。
其他回答
答案是(几乎)全部(7位ASCII)。如果包含规则“…在某些/任何/无条件下允许…”
仅通过查看RFC 5322第17页顶部“域文本”部分中允许文本的几种可能包含规则之一,我们就可以发现:
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
本说明中仅有的三个缺失字符用于域文字[]中,以形成引号对\和空白字符(%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 ....
因此,这样的包含规则“过于宽泛”。或者,在其他意义上,预期规则“过于简单化”。
姓名:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.
服务器:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.
小心这条线索中有一堆知识腐烂(以前是真的,现在不是了)。
为了避免在当前和未来世界以及世界任何地方对实际电子邮件地址的误报拒绝,您至少需要了解RFC 3490“应用程序中的域名国际化(IDNA)”的高级概念。我知道美国和A的人通常对此并不感兴趣,但它已经在世界各地广泛使用并迅速增加(主要是非英语为主的部分)。
要点是你现在可以像梅森一样使用地址@日本.com和wildwezyr@fahrvergn不,这还不能与现有的一切兼容(正如许多人在上面所感叹的那样,即使是简单的qmail样式+ident地址也经常被错误地拒绝)。但有一个RFC,有一个规范,它现在得到了IETF和ICANN的支持,而且更重要的是,目前有大量且越来越多的实现支持这种改进。
直到我搬回日本,开始看到像hei这样的电子邮件地址,我自己才对这一发展了解很多@やる.ca和Amazon URL如下:
http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e?即=UTF8&节点=3210981
我知道你不希望链接到规范,但如果你完全依赖互联网论坛上黑客的过时知识,你的电子邮件验证器最终会拒绝非英语用户越来越希望使用的电子邮件地址。对于这些用户来说,这种验证将与我们都讨厌的常见的脑死亡形式一样令人讨厌,这种形式无法处理一个+或三部分域名或其他任何东西。
所以我并不是说这不麻烦,但“在某些/任何/无条件下允许”的完整字符列表几乎是所有语言中的所有字符。如果你想“接受所有有效的电子邮件地址(也有许多无效的)”,那么你必须考虑IDN,这基本上使基于字符的方法变得无用(抱歉),除非你首先将国际化的电子邮件地址转换为Punycode(自2015年9月以来就已经过时了,以前是这样一种有效的替代方法)。
做完这些之后,你可以(大部分)遵循上面的建议。
这件事读得很好。
摘录:
These are all valid email addresses!
"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com
在我的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'qqq@gmail.com"
)){
echo "legit email";
} else {
echo "NOT legit email";
}
?>
自己试试看http://phpfiddle.org/main/code/9av6-d10r