首页 文章

如何为GB /文件大小选择application / x-www-form-urlencoded / multipart / form-data？

提问于
浏览 次
1

我发送一些视频文件（大小甚至可以是GB）作为 application/x-www-form-urlencoded 超过 HTTP POST .

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

  • 哪种编码更适合传输此类数据？

  • 另外如何找到编码数据的长度（用 application/x-www-form-urlencoded 编码的数据）？

  • 编码二进制数据会消耗很多时间吗？

  • 通常，编码会跳过非字母数字字符和其他字符 . 那么，我们可以跳过二进制数据（如视频）的编码吗？我们怎么能跳过它？

http post http-headers url-encoding

1 回答

  • 3

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

    而是通过将数据分成几部分然后找到在所述部分中不发生的任何长度的字符串来工作 .
    这种字符串称为边界，它用于界定部分的末尾，即作为八位字节流传输 .
    因此，该文件主要以发送方式发送，对于足够大的数据，可忽略不计的大小开销 .

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

    • 你应该使用 multipart/form-data .

    • 这取决于您使用的平台，一般情况下，如果您无法访问请求正文，则必须重新执行自我编码 .

    • 对于 multipart/form-data 编码，有一点，通常可以忽略不计（与传输时间相比）开销 .

    回复于

相关问题