一、主題:關(guān)于java的中文問題
java的中文問題比較突出,主要表現(xiàn)在控制面板輸出,jsp頁面輸出和數(shù)據(jù)庫訪問上。
本文盡量避開字體問題,而只談編碼。通過本文,你可以了解java中文問題的由來,問題
的解決方法,其中提了一下用jdbc訪問數(shù)據(jù)庫的方法。
二、問題描述:
1)在中文w2000中文窗口編譯和運行,用的是國際版的jdk,連接的是中文w2000下的cp936
編碼的sql server數(shù)據(jù)庫:
j:\exercise\demo\encode\helloworld>make
created by xcompiler. philosoft all rights reserved.
wed may 30 02:54:45 cst 2001
j:\exercise\demo\encode\helloworld>run
created by xrunner. philosoft all rights reserved.
wed may 30 02:51:33 cst 2001
中文
[b@7bc8b569
[b@7b08b569
[b@7860b569
中文
中文
????
中文
中文
????
??
??
??
2)如果在中文w2000的西文窗口(編碼為437)下編譯,用java運行則由于無字體而無法正
常顯示,如果象上面一樣在中文w2000的中文窗口運行,輸出為:
j:\exercise\demo\encode\helloworld>run
created by xrunner. philosoft all rights reserved.
wed may 30 02:51:33 cst 2001
????
[b@7bc0b66a
[b@7b04b66a
[b@7818b66a
????
????
????
????
????
????
中文
中文
????
三)分析
1)出現(xiàn)有亂碼(也就是?)。由于只出現(xiàn)?而沒出現(xiàn)小方框,說明只是編碼有問題,而不
是字體問題。 在編碼中,如果從一種字符集轉(zhuǎn)換到別一種字符集,比較典型的是從gb2312
轉(zhuǎn)換到iso8859_1(即ascii),那么很多漢字(半個漢字)是無法映射到西文字符中去的
,在這種情形下,系統(tǒng)就把這些字符用?代替。同樣,也存在小字符集無法到大字符集的
情況,具體原因這里就不詳談了。
2)出現(xiàn)了中文環(huán)境編譯,中文環(huán)境運行時漢字顯示有正確也有不正確的地方,同樣,在西
文環(huán)境下編譯,在中文環(huán)境下運行時也出現(xiàn)類似情況。這是由于自動(默認)或手工(也
就new string(bytes[,encode])和bytes getbytes([encode]))轉(zhuǎn)碼的結(jié)果。
2.1)在java源文件-->javac-->class-->java-->getbytes()-->new string()-->顯示的過
程中,每一步都有編碼的轉(zhuǎn)換過程,這個過程總是存在的,只是有的時候用默認的參數(shù)進
行。下面我們一步一步分析為什么出現(xiàn)上面的情形。
2.2)這里是源代碼:
helloworld.java:
------------------------
public class helloworld
{
public static void main(string[] argv){
try{
system.out.println("中文");//1
system.out.println("中文".getbytes());//2
system.out.println("中文".getbytes("gb2312"));//3
system.out.println("中文".getbytes("iso8859_1"));//4
system.out.println(new string("中文".getbytes()));//5
system.out.println(new string("中文".getbytes(),"gb2312"));//6
system.out.println(new string("中文".getbytes(),"iso8859_1"));//7
system.out.println(new string("中文".getbytes("gb2312")));//8
system.out.println(new string("中文".getbytes("gb2312"),"gb2312"));//9
system.out.println(new
string("中文".getbytes("gb2312"),"iso8859_1"));//10
system.out.println(new string("中文".getbytes("iso8859_1")));//11
system.out.println(new
string("中文".getbytes("iso8859_1"),"gb2312"));//12
system.out.println(new
string("中文".getbytes("iso8859_1"),"iso8859_1"));//13
}
catch(exception e){
e.printstacktrace();
}
}
}
為了方便起見,在每個轉(zhuǎn)換的后面加了操作序號,分別為1,2,...,13。
2.3)需要說明的是,javac是以系統(tǒng)默認編碼讀入源文件,然后按unicode進行編碼的。在
java運行的時候,java也是采用unicode編碼的,并且默認輸入和輸出的都是操作系統(tǒng)的默
認編碼,也就是說在new string(bytes[,encode])中,系統(tǒng)認為輸入的是編碼為encode的
字節(jié)流,換句話說,如果按encode來翻譯bytes才能得到正確的結(jié)果,這個結(jié)果最后要在ja
va中保存,它還是要從這個encode轉(zhuǎn)換成unicode,也就是說有bytes-->encode字符-->uni
code字符的轉(zhuǎn)換;而在string.getbytes([encode])中,系統(tǒng)要做一個unicode字符-->enco
de字符-->bytes的轉(zhuǎn)換。
在這個例子中,除那個英文窗口編碼的時候除外,其實情形下默認編碼都是gbk(在本例中
,我們暫且把gbk和gb2312等同看待)。
2.4)由于在未指明在上面的兩個用代碼實現(xiàn)的轉(zhuǎn)換中,如果未指定encode,系統(tǒng)將采用默
認的編碼(這里為gbk),我們認為上面的5,6,7和8,9,10是一樣的,8和9、11和12也是一
樣的,所以我們在討論中將只討論1,9,10,12,13。其中的2,3,4只是用于測試,不在我們的
討論范圍之內(nèi)。
2.5)下面我們來跟蹤程序中的“中”字的轉(zhuǎn)換歷程,我們先說在中文窗口下作的編譯和運
行過程,注意在下面的字母下標中,我有意識地使用了一些數(shù)字,以表示相同,相異還是
相關(guān)2.5.1)我們先以上面的13個代碼段中的的代碼9為例:
步驟 內(nèi)容 地點 說明
01: c1 helloworld.java c1泛指一個gbk字符
02: u1 javac讀取 u1泛指一個unicode字符
03: c1 getbytes()第一步 java先和操作系統(tǒng)交流
04: b1,b2 getbytes()第二步 然后返回字節(jié)數(shù)組
05: c1 new string()第一步 java先和操作系統(tǒng)交流
06: u1 new string()第二步 然后返回字符
07: c1 println(string) 能顯示“中”字,內(nèi)容和原來的相同
2.5.2)然后再以代碼段10為例,我們注意到只是:
步驟 內(nèi)容 地點 說明
01: c1 helloworld.java c1泛指一個gbk字符
02: u1 javac讀取 u1泛指一個unicode字符
03: c1 getbytes()第一步 java先和操作系統(tǒng)交流
04: b1,b2 getbytes()第二步 然后返回字節(jié)數(shù)組
05: c3,c4 new string()第一步 java先和操作系統(tǒng)交流,這時解析錯誤
06: u5,u6 new string()第二步 然后返回字符
07: c3,c4 println(string) 由于中字給分成了兩半,在iso8859_1中剛好也沒有字符
能映射上,所以顯示為“??”。在上面的示例中,
“中文”兩個字就顯示為“????”
2.5.3)在完全中文模式下的其它情形類似,我就不多說了
2.6)我們接著看為什么在西文dos窗口下編譯出來的類在中文窗口下也出現(xiàn)類似情形,特
別是為什么居然有的情形下還能正確顯示漢字。
2.6.1)我們還是先以代碼段9為例:
步驟 內(nèi)容 地點 說明
01: c1c2 helloworld.java c1c2分別泛指一個iso8859_1字符,“中”字被拆開
02: u3u4 javac讀取 u1u2泛指一個unicode字符
03: c5c6 getbytes()第一步 java先和操作系統(tǒng)交流,這時解析錯誤
04: b5b6b7b8 getbytes()第二步 然后返回字節(jié)數(shù)組
05: c5c6 new string()第一步 java先和操作系統(tǒng)交流
06: u3u4 new string()第二步 然后返回字符
07: c5c6 println(string) 雖然同是兩個字符,但已不是最初的“兩個iso8859_1字
符”,而是“兩個bgk字符”,“中”顯示成了“??”
而“中文”就顯示成了“????”
2.6.2)下面我們以代碼段12為例,因為它能正確顯示漢字
步驟 內(nèi)容 地點 說明
01: c1c2 helloworld.java c1c2分別泛指一個iso8859_1字符,“中”字被拆開
02: u3u4 javac讀取 u1u2泛指一個unicode字符
03: c1c2 getbytes()第一步 java先和操作系統(tǒng)交流(注意還是正確的哦!)
04: b5b6 getbytes()第二步 然后返回字節(jié)數(shù)組(這是很關(guān)鍵的一步!)
05: c12 new string()第一步 java先和操作系統(tǒng)交流(這是更關(guān)鍵的一步,java已經(jīng)知
道b5b6要解析成一個漢字!)
06: u7 new string()第二步 然后返回字符(真是一個項兩!u7包含了u3u4的信息)
07: c12 println(string) 這就原來的“中”字,很委屈被javac冤枉了一回,不過被程
序員撥亂反正了一下!當然,“中文”兩個字都能正確顯示了!
3)那為什么有的時候用jdbc的
new string(recordset.getbytes(int)[,encode])
recordset.getsting(int)
recordset.setbytes(string.getbytes([encode]))
和
recordset.setstring(string)
的時候會出現(xiàn)亂碼了呢?
其實問題就出現(xiàn)在編寫jdbc的的也考慮了編碼問題,它從數(shù)據(jù)庫讀取數(shù)據(jù)后,可能自作主
張做了一個從gb2312(默認編碼)到unicode的轉(zhuǎn)換,我的這個weblogic for sql server
的jdbc driver就是這樣的,當我讀字串的時候,發(fā)出讀到的不是正確的漢字,可恨的是我
卻可以直接寫漢字字串,這讓人多少有點難以接受!
也就是說,我們不得不在讀或?qū)懙臅r候進行轉(zhuǎn)碼,盡管這個轉(zhuǎn)碼有的時候不是那么明顯,
這是因為我們使用了默認的編碼進行轉(zhuǎn)碼。jdbc driver所做的操作,我們只有進入到源代
碼內(nèi)部才能清楚,不是嗎?

