IMAP 协议是否支持多部分正文中的二进制文件？

Question

IMAP RFC：

通过使用 a
支持 8 位文本和二进制邮件 [MIME-IMB] 内容传输编码。 IMAP4rev1 实施可能
以文字形式传输 8 位或多字节字符，但应该这样做
所以只有当 [CHARSET] 被识别时。

虽然定义了 BINARY 正文编码，但未编码的二进制 不允许使用字符串。 “二进制字符串”是任何带有 NUL 字符。实现必须将二进制数据编码为 传输数据之前的文本形式，例如 BASE64。一种 具有过多 CTL 字符的字符串也可能是 被认为是二进制的。

1. 如果实现必须转换为 base64，为什么 RFC 会说“定义了 BINARY 正文编码”。由于每次我们需要以 base64（或其他格式）发送数据时，不支持有效的二进制。还是我读错了什么？

2. IMAP 支持 MIME 多部分，这里面的部分可以有二进制数据吗？那是内容传输编码？

我是 IMAP/HTTP 的新手，问这个问题的原因是，我必须开发一个支持 HTTP 和 IMAP 的服务器，在 HTTP 服务器中接收二进制数据（巨大的多部分数据，带有内容传输编码作为二进制文件），FETCH 可以在 IMAP 中完成。问题是如果 IMAP 不支持二进制，我需要解析数据并将 multipart 中的每个部分转换为 base64。我认为这是严重的性能问题。

Answer 1

不幸的是，答案是“也许”。

MIME RFC 支持二进制，但 IMAP RFC 特别禁止发送NULL 字符。这可能是因为它们可能会混淆基于文本的解析器，尤其是那些用 C 编写的解析器，其中 NULL 具有字符串结尾的含义。

一些 IMAP 服务器只是将正文视为“字节袋”，我怀疑很少有（如果有的话）实际上进行重新编码。因此，如果您询问整个消息，您可能会得到它的字面内容。

如果您的客户可以处理 MIME-Binary，您可能会没事的。

有 RFC 3516 用于 IMAP 扩展以正确支持 BINARY，但这并未广泛部署。

附带说明：您为什么使用 Multipart MIME？对于 HTTP，这是一个奇怪的实现选择。