java字符串編碼總結

S tring newStr = new String(oldStr.getBytes(), "UTF-8");

java中的String類是按照unicode進行編碼的，當使用String(byte[] bytes, String encoding)構造字符串時，encoding所指的是bytes中的數據是按照那種方式編碼的，而不是最後產生的String是什麼編碼方式，換句話說，是讓系統把bytes中的數據由encoding編碼方式轉換成unicode編碼。若是不指明，bytes的編碼方式將由jdk根據操做系統決定。

當咱們從文件中讀數據時，最好使用InputStream方式，而後採用String(byte[] bytes, String encoding)指明文件的編碼方式。不要使用Reader方式，由於Reader方式會自動根據jdk指明的編碼方式把文件內容轉換成unicode 編碼。

當咱們從數據庫中讀文本數據時，採用ResultSet.getBytes()方法取得字節數組，一樣採用帶編碼方式的字符串構造方法便可。

ResultSet rs;
bytep[] bytes = rs.getBytes();
String str = new String(bytes, "gb2312");

不要採起下面的步驟。

ResultSet rs;
String str = rs.getString();
str = new String(str.getBytes("iso8859-1"), "gb2312");

這種編碼轉換方式效率底。之因此這麼作的緣由是，ResultSet在getString()方法執行時，默認數據庫裏的數據編碼方式爲 iso8859-1。系統會把數據依照iso8859-1的編碼方式轉換成unicode。使用str.getBytes("iso8859-1")把數據還原，而後利用new String(bytes, "gb2312")把數據從gb2312轉換成unicode，中間多了好多步驟。

從HttpRequest中讀參數時，利用reqeust.setCharacterEncoding()方法設置編碼方式，讀出的內容就是正確的了。

先說Java。
JVM裏面的任何字符串資源都是Unicode，就是說，任何String類型的數據都是Unicode編碼。沒有例外。既然只有一種編碼，那麼，咱們能夠這麼說，JVM裏面的String是不帶編碼的。String至關於 char[]。
JVM裏面的 byte[] 數據是帶編碼的。好比，Big5，GBK，GB2312，UTF-8之類的。
一個GBK編碼的byte[] 轉換成 String，其實就是從GBK編碼向Unicode編碼轉換。
一個String轉換成一個Big5編碼的byte[]，其實就是從Unicode編碼向Big5編碼轉換。
因此，Unicode是全部編碼轉換的中間介質。全部的編碼都有一個轉換器能夠轉換到Unicode，而Unicode也能夠轉換到其餘全部的編碼。這樣構成了一個總線結構。
好比，若是總共有10種編碼，那麼只須要 10 + 10 = 20個轉換器就夠了。若是要是兩兩直接轉換，那麼，須要的轉換器數量是一個組合數字，須要90個轉換器。

一個系統的不一樣部分，都有本身的編碼。好比，數據庫，文件，JVM，瀏覽器這4個部分。
在這些部分之間數據交換的地方，就會出現編碼問題。好比，數據庫和JVM之間，文件和JVM之間，瀏覽器和JVM之間。這些問題的原理都是相通的。

編碼問題最容易處理的地方是文件和JVM之間。文件IO API帶有encoding 參數，請自行查閱。
最不容易出現編碼問題的地方是數據庫和JVM之間。這應該是數據庫JDBC鏈接的基本功能。本文不專門進行討論。
最容易出問題的地方是瀏覽器和服務器JVM之間（其實，代碼裏面的字符串更容易出問題，不過，我已經事先聲明，本文不討論代碼中的字符串編碼）。下面主要討論這塊瀏覽器和服務器JVM之間的編碼問題。

咱們把瀏覽器編碼叫作 Browser_Charset，把JVM編碼叫作JVM_Charset（一般等於服務器系統編碼）。
當瀏覽器的數據過來的時候，是一個帶有Browser_Charset的byte[]。
若是用戶處理程序須要一個String類型的數據，那麼JVM會好心好意地把這個byte[]轉換成String。使用的轉換器是 JVM_Charset -> Unicode。
注意，若是這個時候，Browser_Charset 和 JVM_Charset並不相等。那麼，這個自動轉換是錯誤的。
爲了彌補這個錯誤。咱們須要作兩步工做。
(1) Unicode -> JVM_Charset，把這個String 轉換回到原來的 byte[]。
(2) Browser_Charset -> Unicode，把這個還原的byte[]轉換成 String。

這個效果，和直接從HTTP Request取得byte[]，而後執行 (2) Browser_Charset -> Unicode 的效果是同樣的。

