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

最近在做GGLook的時(shí)候,發(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).對(duì)于第二個(gè),我們可以對(duì)編碼進(jìn)行設(shè)置.但是對(duì)于第一個(gè),j2sdk實(shí)現(xiàn)的默認(rèn)編碼卻是iso-8859-1.沒(méi)搞懂為什么內(nèi)部編碼為UNICODE的java要把他實(shí)現(xiàn)成為iso-8859-1.還有就是tomcat為什么不采用配置文件的方式使我們自己能設(shè)定其編碼方式.現(xiàn)在一跳轉(zhuǎn)到errorpage.jsp就是亂碼.沒(méi)辦法,要嗎改j2sdk,要嗎改tomcat.最后,確定下載tomcat原代碼包,將Generator.java改掉,重新編譯,現(xiàn)在一切運(yùn)行正常!

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

1. 寫個(gè)filter，然后在filter里面進(jìn)行request.setCharacterEncoding("GBK")
2. 每個(gè)jsp頁(yè)面的頭部都寫上request.setCharacterEncoding("GBK")，原理和1是一樣的
3. 傳參數(shù)前先對(duì)中文進(jìn)行encode，得到參數(shù)后再使用對(duì)應(yīng)的decode，這樣的話傳遞的參數(shù)就不會(huì)丟失，但是比較麻煩
4. 修改tomcat的server.xml配置文件，在<Connector>節(jié)點(diǎn)增加一個(gè)屬性：URIEncoding="GBK"，但是感覺(jué)這個(gè)參數(shù)沒(méi)有起作用，官方文檔是這么描述的“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的話，則會(huì)使用過(guò)濾器；如果是Get方式的話，tomcat默認(rèn)會(huì)使用URIEncoding----是tomcat的server.xml配置文件，在<Connector>節(jié)點(diǎn)有一個(gè)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是通過(guò)Get提交數(shù)據(jù)的（sends a GET request to the server.），所以還是使用了ISO-8859-1編碼。

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

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