Http/Smtp MIME 多部分。为什么要有边界？

Question

我对这些协议的设计有疑问。为什么我们使用边界来分隔多部分消息的各个部分，而不是为每个部分引入内容长度？使用长度解析会更容易。我是否错过了使用边界而不是长度参数的一些主要原因？谢谢！

Answer 1

使用长度解析会更容易

这就是你错的地方。多部分 MIME 的作者考虑到了无法预先确定消息部分长度的情况。考虑改变消息长度的内容编码，例如 base64、UUencode 等。还有压缩、加密等等。另外：

Content-Length

是实体标题。这意味着如果您到达它，您就已经开始解析消息部分。它与边界标记相比实际上没有任何优势。

如果您研究较旧的协议，您经常会遇到一些标记（通常是

\0

）来指示消息的结束。发送消息的字节数是另一种解决方案，但在消息内容必须即时转换或以某种方式流式传输的地方，您不会发现它很多。

底线：多部分边界允许一些有趣的应用程序具有不可预测大小的消息内容。 HTTP 服务器推送 是一个值得注意的例子。

Answer 2

因为在过去，MIME 标准是这样定义的。 原因之一可能是内容长度对文本/纯数据有问题，其中换行符可能是 CR（旧的 mac）、LF（unix）或 CR LF（windows、dos）。另一个可能是人类更容易阅读，恕我直言，这是一个糟糕的论点，但当更喜欢 HTTP、XML 或 SOAP 等文本表示而不是 ASN.1 或 SUN RPC 等更有效的二进制方式时，这种情况经常发生。

您也可能将其视为业界通过在协议中引入无用的开销来销售更强大的服务器的成功尝试:)