HTTP協議之GET和POST

1、Get是用來從服務器上獲得數據,而Post是用來向服務器上傳遞數據。

2、Get將表單中數據的按照variable=value的形式,添加到action所指向的URL後面,並且兩者使用“?”連接,而各個變量之間使用“&”連接;Post是將表單中的數據放在form的數據體中,按照變量和值相對應的方式,傳遞到action所指向URL。

3、Get是不安全的,因爲在傳輸過程,數據被放在請求的URL中,而如今現有的很多服務器、代理服務器或者用戶代理都會將請求URL記錄到日誌文件中,然後放在某個地方,這樣就可能會有一些隱私的信息被第三方看到。另外,用戶也可以在瀏覽器上直接看到提交的數據,
一些系統內部消息將會一同顯示在用戶面前。Post的所有操作對用戶來說都是不可見的。

4、Get傳輸的數據量小,這主要是因爲受URL長度限制;而Post可以傳輸大量的數據,所以在上傳文件只能使用Post(當然還有一個原因,將在後面的提到)。

5、Get限制Form表單的數據集的值必須爲ASCII字符;而Post支持整個ISO10646字符集。默認是用ISO-8859-1編碼

6、Get是Form的默認方法。

以下的比較非常非常使用:
做java的web開發有段日子了,有個問題老是困擾着我,就是亂碼問題,基本上是網上查找解決方案(網上資料真的很多),都是一大堆的介紹如何解決此類的亂碼問題,但是沒幾個把問題的來龍去脈說清楚的,有時候看了些文章後,以爲自己懂了,但是在開發中亂碼問題又像鬼魂一樣出來嚇人,真是頭大了!這篇文章是我長時間和亂碼做鬥爭的一些理解的積累,還希望有更多的朋友給出指點和補充。

form有2中方法把數據提交給服務器,get和post,分別說下吧。

(一)get提交

1.首先說下客戶端(瀏覽器)的form表單用get方法是如何將數據編碼後提交給服務器端的吧。

對於get方法來說,都是把數據串聯在請求的url後面作爲參數,如:http://localhost:8080/servlet?msg=abc很常見的
一個亂碼問題就要出現了,如果url中出現中文或其它特殊字符的話,如:http://localhost:8080 /servlet?msg=杭州,
服務器端容易得到亂碼),url拼接完成後,瀏覽器會對url進行URL encode,然後發送給服務器,URL encode的過程就是把
部分url做爲字符,按照某種編碼方式(如:utf-8,gbk等)編碼成二進制的字節碼,然後每個字節用一個包含3個字符的
字符串 "%xy"表示,其中xy爲該字節的兩位十六進制表示形式。我這裏說的可能不清楚,
具體介紹可以看java.net.URLEncoder類的介紹在這裏。

瞭解了 URL encode的過程,我們能看到2個很重要的問題。

第一:需要URL encode的字符一般都是非ASCII的字符(籠統的講),再通俗的講就是除了英文字母以外的文字(如:中文,日文等)都要進行URL encode,所以對於我們來說,都是英文字母的url不會出現服務器得到亂碼問題,出現亂碼都是url裏面帶了中文或特殊字符造成的;

第二:URL encode到底按照那種編碼方式對字符編碼?這裏就是瀏覽器的事情了,而且不同的瀏覽器有不同的做法,中文版的瀏覽器一般會默認的使用GBK,通過設置瀏覽器也可以使用UTF-8,可能不同的用戶就有不同的瀏覽器設置,也就造成不同的編碼方式,所以很多網站的做法都是先把url裏面的中文或特殊字符用 javascriptURL encode,然後再拼接url提交數據,也就是替瀏覽器做了URL encode,好處就是網站可以統一get方法提交數據的編碼方式。 完成了URL encode,那麼現在的url就成了ASCII範圍內的字符了,然後以iso-8859-1的編碼方式轉換成二進制隨着請求頭一起發送出去。這裏想多說幾句的是,對於get方法來說,沒有請求實體,含有數據的url都在請求頭裏面,之所以用URL encode,我個人覺的原因是:對於請求頭來說最終都是要用iso-8859-1編碼方式編碼成二進制的101010…..的純數據在互聯網上傳送,如果直接將含有中文等特殊字符做iso-8859-1編碼會丟失信息,所以先做URL encode是有必要的。

