首页 > 代码库 > WEB中的GET和POST

WEB中的GET和POST

  客户端提交数据到服务器端有两种方式GET和POST,get是将数据拼接到url上,而post是将数据封装在request body中,发送过去。顾名思义,get即请求数据,有时需要其附带部分参数;post即发送数据,所以需要携带数据。

一、GET方式

  get请求是安全和幂等的。

  1、安全性:get操作不会修改服务器的数据,无论多少次get请求,服务器的数据都不会改变。

  2、幂等性:幂等是说,同一个请求原封不动的发送N次和M次,服务器上资源的状态最终都是一致的,相应的服务器返回的内容也是一致的。

 

  get请求发送数据量较小。

  1、http协议中的get/post并没有发送数据大小的限制,对发送数据大小产生限制的是浏览器以及操作系统、服务器,http本身没有对url长度有所限制

  url长了,服务器处理也是一种负担。原本一个会话就没有多少数据,如果恶意构造几个几M大小的URL,并不停的访问你的服务器,服务器的并发数就会下降。

 

  get能被缓存,post不能被缓存

  打开一个页面,如果之前被打开,那么很明显这次打开速度会加快,这是因为html/js/css/img等文件都能被浏览器缓存,而这些文件的获取,都是用的get请求。 post请求目前为止我只在ajax和form表单中见过。

二、POST 方式

  post请求是安全的

  get是将数据拼接到url上,而post是将数据封装在request body中。get的请求附加的参数有可能被人在浏览器地址栏上直接看到,或者查看浏览器的历史记录或者日志,就能看到参数。而post因为不能被缓存,也不能被保存为书签,所以请求过了就没有记录了? 请求参数就不能被截获了?非也,抓个包就可以看到了。

所以,post请求只是相对的安全的。

 

三、GET请求乱码

  (1)get请求中数据是直接在url上进行拼接,使用&分隔key-value对.但有时key,value会出现中文等对于html标准来说不安全的字符
  (2)html标准说,除了字符”a”-”z”,”A”-”Z”,”0″-”9″,”.”,”-”,”*”,和”_” 其他的字符都是不安全的,需要进行编码.其中” “空格会被编码成+号。当出现不安全字符时,在发送到服务器之前,浏览器会将这些参数值进行编码。

  (3)一般推荐是使用utf-8编码格式。也可以使用JavaScript对数据进行encodeURIComponent(url);

  引起乱码的原因

  现在的url就成了ASCII范围内的字符了,然后以iso-8859-1的编码方式转换成二进制随着请求头一起发送出去,对于get方法来说,没有请求实体,含有数据的url都在请求头里面。请注意,其实这里进行了两次编码,第一次是使用UTF8,第二次使用iso-8859-1编码成能在网络上传输二进制101010….。  现在问题来到了服务器端,每种服务器默认的编码方式都可能不同,比如tomcat默认编码就是iso-8859-1。按道理服务器端也会做两次的解码动作,第一次是对二进制内容的iso-8859-1的解码,第二次是使用服务器默认的编码对数据进行解码,因此我们使用request.getParameter(“name”)得到的数据是经过两次解码的.
  当tomcat使用iso-8859-1对数据进行第二次解码时,因为对应客户端编码是utf8,因此我们使用request.getParameter(“name”)就肯定乱码.如果我们不去改变tomcat的默认编码,可以使用new String(request.getParameter(“name”).getBytes(“iso-8859-1″), “utf-8″);手工重新解码.
request.setCharacterEncoding(“utf-8″)这种方式对于get方式提交数据是无效的,但是对post方式提交数据却是有效的.因为get没有request body.

  解决方案

  1.通常的做法还是修改tomcat的默认编码:在server.xml中的connector加上URIEncoding=”UTF-8″即可

  2.post方式
  post方式提交的数据也是必须进行编码的.如果form所在html文件指定了编码,就使用那个编码进行url编码.

  为了防止出现乱码,一般系统相关的文件都设成utf8格式,web服务器,Java服务器,数据库的编码格式都设为utf8.这样一般比较少出现乱码问题.
还有就是尽量使用post方式提交数据,一个是因为url的长度是有限制的,而get方式是将数据拼接到url上的.

 

WEB中的GET和POST