1、先說重點：

不同的編碼格式佔位元組數是不同的，UTF-8編碼下一個中文所佔位元組也是不確定的，可能是2個、3個、4個位元組；

2、以下是原始碼：

 1   @Test
 2     public void test1() throws UnsupportedEncodingException {
 3         String a = "名";
 4         System.out.println("UTF-8編碼長度:"+a.getBytes("UTF-8").length);
 5         System.out.println("GBK編碼長度:"+a.getBytes("GBK").length);
 
 6         System.out.println("GB2312編碼長度:"+a.getBytes("GB2312").length);
 7         System.out.println("==========================================");
 8 
 9         String c = "0x20001";
10         System.out.println("UTF-8編碼長度:"+c.getBytes("UTF-8").length);
11         System.out.println("GBK編碼長度:"+c.getBytes("GBK").length);
 
12         System.out.println("GB2312編碼長度:"+c.getBytes("GB2312").length);
13         System.out.println("==========================================");
14 
15         char[] arr = Character.toChars(0x20001);
16         String s = new String(arr);
17         System.out.println("char array length:" + arr.length);
 
18         System.out.println("content:|  " + s + " |");
19         System.out.println("String length:" + s.length());
20         System.out.println("UTF-8編碼長度:"+s.getBytes("UTF-8").length);
21         System.out.println("GBK編碼長度:"+s.getBytes("GBK").length);
22         System.out.println("GB2312編碼長度:"+s.getBytes("GB2312").length);
23         System.out.println("==========================================");
24     }

3、執行結果

 1 UTF-8編碼長度:3
 2 GBK編碼長度:2
 3 GB2312編碼長度:2
 4 ==========================================
 5 UTF-8編碼長度:4
 6 GBK編碼長度:1
 7 GB2312編碼長度:1
 8 ==========================================
 9 char array length:2
10 content:|  ? |
11 String length:2
12 UTF-8編碼長度:4
13 GBK編碼長度:1
14 GB2312編碼長度:1
15 ==========================================

 4、幾種編碼格式的簡單介紹

幾種編碼格式。

• ASCII 碼

學過計算機的人都知道 ASCII 碼，總共有 128 個，用一個位元組的低 7 位表示，0~31 是控制字元如換行回車刪除等；32~126 是列印字元，可以通過鍵盤輸入並且能夠顯示出來。

• ISO-8859-1

128 個字元顯然是不夠用的，於是 ISO 組織在 ASCII 碼基礎上又制定了一些列標準用來擴充套件 ASCII 編碼，它們是 ISO-8859-1~ISO-8859-15，其中 ISO-8859-1 涵蓋了大多數西歐語言字元，所有應用的最廣泛。ISO-8859-1 仍然是單位元組編碼，它總共能表示 256 個字元。

• GB2312

它的全稱是《資訊交換用漢字編碼字符集 基本集》，它是雙位元組編碼，總的編碼範圍是 A1-F7，其中從 A1-A9 是符號區，總共包含 682 個符號，從 B0-F7 是漢字區，包含 6763 個漢字。

• GBK

全稱叫《漢字內碼擴充套件規範》，是國家技術監督局為 windows95 所制定的新的漢字內碼規範，它的出現是為了擴充套件 GB2312，加入更多的漢字，它的編碼範圍是 8140~FEFE（去掉 XX7F）總共有 23940 個碼位，它能表示 21003 個漢字，它的編碼是和 GB2312 相容的，也就是說用 GB2312 編碼的漢字可以用 GBK 來解碼，並且不會有亂碼。

• GB18030

全稱是《資訊交換用漢字編碼字符集》，是我國的強制標準，它可能是單位元組、雙位元組或者四位元組編碼，它的編碼與 GB2312 編碼相容，這個雖然是國家標準，但是實際應用系統中使用的並不廣泛。

• UTF-16

說到 UTF 必須要提到 Unicode（Universal Code 統一碼），ISO 試圖想建立一個全新的超語言字典，世界上所有的語言都可以通過這本字典來相互翻譯。可想而知這個字典是多麼的複雜，關於 Unicode 的詳細規範可以參考相應文件。Unicode 是 Java 和 XML 的基礎，下面詳細介紹 Unicode 在計算機中的儲存形式。

UTF-16 具體定義了 Unicode 字元在計算機中存取方法。UTF-16 用兩個位元組來表示 Unicode 轉化格式，這個是定長的表示方法，不論什麼字元都可以用兩個位元組表示，兩個位元組是 16 個 bit，所以叫 UTF-16。UTF-16 表示字元非常方便，每兩個位元組表示一個字元，這個在字串操作時就大大簡化了操作，這也是 Java 以 UTF-16 作為記憶體的字元儲存格式的一個很重要的原因。

