2008-05-26 17:27
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標記。