UltraEdit编码问题

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 -& gt;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 -& gt;configuration -& gt;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的【文件】菜单中的【转换】 -& gt;【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标记。

本文转自博客园沉睡森林@漂在北京的博客，原文链接：UltraEdit编码问题，如需转载请自行联系原博主。