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

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

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

检查@和。 然后发送电子邮件给他们验证。

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

请参阅RFC 5322：Internet邮件格式，以及在较小程度上的RFC 5321：简单邮件传输协议 。

RFC 822也涵盖了电子邮件地址，但它主要涉及其结构：

像往常一样，维基百科有一篇关于电子邮件地址的文章 ：

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

除ASCII字符外， 截至2012年，您可以使用U+007F 以上的国际字符 ，编码为UTF-8，如RFC 6532规范中所述，并在Wikipedia上进行了解释。 请注意，截至2019年，这些标准仍然标记为建议，但正在缓慢推出。 此规范中的更改实际上将国际字符添加为有效的字母数字字符（atext），而不会影响允许和限制的特殊字符（如!#和@: ：）的规则。

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

domain部分定义如下 ：

协议的Internet标准（Request for Comments）要求组件主机名标签可以仅包含ASCII字母a到z （以不区分大小写的方式），数字0到9以及连字符（ - ）。 RFC 952中主机名的原始规范，强制标签不能以数字或连字符开头，并且不得以连字符结尾。 但是，后续规范（ RFC 1123 ）允许主机名标签以数字开头。 不允许使用其他符号，标点字符或空格。

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

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

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

另外，允许引用字符串（即：“John Doe”@ example.com），从而允许否则将被禁止的字符，但是它们不会出现在通常的实践中。 RFC 5321还警告说“希望接收邮件的主机应该避免定义Local-part需要（或使用）Quoted-string表单的邮箱”。

小心！ 在这个线程中有一堆知识腐烂（过去曾经是真的，现在却没有）。

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

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

在我回到日本并开始看到像hei @やる.ca这样的电子邮件地址以及像这样的Amazon URL之前，我对这个开发本身并不多了解：

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

我知道你不希望链接到规范，但如果你完全依赖于互联网论坛上黑客的过时知识，你的电子邮件验证者最终会拒绝非英语用户越来越期望工作的电子邮件地址。 对于那些用户来说，这样的验证就像我们讨厌的普通脑死亡形式一样令人讨厌，无法处理+或三部分域名或其他任何东西。

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

完成后，您可以遵循（大部分）上面的建议。

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

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

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

数字0到9 ;

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

点. ，除非引用，否则它不是第一个或最后一个字符，并且除非引用，否则它也不会连续出现（例如， [email protected]不允许，但是“ "John..Doe"@example.com [email protected]是允许）;

空格和"(),:;@[\\]字符允许有限制（它们只允许在带引号的字符串中，如下段所述，此外，必须在前面加上反斜杠或双引号反斜杠）;

本地部分两端的括号允许注释; 如john.smith(comment)@example.com和(comment)[email protected]都等同于[email protected] 。

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

带引号的字符串可以作为本地部分中的点分隔实体存在，或者当最外面的引号是本地部分的最外面的字符时可以存在（例如， abc."defghi"[email protected]或"abcdefghixyz"@example.com是允许的。相反， abc"defghi"[email protected]不是; abc\\"def\\"[email protected]也不是。 但是，引用的字符串和字符并不常用。 RFC 5321还警告说“希望接收邮件的主机应该避免定义Local-part需要（或使用）Quoted-string表单的邮箱”。

本地部分postmaster是专门处理它是不区分大小写的，并且应该被转发到域电子邮件管理员。 从技术上讲，所有其他本地部分都区分大小写，因此[email protected]和[email protected]指定不同的邮箱; 但是，许多组织将大写和小写字母视为等效字母。

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

Gmail仅允许+签名作为特殊字符，在某些情况下（。），但Gmail不允许使用任何其他特殊字符。 RFC表示您可以使用特殊字符，但应避免使用特殊字符向Gmail发送邮件。

关于此事的好读。

摘抄：

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

只需在第17页顶部的RFC 5322的“域文本”部分中查看允许文本的几个可能包含规则之一，我们就会发现：

此描述中只有三个缺少的字符用于domain-literal [] ，以形成引用对\\和空格字符 （％D32）。 使用它，使用整个范围32-126（十进制）。 类似的要求显示为“qtext”和“ctext”。 许多控制字符也被允许/使用。 一个这样的控制字符列表出现在RFC 5322的第31页4.1节中，作为obs-NO-WS-CTL。

所有这些控制字符都是允许的，如第3.5节开头所述：

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

在我的PHP中，我使用此检查