若是在Request裏面設置了CharacterEncoding，那麼POST Data參數就不須要本身手工轉換了，web server的自動轉換就是正確的。URL的參數編碼還涉及到URL編碼，須要考慮的問題多一些，沒有這麼簡單。

JVM把數據發到瀏覽器的時候。也須要考慮編碼問題。能夠在Response裏面設置。另外，HTML Meta Header裏面也能夠設置編碼，提醒Browser選擇正確編碼。

有些語言的VM或者解釋器的字符串編碼可能不一樣。好比，Ruby。不過，編碼轉換原理都是同樣的。

That is all.

JAVA字符編碼

1、概要
在JAVA應用程序特別是基於WEB的程序中，常常遇到字符的編碼問題。爲了防止出現亂碼，首先須要瞭解JAVA是如何處理字符的，這樣就能夠有目的地在輸入/輸出環節中增長必要的轉碼。其次，因爲各類服務器有不一樣的處理方式，還須要多作試驗，確保使用中不出現亂碼。
2、基本概念
2．1 JAVA中字符的表達
JAVA 中有char、byte、String這幾個概念。char 指的是一個UNICODE字符，爲16位的整數。byte 是字節，字符串在網絡傳輸或存儲前須要轉換爲byte數組。在從網絡接收或從存儲設備讀取後須要將byte數組轉換成String。String是字符串，能夠當作是由char組成的數組。String 和 char 爲內存形式，byte是網絡傳輸或存儲的序列化形式。
舉例：
英
String ying = 「英」;
char ying = ying.charAt(0);
String yingHex = Integer.toHexString(ying);
82 F1
byte yingGBBytes = ying.getBytes(「GBK」);
GB編碼的字節數值
D3 A2
2．2 編碼方式的簡介
String序列化成byte數組或反序列化時須要選擇正確的編碼方式。若是編碼方式不正確，就會獲得一些0x3F的值。經常使用的字符編碼方式有ISO8859_一、GB23十二、GBK、UTF-8/UTF-16/UTF-32。
ISO8859_1用來編碼拉丁文，它由單字節（0－255）組成。
GB23十二、GBK用來編碼簡體中文，它有單字節和雙字節混合組成。最高位爲1的字節和下一個字節構成一個漢字，最高位爲0的字節是ASCII碼。
UTF-8/UTF-16/UTF-32是國際標準UNICODE的編碼方式。 用得最多的是UTF-8，主要是由於它在對拉丁文編碼時節約空間。
UNICODE值 UTF-8編碼
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
3、J2SE中相關的函數
String str =」英」;
//取得GB2312編碼的字節
byte[] bytesGB2312 = str.getBytes(「GB2312」);
//取得平臺缺省編碼的字節(solaris爲ISO8859_1,windows爲GB2312)
byte[] bytesDefault = str.getBytes();
//用指定的編碼將字節轉換成字符串
String newStrGB = new String(bytesGB2312, 「GB2312」);

//用平臺缺省的編碼將字節轉換成字符串(solaris爲ISO8859_1,windows爲GB2312)
String newStrDefault = new String(bytesDefault);
//用指定的編碼從字節流裏面讀取字符
InputStream in = xxx;
InputStreamReader reader = InputStreamReader( in, 「GB2312」);
char aChar = reader.read();
4、JSP、數據庫的編碼
4．1 JSP中的編碼
(1) 靜態聲明:
CHARSET有兩個做用：
JSP文件的編碼方式：在讀取JSP文件、生成JAVA類時，源JSP文件中漢字的編碼
JSP輸出流的編碼方式：在執行JSP時，往response流裏面寫入數據的編碼方式
(2) 動態改變:在往response流裏面寫數據前能夠調用response.setContentType()，設定正確的編碼類型。
(3) 在TOMCAT中，由Request.getParameter() 獲得的參數，編碼方式都是ISO8859_1。因此若是在瀏覽器輸入框內輸入一個漢字「英」，在服務器端就獲得一個ISO8859_1編碼的（0x00,0xD3,0x00,0xA2）。因此一般在接收參數時轉碼：
String wrongStr = response.getParameter(「name」);
String correctStr = new String(wrongStr.getBytes(「ISO8859_1」),」GB2312」);
在最新的SERVLET規範裏面，也能夠在獲取參數以前執行以下代碼：
request.setCharacterEncoding(「GB2312」);
4．2 數據庫的編碼
(1) 數據庫使用UTF-16
若是String中是UNICODE字符，寫入讀出時不須要轉碼
(2) 數據庫使用ISO8859_1
若是String中是UNICODE字符，寫入讀出時須要轉碼
寫入：String newStr = new String(oldStr.getByte(「GB2312」), 「ISO8859_1」);
讀出：String newStr = new String(oldStr.getByte(「ISO8859_1」),」GB2312」);
5、源文件的編碼
5．1 資源文件
資源文件的編碼方式和編輯平臺相關。在WINDOWS平臺下編寫的資源文件，以GB2312方式編碼。在編譯時須要轉碼，以確保在各個平臺上的正確性：
native2ascii ?encoding GB2312 source.properties
這樣從資源文件中讀出的就是正確的UNICODE字符串。
5．2 源文件
源文件的編碼方式和編輯平臺相關。在WINDOWS平臺下開發的源文件，以GB2312方式編碼。在編譯的時候，須要指定源文件的編碼方式：
javac ?encoding GB2312
JAVA編譯後生成的字節文件的編碼爲UTF-8。

