Unicode 與UTF - OpenHome.cc

... JavaScript》條款七），一開頭的兩個位元組（ff fe）是用來識別檔案採用的位元組順序，稱為BOM（byte order mark），之後使用兩個位元組來儲存每個Unicode 字元。

回Encoding目錄 由於Big5用第一個位元組的某個範圍來作為識別是否為中文字，可儲存的文字範圍就大大減少（約為一萬九千多個），如果儲存的字元，不在Big5/MS950編碼範圍內，那會如何？ 如果是Windows舊版的記事本程式，會出現以下的提示，要你轉存為Unicode格式： 在按下「取消」後，會出現「另存新檔」的對話框，在右下會有個「編碼」選項，下拉的話，會有Unicode、Unicodebigendian與UTF-8三個選項。

Unicode是由TheUnicodeConsortium非營利組織所主導的編碼標準，它是一個字元對應一個數字的映射，這個數字稱之為碼點（Codepoint），在表達字元對應的碼點時，於「U+」之後接著一組十六進位數字來表示字元的碼點，如果使用四個十六進位制數字，可以表達六萬多個字元，如果使用五或六個十六進位制，可以表達更多的字元。

Unicode字元映射至數字的概念編碼（Conceptualencoding），一個字元的Unicode碼點是固定的，而這個數字在電腦中如何用位元組來實作則有不同的方式，Unicode的實作方式就稱為Unicode/UCSTransformationFormat，簡稱UTF。

如果直接將方才的範例選擇「Unicode」儲存，用十六進位檢視會看到： 「犇」這個字的Unicode碼點是U+7287，對於Windows的記事本若選擇使用「Unicode」儲存，則使用兩個位元組來儲存，Windows的記事本選擇「Unicode」選項時，實際上採用UCS-2/UTF-16儲存（UTF-16是UCS-2的後續者，兩者差異對語言會有影響，實例之一可參考《EffectiveJavaScript》條款七），一開頭的兩個位元組（fffe）是用來識別檔案採用的位元組順序，稱為BOM（byteordermark），之後使用兩個位元組來儲存每個Unicode字元。

要注意的是，「犇」這個字的Unicode碼點是U+7287，實際儲存時的位元組卻是87、72，也就是說，Windows記事本選擇「Unicode」儲存兩個以上位元組的資料時，是先存低位元組，再存高位元組，這樣的儲存方式，是採LittleEndian的方式，也就是Windows記事本選擇「Unicode」時，實際上採用的是UCS-2/UTF-16LittleEndian。

Unicode指定BOM編碼為U+FEFF。

如果讀取檔案開頭的BOM是0xfeff，表示檔案採用BigEndian，如果讀取檔案開頭的BOM是0xfffe，表示檔案採用LittleEndian。

如果使用Windows記事本儲存時的選項是「Unicodebigendian」，同樣儲存「犇」，結果會如下： 可以看到，用來表示為Unicode檔案的兩個位元組為fe、ff，與先前的ff、fe相反，而「犇」這個字現在儲存為72、87，與先前的87、72也是相反。

如果儲存兩個以上位元組資料時，採先存高位元，再存低位元方式，則這樣的儲存方式，是採BigEndian的方式。

這會有什麼影響？如果使用以下的Java程式來讀取一個存有「這T是e個s測t試」的文字檔案： packagecc.openhome; importjava.nio.file.Files; importjava.nio.file.Paths; importstaticjava.lang.System.out; publicclassMain{ publicstaticvoidmain(String[]args)throwsException{ byte[]bytes=Files.readAllBytes(Paths.get("sample.txt")); for(inti=0;i