• UTF-8

UTF-16 統一採用兩個位元組表示一個字元，雖然在表示上非常簡單方便，但是也有其缺點，有很大一部分字元用一個位元組就可以表示的現在要兩個位元組表示，儲存空間放大了一倍，在現在的網路頻寬還非常有限的今天，這樣會增大網路傳輸的流量，而且也沒必要。而 UTF-8 採用了一種變長技術，每個編碼區域有不同的字碼長度。不同型別的字元可以是由 1~6 個位元組組成。

UTF-8 有以下編碼規則：

1. 如果一個位元組，最高位（第 8 位）為 0，表示這是一個 ASCII 字元（00 - 7F）。可見，所有 ASCII 編碼已經是 UTF-8 了。
2. 如果一個位元組，以 11 開頭，連續的 1 的個數暗示這個字元的位元組數，例如：110xxxxx 代表它是雙位元組 UTF-8 字元的首位元組。
3. 如果一個位元組，以 10 開始，表示它不是首位元組，需要向前查詢才能得到當前字元的首位元組

5、字元編碼的歷史故事

很久很久以前，有一群人，他們決定用8個可以開合的電晶體來組合成不同的狀態，以表示世界上的萬物。他們認為8個開關狀態作為原子單位很好，於是他們把這稱為"位元組"。 

再後來，他們又做了一些可以處理這些位元組的機器，機器開動了，可以用位元組來組合出更多的狀態，狀態開始變來變去。他們看到這樣是好的，於是它們就這機器稱為"計算機"。 

開始計算機只在美國用。八位的位元組一共可以組合出256（2的8次方）種不同的狀態。 

他們把其中的編號從0開始的32種狀態分別規定了特殊的用途，一但終端裝置或者印表機遇上這些約定好的位元組時，就要做一些約定的動作。遇上 00x10, 終端就換行，遇上0x07, 終端就向人們嘟嘟叫，例好遇上0x1b, 印表機就列印反白的字，對於終端就用彩色顯示字母。他們看到這樣很好，於是就把這些0x20（十進位制32）以下的位元組狀態稱為"控制碼"。 

他們又把所有的空格、標點符號、數字、大小寫字母分別用連續的位元組狀態表示，一直編到了第127號，這樣計算機就可以用不同位元組來儲存英語的 文字了。大家看到這樣，都感覺很好，於是大家都把這個方案叫做 ANSI 的"Ascii"編碼（American Standard Code for Information Interchange，美國資訊互換標準程式碼）。當時世界上所有的計算機都用同樣的ASCII方案來儲存英文文字。 

後來，就像建造巴比倫塔一樣，世界各地的都開始使用計算機，但是很多國家用的不是英文，他們用到的許多字母在ASCII中根本沒有，為了也可以在計算機中儲存他們的文字，他們決定採用127號之後的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一個狀態255。從128到255這一頁的字符集被稱"擴充套件字符集"。從此之後，貪婪的人類再沒有新的狀態可以用了，美帝國主義可能沒有想到還有第三世界國家的人們也希望可以用到計算機吧！ 

等中國人們得到計算機時，已經沒有可以利用的位元組狀態來表示漢字，況且有6000多個常用漢字需要儲存呢。但是這難不倒智慧的中國人民，我們不客氣地把那些127號之後的奇異符號們直接取消掉，並且規定：一個小於127的字元的意義與原來相同，但兩個大於127的字元連在一起時，就表示一個漢字，前面的一個位元組（他稱之為高位元組）從0xA1用到 0xF7，後面一個位元組（低位元組）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裡，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 裡本來就有的數字、標點、字母都統統重新編了兩個位元組長的編碼，這就是常說的"全形"字元，而原來在127號以下的那些就叫"半形"字元了。 

中國人民看到這樣很不錯，於是就把這種漢字方案叫做"GB2312"。GB2312 是對 ASCII 的中文擴充套件。 

但是中國的漢字太多了，我們很快就就發現有許多人的人名沒有辦法在這裡打出來，特別是某些很會麻煩別人的國家領導人（如朱鎔基的“鎔”字）。於是我們不得不繼續把 GB2312 沒有用到的碼位找出來老實不客氣地用上。 

