| 對(duì)DisplayTag、Tomcat中編碼問題的總結(jié)
關(guān)于AppFuse中使用中文編碼的問題
這2個(gè)月一直被DisplayTag折騰，如果DisplayTag的鏈接或者排序的列中有漢字，那么排序或者翻頁(yè)都會(huì)查詢不到結(jié)果或報(bào)錯(cuò)（如果你處理的好，可能會(huì)顯示沒有可以顯示的數(shù)據(jù)）。
我一直以為這個(gè)問題是因?yàn)?FONT size=+0>DisplayTag的開發(fā)者們沒有考慮到中文的問題，因?yàn)轫?xiàng)目進(jìn)度很緊，所以就把排序的功能給屏蔽了，雖然經(jīng)過了大量的測(cè)試，但都沒有發(fā)現(xiàn)翻頁(yè)時(shí)候也存在這個(gè)問題（AppFuse自動(dòng)生成的頁(yè)面的默認(rèn)顯示25行，如果超過25行會(huì)自動(dòng)分頁(yè)），直到前天，測(cè)試人員才發(fā)現(xiàn)這個(gè)問題，按照我的理解要修改DisplayTag的源碼，后來(lái)又想通過自己寫過濾器試試，幸運(yùn)的是在我動(dòng)手干之前，先和倦兔聊了幾句，結(jié)果倦兔說(shuō)他也遇到過這個(gè)問題，指出如果在server.xml中添加URIEncoding="GBK"就可以解決問題，我試了一下，果然可以，但這是為什么呢？
在AppFuse中有一個(gè)Spring的過濾器，對(duì)請(qǐng)求的編碼進(jìn)行轉(zhuǎn)換，這種做法很通用，即使是在以前，我們自己寫這個(gè)過濾器也不麻煩，而且這個(gè)代碼在網(wǎng)上隨處可見，難道是Spring的過濾器沒有起作用嗎?也不是，如果沒起作用，那么我在Struts中的Action中通過request.getParmeter接收到參數(shù)應(yīng)該是亂碼？而且我記得這種做法在Tomcat4.1.24中沒有任何問題，那是為什么？和倦兔討論了一下，我們都沒有找到答案。
于是，我就通過google搜索"URIEncoding",找到一堆文章，我讀了幾篇文章，其中有一篇提到：Tomcat5中對(duì)Post和Get請(qǐng)求不再采用相同的處理策略了，而在Tomcat4中采用的處理策略是相同的。于是我想："我的提交的請(qǐng)求明明是Post，我又沒有用Get請(qǐng)求，那Spring的過濾器就應(yīng)該起作用，為什么結(jié)果會(huì)這樣呢？"，我的一個(gè)jsp中的Form的代碼如下：
<html:form action="editGj" method="post" styleId="gjForm"
focus="mc" onsubmit="return validateGjForm(this)">
看，我的代碼明明是使用的是Post方法，為什么結(jié)果不正確呢？
我的跳轉(zhuǎn)到下一頁(yè)的代碼是：
<a href="?d-449687-p=2&mc=%D7%A8%D2%B5&;
excelname=%D7%A8%D2%B5%C3%FB%B3%C6.xls">下一頁(yè)</a>
加粗的部分就是我的翻頁(yè)的鏈接。如果你立刻就看出了我的問題，那么你就可以不用往下看了，呵呵。如果你沒有看出問題，請(qǐng)繼續(xù)，Come On Baby?。。?BR> 我采用的真的是Post方法嗎？我的form的提交采用的是Post方法，這是沒錯(cuò)的，那么鏈接采用的是Post方法嗎？
不是?。。?！它采用的是Get方法進(jìn)行提交的，這就是問題的答案了!
Post和Get提交有什么區(qū)別嗎？
簡(jiǎn)單的說(shuō)：Post是將地址傳送一次，將form的數(shù)據(jù)單獨(dú)提交，而Get則是將地址和參數(shù)一起傳送，傳送的不止是form的數(shù)據(jù)，但傳送的數(shù)據(jù)的長(zhǎng)度有字節(jié)限制，另外還有安全問題。如果感興趣，你可以用google搜一下，會(huì)找到很多資料。 當(dāng)我想到這個(gè)區(qū)別時(shí)，我又檢查了一下我的顯示列表的頁(yè)面，發(fā)現(xiàn)這個(gè)頁(yè)面沒有form，只有，這說(shuō)明我的提交的確是Get的，于是，Tomcat5對(duì)我的Get請(qǐng)求執(zhí)行的是另外的處理方式，和Post的處理方式不再一樣了！
Tomcat5對(duì)Get請(qǐng)求是怎么處理的？
默認(rèn)情況下，Tomcat對(duì)請(qǐng)求采用的默認(rèn)編碼是ISO-8859-1，我們的JSP頁(yè)面上聲明的
和
<meta http-equiv="Content-Type" content="text/html; charset=GBK"/>
只在顯示漢字時(shí)有用，而且這2種寫法的作用在理論上應(yīng)該時(shí)一致的，但是由于各個(gè)軟件廠商對(duì)Web標(biāo)準(zhǔn)都按照自己的理解進(jìn)行了修改，所以，常常這2種寫法作用就不一致了，使我們?cè)陂_發(fā)Web程序時(shí)備感混亂。如果你想了解詳情，請(qǐng)查看《網(wǎng)站重構(gòu)》一書。
這樣我們提交的漢字被認(rèn)為是ISO-8859-1的編碼，所以在程序中接收時(shí)顯示亂碼，如果使用過濾器，在過濾器中調(diào)用request.setCharacterEncoding("GBK")的話，那么Post上來(lái)的漢字將被認(rèn)為是GBK編碼，而Tomcat5對(duì)于Get請(qǐng)求上來(lái)的編碼并不根據(jù)過濾器的設(shè)定辨認(rèn)編碼方式，默認(rèn)的依然是ISO-8859-1，Tomcat5中處理Get請(qǐng)求的源代碼如下：
上面的代碼中，enc代表Tomcat5中server.xml中Connector部分的URIEnocodeing項(xiàng)設(shè)定的值，可以看出，如果沒有設(shè)定URIEncoding項(xiàng)的話，那么Tomcat5也并沒有使用默認(rèn)的ISO-8859-1編碼，而是一段fast conversion，所以，即使你的頁(yè)面使用默認(rèn)的編碼方式進(jìn)行編碼，然后使用ISO-8859-1進(jìn)行解碼，得到的結(jié)果也不對(duì)，這可能是Tomcat5的一個(gè)Bug。如果想繞過這個(gè)Bug，那么只有在server.xml的Connector部分設(shè)定URIEncoding的值，根據(jù)編碼方式指定自己的值，在我的程序中我使用的是GBK，所以我修改后的部分如下： acceptCount="100"
connectionTimeout="20000"
disableUploadTimeout="true"
port="80"
redirectPort="8443"
enableLookups="false"
minSpareThreads="25"
maxSpareThreads="75"
maxThreads="150"
maxPostSize="0"
URIEncoding="GBK">
這個(gè)問題我參考了這篇文章：
http://www.javaworld.com.tw/jute/post/view?age=0&bid=9&ppg=1&sty=1&id=44042&tpg=1 http://www.javaworld.com.tw/jute/post/view?age=0&bid=9&ppg=1&sty=1&id=44042&tpg=1
另外，對(duì)于編碼解碼的問題，我還有一句要說(shuō)，理論上，如果編碼的charset和解碼的charset是一致的話，那么就應(yīng)該沒有亂碼的問題，但是，對(duì)于某些特殊的字符來(lái)說(shuō)，如果采用的charset不對(duì)，則可能在解碼的時(shí)候不能顯示，所以要選擇好字符集，我推薦在處理簡(jiǎn)體漢字的時(shí)候使用GBK。網(wǎng)上也有推薦UTF-8的，具體使用哪種依情況而定。
以上是我的總結(jié)，若有錯(cuò)誤，請(qǐng)指正，謝謝！
明天，我就放假了，祝我的朋友們春節(jié)快樂，萬(wàn)事勝意！
兔八哥
2005年2月4日14:04
另外，我昨晚看了看Tomcat5自帶的Servlet Example中過濾器的實(shí)現(xiàn)，其中就有關(guān)于處理編碼的過濾器SetCharacterEncodingFilter，還有另外一個(gè)是處理用戶輸入的過濾器，叫HTMLFilter，用于將用戶輸入的字符轉(zhuǎn)化為HTML格式的字符，如將">"轉(zhuǎn)換為">"，這個(gè)過濾器稍加修改就可以用在自己的項(xiàng)目上了，呵呵！ |