java中文乱码decode_Java中文乱码处理
java編碼轉(zhuǎn)換過程
我們總是用一個java類文件和用戶進(jìn)行最直接的交互(輸入、輸出)，這些交互內(nèi)容包含的文字可能會包含中文。無論這些java類是與數(shù)據(jù)庫交互，還是與前端頁面交互，他們的生命周期總是這樣的：
1、程序員在操作系統(tǒng)上通過編輯器編寫程序代碼并且以.java的格式保存操作系統(tǒng)中，這些文件我們稱之為源文件。
2、通過JDK中的javac.exe編譯這些源文件形成.class類。
3、直接運(yùn)行這些類或者部署在WEB容器中運(yùn)行，得到輸出結(jié)果。
這些過程是從宏觀上面來觀察的，了解這個肯定是不行的，我們需要真正來了解java是如何來編碼和被解碼的：
第一步：當(dāng)我們用編輯器編寫java源文件，程序文件在保存時會采用操作系統(tǒng)默認(rèn)的編碼格式(一般我們中文的操作系統(tǒng)采用的是GBK編碼格式)形成一個.java文件。java源文件是采用操作系統(tǒng)默認(rèn)支持的file.encoding編碼格式保存的。下面代碼可以查看系統(tǒng)的file.encoding參數(shù)值。
System.out.println(System.getProperty("file.encoding"));
第二步：當(dāng)我們使用javac.exe編譯我們的java文件時，JDK首先會確認(rèn)它的編譯參數(shù)encoding來確定源代碼字符集，如果我們不指定該編譯參數(shù)，JDK首先會獲取操作系統(tǒng)默認(rèn)的file.encoding參數(shù)，然后JDK就會把我們編寫的java源程序從file.encoding編碼格式轉(zhuǎn)化為JAVA內(nèi)部默認(rèn)的UNICODE格式放入內(nèi)存中。
第三步：JDK將上面編譯好的且保存在內(nèi)存中信息寫入class文件中，形成.class文件。此時.class文件是Unicode編碼的，也就是說我們常見的.class文件中的內(nèi)容無論是中文字符還是英文字符，他們都已經(jīng)轉(zhuǎn)換為Unicode編碼格式了。
在這一步中對對JSP源文件的處理方式有點(diǎn)兒不同：WEB容器調(diào)用JSP編譯器，JSP編譯器首先會查看JSP文件是否設(shè)置了文件編碼格式，如果沒有設(shè)置則JSP編譯器會調(diào)用調(diào)用JDK采用默認(rèn)的編碼方式將JSP文件轉(zhuǎn)化為臨時的servlet類，然后再編譯為.class文件并保持到臨時文件夾中。
第四步：運(yùn)行編譯的類：在這里會存在一下幾種情況
1、直接在console上運(yùn)行。
2、JSP/Servlet類。
3、java類與數(shù)據(jù)庫之間。
這三種情況每種情況的方式都會不同，
1.Console上運(yùn)行的類
這種情況下，JVM首先會把保存在操作系統(tǒng)中的class文件讀入到內(nèi)存中，這個時候內(nèi)存中class文件編碼格式為Unicode，然后JVM運(yùn)行它。如果需要用戶輸入信息，則會采用file.encoding編碼格式對用戶輸入的信息進(jìn)行編碼同時轉(zhuǎn)換為Unicode編碼格式保存到內(nèi)存中。程序運(yùn)行后，將產(chǎn)生的結(jié)果再轉(zhuǎn)化為file.encoding格式返回給操作系統(tǒng)并輸出到界面去。整個流程如下：
在上面整個流程中，凡是涉及的編碼轉(zhuǎn)換都不能出現(xiàn)錯誤，否則將會產(chǎn)生亂碼。
2.Servlet類
由于JSP文件最終也會轉(zhuǎn)換為servlet文件(只不過存儲的位置不同而已)，所以這里我們也將JSP文件納入其中。
當(dāng)用戶請求Servlet時，WEB容器會調(diào)用它的JVM來運(yùn)行Servlet。首先JVM會把servlet的class加載到內(nèi)存中去，內(nèi)存中的servlet代碼是Unicode編碼格式的。然后JVM在內(nèi)存中運(yùn)行該Servlet，在運(yùn)行過程中如果需要接受從客戶端傳遞過來的數(shù)據(jù)(如表單和URL傳遞的數(shù)據(jù))，則WEB容器會接受傳入的數(shù)據(jù)，在接收過程中如果程序設(shè)定了傳入?yún)?shù)的的編碼則采用設(shè)定的編碼格式，如果沒有設(shè)置則采用默認(rèn)的ISO-8859-1編碼格式，接收的數(shù)據(jù)后JVM會將這些數(shù)據(jù)進(jìn)行編碼格式轉(zhuǎn)換為Unicode并且存入到內(nèi)存中。運(yùn)行Servlet后產(chǎn)生輸出結(jié)果，同時這些輸出結(jié)果的編碼格式仍然為Unicode。緊接著WEB容器會將產(chǎn)生的Unicode編碼格式的字符串直接發(fā)送置客戶端，如果程序指定了輸出時的編碼格式，則按照指定的編碼格式輸出到瀏覽器，否則采用默認(rèn)的ISO-8859-1編碼格式。整個過程流程圖如下：
3.數(shù)據(jù)庫部分
我們知道java程序與數(shù)據(jù)庫的連接都是通過JDBC驅(qū)動程序來連接的，而JDBC驅(qū)動程序默認(rèn)的是ISO-8859-1編碼格式的，也就是說我們通過java程序向數(shù)據(jù)庫傳遞數(shù)據(jù)時，JDBC首先會將Unicode編碼格式的數(shù)據(jù)轉(zhuǎn)換為ISO-8859-1的編碼格式，然后在存儲在數(shù)據(jù)庫中，即在數(shù)據(jù)庫保存數(shù)據(jù)時，默認(rèn)格式為ISO-8859-1。
編碼&解碼
在上篇博客中LZ闡述了三個渠道的編碼轉(zhuǎn)換過程，下面LZ將結(jié)束java在那些場合需要進(jìn)行編碼和解碼操作，并詳序中間的過程，進(jìn)一步掌握java的編碼和解碼過程。在java中主要有四個場景需要進(jìn)行編碼解碼操作：
1：I/O操作
2：內(nèi)存
3：數(shù)據(jù)庫
4：javaWeb
下面主要介紹前面兩種場景，數(shù)據(jù)庫部分只要設(shè)置正確編碼格式就不會有什么問題，javaWeb場景過多需要了解URL、get、POST的編碼，servlet的解碼，所以javaWeb場景下節(jié)LZ介紹。
I/O操作
在前面LZ就提過亂碼問題無非就是轉(zhuǎn)碼過程中編碼格式的不統(tǒng)一產(chǎn)生的，比如編碼時采用UTF-8，解碼采用GBK，但最根本的原因是字符到字節(jié)或者字節(jié)到字符的轉(zhuǎn)換出問題了，而這中情況的轉(zhuǎn)換最主要的場景就是I/O操作的時候。當(dāng)然I/O操作主要包括網(wǎng)絡(luò)I/O(也就是javaWeb)和磁盤I/O。網(wǎng)絡(luò)I/O下節(jié)介紹。
首先我們先看I/O的編碼操作。
InputStream為字節(jié)輸入流的所有類的超類，Reader為讀取字符流的抽象類。java讀取文件的方式分為按字節(jié)流讀取和按字符流讀取，其中InputStream、Reader是這兩種讀取方式的超類。
按字節(jié)
我們一般都是使用InputStream.read()方法在數(shù)據(jù)流中讀取字節(jié)(read()每次都只讀取一個字節(jié)，效率非常慢，我們一般都是使用read(byte[]))，然后保存在一個byte[]數(shù)組中，最后轉(zhuǎn)換為String。在我們讀取文件時，讀取字節(jié)的編碼取決于文件所使用的編碼格式，而在轉(zhuǎn)換為String過程中也會涉及到編碼的問題，如果兩者之間的編碼格式不同可能會出現(xiàn)問題。例如存在一個問題test.txt編碼格式為UTF-8，那么通過字節(jié)流讀取文件時所獲得的數(shù)據(jù)流編碼格式就是UTF-8，而我們在轉(zhuǎn)化成String過程中如果不指定編碼格式，則默認(rèn)使用系統(tǒng)編碼格式(GBK)來解碼操作，由于兩者編碼格式不一致，那么在構(gòu)造String過程肯定會產(chǎn)生亂碼，如下：
File file = new File("C:\\test.txt");
InputStream input= newFileInputStream(file);
StringBuffer buffer= newStringBuffer();byte[] bytes = new byte[1024];for(int n ; (n = input.read(bytes))!=-1; ){
buffer.append(new String(bytes,0,n));
}
System.out.println(buffer);
輸出結(jié)果：锘挎垜鏄?cm
test.txt中的內(nèi)容為：我是 cm。
要想不出現(xiàn)亂碼，在構(gòu)造String過程中指定編碼格式，使得編碼解碼時兩者編碼格式保持一致即可：
buffer.append(new String(bytes,0,n,"UTF-8"));
按字符
其實(shí)字符流可以看做是一種包裝流，它的底層還是采用字節(jié)流來讀取字節(jié)，然后它使用指定的編碼方式將讀取字節(jié)解碼為字符。在java中Reader是讀取字符流的超類。所以從底層上來看按字節(jié)讀取文件和按字符讀取沒什么區(qū)別。在讀取的時候字符讀取每次是讀取留個字節(jié)，字節(jié)流每次讀取一個字節(jié)。
字節(jié)&字符轉(zhuǎn)換
字節(jié)轉(zhuǎn)換為字符一定少不了InputStreamReader。API解釋如下：InputStreamReader 是字節(jié)流通向字符流的橋梁：它使用指定的?charset?讀取字節(jié)并將其解碼為字符。它使用的字符集可以由名稱指定或顯式給定，或者可以接受平臺默認(rèn)的字符集。 每次調(diào)用 InputStreamReader 中的一個 read() 方法都會導(dǎo)致從底層輸入流讀取一個或多個字節(jié)。要啟用從字節(jié)到字符的有效轉(zhuǎn)換，可以提前從底層流讀取更多的字節(jié)，使其超過滿足當(dāng)前讀取操作所需的字節(jié)。API解釋非常清楚，InputStreamReader在底層讀取文件時仍然采用字節(jié)讀取，讀取字節(jié)后它需要根據(jù)一個指定的編碼格式來解析為字符，如果沒有指定編碼格式則采用系統(tǒng)默認(rèn)編碼格式。
String file = "C:\\test.txt";
String charset= "UTF-8";//寫字符換轉(zhuǎn)成字節(jié)流
FileOutputStream outputStream = newFileOutputStream(file);
OutputStreamWriter writer= newOutputStreamWriter(outputStream, charset);try{
writer.write("我是 cm");
}finally{
writer.close();
}//讀取字節(jié)轉(zhuǎn)換成字符
FileInputStream inputStream = newFileInputStream(file);
InputStreamReader reader= newInputStreamReader(
inputStream, charset);
StringBuffer buffer= newStringBuffer();char[] buf = new char[64];int count = 0;try{while ((count = reader.read(buf)) != -1) {
buffer.append(buf,0, count);
}
}finally{
reader.close();
}
System.out.println(buffer);
內(nèi)存
首先我們看下面這段簡單的代碼
String s = "我是 cm";byte[] bytes =s.getBytes();
String s1= new String(bytes,"GBK");
String s2= new String(bytes);
在這段代碼中我們看到了三處編碼轉(zhuǎn)換過程(一次編碼，兩次解碼)。先看String.getTytes():
public byte[] getBytes() {return StringCoding.encode(value, 0, value.length);
}
內(nèi)部調(diào)用StringCoding.encode()方法操作：
static byte[] encode(char[] ca, int off, intlen) {
String csn=Charset.defaultCharset().name();try{//use charset name encode() variant which provides caching.
returnencode(csn, ca, off, len);
}catch(UnsupportedEncodingException x) {
warnUnsupportedCharset(csn);
}try{return encode("ISO-8859-1", ca, off, len);
}catch(UnsupportedEncodingException x) {//If this code is hit during VM initialization, MessageUtils is//the only way we will be able to get any kind of error message.
MessageUtils.err("ISO-8859-1 charset not available: "
+x.toString());//If we can not find ISO-8859-1 (a required encoding) then things//are seriously wrong with the installation.
System.exit(1);return null;
}
}
encode(char[] paramArrayOfChar, int paramInt1, int paramInt2)方法首先調(diào)用系統(tǒng)的默認(rèn)編碼格式，如果沒有指定編碼格式則默認(rèn)使用ISO-8859-1編碼格式進(jìn)行編碼操作，進(jìn)一步深入如下：
String csn = (charsetName == null) ? "ISO-8859-1" : charsetName;
同樣的方法可以看到new String 的構(gòu)造函數(shù)內(nèi)部是調(diào)用StringCoding.decode()方法：
public String(byte bytes[], int offset, intlength, Charset charset) {if (charset == null)throw new NullPointerException("charset");
checkBounds(bytes, offset, length);this.value =StringCoding.decode(charset, bytes, offset, length);
}
decode方法和encode對編碼格式的處理是一樣的。
對于以上兩種情況我們只需要設(shè)置統(tǒng)一的編碼格式一般都不會產(chǎn)生亂碼問題。
編碼&編碼格式
首先先看看java編碼類圖[1]
首先根據(jù)指定的chart設(shè)置ChartSet類，然后根據(jù)ChartSet創(chuàng)建ChartSetEncoder對象，最后再調(diào)用 CharsetEncoder.encode 對字符串進(jìn)行編碼，不同的編碼類型都會對應(yīng)到一個類中，實(shí)際的編碼過程是在這些類中完成的。下面時序圖展示詳細(xì)的編碼過程：
通過這編碼的類圖和時序圖可以了解編碼的詳細(xì)過程。下面將通過一段簡單的代碼對ISO-8859-1、GBK、UTF-8編碼
public classTest02 {public static void main(String[] args) throwsUnsupportedEncodingException {
String string= "我是 cm";
Test02.printChart(string.toCharArray());
Test02.printChart(string.getBytes("ISO-8859-1"));
Test02.printChart(string.getBytes("GBK"));
Test02.printChart(string.getBytes("UTF-8"));
}/*** char轉(zhuǎn)換為16進(jìn)制*/
public static void printChart(char[] chars){for(int i = 0 ; i < chars.length ; i++){
System.out.print(Integer.toHexString(chars[i])+ " ");
}
System.out.println("");
}/*** byte轉(zhuǎn)換為16進(jìn)制*/
public static void printChart(byte[] bytes){for(int i = 0 ; i < bytes.length ; i++){
String hex= Integer.toHexString(bytes[i] & 0xFF);if (hex.length() == 1) {
hex= '0' +hex;
}
System.out.print(hex.toUpperCase()+ " ");
}
System.out.println("");
}
}
-------------------------outPut:6211 662f 20 636d
3F 3F20 636D
CE D2 CA C720 636D
E688 91 E6 98 AF 20 63 6D
通過程序我們可以看到“我是 cm”的結(jié)果為：
char[]：6211 662f 20 636d
ISO-8859-1：3F 3F 20 636D
GBK：CE D2 CA C720 636D
UTF-8：E6 88 91 E6 98 AF 20 63 6D
圖如下：
編碼&解碼
通過下圖我們可以了解在javaWeb中有哪些地方有轉(zhuǎn)碼：
用戶想服務(wù)器發(fā)送一個HTTP請求，需要編碼的地方有url、cookie、parameter，經(jīng)過編碼后服務(wù)器接受HTTP請求，解析HTTP請求，然后對url、cookie、parameter進(jìn)行解碼。在服務(wù)器進(jìn)行業(yè)務(wù)邏輯處理過程中可能需要讀取數(shù)據(jù)庫、本地文件或者網(wǎng)絡(luò)中的其他文件等等，這些過程都需要進(jìn)行編碼解碼。當(dāng)處理完成后，服務(wù)器將數(shù)據(jù)進(jìn)行編碼后發(fā)送給客戶端，瀏覽器經(jīng)過解碼后顯示給用戶。在這個整個過程中涉及的編碼解碼的地方較多，其中最容易出現(xiàn)亂碼的位置就在于服務(wù)器與客戶端進(jìn)行交互的過程。
上面整個過程可以概括成這樣，頁面編碼數(shù)據(jù)傳遞給服務(wù)器，服務(wù)器對獲得的數(shù)據(jù)進(jìn)行解碼操作，經(jīng)過一番業(yè)務(wù)邏輯處理后將最終結(jié)果編碼處理后傳遞給客戶端，客戶端解碼展示給用戶。所以下面我就請求對javaweb的編碼&解碼進(jìn)行闡述。
請求
客戶端想服務(wù)器發(fā)送請求無非就通過四中情況：
1、URL方式直接訪問。
2、頁面鏈接。
3、表單get提交
4、表單post提交
URL方式
對于URL，如果該URL中全部都是英文的那倒是沒有什么問題，如果有中文就要涉及到編碼了。如何編碼？根據(jù)什么規(guī)則來編碼？又如何來解碼呢？下面LZ將一一解答！首先看URL的組成部分：
在這URL中瀏覽器將會對path和parameter進(jìn)行編碼操作。為了更好地解釋編碼過程，使用如下URL
http://127.0.0.1:8080/perbank/我是cm?name=我是cm
將以上地址輸入到瀏覽器URL輸入框中，通過查看http 報文頭信息我們可以看到瀏覽器是如何進(jìn)行編碼的。下面是IE、Firefox、Chrome三個瀏覽器的編碼情況：
可以看到各大瀏覽器對“我是”的編碼情況如下：
path部分
Query String
Firefox
E6 88 91 E6 98 AF
E6 88 91 E6 98 AF
Chrome
E6 88 91 E6 98 AF
E6 88 91 E6 98 AF
IE
E6 88 91 E6 98 AF
CE D2 CA C7
查閱上篇博客的編碼可知對于path部分Firefox、chrome、IE都是采用UTF-8編碼格式，對于Query String部分Firefox、chrome采用UTF-8，IE采用GBK。至于為什么會加上%，這是因?yàn)閁RL的編碼規(guī)范規(guī)定瀏覽器將ASCII字符非 ASCII 字符按照某種編碼格式編碼成 16 進(jìn)制數(shù)字然后將每個 16 進(jìn)制表示的字節(jié)前加上“%”。
當(dāng)然對于不同的瀏覽器，相同瀏覽器不同版本，不同的操作系統(tǒng)等環(huán)境都會導(dǎo)致編碼結(jié)果不同，上表某一種情況，對于URL編碼規(guī)則下任何結(jié)論都是過早的。由于各大瀏覽器、各個操作系統(tǒng)對URL的URI、QueryString編碼都可能存在不同，這樣對服務(wù)器的解碼勢必會造成很大的困擾，下面我們將已tomcat，看tomcat是如何對URL進(jìn)行解碼操作的。
解析請求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，這個方法把傳過來的 URL 的 byte[] 設(shè)置到 org.apache.coyote.Request 的相應(yīng)的屬性中。這里的 URL 仍然是 byte 格式，轉(zhuǎn)成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：
protected voidconvertURI(MessageBytes uri, Request request)throwsException {
ByteChunk bc=uri.getByteChunk();int length =bc.getLength();
CharChunk cc=uri.getCharChunk();
cc.allocate(length,-1);
String enc= connector.getURIEncoding(); //獲取URI解碼集
if (enc != null) {
B2CConverter conv=request.getURIConverter();try{if (conv == null) {
conv= newB2CConverter(enc);
request.setURIConverter(conv);
}
}catch(IOException e) {...}if (conv != null) {try{
conv.convert(bc, cc, cc.getBuffer().length-cc.getEnd());
uri.setChars(cc.getBuffer(), cc.getStart(), cc.getLength());return;
}catch(IOException e) {...}
}
}//Default encoding: fast conversion
byte[] bbuf =bc.getBuffer();char[] cbuf =cc.getBuffer();int start =bc.getStart();for (int i = 0; i < length; i++) {
cbuf[i]= (char) (bbuf[i + start] & 0xff);
}
uri.setChars(cbuf,0, length);
}
從上面的代碼可知，對URI的解碼操作是首先獲取Connector的解碼集，該配置在server.xml中
如果沒有定義則會采用默認(rèn)編碼ISO-8859-1來解析。
對于Query String部分，我們知道無論我們是通過get方式還是POST方式提交，所有的參數(shù)都是保存在Parameters，然后我們通過request.getParameter，解碼工作就是在第一次調(diào)用getParameter方法時進(jìn)行的。在getParameter方法內(nèi)部它調(diào)用org.apache.catalina.connector.Request 的 parseParameters 方法，這個方法將會對傳遞的參數(shù)進(jìn)行解碼。下面代碼只是parseParameters方法的一部分：
//獲取編碼
String enc =getCharacterEncoding();//獲取ContentType 中定義的 Charset
boolean useBodyEncodingForURI =connector.getUseBodyEncodingForURI();if (enc != null) { //如果設(shè)置編碼不為空，則設(shè)置編碼為enc
parameters.setEncoding(enc);if (useBodyEncodingForURI) { //如果設(shè)置了Chartset，則設(shè)置queryString的解碼為ChartSet
parameters.setQueryStringEncoding(enc);
}
}else { //設(shè)置默認(rèn)解碼方式
parameters.setEncoding(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);if(useBodyEncodingForURI) {
parameters.setQueryStringEncoding(org.apache.coyote.Constants.DEFAULT_CHARACTER_ENCODING);
}
}
從上面代碼可以看出對query String的解碼格式要么采用設(shè)置的ChartSet要么采用默認(rèn)的解碼格式ISO-8859-1。注意這個設(shè)置的ChartSet是在 http Header中定義的ContentType，同時如果我們需要改指定屬性生效，還需要進(jìn)行如下配置：
上面部分詳細(xì)介紹了URL方式請求的編碼解碼過程。其實(shí)對于我們而言，我們更多的方式是通過表單的形式來提交。
表單GET
我們知道通過URL方式提交數(shù)據(jù)是很容易產(chǎn)生亂碼問題的，所以我們更加傾向于通過表單形式。當(dāng)用戶點(diǎn)擊submit提交表單時，瀏覽器會更加設(shè)定的編碼來編碼數(shù)據(jù)傳遞給服務(wù)器。通過GET方式提交的數(shù)據(jù)都是拼接在URL后面(可以當(dāng)做query String？？)來提交的，所以tomcat服務(wù)器在進(jìn)行解碼過程中URIEncoding就起到作用了。tomcat服務(wù)器會根據(jù)設(shè)置的URIEncoding來進(jìn)行解碼，如果沒有設(shè)置則會使用默認(rèn)的ISO-8859-1來解碼。假如我們在頁面將編碼設(shè)置為UTF-8，而URIEncoding設(shè)置的不是或者沒有設(shè)置，那么服務(wù)器進(jìn)行解碼時就會產(chǎn)生亂碼。這個時候我們一般可以通過new String(request.getParameter("name").getBytes("iso-8859-1"),"utf-8") 的形式來獲取正確數(shù)據(jù)。
表單POST
對于POST方式，它采用的編碼也是由頁面來決定的即contentType。當(dāng)我通過點(diǎn)擊頁面的submit按鈕來提交表單時，瀏覽器首先會根據(jù)ontentType的charset編碼格式來對POST表單的參數(shù)進(jìn)行編碼然后提交給服務(wù)器，在服務(wù)器端同樣也是用contentType中設(shè)置的字符集來進(jìn)行解碼(這里與get方式就不同了)，這就是通過POST表單提交的參數(shù)一般而言都不會出現(xiàn)亂碼問題。當(dāng)然這個字符集編碼我們是可以自己設(shè)定的：request.setCharacterEncoding(charset) 。
我們知道JSP頁面是需要轉(zhuǎn)換為servlet的，在轉(zhuǎn)換過程中肯定是要進(jìn)行編碼的。在JSP轉(zhuǎn)換為servlet過程中下面一段代碼起到至關(guān)重要的作用。
在上面代碼中有兩個地方存在編碼：pageEncoding、contentType的charset。其中pageEncoding是jsp文件本身的編碼，而contentType的charset是指服務(wù)器發(fā)送給客戶端時的內(nèi)容編碼。
jsp在轉(zhuǎn)換為Servlet的過程中是需要經(jīng)過主要的三次編碼轉(zhuǎn)換過程(除去數(shù)據(jù)庫編碼轉(zhuǎn)換、頁面參數(shù)輸入編碼轉(zhuǎn)換)：
第一次：轉(zhuǎn)換為.java文件；
第二次：轉(zhuǎn)換為.class文件；
第三次：業(yè)務(wù)邏輯處理后輸出。
第一階段
JVM將JSP編譯為.jsp文件。在這個過程中pageEncoding就起到作用了，JVM首先會獲取pageEncoding的值，如果該值存在則采用它設(shè)定的編碼來編譯，否則則采用file.encoding編碼來編譯。
第二階段
JVM將.java文件轉(zhuǎn)換為.class文件。在這個過程就與任何編碼的設(shè)置都沒有關(guān)系了，不管JSP采用了什么樣的編碼格式都將無效。經(jīng)過這個階段后.jsp文件就轉(zhuǎn)換成了統(tǒng)一的Unicode格式的.class文件了。
第三階段
后臺經(jīng)過業(yè)務(wù)邏輯處理后將產(chǎn)生的結(jié)果輸出到客戶端。在這個過程中contentType的charset就發(fā)揮了功效。如果設(shè)置了charset則瀏覽器就會使用指定的編碼格式進(jìn)行解碼，否則采用默認(rèn)的ISO-8859-1編碼格式進(jìn)行解碼處理。
流程如如下：
我們主要通過兩種形式提交向服務(wù)器發(fā)送請求：URL、表單。而表單形式一般都不會出現(xiàn)亂碼問題，亂碼問題主要是在URL上面。通過前面幾篇博客的介紹我們知道URL向服務(wù)器發(fā)送請求編碼過程實(shí)在是實(shí)在太混亂了。不同的操作系統(tǒng)、不同的瀏覽器、不同的網(wǎng)頁字符集，將導(dǎo)致完全不同的編碼結(jié)果。如果程序員要把每一種結(jié)果都考慮進(jìn)去，是不是太恐怖了？有沒有辦法，能夠保證客戶端只用一種編碼方法向服務(wù)器發(fā)出請求？
有！這里我主要提供以下幾種方法
一、javascript
使用javascript編碼不給瀏覽器插手的機(jī)會，編碼之后再向服務(wù)器發(fā)送請求，然后在服務(wù)器中解碼。在掌握該方法的時候，我們需要料及javascript編碼的三個方法：escape()、encodeURI()、encodeURIComponent()。
escape
采用SIO Latin字符集對指定的字符串進(jìn)行編碼。所有非ASCII字符都會被編碼為%xx格式的字符串，其中xx表示該字符在字符集中所對應(yīng)的16進(jìn)制數(shù)字。例如，格式對應(yīng)的編碼為%20。它對應(yīng)的解碼方法為unescape()。
事實(shí)上escape()不能直接用于URL編碼，它的真正作用是返回一個字符的Unicode編碼值。比如上面“我是cm”的結(jié)果為%u6211%u662Fcm，其中“我”對應(yīng)的編碼為6211，“是”的編碼為662F，“cm”編碼為cm。
注意，escape()不對"+"編碼。但是我們知道，網(wǎng)頁在提交表單的時候，如果有空格，則會被轉(zhuǎn)化為+字符。服務(wù)器處理數(shù)據(jù)的時候，會把+號處理成空格。所以，使用的時候要小心。
encodeURI
對整個URL進(jìn)行編碼，它采用的是UTF-8格式輸出編碼后的字符串。不過encodeURI除了ASCII編碼外對于一些特殊的字符也不會進(jìn)行編碼如：! @ # $& * ( ) = : / ; ? + '。
encodeURIComponent
把URI字符串采用UTF-8編碼格式轉(zhuǎn)化成escape格式的字符串。相對于encodeURI，encodeURIComponent會更加強(qiáng)大，它會對那些在encodeURI()中不被編碼的符號(; / ? : @ & = + $ , #)統(tǒng)統(tǒng)會被編碼。但是encodeURIComponent只會對URL的組成部分進(jìn)行個別編碼，而不用于對整個URL進(jìn)行編碼。對應(yīng)解碼函數(shù)方法decodeURIComponent。
當(dāng)然我們一般都是使用encodeURI方來進(jìn)行編碼操作。所謂的javascript兩次編碼后臺兩次解碼就是使用該方法。javascript解決該問題有一次轉(zhuǎn)碼、兩次轉(zhuǎn)碼兩種解決方法。
一次轉(zhuǎn)碼
javascript轉(zhuǎn)碼：
var url = '/ShowMoblieQRCode.servlet?name=我是cm';
window.location.href= encodeURI(url);
后臺處理:
String name = request.getParameter("name");
System.out.println("前臺傳入?yún)?shù)：" +name);
name= new String(name.getBytes("ISO-8859-1"),"UTF-8");
System.out.println("經(jīng)過解碼后參數(shù)：" + name);
輸出結(jié)果：
前臺傳入?yún)?shù)：??????cm
經(jīng)過解碼后參數(shù)：我是cm
二次轉(zhuǎn)碼
var url = '/ShowMoblieQRCode.servlet?name=我是cm';
window.location.href= encodeURI(encodeURI(url));
后臺處理：
String name = request.getParameter("name");
System.out.println("前臺傳入?yún)?shù)：" +name);
name= URLDecoder.decode(name,"UTF-8");
System.out.println("經(jīng)過解碼后參數(shù)：" + name);
輸出結(jié)果：
前臺傳入?yún)?shù)：E68891E698AFcm
經(jīng)過解碼后參數(shù)：我是cm
filter
使用過濾器，過濾器LZ提供兩種，第一種設(shè)置編碼，第二種直接在過濾器中進(jìn)行解碼操作。
過濾器1
該過濾器是直接設(shè)置request的編碼格式的。
public class CharacterEncoding implementsFilter {privateFilterConfig config ;
String encoding= null;public voiddestroy() {
config= null;
}public voiddoFilter(ServletRequest request, ServletResponse response,
FilterChain chain)throwsIOException, ServletException {
request.setCharacterEncoding(encoding);
chain.doFilter(request, response);
}public void init(FilterConfig config) throwsServletException {this.config =config;//獲取配置參數(shù)
String str = config.getInitParameter("encoding");if(str!=null){
encoding=str;
}
}
}
配置：
chineseEncoding
com.test.filter.CharacterEncoding
encoding
utf-8
chineseEncoding
/*
過濾器2
該過濾器在處理方法中將參數(shù)直接進(jìn)行解碼操作，然后將解碼后的參數(shù)重新設(shè)置到request的attribute中。
public class CharacterEncoding implementsFilter {protectedFilterConfig filterConfig ;
String encoding= null;public voiddestroy() {this.filterConfig = null;
}/*** 初始化*/
public voidinit(FilterConfig filterConfig) {this.filterConfig =filterConfig;
}/*** 將 inStr 轉(zhuǎn)為 UTF-8 的編碼形式
*
*@paraminStr 輸入字符串
*@returnUTF - 8 的編碼形式的字符串
*@throwsUnsupportedEncodingException*/
private String toUTF(String inStr) throwsUnsupportedEncodingException {
String outStr= "";if (inStr != null) {
outStr= new String(inStr.getBytes("iso-8859-1"), "UTF-8");
}returnoutStr;
}/*** 中文亂碼過濾處理*/
public voiddoFilter(ServletRequest servletRequest,
ServletResponse servletResponse, FilterChain chain)throwsIOException,
ServletException {
HttpServletRequest request=(HttpServletRequest) servletRequest;
HttpServletResponse response=(HttpServletResponse) servletResponse;//獲得請求的方式 (1.post or 2.get), 根據(jù)不同請求方式進(jìn)行不同處理
String method =request.getMethod();//1. 以 post 方式提交的請求 , 直接設(shè)置編碼為 UTF-8
if (method.equalsIgnoreCase("post")) {try{
request.setCharacterEncoding("UTF-8");
}catch(UnsupportedEncodingException e) {
e.printStackTrace();
}
}//2. 以 get 方式提交的請求
else{//取出客戶提交的參數(shù)集
Enumeration paramNames =request.getParameterNames();//遍歷參數(shù)集取出每個參數(shù)的名稱及值
while(paramNames.hasMoreElements()) {
String name= paramNames.nextElement(); //取出參數(shù)名稱
String values[] = request.getParameterValues(name); //根據(jù)參數(shù)名稱取出其值//如果參數(shù)值集不為空
if (values != null) {//遍歷參數(shù)值集
for (int i = 0; i < values.length; i++) {try{//回圈依次將每個值調(diào)用 toUTF(values[i]) 方法轉(zhuǎn)換參數(shù)值的字元編碼
String vlustr =toUTF(values[i]);
values[i]=vlustr;
}catch(UnsupportedEncodingException e) {
e.printStackTrace();
}
}//將該值以屬性的形式藏在 request
request.setAttribute(name, values);
}
}
}//設(shè)置響應(yīng)方式和支持中文的字元集
response.setContentType("text/html;charset=UTF-8");//繼續(xù)執(zhí)行下一個 filter, 無一下個 filter 則執(zhí)行請求
chain.doFilter(request, response);
}
}
配置：
chineseEncoding
com.test.filter.CharacterEncoding
chineseEncoding
/*
其他
1、設(shè)置pageEncoding、contentType
2、設(shè)置tomcat的URIEncoding
在默認(rèn)情況下，tomcat服務(wù)器使用的是ISO-8859-1編碼格式來編碼的，URIEncoding參數(shù)對get請求的URL進(jìn)行編碼，所以我們只需要在tomcat的server.xml文件的標(biāo)簽中加上URIEncoding="utf-8"即可。
,請尊重作者辛勤勞動成果,轉(zhuǎn)載說明出處.
總結(jié)
以上是生活随笔為你收集整理的java中文乱码decode_Java中文乱码处理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 最大流（Dinic算法）
- 下一篇： slickedit快捷键冲突问题