732

我不是在询问完整的电子邮件验证。

我只想知道电子​​邮件地址中允许使用的字符user-name和server部分内容。这可能过于简单，也许电子邮件地址可以采用其他形式，但我不在乎。我只询问这种简单的形式：（user-name@server例如wild.wezyr@best-server-ever.com）和两个部分中允许的字符。

4

17 回答 17

883

请参阅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 字符：

  • 大写和小写拉丁字母AtoZ和ato z;
  • 数字0到9;
  • 特殊字符!#$%&'*+-/=?^_`{|}~；
  • dot .，前提是它不是第一个或最后一个字符，除非被引用，并且它不连续出现，除非被引用（例如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，如RFC 6532 规范中所述并在Wikipedia上进行了解释。请注意，截至 2019 年，这些标准仍被标记为已提议，但正在缓慢推出。本规范中的更改实质上将国际字符添加为有效的字母数字字符（atext），而不会影响允许和受限特殊字符（如!#和）的规则@:。

有关验证，请参阅使用正则表达式验证电子邮件地址。

该domain部分定义如下：

协议的 Internet 标准（征求意见）要求组件主机名标签只能包含 ASCII 字母（a以z不区分大小写的方式）、数字0和9连字符 ( -)。RFC 952中主机名的原始规范要求标签不能以数字或连字符开头，也不能以连字符结尾。但是，后续规范 ( RFC 1123 ) 允许主机名标签以数字开头。不允许使用其他符号、标点符号或空格。

于 2010-01-12T14:15:23.660 回答
362

小心！在这个线程中有一堆知识腐烂（过去是真的，现在不是的东西）。

为了避免在当前和未来世界以及来自世界任何地方的实际电子邮件地址被误报拒绝，您至少需要了解RFC 3490的高级概念，“应用程序中的国际化域名 (IDNA)”。我知道美国和 A 的人们通常对此并不感兴趣，但它已经在世界范围内广泛使用并迅速增加（主要是非英语为主的部分）。

要点是您现在可以使用 mason@日本.com 和 wildwezyr@fahrvergnügen.net 等地址。不，这还不能与外面的所有东西兼容（正如许多人在上面所感叹的那样，即使是简单的 qmail 风格的 +ident 地址也经常被错误地拒绝）。但是有一个 RFC，有一个规范，它现在得到了 IETF 和 ICANN 的支持，而且——更重要的是——支持这种改进的大量且不断增长的实现目前正在服务中。

直到我搬回日本并开始看到 hei@やる.ca 之类的电子邮件地址和这样的亚马逊 URL 之前，我自己对这个发展了解不多：

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e?ie=UTF8&node=3210981

我知道你不想要规范的链接，但如果你只依赖互联网论坛上黑客的过时知识，你的电子邮件验证器最终会拒绝非英语用户越来越期望工作的电子邮件地址。对于那些用户来说，这样的验证将与我们都讨厌的常见的脑死亡形式一样烦人，这种形式无法处理 + 或三部分域名等。

所以我并不是说这不麻烦，而是“在某些/任何/无条件下允许”的完整字符列表是（几乎）所有语言中的所有字符。如果您想“接受所有有效的电子邮件地址（以及许多无效的电子邮件地址）”，那么您必须考虑 IDN，这基本上使基于字符的方法无用（对不起），除非您首先转换国际化的电子邮件地址（自2015 年 9 月，过去是这样的——Punycode的一个可行的替代方案。

之后，您可以遵循（大部分）上述建议。

于 2010-01-15T12:01:00.740 回答
83

电子邮件地址的格式为：（local-part@domain-part最多 64@255 个字符，总共不超过 256 个）。

local-partand可能有不同的domain-part允许字符集，但这还不是全部，因为它还有更多规则。

通常，本地部分可以有这些 ASCII 字符：

  • 小写拉丁字母：abcdefghijklmnopqrstuvwxyz,
  • 大写拉丁字母：ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • 数字：0123456789,
  • 特殊字符：!#$%&'*+-/=?^_`{|}~,
  • 点：（.不是第一个或最后一个字符或重复，除非引用），
  • 空格标点符号，例如：（"(),:;<>@[\]有一些限制），
  • 评论：（()允许在括号内，例如(comment)john.smith@example.com）。

