用ultraedit实现编码转换

BOM
这里涉及到一个BOM(Byte Order Mark) 的概念。简单的讲，在Unicode标准中，为了标示文本文件的编码类型，可以在文本文件的开始插入几个特殊的byte， 通过这几个特殊的byte，应用程序就可以鉴别文本文件使用的是那种编码了。那几个特殊的byte也被称之为BOM(参考:http://unicode.org/faq/utf_bom.html )。

对于Unicode，几种编码的BOM如下：

UTF-32， big-endian 文件的前4个byte是：00 00 FE FF
UTF-32， little-endian文件的前4个byte是：FF FE 00 00
UTF-16， big-endian文件的前2个byte是：FE FF
UTF-16， little-endian文件的前2个byte是：FF FE
UTF-8文件的前3个byte是：:EF BB BF
UTF-7的规律特殊一点，不是前几个byte，而是所有的byte转换为十进制都小于127。



    使用UltraEdit打开一个文本文件，可以不用关心其编码。(Notepad创建的文件的默认编码还是当前code page设定的编码，在简体中文环境下是 CP936， 即GBK。)
    设定UltraEdit当前的code page: 选择 "View -> Set Code Page"， 然后选择你需要的code page，这样后面执行的编码转换操作都是根据这里设定的code page进行的。
    选择 "Edit -> Hex Function -> Hex Edit" 进入Hex编辑模式，这样你可以输入任意你需要的16进制数字，例如 4E02(Unicode) 或者 8140(GBK) ( "丂" )。
    转换： 根据你当前的文件的编码，选择 "File -> Conversions -> Unicode to ASCII" 或者 "File -> Conversions -> ASCII to Unicode"， 这里的ASCII就是便是当前的 Code Page的编码。
    首先需要适当的字体，例如如果你的Windows是简体中文，而你想要转换 Unicode -> Big5，那么你需要 Big5 字体。从http://www.unifont.org/可以下载到很多字体。
    即使有了合适的字体也不一定能正确的显示。我将我的系统 code page 设定成 CP950(Big5)， 重起后将 UltraEdit 的 Code Page 设定成 CP936，然后转换 GBK <-> Unicode，结果是能够显示 Unicode编码的简体中文字符，而不能显示 GBK 编码的中文字符。估计可能是和字体的处理有关，字体处理如果和当前的 code page 有关的话，这种设定的不一致就会造成无法正确显示。不过在系统code page 是 CP936的情况下在选择了正确的字体后能显示繁体Big5-HKSCS的字符。
    从 http://www.microsoft.com/globaldev/reference/WinCP.mspx 可以看到不同 Code Page 的编码转换表。


在编码方面UltraEdit存在一写令人费解的问题

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格式，如果 数据中没有中文字符，或者charset=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标记。