0

一家电子邮件提供商拒绝了一封包含特殊字符（例如变音符号）的电子邮件。他们说它们符合 RFC-5321 和 RFC-5322。现在我浏览了这些标准，但是它们不支持国际电子邮件（因此没有变音符号）。仅支持 ASCII-127。现在有一个名为 RFC-6532 的扩展，用于标准化国际电子邮件。我们的电子邮件采用 UTF-8（可引用打印）编码并发送如下：

"=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?="<boerge.moeller@foo.org>

这是一个符合 RFC-6532 的地址吗？还是其他一些/较旧的 RFC（如 RFC-2054）？毕竟有这么多与邮件相关的 RFC，我可能错过了 10 或 20 个 ;-)

4

1 回答 1

2

它在正确的轨道上，但它是错误的。

"=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?="<boerge.moeller@foo.org>

上面的表格有2个问题：

  1. 编码字（=?UTF-8?Q?...?= 位）被引用，不应该被引用。解析此地址的邮件软件如果符合标准，则不会解码该令牌。
  2. “名称”与尖括号对接，不应如此。为了符合标准，必须有一个空格。

换句话说，它应该是这样的：

=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?= <boerge.moeller@foo.org>

您需要查看的 RFC 是：

  • RFC5322 - 这定义了由您尝试互操作的服务器实现的现代消息语法。
  • RFC2047 - 这定义了编码字的方法和语法，这些字在标头Subject和地址标头中表示非 ASCII 字符（例如，To/From/Cc/Reply-To/etc）。（这是=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?=部分）
  • RFC822 - 这定义了 RFC2047 使用的语法，是 RFC5322 的旧版本。

阅读比 RFC822 新但比 RFC5322 旧的 RFC2822也可能会有所帮助。但是，我的猜测是，您可以跳过它，因为它没有太多价值。RFC822 仍然具有价值的唯一原因是它被 RFC2047 引用的更旧的语法定义（例如, , , , ,等）。atomdot-atomphraseangle-addraddr-spectspecials

RFC6532 甚至比 RFC5322 更新。其目的是通过允许使用 UTF-8 作为替代方案来完全消除对标头进行编码的需要。

在 RFC6532 之前，除了 ASCII（这是 RFC822 使用的）之外，没有用于标头的字符编码标准，因此一切都应该符合 ASCII。

然而，许多软件不遵循标准，因此现实世界中有很多邮件使用 ISO-8859-1 和阳光下的所有其他字符编码，这一切都取决于用户所在的地区（s ) 以及在这些地区广泛使用的字符编码（例如 Big5 和 GB2312 在中国各地流行，Shift-JIS 在日本流行，EUC-KR/KS-C-5601-1987 是在韩国流行等）。

然而，这导致了主要的互操作性问题，不仅因为并非每个邮件客户端都可以处理阳光下的每种字符编码，还因为客户端无法确定甚至使用了哪种字符编码！这一切都只是二进制 gobbeldy-gook。

然而，UTF-8 已经存在了很长时间，它可以表示所有语言的所有字符，因此它最终胜出作为用于国际电子邮件的标准字符编码是合乎逻辑的。

于 2021-11-05T15:24:00.523 回答