我有一个关于这些协议设计的问题。为什么我们使用边界来分隔多部分消息的各个部分，而不是为每个部分引入内容长度？使用长度解析会更容易。我是否遗漏了使用边界而不是长度参数的一些主要原因？谢谢
使用长度解析会更容易
这就是你错的地方。多部分MIME的作者考虑到了无法预先确定消息部分长度的情况。想想改变消息长度的内容编码，比如base64、UUencode和其他。还有压缩、加密等等。另外：Content-Length是实体标头。这意味着，如果您到达它，就已经开始解析消息部分。与边界标记相比，它几乎没有任何优势。
如果你研究旧的协议，你经常会遇到一些标记(通常是 )来指示消息的结束。发送消息的字节数是另一种解决方案，但在必须动态转换消息内容或以某种方式进行流式传输的地方，您不会发现太多这种方法。
一句话：多部分边界允许一些有趣的应用程序使用不可预测大小的消息内容。HTTP服务器推送就是一个显著的例子。
因为在过去，MIME标准是这样定义的。其中一个原因可能是内容长度与文本/纯文本数据有关，其中换行符可能是CR(旧mac)、LF(unix)或CR LF(windows、dos)。另一种可能是人类更容易阅读，这是IMHO的一个糟糕论点，但当人们更喜欢HTTP、XML或SOAP等文本表示，而不是ASN.1或SUNRPC等更有效的二进制方式时，这种情况会发生很多。
您也可以将其视为行业通过在协议中引入无用的开销来销售更强大服务器的成功尝试：)
除了DaSourcerer在回答中所说的之外，我想指出的是，人们不知道内容长度的原因有很多。在一条评论中，最引人注目的一条已经被命名为：流媒体
停止思考"文件大小"；或者甚至"；文件"；伙计们！当构造MIME多部分时，创建者甚至可能不读取文件，而是读取输入流，或者她可能逐行从依赖于平台的读取器读取，这再次引入了LF与CRLF的问题。流可能太大了，效率很低，甚至不可能在再次写入之前完全读取它，只是为了确定它的大小。
最后但同样重要的是，RFC 1341规定了一个多部分实体可以有一个前导(第一个边界之前的东西)和一个尾声(最后一个边界之后的东西)。报价：
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple
boundary"
This is the preamble. It is to be ignored, though it
is a handy place for mail composers to include an
explanatory note to non-MIME compliant readers.
--simple boundary
This is implicitly typed plain ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text.
It DOES end with a linebreak.
--simple boundary--
This is the epilogue. It is also to be ignored.