域部分：

  • 小写拉丁字母：abcdefghijklmnopqrstuvwxyz,
  • 大写拉丁字母：ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • 数字：0123456789,
  • 连字符：（-不是第一个或最后一个字符），
  • 可以包含用方括号括起来的 IP 地址：jsmith@[192.168.2.1]或jsmith@[IPv6:2001:db8::1].

这些电子邮件地址有效：

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com（一个字母的本地部分）
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1（没有顶级域的本地域名）
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org（引号之间的空格）
  • example@localhost（从本地主机发送）
  • example@s.solutions（见互联网顶级域名列表）
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

而这些无效的例子：

  • Abc.example.com（没有@字符）
  • A@b@c@example.com@（引号外只能有一个）
  • a"b(c)d,e:f;gi[j\k]l@example.com（此本地部分的特殊字符都不允许在引号之外）
  • just"not"right@example.com（引用的字符串必须用点分隔或构成本地部分的唯一元素）
  • this is"not\allowed@example.com（空格、引号和反斜杠只能存在于带引号的字符串中并且前面有反斜杠）
  • this\ still\"not\allowed@example.com（即使转义（前面有反斜杠），空格、引号和反斜杠仍必须包含在引号中）
  • john..doe@example.com（前双点@）；（需要注意的是：Gmail 可以通过）
  • john.doe@example..com（后双点@）
  • 带有前导空格的有效地址
  • 带有尾随空格的有效地址

来源：维基百科的电子邮件地址

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（允许的字符）。

有关的：

于 2016-08-05T10:45:59.830 回答
25

Wikipedia 对此有一篇很好的文章，官方规范在这里。来自维基百科：

电子邮件地址的本地部分可以使用以下任何 ASCII 字符：

  • 大写和小写英文字母（az、AZ）
  • 数字 0 到 9
  • 人物 ！# $ % & ' * + - / = ? ^ _ ` { | } ~
  • 特点 。（点、句号、句号）只要它不是第一个或最后一个字符，并且它不连续出现两次或多次。

此外，允许使用带引号的字符串（即：“John Doe”@example.com），从而允许原本被禁止的字符，但它们不会出现在常见的实践中。RFC 5321 还警告说“希望接收邮件的主机应该避免定义本地部分需要（或使用）引用字符串形式的邮箱”。

于 2010-01-12T14:20:18.243 回答
16

您可以从维基百科文章开始：

  • 大写和小写英文字母（az、AZ）
  • 数字 0 到 9
  • 人物 ！# $ % & ' * + - / = ? ^ _ ` { | } ~
  • 特点 。（点、句号、句号）只要它不是第一个或最后一个字符，并且它不连续出现两次或多次。
于 2010-01-12T14:20:10.897 回答
14

谷歌用他们的 gmail.com 地址做了一件有趣的事。gmail.com 地址仅允许字母 (az)、数字和句点（被忽略）。

例如，pikachu@gmail.com 与 pi.kachu@gmail.com 相同，两个电子邮件地址将发送到同一个邮箱。PIKACHU@gmail.com 也发送到同一个邮箱。

因此，要回答这个问题，有时取决于实施者他们想要遵循多少 RFC 标准。Google 的 gmail.com 地址样式与标准兼容。他们这样做是为了避免混淆，不同的人会使用相似的电子邮件地址，例如

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

维基百科链接是关于通常允许使用哪些电子邮件地址的一个很好的参考。 http://en.wikipedia.org/wiki/Email_address

于 2012-01-18T09:34:30.153 回答
10

姓名：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

服务器：

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.
于 2012-01-18T09:34:16.837 回答
9

检查 @ 和 . 然后发邮件给他们验证。

我仍然无法在互联网上 20% 的网站上使用我的 .name 电子邮件地址，因为有人搞砸了他们的电子邮件验证，或者因为它早于新地址有效。

于 2013-06-11T19:28:39.313 回答
7

