UltraEdit editplus notepad等的編碼問題

文章目錄

• UltraEdit是一個非常強大的工具，但是，工具太強大了就會變成一個雙刃劍，用好了是好工具，用不好可能會存在很多的疑惑，在編碼方面UltraEdit存在一寫令人費解的問題，本人做了一點點研究，與大家分享。

UltraEdit是一個非常強大的工具，但是，工具太強大了就會變成一個雙刃劍，用好了是好工具，用不好可能會存在很多的疑惑，在編碼方面UltraEdit存在一寫令人費解的問題，本人做了一點點研究，與大家分享。

主要的問題來源於UTF-8的處理。

Unicode規範中推薦的標記位元組順序的方法是BOM(Byte Order Mark)

UTF-8不需要BOM來表明位元組順序，但可以用BOM來表明編碼方式。如果接收者收到以EF BB BF開頭的位元組流，就知道這是UTF-8編碼了。
由於UTF-8 BOM並沒有得到廣泛的支援，所以造成了一定範圍內的不相容。下面列出幾個主要工具對於BOM的處理。

1.   notepad

 notepad 在儲存時，選擇UTF-8 格式，會在檔案頭寫上BOM header.讀取檔案時，會分析BOM和檔案中是否有中文字元，進而做出正確的選擇。

2.   notepad++

可以設定各種格式，有無BOM都支援。

3.   editplus

 檔案儲存時，選擇UTF-8 格式，不會在檔案頭寫上 BOM header.讀取可以識別UTF-8

4.   ultraedit

 ultraedit在advanced->configuration中可以選擇檔案儲存時是否寫上BOM header.或者另存新檔中選擇。讀取是，如果沒有設定自動檢測UTF-8或者部分無BOM檔案會無法正常顯示。

5.   Eclipse

如果設定了檔案的編碼問UTF-8，那麼檔案儲存為無BOM格式。讀取正常。

6.   vi

 指的是Linux 下的vim, 如果UTF-8 檔案開頭有BOM header, 其能夠正常顯示UTF-8 編碼，否則，顯示為亂碼。

 

UltraEdit的主要問題

1.  如果建立一個檔案，選擇儲存為UTF-8 無 BOM格式，如果資料中沒有中文字元，或者harset=UTF-8，那麼無論怎麼儲存，UE仍然會把檔案儲存為ANSI格式，這樣，以後再加入中文的時 候編碼方式也不會改變，這就會造成Java Build程式產生的指令碼含有亂碼。

2.  如果是正確的UTF-8無BOM格式，在前9205個字元中如果沒有中文，那麼UE會頑固的認為此檔案是ANSI格式，所以導致檔案中文亂碼（測試版本UE 13.10a）。解決辦法就是主動的在前9205個字元前加入一個中文字元。

3.  哭笑不得的UTF-8自動檢測。在advanced->configuration->Unicode/UTF-8 Auto Check中有自動檢測UTF-8的選項，如果選擇，經分析UE將採用三種檢測方式：

a)   檔案編碼的開頭是否有【EF BB BF】字元（即BOM），如果有則認為是UTF-8

b)   檢查是否含有charset=UTF-8類似的文字，如果有，那麼認為是UTF-8格式，這將導致以ANSI儲存的檔案亂碼。

c)   如果是UTF-8無BOM格式的文檔，UE會檢查前9205個字元是否含有中文字元，如果有，如果沒有則使用ANSI編碼進行解析，造成後面的中文字元亂 碼。如果這個時候強制的用UE轉換為UTF-8，則亂上加亂，檔案作廢。對於本身是ANSI格式儲存的檔案，沒有此檢測，中文正常。

4.  UE開啟UTF-8的檔案預設會轉換為UTF-16，影響不大。

 

對於使用者

1.  UE開啟亂碼的問題，在前9205字元中加入中文注釋可以解決此問題，或者使用在UE的【檔案】菜單中的【轉換】->【UNICODE/UTF-8 到 UTF-8（Unicode編輯）】進行轉換。

2.  不要使用UE來建立無中文的UTF-8無BOM檔案。

3.  不要在已經亂碼的檔案中，刪除亂碼然後添加中文再儲存。

4.  建立UTF-8無BOM檔案可以使用Eclipse、Notepad++、EditPlus進行

5.  對於記事本儲存的UTF-8指令檔，Java Build程式也是可以識別的，但是Java檔案不能使用記事本編輯編輯器無法識別檔案頭的EF BB BF標記。