电子邮件地址允许使用哪些字符？

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

我只是想知道什么是电子邮件地址的user-name和server部分允许的字符。 这可能过于简单，也许电子邮件地址可以采取其他forms，但我不在乎。 我只问这个简单的forms： user-name@server （例如[e-mail]）和允许在这两个部分的字符。

Answer 1

请参阅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 ;
• 特殊字符!#$%&'*+-/=?^_`{|}~ ;
• 点. ，除非引用它不是第一个或最后一个字符，并且还规定它不会连续出现，除非被引用（例如[e-mail]是不允许的，但是“ "John..Doe"@example.com [e-mail]是允许）;
• 空格和"(),:;<>@[\]字符是有限制的允许的（它们只允许在一个带引号的string中，如下面的段落所述，另外，反斜杠或双引号必须以反斜杠）;
• 允许在本地部分的任一端使用括号进行评论; 例如(comment)[e-mail]和（ (comment)[e-mail]等同于(comment)[e-mail] 。

除了ASCII字符外， 截至2012年，您可以使用U+007F 以上的国际字符 ，编码为UTF-8 。

有关validation，请参阅使用正则expression式validation电子邮件地址 。

domain部分定义如下 ：

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

Answer 2

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

为了避免在当前和未来世界以及世界任何地方对实际电子邮件地址进行错误的拒绝，您至less需要了解RFC 3490 “应用程序中的域名国际化（IDNA）”的高级概念。 我知道美国和美国的人们往往不在这方面，但它已经在世界各地（主要是非英语为主的部分） 广泛和迅速增长的使用 。

要点是，你现在可以使用像mason @日本.com和wildwezyr@fahrvergnügen.net地址。 不，这还不是和所有的东西都兼容的（正如上面所说的那样，即使简单的qmail-style + ident地址经常被错误地拒绝）。 但是有一个RFC，有一个规范，它现在由IETF和ICANN支持，更重要的是，有大量的支持这种改进的实现正在服务中。

直到我回到日本开始看到像hei @やる.ca和亚马逊url这样的电子邮件地址，我才对自己的这个发展了解不多。

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/ B / REF = topnav_storetab_e即= UTF8＆节点= 3210981

我知道你不想要规范的链接，但是如果你完全依赖networking论坛上黑客的过时知识，那么你的电子邮件validation器将最终拒绝非Enlish用户越来越期望工作的电子邮件地址。 对于那些用户来说，这样的validation就像我们都讨厌的常见的脑死亡forms一样烦人，无法处理+或三部分域名或者其他什么。

所以我并不是说这不是一件麻烦的事情，但是“在一些/任何/没有条件下允许的”字符的全部列表（几乎）是所有语言中的所有字符。 如果你想“接受所有有效的电子邮件地址（也有很多无效的）”，那么你必须考虑IDN，这基本上使基于字符的方法无用（对不起），除非你首先将国际化的电子邮件地址转换为Punycode 。

这样做之后，您可以按照（大部分）上面的build议。

Answer 3

名称：

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

服务器：

 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-. 

Answer 4

维基百科有一个很好的文章 ， 官方规格在这里 。 来自Wikipdia：

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

• 大写和小写英文字母（az，AZ）
• 数字0到9
• 人物！ ＃$％＆'* + – / =？ ^ _`{| }〜
• 性格。 （点，句号，句号），前提是不是第一个或最后一个字符，并且规定它不会连续出现两次或更多次。

此外，引用string（即：“John Doe”@ example.com）是允许的，因此允许禁止使用字符，但是它们并不常见。 RFC 5321还警告说：“预期接收邮件的主机应该避免在本地部分需要（或使用）引用string表单的情况下定义邮箱”。

Answer 5

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

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

一般来说，本地部分可以有这些ASCII字符：

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

域名部分：

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

这些电子邮件地址是有效的：