简短的回答是有 2 个答案。你应该做什么有一个标准。即明智的行为，可以让你远离麻烦。对于您应该接受而又不惹麻烦的行为，还有另一个（更广泛的）标准。这种二元性适用于发送和接受电子邮件，但在生活中具有广泛的应用。

有关您创建的地址的良好指南；见：https ://www.jochentopf.com/email/chars.html

要过滤有效的电子邮件，只需传递任何可以理解的内容以查看下一步。或者开始阅读一堆 RFC，小心，这里是龙。

于 2012-03-01T01:50:28.017 回答
6

在讨论电子邮件地址的有效本地部分时，接受的答案是指维基百科的文章，但维基百科不是这方面的权威。

IETF RFC 3696 是这方面的权威，应在第 3 部分查阅。第 5 页的电子邮件地址限制：

现代电子邮件地址由一个“本地部分”与一个“域部分”（一个完全限定的域名）通过 at 符号（“@”）分隔。域部分的语法对应于上一节中的语法。该部分中确定的有关过滤和名称列表的问题也适用于电子邮件上下文中使用的域名。域名也可以用方括号中的 IP 地址替换，但强烈建议不要使用这种形式，除非用于测试和故障排除目的。

本地部分可能会使用下面描述的引用约定出现。引用的表格在实践中很少使用，但出于某些合法目的是必需的。因此，它们不应在过滤例程中被拒绝，而应被传递到电子邮件系统以供目标主机评估。

确切的规则是任何 ASCII 字符，包括控制字符，都可以出现在引号中，或者出现在带引号的字符串中。当需要引用时，反斜杠字符用于引用后面的字符。例如

  Abc\@def@example.com

是电子邮件地址的有效形式。也可能出现空格，如

  Fred\ Bloggs@example.com

反斜杠字符也可用于引用自身，例如，

  Joe.\\Blow@example.com

除了使用反斜杠字符引用之外，还可以使用传统的双引号字符来包围字符串。例如

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

是上述前两个示例的替代形式。这些引用的形式很少被推荐，并且在实践中并不常见，但是，如上所述，必须得到处理电子邮件地址的应用程序的支持。特别是，引用的形式经常出现在与来自其他系统和上下文的转换相关的地址上下文中；这些过渡性要求仍然存在，并且由于接受用户提供的电子邮件地址的系统无法“知道”该地址是否与旧系统相关联，因此必须接受地址表格并将其传递到电子邮件环境中。

如果没有引号，本地部分可以由
字母字符、数字或任何特殊字符的任意组合组成

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

句点（“.”）也可能出现，但不能用于开始或结束局部部分，也不能出现两个或多个连续句点。换句话说，除 at 符号 ("@")、反斜杠、双引号、逗号或方括号之外的任何 ASCII 图形（打印）字符都可以不带引号出现。如果要出现该排除字符列表中的任何一个，则必须引用它们。形式如

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

有效且经常出现，但允许使用上面列出的任何字符。

正如其他人所做的那样，我提交了一个适用于 PHP 和 JavaScript 的正则表达式来验证电子邮件地址：

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i
于 2015-12-04T20:35:15.463 回答
5

好好读一读这件事。

摘抄：

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
于 2015-01-06T16:33:05.603 回答
3

可以在这个维基百科链接中找到

电子邮件地址的本地部分可以使用以下任何 ASCII 字符：

  • 大写和小写拉丁字母AtoZ和ato z;

  • 数字0到9;

  • 特殊字符!#$%&'*+-/=?^_`{|}~；

  • dot .，前提是它不是第一个或最后一个字符，除非被引用，并且它不连续出现，除非被引用（例如John..Doe@example.com，不允许但"John..Doe"@example.com允许）；

  • 空格和"(),:;<>@[\]字符是有限制的（它们只允许在带引号的字符串中，如下文所述，此外，反斜杠或双引号必须以反斜杠开头）；

  • 允许在本地部分的任一端带括号的注释；例如john.smith(comment)@example.com和(comment)john.smith@example.com都等价于john.smith@example.com。

