問題一。記事本文件的編碼格式：
在計算機中字符通常並不是保存爲圖像，每個字符都是使用一個編碼來表示的，而每個字符究竟使用哪個編碼代表，要取決於使用哪個字符集(charset)。
在最初的時候，Internet上只有一種字符集——ANSI的ASCII字符集，它使用7 bits來表示一個字符，總共表示128個字符，其中包括了英文字母、數字、標點符號等常用字符。之後，又進行擴展，使用8 bits表示一個字符，可以表示256個字符，主要在原來的7 bits字符集的基礎上加入了一些特殊符號例如製表符。
後來，由於各國語言的加入，ASCII已經不能滿足信息交流的需要，因此，爲了能夠表示其它國家的文字，各國在ASCII的基礎上制定了自己的字符集，這些從ANSI標準派生的字符集被習慣的統稱爲ANSI字符集，它們正式的名稱應該是MBCS(Multi-Byte Chactacter System，即多字節字符系統)。這些派生字符集的特點是以ASCII 127 bits爲基礎，兼容ASCII 127，他們使用大於128的編碼作爲一個Leading Byte，緊跟在Leading Byte後的第二（甚至第三）個字符與Leading Byte一起作爲實際的編碼。這樣的字符集有很多，我們常見的GB-2312就是其中之一。
例如在GB-2312字符集中，“連通”的編碼爲C1 AC CD A8，其中C1和CD就是Leading Byte。前127個編碼爲標準ASCII保留，例如“0”的編碼是30H（30H表示十六進制的30）。軟件在讀取時，如果看到30H，知道它小於128就是標準ASCII，表示“0”，看到C1大於128就知道它後面有一個另外的編碼，因此C1 AC一同構成一個整個的編碼，在GB-2312字符集中表示“連”。
由於每種語言都制定了自己的字符集，導致最後存在的各種字符集實在太多，在國際交流中要經常轉換字符集非常不便。因此，提出了Unicode字符集，它固定使用16 bits（兩個字節、一個字）來表示一個字符，共可以表示65536個字符。將世界上幾乎所有語言的常用字符收錄其中，方便了信息交流。標準的Unicode稱爲UTF-16。後來爲了雙字節的Unicode能夠在現存的處理單字節的系統上正確傳輸，出現了UTF-8，使用類似MBCS的方式對Unicode進行編碼。注意UTF-8是編碼，它屬於Unicode字符集。Unicode字符集有多種編碼形式，而ASCII只有一種，大多數MBCS（包括GB-2312）也只有一種。
例如“連通”兩個字的Unicode標準編碼UTF-16 (big endian）爲：DE 8F 1A 90
而其UTF-8編碼爲：E8 BF 9E E9 80 9A
最後，當一個軟件打開一個文本時，它要做的第一件事是決定這個文本究竟是使用哪種字符集的哪種編碼保存的。軟件有三種途徑來決定文本的字符集和編碼：
最標準的途徑是檢測文本最開頭的幾個字節，如下表：
|
開頭字節 |
Charset/encoding |
|
EF BB BF |
UTF-8 |
|
FE FF |
UTF-16/UCS-2, little endian |
|
FF FE |
UTF-16/UCS-2, big endian |
|
FF FE 00 00 |
UTF-32/UCS-4, little endian. |
|
00 00 FE FF |
UTF-32/UCS-4, big-endian. |
例如插入標記後，連通”兩個字的UTF-16 (big endian）和UTF-8碼分別爲：
FF FE DE 8F 1A 90
EF BB BF E8 BF 9E E9 80 9A
但是MBCS文本沒有這些位於開頭的字符集標記，更不幸的是，一些早期的和一些設計不良的軟件在保存Unicode文本時不插入這些位於開頭的字符集標記。因此，軟件不能依賴於這種途徑。這時，軟件可以採取一種比較安全的方式來決定字符集及其編碼，那就是彈出一個對話框來請示用戶，例如將那個“連通”文件拖到MS Word中，Word就會彈出一個對話框。
如果軟件不想麻煩用戶，或者它不方便向用戶請示，那它只能採取自己“猜”的方法，軟件可以根據整個文本的特徵來猜測它可能屬於哪個charset，這就很可能不準了。使用記事本打開那個“連通”文件就屬於這種情況。
我們可以證明這一點：在記事本中鍵入“連通”後，選擇“另存爲”，會看到最後一個下拉框中顯示有“ANSI”，這時保存。當再當打開“連通”文件出現亂碼後，再點擊“文件”->“另存爲”，會看到最後一個下拉框中顯示有“UTF-8”，這說明記事本認爲當前打開的這個文本是一個UTF-8編碼的文本。而我們剛纔保存時是用ANSI字符集保存的。這說明，記事本猜測了“連通”文件的字符集，認爲它更像一個UTF-8編碼文本。這是因爲“連通”兩個字的GB-2312編碼看起來更像UTF-8編碼導致的，這是一個巧合，不是所有文字都這樣。可以使用記事本的打開功能，在打開“連通”文件時在最後一個下拉框中選擇ANSI，就能正常顯示了。反過來，如果之前保存時保存爲UTF-8編碼，則直接打開也不會出現問題。
如果將“連通”文件放入MS Word中，Word也會認爲它是一個UTF-8編碼的文件，但它不能確定，因此會彈出一個對話框詢問用戶，這時選擇“簡體中文（GB2312）”，就能正常打開了。記事本在這一點上做得比較簡化罷了。
實驗證明：
File file = new File("D:/記事本.txt");
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(file));
int t;
int j = 0;
while ((t=bis.read()) != -1) {
j++;
System.out.print(Integer.toString(t, 16) + " ");
if (j % 2 == 0) {
System.out.println();
}
}
當記事本保存爲ANSI格式時：
輸出： c1 ac cd a8
當記事本保存爲UTF-8:
ef bb bf (bom)
e8 bf 9e
e9 80 9a
當記事本保存爲Unicode時：
ff fe （bom）
de 8f
1a 90
當記事本保存爲Unicode big endian
fe ff (bom)
8f de
90 1a
讀取字符流時，要根據記事本文件的格式，指定直接流，轉換爲字符流的編碼格式：方法如下：
BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(file),"utf-8"));
int t;
while ((t=br.read()) != -1) {
System.out.println((char)t);
}
編碼基礎知識：
1，字符：字符是抽象的最小文本單位。它沒有固定的形狀（可能是一個字形），而且沒有值。“A”是一個字符，“€”（德國、法國和許多其他歐洲國家通用貨幣的標誌）也是一個字符。“中”“國”這是兩個漢字字符。字符僅僅代表一個符號，沒有任何實際值的意義。
2，字符集：字符集是字符的集合。例如，漢字字符是中國人最先發明的字符，在中文、日文、韓文和越南文的書寫中使用。這也說明了字符和字符集之間的關係，字符組成字符集（iso8859-1，GB2312/GBK，unicode）。
3，代碼點：字符集中的每個字符都被分配到一個“代碼點”。每個代碼點都有一個特定的唯一數值，稱爲標值。該標量值通常用十六進制表示。
4，代碼單元： 在每種編碼形式中，代碼點被映射到一個或多個代碼單元。“代碼單元”是各個編碼方式中的單個單元。代碼單元的大小等效於特定編碼方式的位數：
UTF-8 ：UTF-8 中的代碼單元由 8 位組成；在 UTF-8 中，因爲代碼單元較小的緣故，每個代碼點常常被映射到多個代碼單元。代碼點將被映射到一個、兩個、三個或四個代碼單元；
UTF-16 ：UTF-16 中的代碼單元由 16 位組成；UTF-16 的代碼單元大小是 8 位代碼單元的兩倍。所以，標量值小於 U+10000 的代碼點被編碼到單個代碼單元中；
UTF-32：UTF-32 中的代碼單元由 32 位組成； UTF-32 中使用的 32 位代碼單元足夠大，每個代碼點都可編碼爲單個代碼單元；
GB18030：GB18030 中的代碼單元由 8 位組成；在 GB18030 中，因爲代碼單元較小的緣故，每個代碼點常常被映射到多個代碼單元。代碼點將被映射到一個、兩個或四個代碼單元。
5，舉例：
“中國北京香蕉是個大笨蛋”這是我定義的aka字符集；各字符對應代碼點爲：
北 00000001
京 00000010
香 10000001
蕉 10000010
是 10000100
個 10001000
大 10010000
笨 10100000
蛋 11000000
中 00000100
國 00001000
下面是我定義的 zixia 編碼方案（8位），可以看到它的編碼中表示了aka字符集的所有字符對應的 代碼單元；
北 10000001
京 10000010
香 00000001
蕉 00000010
是 00000100
個 00001000
大 00010000
笨 00100000
蛋 01000000
中 10000100
國 10001000
所謂文本文件 就是我們按一定編碼方式將二進制數據表示爲對應的文本如 00000001000000100000010000001000000100000010000001000000這樣的文件。我用一個支持 zixia編碼和aka字符集的記事本打開，它就按照編碼方案顯示爲 “香蕉是個大笨蛋 ”
如果我把這些字符按照GBK另存一個文件，那麼則肯定不是這個，而是
1100111111100011 1011110110110110 1100101011000111 1011100011110110 1011010011110011 1011000110111111 1011010110110000 110100001010
二，字符集
1， 常用字符集分類
ASCII及其擴展字符集
作用：表語英語及西歐語言。
位數：ASCII是用7位表示的，能表示128個字符；其擴展使用8位表示，表示256個字符。
範圍：ASCII從00到7F，擴展從00到FF。
ISO-8859-1字符集
作用：擴展ASCII，表示西歐、希臘語等。
位數：8位，
範圍：從00到FF，兼容ASCII字符集。
GB2312字符集
作用：國家簡體中文字符集，兼容ASCII。
位數：使用2個字節表示，能表示7445個符號，包括6763個漢字，幾乎覆蓋所有高頻率漢字。
範圍：高字節從A1到F7, 低字節從A1到FE。將高字節和低字節分別加上0XA0即可得到編碼。
BIG5字符集
作用：統一繁體字編碼。
位數：使用2個字節表示，表示13053個漢字。
範圍：高字節從A1到F9，低字節從40到7E，A1到FE。
GBK字符集
作用：它是GB2312的擴展，加入對繁體字的支持，兼容GB2312。
位數：使用2個字節表示，可表示21886個字符。
範圍：高字節從81到FE，低字節從40到FE。
GB18030字符集
作用：它解決了中文、日文、朝鮮語等的編碼，兼容GBK。
位數：它採用變字節表示(1 ASCII，2，4字節)。可表示27484個文字。
範圍：1字節從00到7F; 2字節高字節從81到FE，低字節從40到7E和80到FE；4字節第一三字節從81到FE，第二四字節從30到39。
UCS字符集
作用：國際標準 ISO 10646 定義了通用字符集 (Universal Character Set)。它是與UNICODE同類的組織，UCS-2和UNICODE兼容。
位數：它有UCS-2和UCS-4兩種格式，分別是2字節和4字節。
範圍：目前，UCS-4只是在UCS-2前面加了0×0000。
UNICODE字符集
作用：爲世界650種語言進行統一編碼，兼容ISO-8859-1。
位數：UNICODE字符集有多個編碼方式，分別是UTF-8，UTF-16和UTF-32。
2 ，按所表示的文字分類
語言 字符集 正式名稱
英語、西歐語 ASCII，ISO-8859-1 MBCS 多字節
簡體中文 GB2312 MBCS 多字節
繁體中文 BIG5 MBCS 多字節
簡繁中文 GBK MBCS 多字節
中文、日文及朝鮮語 GB18030 MBCS 多字節
各國語言 UNICODE，UCS DBCS 寬字節
三，編碼
UTF-8：採用變長字節 (1 ASCII, 2 希臘字母, 3 漢字, 4 平面符號) 表示，網絡傳輸, 即使錯了一個字節，不影響其他字節，而雙字節只要一個錯了，其他也錯了，具體如下：
如果只有一個字節則其最高二進制位爲0；如果是多字節，其第一個字節從最高位開始，連續的二進制位值爲1的個數決定了其編碼的字節數，其餘各字節均以10開頭。UTF-8最多可用到6個字節。
UTF-16：採用2字節，Unicode中不同部分的字符都同樣基於現有的標準。這是爲了便於轉換。從 0×0000到0×007F是ASCII字符，從0×0080到0×00FF是ISO-8859-1對ASCII的擴展。希臘字母表使用從0×0370到 0×03FF 的代碼，斯拉夫語使用從0×0400到0×04FF的代碼，美國使用從0×0530到0×058F的代碼，希伯來語使用從0×0590到0×05FF的代 碼。中國、日本和韓國的象形文字（總稱爲CJK）佔用了從0×3000到0×9FFF的代碼；由於0×00在c語言及操作系統文件名等中有特殊意義，故很 多情況下需要UTF-8編碼保存文本，去掉這個0×00。舉例如下：
UTF-16: 0×0080 = 0000 0000 1000 0000
UTF-8: 0xC280 = 1100 0010 1000 0000
UTF-32：採用4字節。
優缺點
UTF-8、UTF-16和UTF-32都可以表示有效編碼空間 (U+000000-U+10FFFF) 內的所有Unicode字符。
使用UTF-8編碼時ASCII字符只佔1個字節，存儲效率比較高，適用於拉丁字符較多的場合以節省空間。
對於大多數非拉丁字符（如中文和日文）來說，UTF-16所需存儲空間最小，每個字符只佔2個字節。
Windows NT內核是Unicode（UTF-16），採用UTF-16編碼在調用系統API時無需轉換，處理速度也比較快。
採用UTF-16和UTF-32會有Big Endian和Little Endian之分，而UTF-8則沒有字節順序問題，所以UTF-8適合傳輸和通信。
UTF-32採用4字節編碼，一方面處理速度比較快，但另一方面也浪費了大量空間，影響傳輸速度，因而很少使用。
四，如何判斷字符集
1，字節序
首先說一下字節序對編碼的影響，字節序分爲Big Endian字節序和Little Endian字節序。不同的處理器可能不一樣。所以，傳輸時需要告訴處理器當時的編碼字節序。對於前者而言，高位字節存在低地址，低字節存於高地址；後者相反。例如，0X03AB,
Big Endian字節序
0000: 0 3
0001: AB
Little Endian字節序是
0000: AB
0001: 0 3
2，編碼識別
UNICODE，根據前幾個字節可以判斷UNICODE字符集的各種編碼，叫做Byte Order Mask方法BOM：
UTF-8: EFBBBF (符合UTF-8格式，請看上面。但沒有含義在UCS即UNICODE中)
UTF-16 Big Endian：FEFF (沒有含義在UCS-2中)
UTF-16 Little Endian：FFFE (沒有含義在UCS-2中)
UTF-32 Big Endian：0000FEFF (沒有含義在UCS-4中)
UTF-32 Little Endian：FFFE0000 (沒有含義在UCS-4中)
GB2312：高字節和低字節的第1位都是1。
BIG5，GBK&GB18030：高字節的第1位爲1。操作系統有默認的編碼，常爲GBK，可以下載別的並升級。通過判斷高字節的第1位從而知道是ASCII或者漢字編碼。
