包含特殊字符的电子邮件被拒绝 - RFC-6532 和 "quoted-printable"
Email with special characters rejected - RFC-6532 and "quoted-printable"
一个电子邮件提供商拒绝了一封包含特殊字符（例如元音变音）的电子邮件。他们说他们符合 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 标准的地址吗？还是一些 other/older RFC（如 RFC-2054）？毕竟有太多与邮件相关的 RFC，我可能错过了 10 或 20 个 ;-)
方向是对的，但是错了
"=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?="<boerge.moeller@foo.org>
上面的表格有2个问题：
- encoded-word（=?UTF-8?Q?...?= 位）被引用但不应该被引用。解析此地址的邮件软件不会解码该令牌，如果它们是 standards-compliant。
- “名称”靠在尖括号上，不应该。必须有 space 才能符合标准。
换句话说，这就是它应该的样子：
=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?= <boerge.moeller@foo.org>
您需要查看的 RFC 是：
- RFC5322 - 这定义了由您尝试与之互操作的服务器实现的现代消息语法。
- RFC2047 - 这定义了在 headers 中表示 non-ASCII 字符所需的 encoded-word 的方法和语法，例如
Subject 和地址headers（例如 To/From/Cc/Reply-To/etc）。 （这是 =?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?= 部分）
- RFC822 - 这定义了 RFC2047 使用的语法，是 RFC5322 的旧版本。
阅读比 RFC822 新但比 RFC5322 旧的 RFC2822 可能 也有帮助。但是，我的猜测是您可以跳过它，因为它没有太多价值。 RFC822 仍然有价值的唯一原因是因为它的更旧的语法定义被 RFC2047 引用（例如 atom、dot-atom、phrase、angle-addr、addr-spec、tspecials、等等）。
RFC6532 比 RFC5322 还要新。其目的是通过允许使用 UTF-8 作为替代方案来完全消除对 headers 进行编码的需要。
在 RFC6532 之前，除了 ASCII（这是 RFC822 使用的）之外，没有用于 headers 的字符编码标准，所以一切都是 假设符合 ASCII。
然而，很多软件并不遵循标准，因此现实世界中有很多邮件使用 ISO-8859-1 和阳光下的所有其他字符编码，这取决于什么用户所在的地区以及这些地区广泛使用的字符编码（例如 Big5 和 GB2312 在中国各地流行，Shift-JIS 在日本流行，EUC-KR/KS-C-5601-1987在韩国等地很受欢迎）。
这导致了重大的互操作性问题，尤其是因为并非每个邮件客户端都可以处理所有字符编码，而且还因为客户端无法确定正在处理的是哪种字符编码用过的！这只是二进制 gobbeldy-gook.
然而，UTF-8 已经存在了很长时间，可以 表示所有语言的所有字符，所以它最终胜出是合乎逻辑的用于国际电子邮件的标准字符编码。
一个电子邮件提供商拒绝了一封包含特殊字符（例如元音变音）的电子邮件。他们说他们符合 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 标准的地址吗？还是一些 other/older RFC（如 RFC-2054）？毕竟有太多与邮件相关的 RFC，我可能错过了 10 或 20 个 ;-)
方向是对的，但是错了
"=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?="<boerge.moeller@foo.org>
上面的表格有2个问题：
- encoded-word（=?UTF-8?Q?...?= 位）被引用但不应该被引用。解析此地址的邮件软件不会解码该令牌，如果它们是 standards-compliant。
- “名称”靠在尖括号上，不应该。必须有 space 才能符合标准。
换句话说，这就是它应该的样子：
=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?= <boerge.moeller@foo.org>
您需要查看的 RFC 是：
- RFC5322 - 这定义了由您尝试与之互操作的服务器实现的现代消息语法。
- RFC2047 - 这定义了在 headers 中表示 non-ASCII 字符所需的 encoded-word 的方法和语法，例如
Subject和地址headers（例如 To/From/Cc/Reply-To/etc）。 （这是=?UTF-8?Q?B=C3=B6rge_M=C3=B6ller?=部分） - RFC822 - 这定义了 RFC2047 使用的语法，是 RFC5322 的旧版本。
阅读比 RFC822 新但比 RFC5322 旧的 RFC2822 可能 也有帮助。但是，我的猜测是您可以跳过它，因为它没有太多价值。 RFC822 仍然有价值的唯一原因是因为它的更旧的语法定义被 RFC2047 引用（例如 atom、dot-atom、phrase、angle-addr、addr-spec、tspecials、等等）。
RFC6532 比 RFC5322 还要新。其目的是通过允许使用 UTF-8 作为替代方案来完全消除对 headers 进行编码的需要。
在 RFC6532 之前，除了 ASCII（这是 RFC822 使用的）之外，没有用于 headers 的字符编码标准，所以一切都是 假设符合 ASCII。
然而，很多软件并不遵循标准，因此现实世界中有很多邮件使用 ISO-8859-1 和阳光下的所有其他字符编码，这取决于什么用户所在的地区以及这些地区广泛使用的字符编码（例如 Big5 和 GB2312 在中国各地流行，Shift-JIS 在日本流行，EUC-KR/KS-C-5601-1987在韩国等地很受欢迎）。
这导致了重大的互操作性问题，尤其是因为并非每个邮件客户端都可以处理所有字符编码，而且还因为客户端无法确定正在处理的是哪种字符编码用过的！这只是二进制 gobbeldy-gook.
然而，UTF-8 已经存在了很长时间，可以 表示所有语言的所有字符，所以它最终胜出是合乎逻辑的用于国际电子邮件的标准字符编码。