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

时间:2018-08-08 15:05:08

标签: java http multipartform-data resttemplate

标题说明了一切。 我的意思是假设我们正在尝试上传多张图片, 对于每个包含多个部分的部分,我们都会有类似

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

Content-Length足以告诉解析器该内容部分何时结束 然后开始另一部分。 但是我很想念一些东西,你能帮忙吗?

2 个答案:

答案 0 :(得分:2)

  

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

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

每个部分都由其自己的内容标头(零个或多个Content-标头字段)和主体组成。同样重要的是要提到边界定界符一定不能出现在任何封装的部件内部。

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

  

然后,主体必须包含一个或多个主体部分,每个主体部分前面都有边界定界线,最后一个部分后面是封闭的边界定界线。在其边界定界线之后,每个正文部分都包含一个标题区域,一个空白行和一个正文区域。

答案 1 :(得分:1)

Content-Length不是多部分内容的要求。在the old RFC部分中解决了使用长度的问题:

  

5.2其他数据编码而不是多部分

     

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

该文字不在current one中; length根本没有出现。

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

相关问题