☰

邮件附件 EOL（行尾）问题

tag-icon • tag-icon email specifications email-client
邮件附件 EOL（行尾）问题

我正在 Windows XP 上发送一封带有 4 个附件的简单邮件：

  • dummy.txt（行尾：CRLF）
  • dummy.xml（行尾：CRLF）
  • dummyjustlf.txt（行尾：LF）
  • dummyjustlf.xml（行结束：LF）

根据客户的要求，我发送的邮件的行尾进行了更改：

  • 2007年展望：EOL 保持不变
  • 雷鸟 3：dummyjustlf.txt 的 EOL 改为 CRLF，其他保持不变
  • Java 邮件：dummyjustlf.txt 和 dummyjustlf.xml 的 EOL 更改为 CRLF，其他保持不变

这种行为是如何指定的？是否有 RFC 对此进行记录？客户端是否决定如何发送或如何接收带有附件的邮件并按其想要的方式转换 EOL？

答案1

它可能是您正在运行的电子邮件客户端和平台的组合。

理想情况下，附件应该始终保持不变，如果文件是二进制（或放在二进制容器中，例如 .zip）就不会出现问题。

我怀疑发生的情况是客户端应用程序将纯文本消息作为附件插入，并使用“quoted printable”编码，而不是 Base64（二进制文件编码为 Base64）。要检查这一点，您需要在接收电子邮件应用程序中查看原始消息数据：

  • 在 Gmail 中，这是右上角回复按钮旁边菜单中的“显示原始内容”。
  • 在 Thunderbird 中，查看 -> 消息来源
  • Outlook 和 Java 邮件中可能有等效项。

您需要查找以如下标题开头的附件：

--0016e65c71b2a252eb04a3a1f642
Content-Type: text/plain; charset=US-ASCII; name="test.txt"
Content-Disposition: attachment; filename="test.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gnvt3nlf0

如果“Content-Transfer-Encoding”不是“base64”（例如“quoted-printable”），并且您可以看到下面文本文件的文本内容，那么这可能是错误的来源，因为行尾可能在发送消息时由发送应用程序标准化（大多数电子邮件都是以纯文本形式发送的）。

Base64 编码将二进制文件转换为纯文本，发送者可以将其发送，接收者再将其转换为二进制，这样在纯文本驱动的电子邮件世界中就不会出现混乱。这可能是 Outlook 对所有附件所做的，也是 TB 对 .xml 文件所做的。

相关内容