昨天做個小頁面,忽然發現運行后全是亂碼.后來再看看,貌似就是忘記編碼問題了.開頭加個<%@page contentType="text/html; charset=gb2312"%> ,OK,一切OK了就.實際上這個語句的作用就是在jsp被編譯成為html的過程中提供編碼方式讓java來”讀取”表達式當中的String.而類似的有一個句子<META http-equiv=Content-Type content=”text/html; charset=gb2312〃>則是用來顯示最后的數據.網絡上常能看到合二為一亂用的情況.有關涉及到數據交換的,貌似用<%request.setCharacterEncoding("gb2312");%> 或者是<%response.setCharacterEncoding("gb2312");%> 應該就可用搞定了.
就gb2312來說,它是比較早的中文編碼了,屬于第一代產品,現在雖然也用的多,不過個人感覺還是GBK大方一點,但是支持的軟件米有2312的多,- -!從2312一直向上,到GBK個規范,再到現在GBK2K的國家標準,這個國標貌似生存能力>>GBK...可是現在支持它的軟件鳳毛麟角,基本上屬于珍惜動物..所以現在貌似還是2312范圍廣一點,畢竟夠用,而且不怕什么軟件不支持.
到應用服務器端,個人開發還是用的開源tomcat的多.畢竟免費,性能也不錯,可人家畢竟是國外開發的,默認的編碼當然不會用你的GB,從它的默認文件中就找的出默認編碼,

<Connector port="8080"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

debug="0" connectionTimeout="20000" useBodyEncodingForURI="true"

disableUploadTimeout="true" URIEncoding=”UTF-8”/>
最后那個,人家用的是UTF-8.可以用request的setCharacterEncoding方法設定編碼方案.8過UTF-8貌似也能支持中文- -!還有個URL中文參數的問題,貌似可以用URLEncode.encode解決之.
MySQL就不用說了,畢竟是瑞典人開發的,默認拉丁編碼,其實也是支持中文的,我就曾經同樣的編碼頭一天還能看到中文,第二天打開看就全變固定的亂碼了,無奈把編碼改個GB才好用- -!