在 HTTP 中有两种 POST 数据的方式:application/x-www-form-urlencoded和multipart/form-data. 我了解大多数浏览器只有在使用时才能上传文件multipart/form-data。在 API 上下文(不涉及浏览器)中使用其中一种编码类型时是否有任何其他指导?这可能例如基于:
application/x-www-form-urlencoded
multipart/form-data
到目前为止,我基本上没有在网上找到关于使用不同内容类型的正式指南。
概括; 如果您有二进制(非字母数字)数据(或相当大的有效载荷)要传输,请使用multipart/form-data. 否则,使用application/x-www-form-urlencoded.
Content-Type您提到的 MIME 类型是用户代理(浏览器)必须支持的 HTTP POST 请求的两个标头。这两种类型的请求的目的都是向服务器发送名称/值对列表。根据所传输数据的类型和数量,其中一种方法将比另一种更有效。要了解原因,您必须查看每个人在幕后所做的事情。
Content-Type
因为application/x-www-form-urlencoded,发送到服务器的 HTTP 消息的主体本质上是一个巨大的查询字符串——名称/值对由 & 号 ( &) 分隔,名称与值由等号 ( =) 分隔。这方面的一个例子是:
&
=
MyVariableOne=ValueOne&MyVariableTwo=ValueTwo
根据规范:
[保留和] 非字母数字字符替换为 `%HH’、一个百分号和两个表示字符 ASCII 码的十六进制数字
这意味着对于我们的一个值中存在的每个非字母数字字节,将需要三个字节来表示它。对于大型二进制文件,将有效负载增加三倍将非常低效。
这就是multipart/form-data进来的地方。使用这种传输名称/值对的方法,每对都表示为 MIME 消息中的“部分”(如其他答案所述)。部分由特定的字符串边界分隔(特别选择以便此边界字符串不会出现在任何“值”有效负载中)。每个部分都有自己的一组 MIME 标头,例如Content-Type,特别是Content-Disposition,它们可以为每个部分提供其“名称”。每个名称/值对的值片段是 MIME 消息每个部分的有效负载。MIME 规范在表示值有效负载时为我们提供了更多选择——我们可以选择更有效的二进制数据编码来节省带宽(例如 base 64 甚至原始二进制)。
Content-Disposition
为什么不multipart/form-data一直使用?对于较短的字母数字值(如大多数 Web 表单),添加所有 MIME 标头的开销将大大超过更有效的二进制编码所节省的成本。