後來還是不夠用，於是乾脆不再要求低位元組一定是127號之後的內碼，只要第一個位元組是大於127就固定表示這是一個漢字的開始，不管後面跟的是不是擴充套件字符集裡的內容。結果擴充套件之後的編碼方案被稱為 GBK 標準，GBK 包括了 GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。 

後來少數民族也要用電腦了，於是我們再擴充套件，又加了幾千個新的少數民族的字，GBK 擴成了 GB18030。從此之後，中華民族的文化就可以在計算機時代中傳承了。 

中國的程式設計師們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 "DBCS"（Double Byte Charecter Set 雙位元組字符集）。在DBCS系列標準裡，最大的特點是兩位元組長的漢字字元和一位元組長的英文字元並存於同一套編碼方案裡，因此他們寫的程式為了支援中文處理，必須要注意字串裡的每一個位元組的值，如果這個值是大於127的，那麼就認為一個雙位元組字符集裡的字元出現了。那時候凡是受過加持，會程式設計的計算機僧侶們都要每天念下面這個咒語數百遍： 

"一個漢字算兩個英文字元！一個漢字算兩個英文字元……" 

因為當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支援別人的編碼，連大陸和臺灣這樣只相隔了150海里，使用著同一種語言的兄弟地區，也分別採用了不同的 DBCS 編碼方案——當時的中國人想讓電腦顯示漢字，就必須裝上一個"漢字系統"，專門用來處理漢字的顯示、輸入的問題，但是那個臺灣的愚昧封建人士寫的算命程式就必須加裝另一套支援 BIG5 編碼的什麼"倚天漢字系統"才可以用，裝錯了字元系統，顯示就會亂了套！這怎麼辦？而且世界民族之林中還有那些一時用不上電腦的窮苦人民，他們的文字又怎麼辦？ 

真是計算機的巴比倫塔命題啊！ 

正在這時，大天使加百列及時出現了——一個叫 ISO （國際標誰化組織）的國際組織決定著手解決這個問題。他們採用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符號的編碼！他們打算叫它"Universal Multiple-Octet Coded Character Set"，簡稱 UCS, 俗稱 "UNICODE"。 

UNICODE 開始制訂時，計算機的儲存器容量極大地發展了，空間再也不成為問題了。於是 ISO 就直接規定必須用兩個位元組，也就是16位來統一表示所有的字元，對於ascii裡的那些"半形"字元，UNICODE 包持其原編碼不變，只是將其長度由原來的8位擴充套件為16位，而其他文化和語言的字元則全部重新統一編碼。由於"半形"英文符號只需要用到低8位，所以其高 8位永遠是0，因此這種大氣的方案在儲存英文文字時會多浪費一倍的空間。 

這時候，從舊社會裡走過來的程式設計師開始發現一個奇怪的現象：他們的strlen函式靠不住了，一個漢字不再是相當於兩個字元了，而是一個！是 的，從 UNICODE 開始，無論是半形的英文字母，還是全形的漢字，它們都是統一的"一個字元"！同時，也都是統一的"兩個位元組"，請注意"字元"和"位元組"兩個術語的不同， "位元組"是一個8位的物理存貯單元，而"字元"則是一個文化相關的符號。在UNICODE 中，一個字元就是兩個位元組。一個漢字算兩個英文字元的時代已經快過去了。 

從前多種字符集存在時，那些做多語言軟體的公司遇上過很大麻煩，他們為了在不同的國家銷售同一套軟體，就不得不在區域化軟體時也加持那個雙位元組字符集咒語，不僅要處處小心不要搞錯，還要把軟體中的文字在不同的字符集中轉來轉去。UNICODE 對於他們來說是一個很好的一攬子解決方案，於是從 Windows NT 開始，MS 趁機把它們的作業系統改了一遍，把所有的核心程式碼都改成了用 UNICODE 方式工作的版本，從這時開始，WINDOWS 系統終於無需要加裝各種本土語言系統，就可以顯示全世界上所有文化的字元了。 

但是，UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持相容，這使得 GBK 與UNICODE 在漢字的內碼編排上完全是不一樣的，沒有一種簡單的算術方法可以把文字內容從UNICODE編碼和另一種編碼進行轉換，這種轉換必須通過查表來進行。 

如前所述，UNICODE 是用兩個位元組來表示為一個字元，他總共可以組合出65535不同的字元，這大概已經可以覆蓋世界上所有文化的符號。如果還不夠也沒有關係，ISO已經準備了UCS-4方案，說簡單了就是四個位元組來表示一個字元，這樣我們就可以組合出21億個不同的字元出來（最高位有其他用途），這大概可以用到銀河聯邦成立那一天吧！ 

