HTML数据信息递交post

HTTP/1.1 协议书要求的 HTTP 恳求方式有 OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT 这几种。在其中 POST 1般用来向服务端递交数据信息,本文关键探讨 POST 递交数据信息的几种方法。

大家了解,HTTP 协议书是以 ASCII 码传送,创建在 TCP/IP 协议书之上的运用层标准。标准把 HTTP 恳求分成3个一部分:情况行、恳求头、信息行为主体。相近于下面这样:

<method> <request-url> <version>
<headers>
<entity-body></entity-body></headers></version></request-url></method>

协议书要求 POST 递交的数据信息务必放在信息行为主体(entity-body)中,但协议书并沒有要求数据信息务必应用甚么编号方法。具体上,开发设计者彻底能够自身决策信息行为主体的文件格式,要是最终推送的 HTTP 恳求考虑上面的文件格式便可以。

可是,数据信息推送出去,还要服务端分析取得成功才成心义。1般服务端語言如 Java等,和它们的 framework,都内嵌了全自动分析普遍数据信息文件格式的作用。服务端一般是依据恳求头(headers)中的 Content-Type 字段来得知恳求中的信息行为主体是用何种方法编号,再对行为主体开展分析。因此说到 POST 递交数据信息计划方案,包括了 Content-Type 和信息行为主体编号方法两一部分。下面就宣布刚开始详细介绍它们。

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⑻
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

最先,Content-Type 被特定为 application/x-www-form-urlencoded;其次,递交的数据信息依照 key1=val1&key2=val2 的方法开展编号,key 和 val 都开展了 URL 转码。绝大多数服务端語言都对这类方法有很好的适用。比如 PHP 中,POST[′title′]能够获得到title的值,POST[′title′]能够获得到title的值,_POST['sub'] 能够获得 sub 数字能量数组。

许多情况下,大家用 Ajax 递交数据信息时,也是应用这类方法。比如 JQuery  的 Ajax,Content-Type 默认设置值是「application/x-www-form-urlencoded;charset=utf⑻」。

multipart/form-data

这又是1个普遍的 POST 数据信息递交的方法。大家应用表单提交文档时,务必让 form 的 enctyped 等于这个值。立即看来1个恳求示例:

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个事例略微繁杂点。最先转化成了1个 boundary 用于切分不一样的字段,以便防止与文章正文內容反复,boundary 很长很繁杂。随后 Content-Type 里指明了数据信息是以 mutipart/form-data 来编号,本次恳求的 boundary 是甚么內容。信息行为主体里依照字段个数又分成好几个构造相近的一部分,每一部分全是以 --boundary 刚开始,紧接着內容叙述信息内容,随后是回车,最终是字段实际內容(文字或2进制)。假如传送的是文档,还要包括文档名和文档种类信息内容。信息行为主体最终以 --boundary-- 标识完毕。有关 mutipart/form-data 的详尽界定,请前往 rfc1867 查询。

这类方法1般用来提交文档,各大服务端語言对它也是有着优良的适用。

上面提到的这两种 POST 数据信息的方法,全是访问器原生态适用的,并且目前原生态 form 表单也只适用这两种方法。可是伴随着愈来愈多的 Web 站点,特别是 WebApp,所有应用 Ajax 开展数据信息互动以后,大家彻底能够界定新的数据信息递交方法,给开发设计带来更多便捷。

application/json
 

application/json 这个 Content-Type 做为回应头大伙儿毫无疑问不生疏。具体上,如今愈来愈多的人把它做为恳求头,用来告知服务端信息行为主体是编码序列化后的 JSON 标识符串。因为 JSON 标准的时兴,除低版本号 IE 以外的各大访问器都原生态适用 JSON.stringify,服务端語言也都有解决 JSON 的涵数,应用 JSON 不容易遇到甚么不便。

JSON 文件格式适用比键值对繁杂很多的构造化数据信息,这1点也很有效。记得我几年前做1个新项目时,必须递交的数据信息层级十分深,我便是把数据信息 JSON 编码序列化以后来递交的。但是那时候我是把 JSON 标识符串做为 val,依然放在键值对里,以 x-www-form-urlencoded 方法递交。
 

Google 的 AngularJS 中的 Ajax 作用,默认设置便是递交 JSON 标识符串。比如下面这段编码:

var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
...
});

最后推送的恳求是:

POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf⑻
{"title":"test","sub":[1,2,3]}

这类计划方案,能够便捷的递交繁杂的构造化数据信息,非常合适 RESTful 的插口。各大抓包软件专用工具如 Chrome 自带的开发设计者专用工具、Firebug、Fiddler,都会以树形构造展现 JSON 数据信息,十分友善。但也是有些服务端語言都还没适用这类方法,比如 php 就没法根据 $_POST 目标从上面的恳求中得到內容。这时候候,必须自身动手能力解决下:在恳求头中 Content-Type 为 application/json 时,从 php://input 里得到初始键入流,再 json_decode 成目标。1些 Java 架构早已刚开始这么做了。

自然 AngularJS 还可以配备为应用 x-www-form-urlencoded 方法递交数据信息。

text/xml
 

XML-RPC(XML Remote Procedure Call)。它是1种应用 HTTP 做为传送协议书,XML 做为编号方法的远程控制启用标准。典型的 XML-RPC 恳求是这样的:
POST http://www.example.com HTTP/1.1
Content-Type: text/xml
<!--?xml version="1.0"?-->
<methodcall>
<methodname>examples.getStateName</methodname>
<params>
<param>
<value><i4>41</i4></value>
</params>
</methodcall>

XML-RPC 协议书简易、作用够用,各种各样語言的完成都有。它的应用也很普遍,如 WordPress 的 XML-RPC Api,检索模块的 ping 服务这些。JavaScript 中,也是有现成的库适用以这类方法开展数据信息互动,能很好的适用已有的 XML-RPC 服务。但是,我本人感觉 XML 构造還是过度臃肿,1般情景用 JSON 会更灵便便捷。