①最新版TOMCAT4.1.18支持request.setCharacterEncoding(String enc)
②資源文件轉碼成company.name=u82f1u65afu514b
③若是數據庫使用utf-16則不須要這部分轉碼
④頁面上應有
轉碼?:
String s = new String
(request.getParameter(「name」).getBytes(「ISO8859_1」),」GB2312」);
轉碼?:
String s = new String(name.getBytes(「GB2312」),」ISO8859_1」);
轉碼?:
String s = new String(name.getBytes(「ISO8859_1」),」 GB2312」);



=========================================================

JAVA內部到底是用的什麼字符編碼呢？這個問題我也找了好久，後來在THINK IN JAVA 3rd的12章裏看到一個例子出現了UTF-16BE，難道是它？
byte[] utf_16be = name.getBytes("utf-16be");

printbyte(utf_16be);

結果出來了：58 02 length = 2
哈哈，I got it!很少很多兩個字節，內容也同樣。果真是它。同時我在裏面也看到，UNICODE的編碼還有一個LE，這裏的BE,LE我想應該是bigendian和littleendian吧。

==========================================================

import java.io.*;
public class TestCodeIO {
public static void main(String[] args) throws Exception{
InputStreamReader isr = new InputStreamReader(System.in,"iso8859-1");
//Create an InputStreamReader that uses the given charset decoder
BufferedReader br = new BufferedReader (isr);
String strLine = br.readLine();
br.close();
isr.close();
System.out.println(strLine);
System.out.println(new String (strLine.getBytes(),"iso8859-1"));//錯誤改法
//Encodes this String (strLine) into a sequence of bytes using the platform's
//default charset(gb2312) then constructs a new String by decoding the
//specified array of bytes using the specified charset (iso8859-1)
//because this String (strLine) uses the charset decoder "iso8859-1",so it can
//only be encoded by "iso8859-1",cann't be encoded by the platform's default
//charset "gb2312",so this line is wrong.
System.out.println(new String (strLine.getBytes("iso8859-1")));//正確改法
//Encodes this String (strLine) into a sequence of bytes using the named
//charset (iso8859-1),then constructs a new String by decoding the
//specified array of bytes using the platform's default charset (gb2312).
//This line is right.
}
}

上面的英文註釋已經說得很清楚了，這裏我仍是解釋一下吧：

首先是錯誤的改法 System.out.println(new String (strLine.getBytes(),"iso8859-1"));
這句代碼是將strLine中的字符串用系統默認的編碼方式（這裏是gb2312）
轉換爲字節序列，而後用指定的編碼方式（這裏是iso8859-1）構造一個新的
String對象，並打印到屏幕上。
錯誤在哪裏呢？

請注意這一段代碼
InputStreamReader isr = new InputStreamReader(System.in,"iso8859-1");
BufferedReader br = new BufferedReader (isr);
String strLine = br.readLine();
這裏strLine存儲的內容是用指定的編碼方式（iso8859-1）存儲的，而轉換成字節碼
的時候（這句代碼strLine.getBytes()）卻使用了系統默認的gb2312編碼，因此固然就
輸出亂碼了！而後用gb2312編碼的字節序列構建新的String對象的時候又使用了
iso8859-1編碼，因此輸出的亂碼和System.out.println(strLine)有所不一樣。

至於正確的改法就不用詳細說明了吧，首先將strLine用iso8859-1編碼方式轉換成字節
序列，而後用系統默認的編碼方式（gb2312）構建新的String對象，而後打印輸出。

參考:

字符串編碼(charset, encoding/decoding)問題原理

http://www.javaeye.com/topic/31860

主題：Java編碼淺析（注意區分三個概念）

http://www.javaeye.com/topic/311583

java 字符編碼

http://wenku.baidu.com/view/3668f2d6195f312b3169a571.html