HTTP 协议是以 ASCII 码传输，建立在 TCP/IP 协议之上的应用层规范。规范把 HTTP 请求分为三个部分：状态行、请求头、消息主体。 协议规定，POST 提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式。服务端通常是根据请求头（headers）中的 Content-Type 字段来获知请求中的消息主体是用何种方式编码，再对主体进行解析。所以说到 POST 提交数据方案，包含了 Content-Type 和消息主体编码方式两部分 。
application/x-www-form-urlencoded
application/x-www-form-urlencoded：是最常见的 POST 提交数据的方式，浏览器的原生表单如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据，它是未指定属性时的默认值。 数据发送过程中会对数据进行序列化处理，以键值对形式?key1=value1&key2=value2的方式发送到服务器。 数据被编码成以 '&' 分隔的键-值对, 同时以 '=' 分隔键和值。非字母或数字的字符会被 percent-encoding。在axios中当请求参数为qs.stringify(data)时，会以此方式提交数据。后台如果使用对象接收的话,可以自动封装成对象。
- 优势: 所有浏览器都兼容。
- 问题：在数据结构及其复杂时，服务端数据解析变得很难
application/json
随着 json 规范的越来越流行，并且对浏览器支持程度原来越好，许多开发人员在请求头中加入 content-type: application/json ，这样做可以方便的提交复杂的结构化数据，这样特别适合restful接口。它告诉服务器请求的主体内容是 json 格式的字符串，服务器端会对json字符串进行解析，json 格式要支持比键值对复杂得多的结构化数据。这种方式的好处就是前端人员不需要关心数据结构的复杂度，只需要标准的json格式就能提交成功。当在 axios 中请求参数为普通对象时，POST 请求默认发送的是 application/json 格式的数据。 application/json 需要封装成对象的话，可以加上 @RequestBody 进行注解。
- 优势：是前端不需要关心数据结构的复杂度，后端解析方便。
- 问题：少数浏览器不兼容。
举例：向服务器发送数据
如果头的格式是application/x-www-form-urlencoded, 则ajax.send("a='a'&b='b'");
如果头的格式是application/json, 则ajax.send(JSON.stringify(data));
补充：Content-Type 值除了上述两种还有，multipart/form-data和text/plain方式
- multipart/form-data： 主要用于文件上传，将文件转成二进制数据进行传输，不涉及转码。
- text/plain： 是使用纯文本进行传输，平时用的很少