应用程序/x-www-表单-urlencode还是多部分/表单-数据？

Question

应用程序/x-www-表单-urlencode还是多部分/表单-数据？在HTTP中，有两种发布数据的方法：application/x-www-form-urlencoded和multipart/form-data..据我所知，大多数浏览器只能在以下情况下才能上传文件multipart/form-data被利用了。在API上下文中使用其中一种编码类型(不涉及浏览器)时，是否有其他指导？例如，这可能是基于：数据大小非ASCII字符的存在性(未编码的)二进制数据的存在需要传输其他数据(如文件名)到目前为止，我基本上没有在网络上找到关于使用不同内容类型的正式指南。

Answer 1

TL；DR

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

---

你提到的哑剧类型有两种Content-Type用户代理(浏览器)必须支持的HTTPPOST请求的头。这两种类型请求的目的是向服务器发送名称/值对的列表。根据所传输数据的类型和数量，其中一种方法比另一种方法更有效。要理解其中的原因，你必须看看每个人都在做些什么。

为application/x-www-form-urlencoded，发送给服务器的HTTP消息的主体本质上是一个巨大的查询字符串-名称/值对由符号和(&)，并且名称与值由相等符号(=)。这方面的一个例子是：

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

根据规格:

[保留和]非字母数字字符替换为‘%hh’，一个百分比符号和两个十六进制数字，表示字符的ASCII代码。

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

在那里multipart/form-data进来。使用这种传递名称/值对的方法，每对都表示为MIME消息中的“部件”(如其他答案所述)。各个部分由一个特定的字符串边界分隔(特别选择这个边界字符串，使这个边界字符串不会出现在任何“值”有效载荷中)。每个部分都有自己的一组MIME标头，如下所示Content-Type，特别是Content-Disposition，它可以赋予每个部分“名称”。每个名称/值对的值段是MIME消息的每个部分的有效负载。MIME规范在表示值有效负载时给了我们更多的选择-我们可以选择更有效的二进制数据编码来节省带宽(例如，基本64甚至原始二进制)。

为什么不使用multipart/form-data一直?简而言之，字母数字值(和大多数Web表单一样)，添加所有MIME头的开销将大大超过更有效的二进制编码节省的费用。

Answer 2

至少在这里读第一段！

我知道这已经晚了3年了，但马特(接受)的答案是不完整的，最终会给你带来麻烦。这里的关键是，如果你选择使用multipart/form-data，边界必须不显示在服务器最终接收的文件数据中。

这不是问题application/x-www-form-urlencoded因为没有边界。x-www-form-urlencoded也可以随时处理二进制数据，通过简单的权宜之计将一个任意字节转换为三个。7BIT字节。效率低下，但它有效(请注意，关于不能发送文件名和二进制数据的注释是不正确的；您只需将其作为另一个键/值对发送)。

与.有关的问题multipart/form-data边界分隔符不能出现在文件数据中(请参见RFC 2388第5.2节还包括一个相当站不住脚的借口，认为没有适当的聚合MIME类型可以避免这个问题)。

所以，乍一看，multipart/form-data毫无价值任何文件上传，二进制或其他。如果你没有正确选择你的边界，那么你将要最终会出现问题，无论您是发送纯文本还是原始二进制文件-服务器将在错误的位置找到一个边界，您的文件将被截断，或者POST将失败。

关键是选择编码和边界，以便所选边界字符不能出现在编码输出中。一个简单的解决方案是使用base64(做不使用原始二进制)。在……里面基准643个任意字节被编码为4个7位字符，其中输出字符集为[A-Za-z0-9+/=](即字母数字、‘+’、‘/’或‘=’)。=是一种特例，并且只能在编码输出的末尾以单一形式出现。=或者双份==..现在，选择您的边界作为一个7位的ASCII字符串，它不能出现在base64输出。您在网络上看到的许多选择都失败了-mdn表单。博士例如，在发送二进制数据时，使用“BLOB”作为边界-这不太好。然而，就像“！BLOB！”永远不会出现在base64输出。