我不是在问完整的电子邮件验证。
我只是想知道电子邮件地址的user-name和server部分允许使用哪些字符。这可能过于简单，也许电子邮件地址可以采取其他形式，但我不在乎。我只询问这个简单的表格：user-name@server（例如wild.wezyr@best-server-ever.com）以及两个部分允许的字符。
答案 0 :(得分：707)
请参阅RFC 5322: Internet Message Format，并在较小程度上RFC 5321: Simple Mail Transfer Protocol。
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
和往常一样，维基百科有一个不错的article on email addresses：
电子邮件地址的本地部分可以使用以下任何ASCII字符：
- 大写和小写拉丁字母
A至Z和a至z;- 位数
0至9;- 特殊字符
!#$%&'*+-/=?^_`{|}~;- 点
.，前提是它不是第一个或最后一个字符，除非引用，并且除非引用，否则它不会连续出现（例如John..Doe@example.com不允许，但"John..Doe"@example.com允许）;- 允许空格和
"(),:;<>@[\]个字符有限制（它们只允许在带引号的字符串中，如下段所述，此外，反斜杠或双引号必须以反斜杠开头）;- 允许在本地部分的两端用括号注释;例如
john.smith(comment)@example.com和(comment)john.smith@example.com都等同于john.smith@example.com。
除了ASCII字符as of 2012之外，您还可以使用国际characters above U+007F，编码为RFC 6532 spec中所述的UTF-8，并在{{3} }。请注意，截至2019年，这些标准仍然标记为建议，但正在缓慢推出。此规范中的更改实际上将国际字符添加为有效的字母数字字符（atext），而不会影响允许的＆amp;受限制的特殊字符，例如!#和@:。
有关验证，请参阅Wikipedia。
domain部分定义为Using a regular expression to validate an email address：
协议的Internet标准（Request for Comments）要求组件主机名标签只能包含ASCII字母
a到z（不区分大小写），数字{{1} }通过0和连字符（9）。 as follows中主机名的原始规范，强制标签不能以数字或连字符开头，并且不得以连字符结尾。但是，后续规范（RFC 952）允许主机名标签以数字开头。不允许使用其他符号，标点字符或空格。
答案 1 :(得分：293)
小心！在这个线程中有一堆知识腐烂（过去曾经是真的，现在却没有）。
为了避免在当前和未来的世界以及世界任何地方误报实际电子邮件地址，您至少需要了解RFC 3490的高级概念，“将域名国际化应用程序（IDNA）“。我知道美国和美国的人们往往不会这样做，但它已经在全球范围内广泛且迅速增加使用（主要是非英语主导的部分）。
要点是，您现在可以使用mason @日本.com和wildwezyr@fahrvergnügen.net等地址。不，这还不兼容那里的所有东西（正如许多人在上面感叹，即使简单的qmail风格+身份地址也经常被错误地拒绝）。但是有一个RFC，有一个规范，它现在得到IETF和ICANN的支持，而且 - 更重要的是 - 支持这一改进的大量且越来越多的实现正在服务中。
在我回到日本并开始看到像hei @やる.ca这样的电子邮件地址以及像这样的亚马逊网址之前，我自己对这个开发了解不多：
http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e?ie=UTF8&node=3210981
我知道您不希望链接到规范，但如果您完全依赖于互联网论坛上黑客的过时知识，那么您的电子邮件验证程序最终将拒绝非英语用户越来越期望工作的电子邮件地址。对于那些用户来说，这种验证就像我们讨厌的普通脑死亡形式一样烦人，无法处理+或三部分域名或其他任何东西。
所以我并不是说这不麻烦，但是“允许在某些/任何/无条件下”的完整字符列表（几乎）是所有语言中的所有字符。如果您想“接受所有有效的电子邮件地址（以及许多无效的电子邮件地址）”，那么您必须考虑IDN，这基本上使基于字符的方法无用（抱歉），除非您首先convert the internationalized email addresses到{{ 3}}
在这样做之后，你可以遵循（大部分）上面的建议。
答案 2 :(得分：39)
电子邮件地址的格式为：local-part@domain-part（最多64个@ 255个字符，总共不超过256个。）
local-part和domain-part可能有不同的允许字符集，但并非全部，因为有更多规则。
通常，本地部分可以包含以下ASCII字符：
abcdefghijklmnopqrstuvwxyz，ABCDEFGHIJKLMNOPQRSTUVWXYZ，0123456789，!#$%&'*+-/=?^_`{|}~，.（不是第一个或最后一个字符或重复，除非引用），"(),:;<>@[\]（有一些限制），()（括号内允许使用，例如(comment)john.smith@example.com）。域名部分：
abcdefghijklmnopqrstuvwxyz，ABCDEFGHIJKLMNOPQRSTUVWXYZ，0123456789，-（不是第一个或最后一个字符），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（从localhost发送）example@s.solutions（请参阅List of Internet top-level domains）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（@之后的双点）来源：维基百科的Email address
Perl's RFC2822 regex用于验证电子邮件：
(?:(?:\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。
另请参阅：RFC 822 Email Address Parser in PHP。
电子邮件地址的正式定义如下：
相关：
答案 3 :(得分：21)
Wikipedia has a good article on this和the official spec is here。来自Wikipdia：
电子邮件地址的本地部分可以使用以下任何ASCII字符：
- 大写和小写英文字母（a-z，A-Z）
- 数字0到9
- 人物！ ＃$％＆amp; '* + - / =？ ^ _` {| }〜
- 性格。 （点，句号，句号），前提是它不是第一个或最后一个字符，并且也表示连续两次或多次不出现。
此外，允许引用字符串（即：“John Doe”@ example.com），从而允许以其他方式被禁止的字符，但是它们不会出现在常规实践中。 RFC 5321还警告说“希望接收邮件的主机应该避免定义Local-part需要（或使用）Quoted-string表单的邮箱”。
答案 4 :(得分：13)
Google用他们的gmail.com地址做了一件有趣的事情。 gmail.com地址只允许字母（a-z），数字和句点（被忽略）。
例如，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
答案 5 :(得分：12)
您可以从wikipedia article开始：
答案 6 :(得分：11)
姓名：
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.
服务器：
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.
答案 7 :(得分：9)
检查@和。然后发送电子邮件给他们验证。
我仍然无法在互联网上20％的网站上使用我的.name电子邮件地址，因为有人搞砸了他们的电子邮件验证，或者因为它早于新地址有效。
答案 8 :(得分：5)
简短的回答是有2个答案。你应该做什么有一个标准。即行为是明智的，将使你摆脱困境。对于你应该接受而不会制造麻烦的行为，还有另一个（更广泛的）标准。这种二元性适用于发送和接受电子邮件，但在生活中具有广泛的应用。
为您创建的地址提供良好的指导;见：http://www.remote.org/jochen/mail/info/chars.html
要过滤有效的电子邮件，只需传递一些可理解的内容，以便查看下一步。 或者开始阅读一堆RFC，请注意，这里是龙。
答案 9 :(得分：5)
对matter的好读。
摘录：
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
答案 10 :(得分：5)
在讨论电子邮件地址的有效本地部分时，接受的答案是指维基百科的文章，但维基百科不是这方面的权威。
IETF RFC 3696 是此事项的权威，应在 3部分查阅。第5页的电子邮件地址限制：
当代电子邮件地址包含＆＃34;本地部分＆＃34;分开 a＆＃34;域名部分＆＃34; （一个完全合格的域名）由at符号（＆＃34; @＆＃34;）。 域部分的语法对应于前一部分的语法 部分。该部分中关于过滤和关注的问题 名称列表适用于电子邮件上下文中使用的域名 好。域名也可以替换为IP地址 方括号，但强烈不鼓励这种形式除外 测试和故障排除目的。
本地部分可能使用所述的引用约定出现 下面。引用的表格在实践中很少使用，但是是必需的 出于某些合法目的。因此，他们不应该被拒绝 过滤例程，但应该传递给电子邮件系统 由目的地主机评估。
确切的规则是任何ASCII字符，包括控制 字符，可能出现引号，或带引号的字符串。引用时是 需要时，反斜杠字符用于引用以下内容 字符。例如
Abc\@def@example.com是电子邮件地址的有效形式。空格也可能出现， 如在
Fred\ Bloggs@example.com反斜杠字符也可用于引用自身，例如，
Joe.\\Blow@example.com除了使用反斜杠字符引用外，常规 双引号字符可用于包围字符串。例如
"Abc@def"@example.com "Fred Bloggs"@example.com是上面前两个例子的替代形式。引用这些 表格很少被推荐，在实践中并不常见，但是，如 如上所述，必须由正在处理的应用程序支持 电子邮件地址。特别是，引用的形式经常出现在 与其他系统转换相关的地址上下文 和背景;那些过渡性要求仍然会出现， 因为接受用户提供的电子邮件地址的系统不能 ＆＃34;知＆＃34;该地址是否与遗留系统相关联 地址表格必须被接受并传递到电子邮件环境中。
如果没有引号，本地部分可以包含任何组合 字母字符，数字或任何特殊字符
句号（＆＃34;。＆＃34;）也可能出现，但可能不会用于开始或结束 本地部分，也可能出现两个或更多连续的时期。 换句话说，除了以外的任何ASCII图形（打印）字符 at-sign（＆＃34; @＆＃34;），反斜杠，双引号，逗号或方括号 可能会出现没有引用。如果排除任何该列表 要出现字符，必须引用它们。表格如! # $ % & ' * + - / = ? ^ _ ` . { | } ~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
答案 11 :(得分：3)
电子邮件地址的本地部分可以使用以下任何ASCII字符：
大写和小写拉丁字母
A至Z和a至z;数字
0至9;特殊字符
!#$%&'*+-/=?^_`{|}~;点
.，前提是它不是第一个或最后一个字符，除非引用，并且还提供它不会连续出现，除非引用（例如John..Doe@example.com不允许但"John..Doe"@example.com允许1}};空格和
"(),:;<>@[\]字符是允许的限制（它们只允许在带引号的字符串中，如下段所述，此外，反斜杠或双引号必须在前面加上反斜杠）;允许在本地部分的两端带括号的注释;例如
john.smith(comment)@example.com和(comment)john.smith@example.com都等同于john.smith@example.com。除上述ASCII字符外，RFC 6531允许使用编码为UTF-8的U + 007F以上的国际字符，但邮件系统可能会限制在分配本地部分时使用哪些字符。
引用的字符串可以作为本地部分中的点分隔实体存在，或者当最外面的引号是本地部分的最外面的字符时可能存在（例如，
abc."defghi".xyz@example.com或"abcdefghixyz"@example.com相反，abc"defghi"xyz@example.com不是;abc\"def\"ghi@example.com也不是。{但是，引用的字符串和字符并不常用。 RFC 5321还警告说“希望接收邮件的主机应该避免定义Local-part要求（或使用）Quoted-string表单的邮箱”。本地部分
postmaster受到特殊处理 - 它不区分大小写，应转发给域电子邮件管理员。从技术上讲，所有其他本地部分都区分大小写，因此jsmith@example.com和JSmith@example.com指定不同的邮箱;但是，许多组织将大写和小写字母视为等效字母。尽管技术上有效的特殊字符种类繁多;实际上，组织，邮件服务，邮件服务器和邮件客户端通常不接受所有这些。例如，Windows Live Hotmail仅允许使用字母数字，点（
.），下划线（_）和连字符（-）创建电子邮件地址。常见的建议是避免使用某些特殊字符以避免被拒绝电子邮件的风险。
答案 12 :(得分：0)
答案是（差不多）ALL（7位ASCII）
如果包含规则是＆＃34; ...允许在某些/任何/无条件下......＆＃34;
只需在＆＃34;域文本中查看允许文本的几个可能的包含规则之一＆＃34;在第17页顶部的RFC 5322中，我们找到了：
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
此描述中仅有三个缺少的字符用于域文字[]，以形成引用对\和空格字符（％d32）。使用它，使用整个范围32-126（十进制）。类似的要求显示为＆＃34; qtext＆＃34;和＆＃34; ctext＆＃34;。许多控制字符也被允许/使用。一个这样的控制字符列表出现在第31页section 4.1 of RFC 5322中，作为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 ....
因此，这样的包含规则是太宽了＃34;或者，在其他意义上，预期的规则是过于简单化＆＃34;。
答案 13 :(得分：0)
为了简单起见，我通过在验证之前删除双引号内的所有文本以及那些相关的周围双引号来清理提交，根据不允许的内容提交电子邮件地址提交。只是因为有人可以拥有约翰...＆＃34; * $ hizzle * Bizzle＆＃34; ... 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
尝试添加或更改电子邮件地址时，向剩余结果发送确认电子邮件是查看您的代码是否可以处理提交的电子邮件地址的好方法。如果电子邮件在需要进行多轮清理后通过验证，则启动该确认。如果请求从确认链接返回，则新电子邮件可以从持有|| temporary ||炼狱状态或存储中移动，成为真实的，真实的头等存储电子邮件。
如果您想要体谅，可以将电子邮件地址更改失败或成功的通知发送到旧电子邮件地址。未经证实的帐户设置可能会在合理的时间后完全失败，因为失败的尝试完全失效。
我不允许在我的系统上发送臭名昭着的电子邮件，也许这只是丢钱。但是，99.9％的时间人们只是做正确的事情并且使用边缘情况兼容性方案发送的电子邮件并没有将符合性限制推向边缘。注意正则表达式DDoS，这是一个你可以遇到麻烦的地方。这与我做的第三件事有关，我限制了我愿意处理任何一封电子邮件的时间。如果它需要减慢我的机器以进行验证 - 它不会超过我的传入数据API端点逻辑。
编辑：这个答案继续因为＆＃34;坏＆＃34;而得到了回应，也许它应该得到它。也许它仍然很糟糕，也许不是。
答案 14 :(得分：-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";
}
?>
答案 15 :(得分：-1)
我根据RFC指南创建了这个正则表达式：
^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$
答案 16 :(得分：-2)
Gmail只允许+签名作为特殊字符，在某些情况下（。），但Gmail不允许使用任何其他特殊字符。 RFC表示您可以使用特殊字符，但应避免使用特殊字符向Gmail发送邮件。