維護(hù)一個古董級的項(xiàng)目，在jsp傳參的時候亂碼了，如下：
       使用request得到的都是問號，最后在網(wǎng)上找到了下面的一段話，才解開了我心中的謎團(tuán)。
  

最近在做GGLook的時候,發(fā)現(xiàn)<jsp:forword>被tomcat generate成了...pageContent.forword(...java.util.URLEncoder.encode("" + ... )); 看了函數(shù)原形java.util.URLEncoder.encode有兩種形式:1.encode(String s)  2.encode(String s, String enc).對于第二個,我們可以對編碼進(jìn)行設(shè)置.但是對于第一個,j2sdk實(shí)現(xiàn)的默認(rèn)編碼卻是iso-8859-1.沒搞懂為什么內(nèi)部編碼為UNICODE的java要把他實(shí)現(xiàn)成為iso-8859-1.還有就是tomcat為什么不采用配置文件的方式使我們自己能設(shè)定其編碼方式.現(xiàn)在一跳轉(zhuǎn)到errorpage.jsp就是亂碼.沒辦法,要嗎改j2sdk,要嗎改tomcat.最后,確定下載tomcat原代碼包,將Generator.java改掉,重新編譯,現(xiàn)在一切運(yùn)行正常!

  
    原來是因?yàn)閡rl里面沒有指定編碼，會默認(rèn)使用ISO-8859-1進(jìn)行編碼，而ISO-8859-1是不支持中文的，即URLEncoder.encode之后  都會顯示%3F%3F%3F，所以之后無論使用何種字符集解碼都是問號了。。。
   最后的解決方案有一下幾種，其中第四種沒有成功：

1. 寫個filter，然后在filter里面進(jìn)行request.setCharacterEncoding("GBK")
2. 每個jsp頁面的頭部都寫上request.setCharacterEncoding("GBK")，原理和1是一樣的
3. 傳參數(shù)前先對中文進(jìn)行encode，得到參數(shù)后再使用對應(yīng)的decode，這樣的話傳遞的參數(shù)就不會丟失，但是比較麻煩
4. 修改tomcat的server.xml配置文件，在<Connector>節(jié)點(diǎn)增加一個屬性：URIEncoding="GBK"，但是感覺這個參數(shù)沒有起作用，官方文檔是這么描述的“This specifies the character encoding used to decode the URI bytes, after %xx decoding the URL. If not specified, ISO-8859-1 will be used. ”

     我的理解是要區(qū)分你是怎么提交數(shù)據(jù)的，如果是Post的話，則會使用過濾器；如果是Get方式的話，tomcat默認(rèn)會使用URIEncoding----是tomcat的server.xml配置文件，在<Connector>節(jié)點(diǎn)有一個URIEncoding的屬性，如果不配置的話默認(rèn)是：URIEncoding="ISO-8859-1"，官方文檔是這么描述的“This specifies the character encoding used to decode the URI bytes, after %xx decoding the URL. If not specified, ISO-8859-1 will be used. ”
因?yàn)閍jaxAnywhere.getAJAX是通過Get提交數(shù)據(jù)的（sends a GET request to the server.），所以還是使用了ISO-8859-1編碼。

 HTTP 定義了與服務(wù)器交互的不同方法，最基本的方法是 GET 和 POST。事實(shí)上 GET 適用于多數(shù)請求，而保留 POST 僅用于更新站點(diǎn)。根據(jù) HTTP 規(guī)范，GET 用于信息獲取，而且應(yīng)該是 安全的和 冪等的。所謂安全的意味著該操作用于獲取信息而非修改信息。換句話說，GET 請求一般不應(yīng)產(chǎn)生副作用。冪等的意味著對同一 URL 的多個請求應(yīng)該返回同樣的結(jié)果。完整的定義并不像看起來那樣嚴(yán)格。從根本上講，其目標(biāo)是當(dāng)用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞?wù)军c(diǎn)的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。反之亦然。POST 請求就不那么輕松了。POST 表示可能改變服務(wù)器上的資源的請求。仍然以新聞?wù)军c(diǎn)為例，讀者對文章的注解應(yīng)該通過 POST 請求實(shí)現(xiàn)，因?yàn)樵谧⒔馓峤恢笳军c(diǎn)已經(jīng)不同了（比方說文章下面出現(xiàn)一條注解）；
 
在FORM提交的時候，如果不指定Method，則默認(rèn)為GET請求，F(xiàn)orm中提交的數(shù)據(jù)將會附加在url之后，以?分開與url分開。字母數(shù)字字符原樣發(fā)送，但空格轉(zhuǎn)換為“+“號，其它符號轉(zhuǎn)換為%XX,其中XX為該符號以16進(jìn)制表示的ASCII（或ISO Latin-1）值。GET請求請?zhí)峤坏臄?shù)據(jù)放置在HTTP請求協(xié)議頭中，而POST提交的數(shù)據(jù)則放在實(shí)體數(shù)據(jù)中；

GET方式提交的數(shù)據(jù)最多只能有1024字節(jié)，而POST則沒有此限制。