以 GB 为单位的文件大小选择 application/x-www-form-urlencoded / multipart/form-data 什么？答案

【问题标题】：What to chose application/x-www-form-urlencoded / multipart/form-data for file size in GB?以 GB 为单位的文件大小选择 application/x-www-form-urlencoded / multipart/form-data 什么？
【发布时间】：2017-01-24 08:28:03
【问题描述】：

我以application/x-www-form-urlencodedover HTTP POST 发送一些视频文件（大小甚至可以以GB 为单位）。

以下链接 link 建议，当我们有非字母数字内容时，最好通过 Multipart 表单数据传输它。

哪种编码方式更适合传输此类数据？
另外我怎样才能找到编码数据的长度（用application/x-www-form-urlencoded编码的数据）？
对二进制数据进行编码会耗费很多时间吗？
通常，编码会跳过非字母数字字符和其他一些字符。那么，我们可以跳过二进制数据（如视频）的编码吗？我们如何跳过它？

【问题讨论】：

标签： http post http-headers url-encoding

【解决方案1】：

x-www-form-urlencoded 将表单数据集中条目的值视为字节序列（八位字节）。
在可能的 256 个值中，只有 66 个保留原样或仍编码为单字节值，其他的被替换为其代码点值的十六进制表示。这通常需要三到五个字节，具体取决于编码。
因此，平均 (256-66)/256 或 74% 的文件将被编码为占用原始空间的三到五倍。然而，这种编码没有标头，也没有显着的开销。

multipart/form-data 的工作原理是将数据分成几部分，然后找到该部分中不存在的任意长度的字符串。
这样的字符串称为boundary，它用于分隔部分的结尾，即作为八位字节流传输。
所以文件主要是按原样发送的，对于足够大的数据来说，大小开销可以忽略不计。

缺点是用户代理需要找到一个合适的边界，但是给定长度为 k 的字符串只有 2^-8k 的概率在统一生成的二进制文件中查找该字符串。
因此，用户代理可以简单地生成一个随机字符串并进行快速搜索，并利用网络传输时间来隐藏搜索的延迟。

你应该使用multipart/form-data。
这取决于您使用的平台，一般来说，如果您无法访问请求正文，您必须自己重新执行编码。
multipart/form-data 编码有一点，通常可以忽略不计（与传输时间相比）开销。

【讨论】：

在multipart/form-data 中不会。