沉睡森林@漂在北京

本处文章除注明“转载”外均为原创,转载请注明出处。

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  152 随笔 :: 4 文章 :: 114 评论 :: 0 Trackbacks

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标记。
posted on 2010-06-11 16:59 王总兵 阅读(1024) 评论(1)  编辑  收藏

评论

# re: UltraEdit编码问题 2012-09-18 19:30 lostgdi
useful for me , thank  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: