xml - 将 XML 文件作为附件通过电子邮件发送时对内容传输编码感到困惑

Question

我有一个 UTF-8 编码的 XML 文件，它作为附件通过电子邮件发送。当电子邮件收件人打开电子邮件并保存附件时，XML 文件不再是 UTF-8(而是报告 ANSI 编码)。在这种情况下，收件人使用了 Microsoft Outlook(如果重要的话)。

我在无法依赖合适的 MIME 库的可用性的环境中进行编程，所以我需要了解我哪里出错了。

在通过电子邮件发送 XML 文件之前，在服务器上创建它之后，我可以使用 Linux file 命令看到它是一个 UTF-8 文件。除此之外，XML 还有一个版本头 <?xml version="1.0" encoding="UTF-8"?> (这与我的问题并不真正相关，但为了完整起见，我将其包括在内)。我很确定我通过电子邮件发送文件的代码是这里的问题，但我不确定执行此操作的“正确”方法。

我发送的标题是:

"Mime-Version" "1.0"
"Content-Type" "multipart/mixed; boundary="__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___"\n\n"

电子邮件的正文是:

--__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___\n
Content-Type: text/plain; charset="utf-8"; format=flowed\n
Content-Transfer-Encoding: 7bit\n\n
Please find attached the data file generated 
--__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___\n
Content-Type: text/plain; charset="utf-8"\n
Content-Disposition: attachment; filename="My_File_Name"\n\n
XML FILE CONTENTS GO HERE
--__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___--\n

问题:

我应该使用 quoted-printable , 8bit或其他类型Content-Transfer-Encoding这里？我已经尝试了所有这些，但它
没有改变结果。

是 Content-Type: text/plain XML 附件是否正确？

还有其他建议吗？

Answer 1

通过指定 text/plain您基本上将控制权交给远程客户端的文本处理能力，这在这种特殊情况下显然是有限的。 XML 按照规范是 Unicode，因此通过选择更好的内容类型，您更有可能成功。试试 text/xml或 application/xml相反，甚至是完全不透明的 application/octet-stream ，这应该只允许接收者以字节对字节相同的形式将其保存在磁盘上。
内容传输编码根本不应该影响这种行为，但由于您似乎不清楚其重要性，这里是一个简短的讨论。
内容传输编码是完全透明的；它不会影响交付的内容或远程客户端可以用它做什么。选择哪种内容传输编码取决于数据的性质和需要传输的电子邮件系统的功能。如果它不是 8 位干净的，则需要一个 7 位 CTE 将其封装成。如果内容的行太长而无法放入 SMTP，则需要将其封装为较短的行。但是远程客户端将提取另一端封装内的任何内容。在任何情况下使用。
针对不同情况，内容传输编码具有层次结构:

7bit如果您的数据完全是 7 位 ASCII 并且没有超过大约 990 个字符的行，则适用。然后它甚至可以在未经修改的情况下进行原始的旧 SMTP 传输。在没有任何明确的情况下 Content-Transfer-Encoding: header ，这是根据标准的默认值(尽管您经常看到其中包含 8 位数据的内容，而没有明确的 CTE，甚至没有明确的 7bit 声明)。

8bit放宽了对数据 7 位清洁的要求。如果传输此消息的所有系统都支持 ESMTP 8BITMIME扩展，这对于行长受限的数据应该没问题。

binary另外允许无限的线长。理论上，您应该能够使用它来传递不受限制的内容，但实际上，当系统不严格遵守规范时，这似乎会引发故障。一个典型的症状是过长的线路在运输过程中被截断或折叠，破坏了有效载荷的完整性。为了避免此类问题(并更好地遵守互操作性标准的文字和精神)，您最好采用以下方法之一。

base64接受不受限制的内容，但以一种满足限制行长度和严格限制的 7 位字符库的严格要求的格式对其进行编码。它将有效载荷扩展到原始大小的 4/3 以上。例子:

    ugqcA7R5cPq667vNaSifRUH9HsW00NqZ1gwICk0pNrUkXFpNIFOpbf3o
    5ml8cqqSygkp8KBgPbHrqnDXvZTEBOkNo7ThE+BAvexa75Tm0Ebo/Yjl
    y697pMp1+dnSlk3YTqxkPI9vqpple13dXLHlvnFDmSi0gqIMSwo7kUFD
    SivAWhyCBR6tFO3lY1Pk6lz78+zgL28VthI72kVRkrWWtzoFef/4u5Ip
    GR00CtsNNEJo01GAQGpkTNFT9U9Q/UI9CMGgaI9E9RkMaTDTQICBEyaE
    woSCQOrNGA==

quoted-printable类似地接受任意内容，但将所选字节编码为原始内容的 3 倍。当大部分输入是 ASCII 时，这是一个可以容忍的开销。换句话说，这适用于偶尔有非 ASCII 内容的粗略文本格式，例如使用 8 位编码的许多西方语言中的文本，或者像 HTML 这样的格式，其中 ASCII 标记在实际内容上占主导地位，几乎在任何情况下语。示例:

    <?xml version=3D"1.0" encoding=3D"UTF-8"?>h=C3=ABll=C3=B6 =
    w=C3=B6rld

引用 printable 根本不难实现，并且似乎适合您的场景。
所有这些都编入 MIME RFC 2045到 2048 年。维基百科有很好的可读文章，例如 base64和 quoted-printable .
从您的描述中不清楚您是刚刚将内容声明为可引用打印，还是对其进行了实际编码。我见过人们做前者，当它不起作用时表现出惊讶，但希望你做了后者。只是一个警示故事。