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,影響不大。

5.無中文的文件保存爲無BOM的UTF-8 格式時,實際上保存爲ANSI格式,若要保存爲無BOM的UTF-8 格式的文件必須在前9205個字符中加入中文

 

對於用戶

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標記。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章