• [e-mail]
• [e-mail]
• [e-mail]
• [e-mail]
• [e-mail] （单字母本地部分）
• "much.more unusual"@example.com
• "very.unusual.@.unusual.com"@example.com
• "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
• [e-mail]
• admin@mailserver1 （没有顶级域名的本地域名）
• #!$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org （引号之间的空格）
• example@localhost （从本地example@localhost发送）
• [e-mail] （请参阅Internet顶级域名列表 ）
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

而这些无效的例子：

• Abc.example.com （无@字符）
• A@b@[e-mail] （引号外只允许有一个@ ）
• a"b(c)d,e:f;gi[j\k][e-mail] （本地部分的特殊字符不允许在引号外）
• just"not"[e-mail] （引用的string必须是点分隔的或构成本地部分的唯一元素）
• this is"not\[e-mail] （空格，引号和反斜线只能存在于带引号的string中，并且以反斜杠开头）
• this\ still\"not\[e-mail] （即使转义（前面加一个反斜杠），空格，引号和反斜杠仍然必须包含在引号中）
• [e-mail] （ [e-mail]之前的双点）; （需要注意的是，Gmail允许通过）
• john.doe@example..com （ john.doe@example..com之后的双点）
• 一个领先空间的有效地址
• 一个有空格的有效地址

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

---

