Content-Type

拼搏现实的明天。 2021-09-18 21:56 394阅读 0赞

Content-Type 存在于请求和响应的头部，用于标识数据的类型。(通俗地说就是 , 你想要后台返回给你什么数据类型, 后台需要你发送什么样的数据类型给他)

1. Response Headers

在响应中，Content-Type 告诉客户端实际返回的内容的类型。比如要通常接口会返回 JSON 格式的数据，那么需要将 Content-Type 设置为 application/json，当然这是接口的事，很多后端框架都会自动处理，不用手动去加这个 Header。

2. Request Headers

在请求中，客户端告诉服务器实际发送的数据类型。这里指的是除 GET 方式以外的请求。常见的取值有：

  • x-www-form-urlencoded
  • multipart/form-data
  • application/json

下面我们就来看看不同的 Content-Type 会有什么区别

x-www-form-urlencoded

这应该是目前最常见的方式。提交的数据按照键值对 key1=val1&key2=val2 的方式进行编码。

比如我们要发送数据

  1. {
  2.   "name": "tom",
  3.   "age": 20
  4. }

会被编码为

  1. name=tom&age=20

常用的 <form> 表单默认就是用的这种方式

  1. <form method="post">
  2. </form>

multipart/form-data

这是另一个常见的数据提交方式，一般用于文件上传。

上面的 <form> 表单提交中其实有一个属性叫 enctype，用来指定编码格式，默认值为 application/x-www-form-urlencoded，还可以选择 multipart/form-data（不对字符编码）

  1. <form enctype="multipart/form-data" method="post">
  2. </form>

application/json

支持比键值对复杂得多的结构化数据。由于 JSON 规范的流行，越来越多的人采用了这种方式，常用的第三方请求库 Axios 默认就是用的 application/json。

前面提到的问题就出现在这里，前端一般用了第三方的请求库，很可能请求头 Content-Type 就直接用的默认值 application/json。然而，服务器端对这种格式的数据默认支持并没有 x-www-form-urlencoded 好。比如 PHP 的很多框架就是不直接支持的，需要手动处理。

所以就导致了前端发送 application/json 编码的数据，而后端却只能解析 x-www-form-urlencoded 。

发表评论

表情：
评论列表 （有 0 条评论，394人围观）

还没有评论，来说两句吧...

相关阅读