2008-05-26 17:27
UltraEdit是一個(gè)非常強(qiáng)大的工具，但是，工具太強(qiáng)大了就會(huì)變成一個(gè)雙刃劍，用好了是好工具，用不好可能會(huì)存在很多的疑惑，在編碼方面UltraEdit存在一寫令人費(fèi)解的問題，本人做了一點(diǎn)點(diǎn)研究，與大家分享。
主要的問題來源于UTF-8的處理。
Unicode規(guī)范中推薦的標(biāo)記字節(jié)順序的方法是BOM(Byte Order Mark)
UTF-8不需要BOM來表明字節(jié)順序，但可以用BOM來表明編碼方式。如果接收者收到以EF BB BF開頭的字節(jié)流，就知道這是UTF-8編碼了。
由于UTF-8 BOM并沒有得到廣泛的支持，所以造成了一定范圍內(nèi)的不兼容。下面列出幾個(gè)主要工具對于BOM的處理。
1. notepad
notepad 在保存時(shí)，選擇UTF-8 格式，會(huì)在文件頭寫上BOM header.讀取文件時(shí)，會(huì)分析BOM和文件中是否有中文字符，進(jìn)而做出正確的選擇。
2. notepad++
可以設(shè)置各種格式，有無BOM都支持。
3. editplus
文件保存時(shí)，選擇UTF-8 格式，不會(huì)在文件頭寫上 BOM header.讀取可以識別UTF-8
4. ultraedit
ultraedit在advanced->configuration中可以選擇文件保存時(shí)是否寫上BOM header.或者另存為中選擇。讀取是，如果沒有設(shè)置自動(dòng)檢測UTF-8或者部分無BOM文件會(huì)無法正常顯示。
5. Eclipse
如果設(shè)置了文件的編碼問UTF-8，那么文件保存為無BOM格式。讀取正常。
6. vi
指的是Linux 下的vim, 如果UTF-8 文件開頭有BOM header, 其能夠正常顯示UTF-8 編碼，否則，顯示為亂碼。
UltraEdit的主要問題
1. 如果新建一個(gè)文件，選擇保存為UTF-8 無 BOM格式，如果數(shù)據(jù)中沒有中文字符，或者h(yuǎn)arset=UTF-8，那么無論怎么保存，UE仍然會(huì)把文件保存為ANSI格式，這樣，以后再加入中文的時(shí) 候編碼方式也不會(huì)改變，這就會(huì)造成Java Build程序生成的腳本含有亂碼。
2. 如果是正確的UTF-8無BOM格式，在前9205個(gè)字符中如果沒有中文，那么UE會(huì)頑固的認(rèn)為此文件是ANSI格式，所以導(dǎo)致文件中文亂碼（測試版本UE 13.10a）。解決辦法就是主動(dòng)的在前9205個(gè)字符前加入一個(gè)中文字符。
3. 哭笑不得的UTF-8自動(dòng)檢測。在advanced->configuration->Unicode/UTF-8 Auto Check中有自動(dòng)檢測UTF-8的選項(xiàng)，如果選擇，經(jīng)分析UE將采用三種檢測方式：
a) 文件編碼的開頭是否有【EF BB BF】字符（即BOM），如果有則認(rèn)為是UTF-8
b) 檢查是否含有charset=UTF-8類似的文字，如果有，那么認(rèn)為是UTF-8格式，這將導(dǎo)致以ANSI存儲的文件亂碼。
c) 如果是UTF-8無BOM格式的文檔，UE會(huì)檢查前9205個(gè)字符是否含有中文字符，如果有，如果沒有則使用ANSI編碼進(jìn)行解析，造成后面的中文字符亂 碼。如果這個(gè)時(shí)候強(qiáng)制的用UE轉(zhuǎn)換為UTF-8，則亂上加亂，文件作廢。對于本身是ANSI格式存儲的文件，沒有此檢測，中文正常。
4. UE打開UTF-8的文件默認(rèn)會(huì)轉(zhuǎn)換為UTF-16，影響不大。
對于用戶
1. UE打開亂碼的問題，在前9205字符中加入中文注釋可以解決此問題，或者使用在UE的【文件】菜單中的【轉(zhuǎn)換】->【UNICODE/UTF-8 到 UTF-8（Unicode編輯）】進(jìn)行轉(zhuǎn)換。
2. 不要使用UE來新建無中文的UTF-8無BOM文件。
3. 不要在已經(jīng)亂碼的文件中，刪除亂碼然后添加中文再保存。
4. 新建UTF-8無BOM文件可以使用Eclipse、Notepad++、EditPlus進(jìn)行
5. 對于記事本保存的UTF-8腳本文件，Java Build程序也是可以識別的，但是Java文件不能使用記事本編輯編輯器無法識別文件頭的EF BB BF標(biāo)記。