站长点评：各位徒弟，请务必掌握 POST 提交数据的方式。

HTTP/1.1 协议规定的 HTTP 请求方法有 OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT 这几种。其中 POST 一般用来向服务端提交数据，应用最为广泛，所以本文主要讨论 POST 提交数据的几种方式。

我们知道，HTTP 协议是以 ASCII 码传输，建立在 TCP/IP 协议之上的应用层规范。规范把 HTTP 请求分为三个部分：请求行、请求头、消息主体。类似于下面这样：

<method> <request-URL> <version>
<headers>

<entity-body>

协议规定 POST 提交的数据必须放在消息主体（entity-body）中，但协议并没有规定数据必须使用什么编码方式。实际上，开发者完全可以自主决定消息主体的格式，只要最后发送的 HTTP 请求满足上面的格式就可以。

数据发送出去之后，还要服务端解析成功才有意义。一般服务端语言如 java、python 等都内置了自动解析常见数据格式的功能。服务端通常是根据请求头（headers）中的 Content-Type 字段来获知请求中的消息主体是用何种方式编码，再对消息主体进行解析。所以说 POST 提交数据方案，Content-Type 至关重要，下面就正式开始介绍它们。

1、application/x-www-form-urlencoded

这应该是最常见的 POST 提交数据的方式了。浏览器的原生 <form> 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。请求类似于下面这样（无关的请求头在本文中都省略掉了）：

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8

name=Tom&age=30&city=beijing

首先，Content-Type 被指定为 application/x-www-form-urlencoded；其次，提交的数据按照 key1=value1&key2=value2 的方式进行编码，如有特殊字符，则会对 key 和 value 进行 URL 编码。大部分服务端语言都对这种方式有很好的支持。

2、multipart/form-data

这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让 <form> 表单的 enctype 等于 multipart/form-data。下面来看一个请求示例：

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="name"

Tom
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="portrait.png"
Content-Type: image/png

PNG ... content of portrait.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个例子稍微复杂点。首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。关于 multipart/form-data 的详细定义，请前往 rfc1867 查看。这种方式一般用来上传文件，各大服务端语言对它也有着良好的支持。

上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段标准中原生 <form> 表单也只支持这两种方式（通过 <form> 元素的 enctype 属性指定，默认为 application/x-www-form-urlencoded。其实 enctype 还支持 text/plain，不过用得非常少）。

3、application/json

application/json 这个 Content-Type 作为请求头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。例如在使用Elasticsearch查询中：

curl -X POST -H 'Content-Type: application/json'  "localhost:9200/myblog/_search?pretty" -d '{
     "query": {"match_all": {}}
 }'

最终发送的请求是这样的：

POST localhost:9200 HTTP/1.1 
Content-Type: application/json;charset=utf-8

{"query": {"match_all": {}}}

这种方案，可以方便的提交复杂的结构化数据，特别适合 RESTful 的接口。

4、text/xml

其主要用于XML-RPC。XML-RPC的全称是XML Remote Procedure Call，即XML远程方法调用。

RPC是Remote Procedure Call的缩写，翻译成中文为：远程方法调用。它是一种在本地机器上调用远端机器上的一个过程（方法）的技术，这个过程也被大家称为“分布式计算”，是为了提高各个分立机器的“互操作性”而发明出来的技术。

XML-RPC是一套允许运行在不同操作系统、不同环境的程序实现基于Internet过程调用的规范和一系列的实现。这种远程过程调用使用HTTP作为传输协议，XML作为传送信息的编码格式。Xml-RPC的定义尽可能的保持了简单，但同时能够传送、处理、返回复杂的数据结构。XML- RPC（http://www.xmlrpc.com）是由美国UserLand公司指定的一个RPC协议。简单的理解是：将数据定义为xml格式，通过http协议进行远程传输。

典型的 XML-RPC 请求是这样的：

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>student.setName</methodName>
    <params>
        <param>
            <value>Tom</value>
        </param>
    </params>
</methodCall>

XML-RPC 协议简单、功能够用，各种语言的实现都有，在早期互联网世界使用也很广泛，但是由于 XML 结构还是过于臃肿，逐渐退出了历史舞台。

标签: none

添加新评论