UNICODE 來到時，一起到來的還有計算機網路的興起，UNICODE 如何在網路上傳輸也是一個必須考慮的問題，於是面向傳輸的眾多 UTF（UCS Transfer Format）標準出現了，顧名思義，UTF8就是每次8個位傳輸資料，而UTF16就是每次16個位，只不過為了傳輸時的可靠性，從UNICODE到 UTF時並不是直接的對應，而是要過一些演算法和規則來轉換。 

受到過網路程式設計加持的計算機僧侶們都知道，在網路裡傳遞資訊時有一個很重要的問題，就是對於資料高低位的解讀方式，一些計算機是採用低位先發送的方法，例如我們PC機採用的 INTEL 架構；而另一些是採用高位先發送的方式。在網路中交換資料時，為了核對雙方對於高低位的認識是否是一致的，採用了一種很簡便的方法，就是在文字流的開始時向對方傳送一個標誌符——如果之後的文字是高位在位，那就傳送"FEFF"，反之，則傳送"FFFE"。不信你可以用二進位制方式開啟一個UTF-X格式的檔案，看看開頭兩個位元組是不是這兩個位元組？ 

下面是Unicode和UTF-8轉換的規則 

 1 Unicode 
 2    
 3 UTF-8 
 4    
 5 0000 - 007F 
 6    
 7 0xxxxxxx 
 8    
 9 0080 - 07FF 
10    
11 110xxxxx 10xxxxxx 
12    
13 0800 - FFFF 
14    
15 1110xxxx 10xxxxxx 10xxxxxx 

例如"漢"字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以要用3位元組模板：1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進位制是：0110 1100 0100 1001，將這個位元流按三位元組模板的分段方法分為0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，這就是其UTF8的編碼。 

講到這裡，我們再順便說說一個很著名的奇怪現象：當你在 windows 的記事本里新建一個檔案，輸入"聯通"兩個字之後，儲存，關閉，然後再次開啟，你會發現這兩個字已經消失了，代之的是幾個亂碼！呵呵，有人說這就是聯通之所以拼不過移動的原因。 

其實這是因為GB2312編碼與UTF8編碼產生了編碼衝撞的原因。 

當一個軟體開啟一個文字時，它要做的第一件事是決定這個文字究竟是使用哪種字符集的哪種編碼儲存的。軟體一般採用三種方式來決定文字的字符集和編碼： 

檢測檔案頭標識，提示使用者選擇，根據一定的規則猜測 

最標準的途徑是檢測文字最開頭的幾個位元組，開頭位元組 Charset/encoding,如下表： 

1 EF BB BF UTF-8 
2    
3 FF FE UTF-16/UCS-2, little endian 
4    
5 FE FF UTF-16/UCS-2, big endian 
6    
7 FF FE 00 00 UTF-32/UCS-4, little endian. 
8    
9 00 00 FE FF UTF-32/UCS-4, big-endian. 

當你新建一個文字檔案時，記事本的編碼預設是ANSI（代表系統預設編碼，在中文系統中一般是GB系列編碼）, 如果你在ANSI的編碼輸入漢字，那麼他實際就是GB系列的編碼方式，在這種編碼下，"聯通"的內碼是： 

1 c1 1100 0001 
2    
3 aa 1010 1010 
4    
5 cd 1100 1101 
6    
7 a8 1010 1000 

注意到了嗎？第一二個位元組、第三四個位元組的起始部分的都是"110"和"10"，正好與UTF8規則裡的兩位元組模板是一致的， 

於是當我們再次開啟記事本時，記事本就誤認為這是一個UTF8編碼的檔案，讓我們把第一個位元組的110和第二個位元組的10去掉，我們就得到了"00001 101010"，再把各位對齊，補上前導的0，就得到了"0000 0000 0110 1010"，不好意思，這是UNICODE的006A，也就是小寫的字母"j"，而之後的兩位元組用UTF8解碼之後是0368，這個字元什麼也不是。這就是隻有"聯通"兩個字的檔案沒有辦法在記事本里正常顯示的原因。 

而如果你在"聯通"之後多輸入幾個字，其他的字的編碼不見得又恰好是110和10開始的位元組，這樣再次開啟時，記事本就不會堅持這是一個utf8編碼的檔案，而會用ANSI的方式解讀之，這時亂碼又不出現了。

6、一個字元為什麼佔兩個位元組

