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

Question

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

Answer 1

因为在过去的好日子里，MIME标准就是这样定义的。 其中一个原因可能是内容长度存在text / plain数据问题，其中换行符可能是CR（旧mac），LF（unix）或CR LF（windows，dos）。另一个可能是人类更容易阅读，这是恕我直言的一个不好的论点，但是当喜欢HTTP，XML或SOAP等文本表示而不是像ASN.1或SUN RPC这样更有效的二进制方式时，会发生很多事情。 / p>

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

Answer 2

  

使用长度解析会更容易

这是你错的地方。多部分MIME的作者考虑了一些情况，您无法事先确定消息部分的长度。考虑改变消息长度的内容编码，例如base64，UUencode等。还有压缩，加密和诸如此类的东西。另外：Content-Length是实体标题。这意味着如果您达到它，您已经开始解析消息部分。它实际上没有优于边界标记的优势。

如果您研究较旧的协议，您将经常遇到一些标记（通常为\0）来指示消息的结束。发送消息的字节数是另一种解决方案，但在消息内容必须即时转换或以某种方式流式传输的地方，您不会发现很多。

底线：多部分边界允许一些有趣的应用程序，其消息内容的大小不可预测。 HTTP server pushing是一个值得注意的例子。