IMAP RFC：
通过使用一个支持8位文本和二进制邮件 [MIME-IMB]内容传输编码。 IMAP4rev1实现可以 在文字中传输8位或多位八位字符，但应该这样做 只有在识别出[CHARSET]时才会这样。
虽然定义了BINARY正文编码，但是未编码的二进制编码 字符串是不允许的。 “二进制字符串”是任何字符串 NUL字符。实现必须将二进制数据编码为 在传输数据之前，文本形式，例如BASE64。一个 具有过多CTL字符的字符串也可以是 被认为是二元的。
如果实现必须转换为base64，为什么RFC会说“定义了BINARY主体编码”。由于每次我们需要以base64（或其他某种格式）发送数据，因此不支持二进制文件。或者我读错了什么？
IMAP支持MIME多部分，这里面的部分可以有二进制数据吗？那是content-transfer-encoding？
我是IMAP / HTTP的新手，有人问这个问题的原因是，我必须开发一个支持HTTP和IMAP的服务器，在HTTP服务器中以二进制方式重新接收数据（HUGE多部分数据，内容传输编码作为二进制），FETCH可以在IMAP中完成。问题是，如果IMAP不支持二进制文件，我需要解析数据并将multipart内的每个部分转换为base64。我认为这是严重的性能问题。
答案 0 :(得分：1)
不幸的是答案可能＆＃34;可能＆＃34;。
MIME RFC支持二进制文件，但IMAP RFC明确禁止发送NULL个字符。这很可能是因为它们可能会混淆基于文本的解析器，尤其是那些用C语言编写的解析器，其中NULL具有字符串结尾的含义。
有些IMAP服务器只是认为主体是一个字节包＆＃34;我怀疑很少，如果有的话，实际上重新编码。因此，如果您要求输入整个消息，您可能会得到它的文字内容。
如果您的客户可以处理MIME-Binary，您可能会没事的。
IMAP扩展RFC 3516可以正常支持BINARY，但这种情况并未广泛部署。
作为旁注：您为什么使用Multipart MIME？这是HTTP的一个奇怪的实现选择。