用于validation电子邮件的Perl的RFC2822正则expression式：

 (?:(?:\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*) 

---

电子邮件地址的正式定义如下：

• RFC 5322（3.2.3节和3.4.1节，废止RFC 2822），RFC 5321，RFC 3696，
• RFC 6531（允许的字符）。

---

有关：

• 正则expression式的真正力量

Answer 6

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

• 大写和小写英文字母（az，AZ）
• 数字0到9
• 人物！ ＃$％＆'* + – / =？ ^ _`{| }〜
• 性格。 （点，句号，句号），前提是不是第一个或最后一个字符，并且规定它不会连续出现两次或更多次。

Answer 7

谷歌做他们的gmail.com地址有趣的事情。 gmail.com地址只允许字母（az），数字和句点（被忽略）。

例如，[e-mail]与[e-mail]相同，并且这两个电子邮件地址将被发送到同一个邮箱。 [e-mail]也发送到同一个邮箱。

所以要回答这个问题，有时候要看实施者是否想遵循多lessRFC标准。 Google的gmail.com地址风格与标准兼容。 他们这样做，以避免混淆不同的人会采取类似的电子邮件地址，例如

 *** gmail.com accepting rules *** [e-mail] (accepted) [e-mail] (bounce and account can never be created) [e-mail] (accepted) D.Oy'[e-mail] (bounce and account can never be created) 

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

Answer 8

简短的答案是有2个答案。 你应该做什么有一个标准。 即明智的行为，并会使你摆脱困境。 还有另一个（更广泛的）你应该接受的行为的标准，而不是麻烦。 这种双重性适用于发送和接受电子邮件，但在生活中具有广泛的应用。

对于你创build的地址有一个很好的指导。 请参阅： http ： //www.remote.org/jochen/mail/info/chars.html

要过滤有效的电子邮件，只需传递足够的东西来看下一步。 或者开始阅读一堆RFC，谨慎，这里是龙。

Answer 9

检查@和。 然后发送一封电子邮件给他们进行validation。

我仍然不能在互联网的20％的网站上使用我的.name电子邮件地址，因为有人搞砸了他们的电子邮件validation，或者因为新邮件地址有效。

Answer 10

关于这件事的一个很好的阅读。

摘抄：

 These are all valid email addresses! "Abc\@def"@example.com "Fred Bloggs"@example.com "Joe\\Blow"@example.com "Abc@def"@example.com customer/department=[e-mail] \$[e-mail] !def![e-mail] [e-mail] 

Answer 11

正如可以在这个维基百科链接中find的

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

• 大写和小写拉丁字母A到Z和a到z ;

• 数字0到9 ;

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

• 点. ，除非引用它不是第一个或最后一个字符，并且还规定它不会连续出现，除非被引用（例如[e-mail]是不允许的，但是“ "John..Doe"@example.com [e-mail]是允许）;

• 空格和"(),:;<>@[\]字符是有限制的允许的（它们只允许在引用的string中，如下面的段落所述，另外，反斜杠或双引号必须以反斜杠）;

• 允许在本地部分的任一端使用括号进行评论; 例如(comment)[e-mail]和（ (comment)[e-mail]等同于(comment)[e-mail] 。

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

带引号的string可以在本地部分中以点分隔实体的forms存在，也可以在最外层引号是本地部分的最外层字符时存在（例如abc."defghi"[e-mail]或"abcdefghixyz"@example.com是允许的。相反， abc"defghi"[e-mail]不是; abc\"def\"[e-mail] ）。 引用的string和字符，但是，并不常用。 RFC 5321还警告说：“预期接收邮件的主机应该避免在本地部分需要（或使用）引用string表单的情况下定义邮箱”。

本地部分的邮件pipe理员是专门处理的 – 它是不区分大小写的，应该被转发给域的邮件pipe理员。 从技术上讲，所有其他本地部分都区分大小写，因此[e-mail]和[e-mail]指定不同的邮箱; 然而，许多组织把大写和小写字母视为等同。

尽pipe在技术上有效的特殊字符范围广泛， 组织，邮件服务，邮件服务器和邮件客户端在实践中往往不接受所有这些。 例如，Windows Live Hotmail只允许使用字母数字，点（ . ），下划线（ _ ）和连字符（ - ）来创build电子邮件地址。 常见的build议是避免使用一些特殊的字符，以避免被拒绝的电子邮件的风险。

Answer 12

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

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

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

 /^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i 

Answer 13

答案是（几乎） ALL （7位ASCII）。
如果包含规则是“…允许在某些/任何/没有条件…”

只要查看第17页顶部的RFC 5322中的“域文本”部分中允许的文本的几个可能的包含规则之一，就可以find：

 dtext = %d33-90 / ; Printable US-ASCII %d94-126 / ; characters not including obs-dtext ; "[", "]", or "\" 

在这个描述中只有三个缺less的字符被用在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 .... 

因此这样一个包含规则“太宽”了。 或者换句话说，预期的规则是“太简单”了。

Answer 14

在我的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'[e-mail]" )){ echo "legit email"; } else { echo "NOT legit email"; } ?> 

自己尝试http://phpfiddle.org/main/code/9av6-d10r

Answer 15

2016年1月24日

关于此时所有RFC最多为6531

我正在考虑删除所有文本与双引号和周围的双引号validation之前，把基于什么是不允许的电子邮件地址（特别是似乎是一个很短的名单…）引用材料被删除后，随后如果通过前两个条件发送确认电子邮件消息到整个电子邮件地址，并且未经确认的账户设置在合理的时间之后完全脱离系统。

不允许：

  local part starts with a period two or more periods in series &'`*|/ more than one @ outside of double quotation marks :% 

Answer 16

我根据RFC准则创build了这个正则expression式：

 ^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$ 

Answer 17

对于那些有兴趣validation国际领域的人来说，这里有一个.NET工具（不属于公司）：

http://cobisi.com/email-validation/.net-component – 符合一长串的RFC：

支持引用字，域文字，非ASCII域名（IDNA）和邮箱的IETF标准（RFC 1123，RFC 2821，RFC 2822，RFC 3490，RFC 3696，RFC 4291，RFC 5321，RFC 5322和RFC 5336）和评论

Answer 18

Gmail将只允许+符号作为特殊字符，在某些情况下（。），但Gmail不允许使用其他任何特殊字符。 RFC的说，你可以使用特殊字符，但你应该避免发送邮件到特殊字符的Gmail。