1 public static void main(String[] args) {
2     System.out.printf("The max value of type char is %d.%n",
3             (int)Character.MAX_VALUE);
4     System.out.printf("The min value of type char is %d.%n",
5             (int)Character.MIN_VALUE);
6 }

執行上面的程式，輸出

　　The max value of type char is 65535.
　　The min value of type char is 0.
說明char的範圍從0到65535，那麼正好是兩個位元組所能表示的範圍(65535十六進位制就是0xFFFF，一個位元組能表示0~0xFF，兩個位元組能表示0~0xFFFF)，所以說一個char佔兩個位元組。

那麼char的值到底是什麼呢？比如當我這樣寫char c = '放';

 1 public static void main(String[] args) throws Exception {
 2     char c = '放';
 3     System.out.printf("The value of char %c is %d.%n", c, (int)c);
 4       
 5     String str = String.valueOf(c);
 6     byte[] bys = str.getBytes("Unicode");
 7     for (int i = 0; i < bys.length; i++) {
 8         System.out.printf("%X ", bys[i]);
 9     }
10     System.out.println();
11       
12     int unicode = (bys[2] & 0xFF) << 8 | (bys[3 & 0xFF]);
13     System.out.printf("The unicode value of %c is %d.%n", c, unicode);
14 }

 執行輸出：
　　The value of char 放 is 25918.
　　FE FF 65 3E 
　　The unicode value of 放 is 25918.
首先你看到，這個char的值是25918，那他是什麼呢？先不管它，接著我把這個char放在一個String裡，並進行Unicode編碼，得到四個位元組FE FF 65 3E，前面兩個實際上與內容無關，是BOM，即位元組序標識，FE FF表示是Big Endian，也就是高位在前，低位在後，所以按照這個規則，講653E轉換為10進位制int，發現最後輸出25918，也就是這個字元的Unicode值是25918，所以你現在知道一個char到底儲存的是什麼了吧。

至於GBK，UTF-8，UTF-16的關係，我先拋開GBK，因為它有點特殊。
首先你要知道UTF-8和UTF-16還有UTF-32是為了方便傳輸和儲存的而產生的對Unicode字元的編碼方式。
先說UTF-8，隨著全球化Unicode流行起來，不管你做什麼，支援Unicode都將是潮流，就算你可能永遠也用不到，但這對西方國家就不太好，因為以前ASCII字符集，一個字元只需要一個位元組，而現在用Unicode一個英文字母也需要兩個位元組，如果需要傳輸和儲存，那會浪費一半的空間或流量，所以就想出了一種變長編碼方式，那就是UTF-8，它對ASCII字符集內的字元，只用一個位元組編碼，而其他字元按照一定規則進行兩、三、四位元組編碼，具體規則是：
Unicode編碼(十六進位制)　   UTF-8 位元組流(二進位制)
000000 - 00007F                0xxxxxxx
000080 - 0007FF                110xxxxx 10xxxxxx
000800 - 00FFFF               1110xxxx 10xxxxxx 10xxxxxx
010000 - 10FFFF               11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

但這樣做一些東方國家不幹了，因為他們的字元基本都是在000800 - 00FFFF這個區間，用UTF-8反倒要多用一個位元組，總共需要三個位元組才能表示，而且用UTF-8處理他們的字元，不能直接轉換，需要做一些運算，以‘放’為例，它的Unicode碼是25918，二進位制表示是0110010100111110，如果要轉成UTF-8，首先取高四位0110，和1110拼接，組成11100110，然後中間六位010100，與10拼接構成10010100，最後低六位111110，與10拼接構成10111110，所以三個位元組是11100110 10010100 10111110，也就是十六進位制的E6  94 BE，也就是你上面寫的-26 -108 -66。可以看到這個運算量雖然不大，基本是位操作，但如果你每個字元都要這麼操作實在是有損效率，綜合這幾點考慮，於是又弄了一個UTF-16，不嚴謹地來說它等價於Unicode原生編碼，它統一採用雙位元組表示一個字元(其實有四位元組區域，但現在一般沒有用到)，而由於它用多位元組表示，和Unicode一樣需要位元組序標識，你上面程式碼裡發現它得到-2, -1, 101, 62，轉為十六進位制就是FE FF 65 3E，和我第二個例項程式中相同，說明UTF-16的碼值(如表示‘放’的65 3E)和Unicode原生編碼是相同的。

