为什么我们需要多部分数据格式的边界？答案

【问题标题】：Why do we need boundaries in multipart data format?为什么我们需要多部分数据格式的边界？
【发布时间】：2018-08-08 15:05:08
【问题描述】：

标题说明了一切。我的意思是假设我们正在尝试上传多张图片，对于每个多部分部分，我们将有像

这样的子标题

Content-Disposition: form-data; name="file"; filename="mia.jpeg"
Content-Type: image/jpeg
Content-Length: 5379

Content-Length 足以告诉解析器此内容部分何时结束并开始另一部分。但我很可能错过了一些东西，你能帮忙吗？

【问题讨论】：

【解决方案1】：

为什么我们需要多部分数据格式的边界？

边界是用于允许服务器将消息拆分为块或正文部分的分隔符。多部分请求可以包含任意数量的正文部分。 multipart/form-data 请求当前在 RFC 7578 中定义。

每个部分都由其自己的内容标头（零个或多个Content- 标头字段）和正文组成。同样重要的是要提到边界分隔符不能出现在任何封装部分内。

另一个相关文档是RFC 2046，它定义了多部分 MIME 数据流：

然后正文必须包含一个或多个正文部分，每个部分前面都有一个边界分隔线，最后一个后面是一个结束边界分隔线。在其边界分隔线之后，每个正文部分由标题区域、空白行和正文区域组成。

【讨论】：

【解决方案2】：

Content-Length 不是多部分内容的要求。这个使用长度的问题在部分the old RFC中得到解决：

5.2 其他数据编码而非多部分

很多人建议使用新的 mime 顶级类型 “聚合”，例如聚合/混合或内容传输编码 “数据包”表示不确定长度的二进制数据，而不是依赖于多部分样式的边界。虽然这将是有用，“多部分”机制已经建立，简单在发送客户端和接收服务器上都实现，并且作为与处理多种组合的其他方法一样有效二进制数据。

不过，该文本不在 current one 中； length 根本没有出现在里面。

如果您认为发送者将流的结果作为多部分帖子的一部分发送，则这特别有意义，而它可能事先不知道该流数据的长度。如果需要长度，则需要缓存或读取两次。

【讨论】：