摘要：
我不是在问完整的电子邮件验证。 我只是想知道电子邮件地址的user-name和server部分中允许的字符是什么。 这可能过于简单，也许电子邮件地址可以采取其他形式... 我只是想知道电子邮件地址的user-name和server部分中允许的字符是什么。 这可能过于简单，也许电子邮件地址可以采取其他形式，但我不在乎。 我只询问这个简单的形式： user-name@server （例如wild.wezyr@best-server-ever.com）和两个部分允许的字符。
#1楼
检查@和。 然后发送电子邮件给他们验证。
我仍然无法在互联网上20％的网站上使用我的.name电子邮件地址，因为有人搞砸了他们的电子邮件验证，或者因为它早于有效的新地址。
#2楼
请参阅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字符：
除ASCII字符外， 截至2012年，您可以使用U+007F 以上的国际字符 ，编码为UTF-8，如所述，并在解释。 请注意，截至2019年，这些标准仍然标记为建议，但正在缓慢推出。 此规范中的更改实际上将国际字符添加为有效的字母数字字符（atext），而不会影响允许和限制的特殊字符（如!#和@: ：）的规则。
有关验证，请参阅使用正则表达式验证电子邮件地址 。
domain部分定义 ：
协议的Internet标准（Request for Comments）要求组件主机名标签可以仅包含ASCII字母a到z （以不区分大小写的方式），数字0到9以及连字符（ - ）。 RFC 952中主机名的原始规范，强制标签不能以数字或连字符开头，并且不得以连字符结尾。 但是，后续规范（ RFC 1123 ）允许主机名标签以数字开头。 不允许使用其他符号，标点字符或空格。
#3楼
你可以从维基百科文章开始：
#4楼
， 官方规范在这里 。 来自Wikipdia：
电子邮件地址的本地部分可以使用以下任何ASCII字符：
另外，允许引用字符串（即：“John Doe”@ example.com），从而允许否则将被禁止的字符，但是它们不会出现在通常的实践中。 RFC 5321还警告说“希望接收邮件的主机应该避免定义Local-part需要（或使用）Quoted-string表单的邮箱”。
#5楼
小心！ 在这个线程中有一堆知识腐烂（过去曾经是真的，现在却没有）。
为了避免在当前和未来世界以及世界任何地方误报实际电子邮件地址，您至少需要了解RFC 3490的高级概念“在应用程序中国际化域名（IDNA）”。 我知道美国和美国的人们往往不会这样做，但它已经广泛使用并且在世界范围内迅速增加 （主要是非英语主导的部分）。
要点是，您现在可以使用mason @日本.com和wildwezyr@fahrvergnügen.net等地址。 不，这还不兼容那里的所有东西（正如许多人在上面感叹，即使简单的qmail风格+身份地址也经常被错误地拒绝）。 但是有一个RFC，有一个规范，它现在得到了IETF和ICANN的支持，而且 - 更重要的是 - 支持这种改进的大量且越来越多的实现正在服务中。
在我回到日本并开始看到像hei @やる.ca这样的电子邮件地址以及像这样的Amazon URL之前，我对这个开发本身并不多了解：
エレクトロニクス-デジタルカメラ-ポータブルオーディオ/ B / REF = topnav_storetab_e即= UTF8＆节点= 3210981
我知道你不希望链接到规范，但如果你完全依赖于互联网论坛上黑客的过时知识，你的电子邮件验证者最终会拒绝非英语用户越来越期望工作的电子邮件地址。 对于那些用户来说，这样的验证就像我们讨厌的普通脑死亡形式一样令人讨厌，无法处理+或三部分域名或其他任何东西。
所以我并不是说这不麻烦，但是“允许在某些/任何/无条件下”的完整字符列表（几乎）是所有语言中的所有字符。 如果你想“接受所有有效的电子邮件地址（以及许多无效的电子邮件地址）”那么你必须考虑IDN，这基本上使得基于字符的方法无用（对不起），除非你首先将国际化的电子邮件地址转换为Punycode 。
完成后，您可以遵循（大部分）上面的建议。
#6楼
可以在找到
电子邮件地址的本地部分可以使用以下任何ASCII字符：
除了上述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仅允许使用字母数字，点（ . ），下划线（ _ ）和连字符（ - ）创建电子邮件地址。 常见的建议是避免使用某些特殊字符以避免被拒绝的电子邮件的风险。
#7楼
Gmail仅允许+签名作为特殊字符，在某些情况下（。），但Gmail不允许使用任何其他特殊字符。 RFC表示您可以使用特殊字符，但应避免使用特殊字符向Gmail发送邮件。
#8楼
关于此事的好读。
摘抄：
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
#9楼
答案是（几乎） ALL （7位ASCII）。
如果包含规则是“......允许在某些/任何/无条件下......”
只需在第17页顶部的的“域文本”部分中查看允许文本的几个可能包含规则之一，我们就会发现：
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
此描述中只有三个缺少的字符用于domain-literal [] ，以形成引用对\\和空格字符 （％D32）。 使用它，使用整个范围32-126（十进制）。 类似的要求显示为“qtext”和“ctext”。 许多控制字符也被允许/使用。 一个这样的控制字符列表出现在第31页作为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 ....
因此，这样的包含规则“太宽”了。 或者，在其他意义上，预期的规则是“过于简单化”。
#10楼
在我的PHP中，我使用此检查
亲自尝试
#11楼
在讨论电子邮件地址的有效本地部分时，接受的答案是指维基百科的文章，但维基百科不是这方面的权威。
IETF RFC 3696 是此问题的权威 ，应参阅第3节。电子邮件地址的限制在第5页：
当前电子邮件地址由“本地部分”组成，该“本地部分”通过符号（“@”）与“域部分”（完全限定的域名）分开。 域部分的语法对应于上一节中的语法。 该部分中关于过滤和名称列表的关注点也适用于电子邮件上下文中使用的域名。 域名也可以用方括号中的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
#12楼
为简单起见，我通过在验证之前删除双引号内的所有文本以及相关的周围双引号来清理提交，根据不允许的内容提交电子邮件地址提交。 仅仅因为有人可以拥有约翰......“* $ 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
在尝试添加或更改电子邮件地址时向剩余结果发送确认电子邮件消息是查看您的代码是否可以处理提交的电子邮件地址的好方法。 如果电子邮件在需要进行多轮清理后通过验证，则启动该确认。 如果请求从确认链接返回，则新电子邮件可以从持有|| temporary ||炼狱状态或存储中移动，以成为真实的，真实的头等存储电子邮件。
如果您想体谅，可以将电子邮件地址更改失败或成功的通知发送到旧电子邮件地址。 未经证实的帐户设置可能会在合理的时间内完全失败，因为失败的尝试完全失败。
我不允许在我的系统上发送恶作剧电子邮件，也许这只是丢钱。 但是，99.9％的时间人们只是做正确的事情并且使用边缘情况兼容性方案的电子邮件不会将符合性限制推向边缘。 注意正则表达式DDoS，这是一个你可以遇到麻烦的地方。 这与我做的第三件事有关，我限制了我愿意处理任何一封电子邮件的时间。 如果它需要减慢我的机器以进行验证 - 它没有超过我的传入数据API端点逻辑。
编辑：这个答案继续因为“糟糕”而被贬低，也许它应该得到它。 也许它仍然很糟糕，也许不是。
#13楼
电子邮件地址的格式为： local-part@domain-part （最多64个@ 255个字符，总共不超过256个字符）。
local-part和domain-part可以有不同的允许字符集，但这不是全部，因为它有更多的规则。
通常，本地部分可以具有以下ASCII字符：
域名部分：
这些电子邮件地址有效：
而这些无效的例子：