文章整理:西部數(shù)碼--專業(yè)提供域名注冊、虛擬主機服務(wù)
http://www.west263.com
以上信息與文章正文是不可分割的一部分,如果您要轉(zhuǎn)載本文章,請保留以上信息,謝謝!
java的中文問題比較突出,主要表現(xiàn)在控制面板輸出,jsp頁面輸出和數(shù)據(jù)庫訪問上。
本文盡量避開字體問題,而只談編碼。通過本文,你可以了解java中文問題的由來,問題
的解決方法,其中提了一下用jdbc訪問數(shù)據(jù)庫的方法。
二、問題描述:
1)在中文w2000中文窗口編譯和運行,用的是國際版的jdk,連接的是中文w2000下的cp936
編碼的sql server數(shù)據(jù)庫:
j:\exercise\demo\encode\helloworld>make
created by xcompiler. philosoft all rights reserved.
wed may 30 02:54:45 cst 2001
j:\exercise\demo\encode\helloworld>run
created by xrunner. philosoft all rights reserved.
wed may 30 02:51:33 cst 2001
中文
[b@7bc8b569
[b@7b08b569
[b@7860b569
中文
中文
????
中文
中文
????
??
??
??
2)如果在中文w2000的西文窗口(編碼為437)下編譯,用java運行則由于無字體而無法正
常顯示,如果象上面一樣在中文w2000的中文窗口運行,輸出為:
j:\exercise\demo\encode\helloworld>run
created by xrunner. philosoft all rights reserved.
wed may 30 02:51:33 cst 2001
????
[b@7bc0b66a
[b@7b04b66a
[b@7818b66a
????
????
????
????
????
????
中文
中文
????
三)分析
1)出現(xiàn)有亂碼(也就是?)。由于只出現(xiàn)?而沒出現(xiàn)小方框,說明只是編碼有問題,而不
是字體問題。 在編碼中,如果從一種字符集轉(zhuǎn)換到別一種字符集,比較典型的是從gb2312
轉(zhuǎn)換到iso8859_1(即ascii),那么很多漢字(半個漢字)是無法映射到西文字符中去的
,在這種情形下,系統(tǒng)就把這些字符用?代替。同樣,也存在小字符集無法到大字符集的
情況,具體原因這里就不詳談了。
2)出現(xiàn)了中文環(huán)境編譯,中文環(huán)境運行時漢字顯示有正確也有不正確的地方,同樣,在西
文環(huán)境下編譯,在中文環(huán)境下運行時也出現(xiàn)類似情況。這是由于自動(默認)或手工(也
就new string(bytes[,encode])和bytes getbytes([encode]))轉(zhuǎn)碼的結(jié)果。
2.1)在java源文件-->javac-->class-->java-->getbytes()-->new string()-->顯示的過
程中,每一步都有編碼的轉(zhuǎn)換過程,這個過程總是存在的,只是有的時候用默認的參數(shù)進
行。下面我們一步一步分析為什么出現(xiàn)上面的情形。
2.2)這里是源代碼:
helloworld.java:
------------------------
public class helloworld
{
public static void main(string[] argv){
try{
system.out.println("中文");//1
system.out.println("中文".getbytes());//2
system.out.println("中文".getbytes("gb2312"));//3
system.out.println("中文".getbytes("iso8859_1"));//4
system.out.println(new string("中文".getbytes()));//5
system.out.println(new string("中文".getbytes(),"gb2312"));//6
system.out.println(new string("中文".getbytes(),"iso8859_1"));//7
system.out.println(new string("中文".getbytes("gb2312")));//8
system.out.println(new string("中文".getbytes("gb2312"),"gb2312"));//9
system.out.println(new
string("中文".getbytes("gb2312"),"iso8859_1"));//10
system.out.println(new string("中文".getbytes("iso8859_1")));//11
system.out.println(new
string("中文".getbytes("iso8859_1"),"gb2312"));//12
system.out.println(new
string("中文".getbytes("iso8859_1"),"iso8859_1"));//13
}
catch(exception e){
e.printstacktrace();
}
}
}
為了方便起見,在每個轉(zhuǎn)換的后面加了操作序號,分別為1,2,...,13。
2.3)需要說明的是,javac是以系統(tǒng)默認編碼讀入源文件,然后按unicode進行編碼的。在
java運行的時候,java也是采用unicode編碼的,并且默認輸入和輸出的都是操作系統(tǒng)的默
認編碼,也就是說在new string(bytes[,encode])中,系統(tǒng)認為輸入的是編碼為encode的
字節(jié)流,換句話說,如果按encode來翻譯bytes才能得到正確的結(jié)果,這個結(jié)果最后要在ja
va中保存,它還是要從這個encode轉(zhuǎn)換成unicode,也就是說有bytes-->encode字符-->uni
code字符的轉(zhuǎn)換;而在string.getbytes([encode])中,系統(tǒng)要做一個unicode字符-->enco
de字符-->bytes的轉(zhuǎn)換。
在這個例子中,除那個英文窗口編碼的時候除外,其實情形下默認編碼都是gbk(在本例中
,我們暫且把gbk和gb2312等同看待)。
2.4)由于在未指明在上面的兩個用代碼實現(xiàn)的轉(zhuǎn)換中,如果未指定encode,系統(tǒng)將采用默
認的編碼(這里為gbk),我們認為上面的5,6,7和8,9,10是一樣的,8和9、11和12也是一
樣的,所以我們在討論中將只討論1,9,10,12,13。其中的2,3,4只是用于測試,不在我們的
討論范圍之內(nèi)。
2.5)下面我們來跟蹤程序中的“中”字的轉(zhuǎn)換歷程,我們先說在中文窗口下作的編譯和運
行過程,注意在下面的字母下標中,我有意識地使用了一些數(shù)字,以表示相同,相異還是
相關(guān)2.5.1)我們先以上面的13個代碼段中的的代碼9為例:
步驟 內(nèi)容 地點 說明
01: c1 helloworld.java c1泛指一個gbk字符
02: u1 javac讀取 u1泛指一個unicode字符
03: c1 getbytes()第一步 java先和操作系統(tǒng)交流
04: b1,b2 getbytes()第二步 然后返回字節(jié)數(shù)組
05: c1 new string()第一步 java先和操作系統(tǒng)交流
06: u1 new string()第二步 然后返回字符
07: c1 println(string) 能顯示“中”字,內(nèi)容和原來的相同
2.5.2)然后再以代碼段10為例,我們注意到只是:
步驟 內(nèi)容 地點 說明
01: c1 helloworld.java c1泛指一個gbk字符
02: u1 javac讀取 u1泛指一個unicode字符
03: c1 getbytes()第一步 java先和操作系統(tǒng)交流
04: b1,b2 getbytes()第二步 然后返回字節(jié)數(shù)組
05: c3,c4 new string()第一步 java先和操作系統(tǒng)交流,這時解析錯誤
06: u5,u6 new string()第二步 然后返回字符
07: c3,c4 println(string) 由于中字給分成了兩半,在iso8859_1中剛好也沒有字符
能映射上,所以顯示為“??”。在上面的示例中,
“中文”兩個字就顯示為“????”
2.5.3)在完全中文模式下的其它情形類似,我就不多說了
2.6)我們接著看為什么在西文dos窗口下編譯出來的類在中文窗口下也出現(xiàn)類似情形,特
別是為什么居然有的情形下還能正確顯示漢字。
2.6.1)我們還是先以代碼段9為例:
步驟 內(nèi)容 地點 說明
01: c1c2 helloworld.java c1c2分別泛指一個iso8859_1字符,“中”字被拆開
02: u3u4 javac讀取 u1u2泛指一個unicode字符
03: c5c6 getbytes()第一步 java先和操作系統(tǒng)交流,這時解析錯誤
04: b5b6b7b8 getbytes()第二步 然后返回字節(jié)數(shù)組
05: c5c6 new string()第一步 java先和操作系統(tǒng)交流
06: u3u4 new string()第二步 然后返回字符
07: c5c6 println(string) 雖然同是兩個字符,但已不是最初的“兩個iso8859_1字
符”,而是“兩個bgk字符”,“中”顯示成了“??”
而“中文”就顯示成了“????”
2.6.2)下面我們以代碼段12為例,因為它能正確顯示漢字
步驟 內(nèi)容 地點 說明
01: c1c2 helloworld.java c1c2分別泛指一個iso8859_1字符,“中”字被拆開
02: u3u4 javac讀取 u1u2泛指一個unicode字符
03: c1c2 getbytes()第一步 java先和操作系統(tǒng)交流(注意還是正確的哦!)
04: b5b6 getbytes()第二步 然后返回字節(jié)數(shù)組(這是很關(guān)鍵的一步!)
05: c12 new string()第一步 java先和操作系統(tǒng)交流(這是更關(guān)鍵的一步,java已經(jīng)知
道b5b6要解析成一個漢字!)
06: u7 new string()第二步 然后返回字符(真是一個項兩!u7包含了u3u4的信息)
07: c12 println(string) 這就原來的“中”字,很委屈被javac冤枉了一回,不過被程
序員撥亂反正了一下!當然,“中文”兩個字都能正確顯示了!
3)那為什么有的時候用jdbc的
new string(recordset.getbytes(int)[,encode])
recordset.getsting(int)
recordset.setbytes(string.getbytes([encode]))
和
recordset.setstring(string)
的時候會出現(xiàn)亂碼了呢?
其實問題就出現(xiàn)在編寫jdbc的的也考慮了編碼問題,它從數(shù)據(jù)庫讀取數(shù)據(jù)后,可能自作主
張做了一個從gb2312(默認編碼)到unicode的轉(zhuǎn)換,我的這個weblogic for sql server
的jdbc driver就是這樣的,當我讀字串的時候,發(fā)出讀到的不是正確的漢字,可恨的是我
卻可以直接寫漢字字串,這讓人多少有點難以接受!
也就是說,我們不得不在讀或?qū)懙臅r候進行轉(zhuǎn)碼,盡管這個轉(zhuǎn)碼有的時候不是那么明顯,
這是因為我們使用了默認的編碼進行轉(zhuǎn)碼。jdbc driver所做的操作,我們只有進入到源代
碼內(nèi)部才能清楚,不是嗎?
文章整理:西部數(shù)碼--專業(yè)提供域名注冊、虛擬主機服務(wù)
http://www.west263.com
以上信息與文章正文是不可分割的一部分,如果您要轉(zhuǎn)載本文章,請保留以上信息,謝謝!