除了上述 ASCII 字符之外，U+007F 以上的国际字符（编码为 UTF-8）在RFC 6531中是允许的，尽管邮件系统在分配本地部分时可能会限制使用哪些字符。

带引号的字符串可以在本地部分中以点分隔实体的形式存在，或者当最外层引号是本地部分的最外层字符时（例如，abc."defghi".xyz@example.com或被"abcdefghixyz"@example.com允许。相反，abc"defghi"xyz@example.com不是；也不是abc\"def\"ghi@example.com）。然而，带引号的字符串和字符并不常用。RFC 5321还警告说“希望接收邮件的主机应该避免定义本地部分需要（或使用）引用字符串形式的邮箱”。

本地部分postmaster被特殊处理——它不区分大小写，应该转发给域电子邮件管理员。从技术上讲，所有其他本地部分都区分大小写，因此jsmith@example.com并 JSmith@example.com指定不同的邮箱；但是，许多组织将大写和小写字母视为等价的。

尽管有大量的特殊字符在技术上是有效的；组织、邮件服务、邮件服务器和邮件客户端在实践中通常不接受所有这些。例如，Windows Live Hotmail 仅允许使用字母数字、点 ( .)、下划线 ( _) 和连字符 ( -) 创建电子邮件地址。常见的建议是避免使用一些特殊字符来避免电子邮件被拒绝的风险。

于 2014-03-21T12:06:26.633 回答
0

答案是（几乎）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 ....

因此，这样的包含规则“太宽泛了”。或者，在其他意义上，预期的规则“过于简单化”。

于 2015-06-21T04:56:14.970 回答
0

为简单起见，我通过在验证之前删除双引号内的所有文本以及相关的双引号周围的文本来清理提交，根据不允许的内容将 kibosh 放在电子邮件地址提交上。仅仅因为有人可以拥有 John.."The*$hizzle*Bizzle"..Doe@whatever.com 地址并不意味着我必须在我的系统中允许它。我们生活在未来，获得免费电子邮件地址可能比做好擦屁股所需的时间更少。这并不是说电子邮件标准没有贴在输入旁边，说明什么是允许的，什么是不允许的。

在引用的材料被删除后，我还会清理各种 RFC 明确不允许的内容。明确禁止的字符和模式列表似乎是一个要测试的短得多的列表。

不允许：

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

在给出的示例中：

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

在尝试添加或更改电子邮件地址时向剩余结果发送确认电子邮件消息是查看您的代码是否可以处理提交的电子邮件地址的好方法。如果电子邮件在根据需要进行多轮清理后通过验证，则启动该确认。如果从确认链接返回请求，则可以将新电子邮件从持有||临时||炼狱状态或存储移动到真正的、真正的一流存储电子邮件。

如果您想体谅，可以将电子邮件地址更改失败或成功的通知发送到旧电子邮件地址。未经确认的帐户设置可能会在一段合理的时间后完全失败，因为尝试失败。

我不允许在我的系统上发送臭名昭著的电子邮件，也许那只是在浪费钱。但是，在 99.9% 的情况下，人们只是做正确的事，并且拥有一封不会利用边缘案例兼容性场景将一致性限制推向边缘的电子邮件。小心正则表达式 DDoS，这是一个你可能会遇到麻烦的地方。这与我做的第三件事有关，我限制了我愿意处理任何一封电子邮件的时间。如果它需要减慢我的机器的速度才能得到验证——它不会超过我的传入数据 API 端点逻辑。

编辑：这个答案不断被指责为“坏”，也许它应得的。也许它仍然很糟糕，也许不是。

于 2016-01-24T06:21:38.013 回答
-1

在我的 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

于 2015-07-23T02:00:19.183 回答
-1

我根据 RFC 指南创建了这个正则表达式：

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$
于 2017-04-19T21:02:41.873 回答
-2

Gmail 仅允许 + 号作为特殊字符，在某些情况下 (.)，但 Gmail 不允许使用任何其他特殊字符。RFC 说您可以使用特殊字符，但您应该避免使用特殊字符向 Gmail 发送邮件。

于 2014-09-17T18:22:36.560 回答