application/x-www-form-urlencoded 还是 multipart/form-data? [英] application/x-www-form-urlencoded or multipart/form-data?

问题描述

在 HTTP 中有两种 POST 数据的方式:application/x-www-form-urlencoded 和 multipart/form-data.我知道大多数浏览器只能在使用 multipart/form-data 时上传文件.何时在 API 上下文中使用其中一种编码类型(不涉及浏览器)是否有任何其他指导?这可能例如基于:

In HTTP there are two ways to POST data: application/x-www-form-urlencoded and multipart/form-data. I understand that most browsers are only able to upload files if multipart/form-data is used. Is there any additional guidance when to use one of the encoding types in an API context (no browser involved)? This might e.g. be based on:

• 数据大小
• 存在非 ASCII 字符
• 存在于(未编码的)二进制数据上
• 需要传输额外的数据(如文件名)

到目前为止，我基本上没有在网络上找到有关使用不同内容类型的正式指南.

I basically found no formal guidance on the web regarding the use of the different content-types so far.

推荐答案

TL;DR

总结；如果您有二进制(非字母数字)数据(或非常大的有效载荷)要传输，请使用 multipart/form-data.否则，请使用 application/x-www-form-urlencoded.

Summary; if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded.

您提到的 MIME 类型是用户代理(浏览器)必须支持的 HTTP POST 请求的两个 Content-Type 标头.这两种类型的请求的目的都是将名称/值对列表发送到服务器.根据传输的数据类型和数量，其中一种方法会比另一种更有效.要了解原因，您必须查看每个人在幕后做了什么.

The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value pairs to the server. Depending on the type and amount of data being transmitted, one of the methods will be more efficient than the other. To understand why, you have to look at what each is doing under the covers.

对于application/x-www-form-urlencoded，发送到服务器的HTTP消息的正文本质上是一个巨大的查询字符串——名称/值对由与号(&)，名称与值之间用等号 (=) 分隔.一个例子是: 

For application/x-www-form-urlencoded, the body of the HTTP message sent to the server is essentially one giant query string -- name/value pairs are separated by the ampersand (&), and names are separated from values by the equals symbol (=). An example of this would be: 

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

根据规范:

[保留和]非字母数字字符替换为'%HH'，一个百分号和两个代表字符ASCII码的十六进制数字

[Reserved and] non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character

这意味着对于存在于我们的值之一中的每个非字母数字字节，它将需要三个字节来表示它.对于大型二进制文件，将有效负载增加三倍将非常低效.

That means that for each non-alphanumeric byte that exists in one of our values, it's going to take three bytes to represent it. For large binary files, tripling the payload is going to be highly inefficient.

这就是 multipart/form-data 的用武之地.使用这种传输名称/值对的方法，每一对都表示为 MIME 消息中的部分"(如其他答案所述).部分由特定的字符串边界分隔(专门选择以便此边界字符串不会出现在任何值"有效负载中).每个部分都有自己的一组 MIME 标头，例如 Content-Type，尤其是 Content-Disposition，它可以为每个部分提供名称".每个名称/值对的值部分是 MIME 消息每个部分的有效负载.MIME 规范在表示值有效负载时为我们提供了更多选择——我们可以选择更有效的二进制数据编码以节省带宽(例如 base 64 甚至原始二进制).

That's where multipart/form-data comes in. With this method of transmitting name/value pairs, each pair is represented as a "part" in a MIME message (as described by other answers). Parts are separated by a particular string boundary (chosen specifically so that this boundary string does not occur in any of the "value" payloads). Each part has its own set of MIME headers like Content-Type, and particularly Content-Disposition, which can give each part its "name." The value piece of each name/value pair is the payload of each part of the MIME message. The MIME spec gives us more options when representing the value payload -- we can choose a more efficient encoding of binary data to save bandwidth (e.g. base 64 or even raw binary).

为什么不一直使用multipart/form-data?对于短字母数字值(如大多数网络表单)，添加所有 MIME 标头的开销将大大超过更高效的二进制编码所节省的开销.

Why not use multipart/form-data all the time? For short alphanumeric values (like most web forms), the overhead of adding all of the MIME headers is going to significantly outweigh any savings from more efficient binary encoding.

这篇关于application/x-www-form-urlencoded 还是 multipart/form-data?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！