2。服務器端(tomcat)是如何將數據獲取到進行解碼的。

第一步是先把數據用iso-8859-1進行解碼,對於get方法來說,tomcat獲取數據的是ASCII範圍內的請求頭字符,其中的請求url裏面帶有參數數據,如果參數中有中文等特殊字符,那麼目前還是URL encode後的%XY狀態,先停下,我們先說下開發人員一般獲取數據的過程。通常大家都是request.getParameter(“name”)獲取參數數據,我們在request對象或得的數據都是經過解碼過的,而解碼過程中程序裏是無法指定,這裏要說下,有很多新手說用 request.setCharacterEncoding(“字符集”)可以指定解碼方式,其實是不可以的,看servlet的官方API說明有對此方法的解釋:Overrides the name of the character encoding used in the body of this request. This method must be called prior to reading request parameters or reading input using getReader().可以看出對於get方法他是無能爲力的。那麼到底用什麼編碼方式解碼數據的呢,這是tomcat的事情了,默認缺省用的是 iso-8859-1,這樣我們就能找到爲什麼get請求帶中文參數爲什麼在服務器端得到亂碼了,原因是在客戶端一般都是用UTF-8GBK對數據 URL encode,這裏用iso-8859-1方式URL decoder顯然不行,在程序裏我們可以直接

Java代碼 :

    1. new String(request.getParameter("name").getBytes("iso-8859-1"),"客戶端指定的URL encode編碼方式")
    還原回字節碼,然後用正確的方式解碼數據,網上的文章通常是在tomcat裏面做個配置  

XML代碼:

 1. <Connector port="8080" protocol="HTTP/1.1" maxThreads="150" connection Timeout="20000" redirectPort="8443" URIEncoding="GBK"/>   

這樣是讓tomcat在獲取數據後用指定的方式URL decoder,URL decoder的介紹在這裏

(二)post提交

1.客戶端(瀏覽器)的form表單用post方法是如何將數據編碼後提交給服務器端的。

 在post方法裏所要傳送的數據也要URL encode,那麼他是用什麼編碼方式的呢?在form所在的html文件裏如果有段
 <metahttp-equiv="Content-Type" content="text/html; charset=字符集(GBK,utf-8等)"/>,
 那麼**post**就會用此處指定的編碼方式編碼。一般大家都認爲這段代碼是爲了讓瀏覽器知道用什麼字符集來對網頁解釋,
 所以網站都會把它放在**html**代碼的最前端,儘量不出現亂碼,其實它還有個作用就是指定form表單的post方法提交數據
 的 URL encode編碼方式。從這裏可以看出對於**get**方法來數,瀏覽器對數據的URL encode的編碼方式是有瀏覽器設置
 來決定,(可以用js做統一指定),而**post**方法,開發人員可以指定。 

2。服務器端(tomcat)是如何將數據獲取到進行解碼的。

如果用tomcat默認缺省設置,也沒做過濾器等編碼設置,那麼他也是用iso-8859-1解碼的,但是request.setCharacterEncoding("字符集")可以派上用場。  

我發現上面說的tomcat所做的事情前提都是在請求頭裏沒有指定編碼方式,如果請求頭裏指定了編碼方式將按照這種方式編碼。
有2篇文章推薦下,地址分別是
深入淺出URL編碼:http://www.cnblogs.com/yencain/articles/1321386.html
表單用post方法提交數據時亂碼問題:http://wanghuan8086.javaeye.com/blog/173869
用post很重要的在form所在的html文件裏如果有段 強烈建議使用post提交

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章