如果我尝试使用 Outlook 客户端打开已使用 Notes 客户端存储到 CMS 的邮件,会出现一些奇怪的行为。我发现原因是 EML 中有 =LF。它们似乎每隔 72 个字符出现在文本中,无论此时写入哪种文本,即使在 html 标记内也是如此。
Outlook 会按文件中的原样显示这些字符。无论如何,如果我在 Notes 中打开同一个文件,它会正确显示。
为什么会这样?我在 Outlook 客户端中可以有相同的行为吗?这在 MIME 消息中是否有效?
X-Notes-Item: CN=<infos>; name=OriginalFrom; flags=45
--0__=4EBB0C59DFDCC3088f9e8a93df938690918c4EBB0C59DFDCC308
Content-Transfer-Encoding: quoted-printable
Content-type: text/html; charset=ISO-8859-1
Content-Disposition: inline
<html><body>
<p><font size=3D"2" face=3D"sans-serif">Hallo zusammen,</font><br>
<br>
<font size=3D"2" face=3D"sans-serif">dieses Material ist ersetzt durch =
xxxxxxxx(Info auf der Zeichnung), welches wiederum ersetzt wurde durch =
xxxxxxx.(Info in xxxx)</font><br>
<br>
<font size=3D"2" face=3D"sans-serif">Der Arbeitsplan zu ist xxxxxxxx ka=
lkulierbar.</font><br>
<br>
答案1
我发现了这一点: https://stackoverflow.com/questions/58666402/quoted-printable-line-continuation-bug
它描述了 Outlook 正在通过行尾检查 RFC2045。因此行尾必须是 (CR)(LF),而不仅仅是 (LF)。
答案2
是的,这是 MIMEQuoted-Printable
传输编码的标准部分。您看到的只是一条非常典型的 MIME 消息(根据--etc
边界指示符判断,是多部分消息)的原始源代码。
问题是由于某种原因,Outlook 无法将其识别为 MIME 消息(要么根本没将其视为 MIME 消息,要么不能很好地处理“多部分”位),因此它没有应用每个部分所需的解码。
如果它被存储为纯文本 RFC822 消息(通常在 .eml 文件中,而不是 Outlook 二进制 .msg 中),则使用文本编辑器打开它并确保顶级标题没有混乱;例如,某些系统在标题之间插入空行,或错误地折叠长值。