UTF-32的誕生其實也不奇怪，因為UTF-16還是一個變長編碼方式，一個字元可能由兩個或四個位元組表示，有些有強迫症的人總覺得不好，所以為了他們就有了UTF-32，它統一使用四位元組表示一個字元，因為用得不多所以不詳細說了。

最後說說GBK是個什麼東西。GBK是國標擴(展)的拼音首字母，是我國在1995年制定的專門針對漢語和一些少數名族語言的編碼方式，和Unicode之間沒有一一對應的關係，也就是說Unicode中有的字元GBK不一定有，GBK有的字元Unicode也不一定有，而且GBK和Unicode中共有字元，他們的編碼值沒有一種簡單的對應關係，也就是無法通過簡單計算得到，只能通過查錶轉換。為什麼會有GBK這種奇葩呢？其實是當時Unicode還沒制定好，更沒在全球範圍內推廣，而中國人要用電腦總不可能永遠用英語吧？所以我國就自行制定了一個國標，當時是GB2312，(其實臺灣地區針對繁體還有一個Big5，但這裡就不詳述了)，GB2312後來增加了很多字元，包括很多少數名族的語言，成為了一個新的編碼標準，那就是GBK。

7、深入分析 Java 中的中文編碼問題（轉載）

原文連結：http://www.ibm.com/developerworks/cn/java/j-lo-chinesecoding/#ibm-pcon

Java 中需要編碼的場景

前面描述了常見的幾種編碼格式，下面將介紹 Java 中如何處理對編碼的支援，什麼場合中需要編碼。

I/O 操作中存在的編碼

我們知道涉及到編碼的地方一般都在字元到位元組或者位元組到字元的轉換上，而需要這種轉換的場景主要是在 I/O 的時候，這個 I/O 包括磁碟 I/O 和網路 I/O，關於網路 I/O 部分在後面將主要以 Web 應用為例介紹。下圖是 Java 中處理 I/O 問題的介面：

Reader 類是 Java 的 I/O 中讀字元的父類，而 InputStream 類是讀位元組的父類，InputStreamReader 類就是關聯位元組到字元的橋樑，它負責在 I/O 過程中處理讀取位元組到字元的轉換，而具體位元組到字元的解碼實現它由 StreamDecoder 去實現，在 StreamDecoder 解碼過程中必須由使用者指定 Charset 編碼格式。值得注意的是如果你沒有指定 Charset，將使用本地環境中的預設字符集，例如在中文環境中將使用 GBK 編碼。

寫的情況也是類似，字元的父類是 Writer，位元組的父類是 OutputStream，通過 OutputStreamWriter 轉換字元到位元組。如下圖所示：

同樣 StreamEncoder 類負責將字元編碼成位元組，編碼格式和預設編碼規則與解碼是一致的。

如下面一段程式碼，實現了檔案的讀寫功能：

清單 1.I/O 涉及的編碼示例

 1 String file = "c:/stream.txt"; 
 2  String charset = "UTF-8"; 
 3  // 寫字元換轉成位元組流
 4  FileOutputStream outputStream = new FileOutputStream(file); 
 5  OutputStreamWriter writer = new OutputStreamWriter( 
 6  outputStream, charset); 
 7  try { 
 8     writer.write("這是要儲存的中文字元"); 
 9  } finally { 
10     writer.close(); 
11  } 
12  // 讀取位元組轉換成字元
13  FileInputStream inputStream = new FileInputStream(file); 
14  InputStreamReader reader = new InputStreamReader( 
15  inputStream, charset); 
16  StringBuffer buffer = new StringBuffer(); 
17  char[] buf = new char[64]; 
18  int count = 0; 
19  try { 
20     while ((count = reader.read(buf)) != -1) { 
21         buffer.append(buffer, 0, count); 
22     } 
23  } finally { 
24     reader.close(); 
25  }

在我們的應用程式中涉及到 I/O 操作時只要注意指定統一的編解碼 Charset 字符集，一般不會出現亂碼問題，有些應用程式如果不注意指定字元編碼，中文環境中取作業系統預設編碼，如果編解碼都在中文環境中，通常也沒問題，但是還是強烈的不建議使用作業系統的預設編碼，因為這樣，你的應用程式的編碼格式就和執行環境繫結起來了，在跨環境下很可能出現亂碼問題。

記憶體中操作中的編碼

在 Java 開發中除了 I/O 涉及到編碼外，最常用的應該就是在記憶體中進行字元到位元組的資料型別的轉換，Java 中用 String 表示字串，所以 String 類就提供轉換到位元組的方法，也支援將位元組轉換為字串的建構函式。如下程式碼示例