0

让我们以这个主题行为例，

$ echo -n 台電用戶意見電子信箱-信件受 | base64
5Y+w6Zu755So5oi25oSP6KaL6Zu75a2Q5L+h566xLeS/oeS7tuWPlw==

它（连同“主题：”等）在编码时超出了限制。所以，一些邮寄者（某电力公司的）首先对其进行编码，然后将其拆分：

Subject: =?utf-8?B?5Y+w6Zu755So5oi25oSP6KaL6Zu75a2Q5L+h566xLeS/oeS7?=
 =?utf-8?B?tuWPl+eQhumAmuefpQ==?=

（但这可能很容易“破坏”一个 UTF-8 多字节字符。）

其他邮件程序（例如 Gnus）首先将其拆分，然后对其进行编码：

Subject: =?utf-8?B?5Y+w6Zu755So5oi25oSP6KaL6Zu75a2Q5L+h566xLeS/oeS7tg==?=
 =?utf-8?B?5Y+X55CG6YCa55+l?=

后者保证在今天的所有邮件阅读器中都能正确呈现。

我的问题是，某些邮件阅读器（例如，Gmail android 应用程序）被前者阻塞，谁的错？

邮件阅读器是否应该总是先将两个字符串粘贴在一起，然后再解码？（所以 Gmail 应用程序是错误的。）

还是先解码，然后将两个解码的字符串粘贴在一起也可以。（所以邮件程序是错的？）

（我认为 Quoted Printable 也会出现同样的问题，不仅仅是 Base64。）

损坏的 UTF-8

事实上，如果你仔细想想，Saying=?utf-8?B?...?=意味着...东西应该是一个有效的 UTF-8 字符串，（就其本身而言）对吧？所以邮件程序是错误的！

同样，可能从来没有定义过如何拆分=?utf-8?B?...?=成两个短语的语法，因为这应该事先处理好，因为创建=?utf-8?B?...?=字符串应该始终是最后一步。

所以：Mailer 软件：有罪。Gmail：无罪。

2021/09/01：这里我分析一下Subject的第一行

4

2 回答 2

1

根据RFC 2047 § 8的示例（和整体解释），编码词不会神奇地跨越多个实例：

  • =?UTF-8?Q?a?=既不能继续前一个编码字，也不能继续后面的编码字 - 它就是，它是什么：a.
  • 当我们混合文本编码时更明显：应该=?UTF-8?Q?a?= =?ISO-8859-1?Q?b?=渲染为ab.

作为逻辑结果，UTF-8 应该按字符而不是字节来分割。这意味着：不应剪切编码 B（Base64）和 Q（引用）（除非剪切巧合地也在编码文本的字符之间）-剪切必须发生在之前。

我只能猜测这对于一些程序员来说“太复杂了”，他们只是认为“它不会破坏任何东西——到目前为止没有人抱怨”。但是，如果必须剪切一个编码字，正确的方法是首先对其进行解码，以便可以按字符（而不是按字节）剪切文本，然后再次对这两个部分进行编码。一个警告是：谁也必须支持上述文本编码 - 虽然 UTF-8 今天很普遍，但软件是否也知道在哪里剪切Shift-JIS和Big5和UTF-16BE？

于 2020-12-30T01:11:08.987 回答
0

您所拥有的是RFC 2047encoded word中定义的语法。您可以混合未编码的标记和各种编码，因此每个编码的单词本身应该是有效的。先解码，然后组合看起来是正确的方法。

阅读 RFC，其中一些注释和示例与您的案例相关。

当然，RFC 介绍中的注释“虽然很不幸……”告诉您，整个领域总是一团糟。

于 2020-12-30T00:58:35.520 回答