Fatal编程技术网
  • email/
  • Email 电子邮件地址是否可以包含国际（非英语）字符？

Email 电子邮件地址是否可以包含国际（非英语）字符？

email internationalization

Email 电子邮件地址是否可以包含国际（非英语）字符？,email,internationalization,non-english,Email,Internationalization,Non English,如果可能的话，我是否应该接受来自用户的此类电子邮件，以及当我将邮件发送到此类地址时会遇到什么问题？官方消息，per-是 要快速解释，请查看主题。还没有。IEEE计划这样做： ，这是 引自H-Online（正如它所言）： 互联网工程任务组（IETF）发布了三份重要文件，用于电子邮件地址头的标准化 包含ASCII字符集之外的符号的。这意味着 很快你就可以使用汉字、法语口音和英语了 德语umlauts在电子邮件地址和正文中都有 消息所以如果你的名字是Zoë，你在一家制造 你可能对一个新的电子邮件地址感

如果可能的话，我是否应该接受来自用户的此类电子邮件，以及当我将邮件发送到此类地址时会遇到什么问题？

官方消息，per-是

要快速解释，请查看主题。

还没有。IEEE计划这样做： ，这是

引自H-Online（正如它所言）：

互联网工程任务组（IETF）发布了三份重要文件，用于电子邮件地址头的标准化 包含ASCII字符集之外的符号的。这意味着 很快你就可以使用汉字、法语口音和英语了 德语umlauts在电子邮件地址和正文中都有 消息所以如果你的名字是Zoë，你在一家制造 你可能对一个新的电子邮件地址感兴趣。但是 供应商的代表已经开始抱怨了。他们说会有 如果要使用Unicode标准UTF-8，则需要“升级狂热” 替换美国信息交换标准代码（ASCII） 当前用作通用电子邮件语言

RFC 5335规定在几乎所有电子邮件头中使用UTF-8。 必须对SMTP客户端、SMTP服务器和邮件用户进行更改 代理（MUA）、邮件列表软件、其他媒体网关、， 以及处理或传递电子邮件的任何其他地方。RFC 5336 展开SMTP电子邮件传输协议。在国家一级 协议，扩展名为UTF8SMTP

新的标题字段将作为“紧急降落伞”添加到 确保UTF-8电子邮件在被丢弃时具有软着陆功能 在通过尚未升级的系统到达收件人之前。 “OldAddress”是一个纯ASCII地址。但旧地址不是 用作第二次传输尝试的通道，但用于 确保将反馈发送回家

最后，RFC5337确保发送有关以下内容的正确消息： 非ASCII电子邮件的传递状态。电话号码的正确地址 无法联系到的收件人必须发回，即使有进一步的传输 他被拒绝了。电子邮件地址国际化（EAI）正在工作 该小组还正在研究一系列的“降级机制” 各种标题字段和信封。如果可能，请选择原始页眉 信息要“打包”并保存

尽管如此，德国的DeNIC，“.de”域名的注册人仍然是 泰然处之。“我们真的无能为力”， 丹尼克发言人克劳斯·赫齐格解释道。丹尼克正在付钱 更多关注IETF正在为 国际域名标准–RFC3490或IDNA2003 有时是已知的。“我们对此不太高兴，因为没有 向后兼容性，”Herzig解释道。当更新到来时， DeNIC表示，它也将全力支持“ß”这个符号 被称为estzett-到目前为止一直被忽视。德国人 登记员还说，它可能会等待一点，然后再切换到光 缺乏向后兼容性。一旦新标准出台 运行稳定，注册商和提供商已经采用了它 将添加

相比之下，专家认为中国注册商在中国和 台湾将迅速实施国际化电子邮件的变革。 CNIC和TWNIC的代表是标准的作者。 目前，中国用户必须用ASCII码在页面左侧书写电子邮件 中文的@和右边的中文字符 已经国际化的域

（莫妮卡·埃尔默特）

我假设是的，因为许多顶级域已经允许非ascii 域的字符，由于域是电子邮件地址的一部分，因此 完全可能。这类领域的一个例子是www.öko.de

简短回答：是

不仅用户名允许，域名也允许

问题在于，某些邮件客户端（服务器工具和/或桌面工具）不支持此功能，例如，当您尝试将邮件发送到包含umlauts的地址时，会引发“无效电子邮件”异常

如果你想要完全的支持，你可以把电子邮件地址部分转换成“punycode”。这允许用户以通常的方式键入地址，但您可以以支持的级别方式保存地址

示例：müller.com»xn--mller-kva.com

两者都指向同一事物。

答案是肯定的，但它们需要专门编码

。阅读有关电子邮件标题和RFC 2047的部分。

2015年更新：使用

该实验已被淘汰：和
此选项后来被设置为“类别：标准轨道”
使之成为标准

（语法扩展到）已将大多数文本字段更新为
包括（适当的）UTF-8。

The following rules extend the ABNF syntax defined in [RFC5322] and
[RFC5234] in order to allow UTF-8 content.

VCHAR   =/  UTF8-non-ascii
ctext   =/  UTF8-non-ascii
atext   =/  UTF8-non-ascii
qtext   =/  UTF8-non-ascii
text    =/  UTF8-non-ascii
             ; note that this upgrades the body to UTF-8
dtext   =/  UTF8-non-ascii

The preceding changes mean that the following constructs now
allow UTF-8:
   1.  Unstructured text, used in header fields like
       "Subject:" or "Content-description:".
   2.  Any construct that uses atoms, including but not limited
       to the local parts of addresses and Message-IDs. This
       includes addresses in the "for" clauses of "Received:"
       header fields.
   3.  Quoted strings.
   4.  Domains.

Note that header field names are not on this list; these are still
restricted to ASCII.
请注意明确包含的域。
以及明确排除标题名称。

另请注意：

然后开始：

令人遗憾的是，这个问题又被问到了，新的问题获得了更多的选票，但是那里的所有信息都比这里的信息更过时。我希望我能在这里给出所有答案+5或其他什么。由于“H”关闭，这个链接现在已经失效了？另外，请查看更多详细信息。当然，请在下面的帖子中进一步查看@BinaryZebra的评论。RFC-5335现已过时。其继任者RFC-6532是当前的标准（不再是实验性的）。您知道哪些邮件交换器/域已经允许在电子邮件地址的本地部分使用UMLAUT吗？您知道哪些邮件交换器/域已经允许在电子邮件地址的本地部分使用UMLAUT吗？ 
The UTF-8 NFKC normalization form SHOULD NOT be used because
it may lose information that is needed to correctly spell
some names in some unusual circumstances.

Also note that messages in this format require the use of the
SMTPUTF8 extension [RFC6531] to be transferred via SMTP.