原来是文件的BOM信息捣乱,用UltraEdit重新打开再保存一下就可以了!
附带一篇文章:Subversion是否可以控制中文目录的访问权限?
作者: PCplayer 时间: 2006-7-1 18:57 标题: Subversion是否可以控制中文目录的访问权限?可以!
经常有朋友问到Subversion是否可以对中文目录进行权限控制,如果可以,该如何配置。
经过测试,发现subversion是可以很好地控制中文目录的权限的。
方法很简单,就是将你的权限控制文件的格式转换为UTF-8格式,
将权限文件改成UTF-8格式我使用的是UltraEdit的菜单"ASCII to UTF-8 (Unicode Editing)"。
关于配置权限控制文件,请参考郑新星发表的
《Subversion之路--利用 svnserve.exe 实现精细的目录访问控制》
http://www.iusesvn.com/bbs/viewt ... &extra=page%3D1
有关中文目录权限控制的讨论,也可以参考
http://www.iusesvn.com/bbs/viewt ... &extra=page%3D1
作者: 郑新星 时间: 2006-7-4 20:21
今晚抽空做了测试,部分结论如下:
1 svn不支持微软格式的UTF-8文件,不支持unicode,仅支持标准UTF-8,就是头部有一个 FF FE的文件
2 用微软自带的“记事本”编辑出来的任何unicode格式文件,svn均不认识
3 只要使用了svn 支持的标准UTF-8文件,svn 就可以很好地实现对中文的支持,包括中文用户名、中文目录、中文组名
现在有个小问题,我新建一个文件只有一个“1”这个字符,然后用UltraEdit查看其UTF-8格式(状态条提示U8-DOS格式)和UNICODE格式(状态条提示U-DOS格式),两者完全一样,看不出区别,不知道究竟区别何在?
作者: 郑新星 时间: 2006-7-4 21:10
查资料说,对于UTF-8文件,应该是 EF BB BF 31,而对于UNICODE文件,应该是 FF FE 00 31
难道是Ultraedit显示的二进制格式,是经过加工的,而不是最原始的?
还有,为什么微软的“记事本”出来的UTF-8格式,会有两个FF FE FF FE呢?
作者: PCplayer 时间: 2006-7-4 21:50
我试了一下,在UltraEdit中
不管UTF-8还是Unicode都是FF FE 31 00
对于微软的“记事本”,经常是有问题的,现在都不敢相信它,只相信UltraEdit
作者: 郑新星 时间: 2006-7-5 23:03
晚上写了个小程序测试了一下,终于弄懂了UltraEdit弄出来的UTF8格式,和微软弄出来的UTF8格式之间的区别了
比如说一个文本文件内容是“1啊”两个字符:
对于 GBK编码:31 B0 A1
对于unicode UCS-2 编码(不论记事本还是Ultaedit): ff fe 31 00 4a 55 (在Ultraedit二进制下看到的是一样的)
对于UltraEdit的“UTF8(unicode editing)” 的编码: 31 e5 95 8a (在Ultraedit下看到的是 FF FE 31 00 4A 55)
对于微软“记事本”另存为出来的UTF8的编码: ef bb bf 31 e5 95 8a (在Ultraedit下看到的是 FF FE FF FE 31 00 4A 55)
可以看出来,微软的UTF8编码其实是符合标准的,因为 ef bb bf 这三个字节,正好就是 FF FE 的UTF8编码。也就是说,看来是我们冤枉微软了,一直以为是Ultraedit出来的utf8标准而微软“记事本”出来的utf8不标准,其实正好相反。
参见 ultraedit forum
看来我手头的 UE9.0 是个很老的版本了。
现在就剩下一个问题:为什么svn不支持标准utf8,无法识别BOM呢?
作者: PCplayer 时间: 2006-7-5 23:21
强,这种钻研精神我要好好学习先!
另外我要找找UTF-8等编码的标准文档。
作者: 郑新星 时间: 2006-7-6 13:01
下面摘自 http://xiushen.com/blog/read.php/114.htm ,说明了BOM的存在对PHP脚本的影响
* 不能登入或者不能登出;
* 页顶出现一条空白;
* 页顶出现错误警告;
* 其它不正常的情况。
则多半是编辑器的问题。
本程序采用UTF-8编码。现在几乎所有的文本编辑软件都可以显示并编辑UTF-8编码的文件。但是很遗憾,其中很多软件的表现并不理想。
类似WINDOWS自带的记事本等软件,在保存一个以UTF-8编码的文件时,会在文件开始的地方插入三个不可见的字符(0xEF 0xBB 0xBF,即BOM)。它是一串隐藏的字符,用于让记事本等编辑器识别这个文件是否以UTF-8编码。对于一般的文件,这样并不会产生什么麻烦。但对于 PHP来说,BOM是个大麻烦。
PHP并不会忽略BOM,所以在读取、包含或者引用这些文件时,会把BOM作为该文件开头正文的一部分。根据嵌入式语言的特点,这串字符将被直接执行(显示)出来。由此造成即使页面的 top padding 设置为0,也无法让整个网页紧贴浏览器顶部,因为在html一开头有这3个字符呢!
最大的麻烦还不是这个。受COOKIE送出机制的限制,在这些文件开头已经有BOM的文件中,COOKIE无法送出(因为在COOKIE送出前PHP已经送出了文件头),所以登入和登出功能失效。一切依赖COOKIE、SESSION实现的功能全部无效。
因此,在编辑、更改任何文本文件时,请务必使用不会乱加BOM的编辑器。Linux下的编辑器应该都没有这个问题。WINDOWS下,请勿使用记事本等编辑器。推荐的编辑器是: Editplus 2.12版本以上; EmEditor; UltraEdit(需要取消‘添加BOM’的相关选项); Dreamweaver(需要取消‘添加BOM’的相关选项)等。
对于已经添加了BOM的文件,要取消的话,可以用以上编辑器另存一次。(Editplus需要先另存为gb,再另存为UTF-8。)
下面一段摘自 http://forums.mozine.org/index.php?showtopic=556 ,说明了BOM对 mozilla 插件制作过程中对BOM的要求:
要编辑中文语言档案,你必需要有合适的编辑器。Mozilla 有些特定的文件格式要求,所以你的编辑器最少要有以下的功能:
1. 支援 UTF-8 文字档型
2. 可选择文件是否要有万国码档案签名 BOM (Byte Order Mark, U+FEFF)
3. 支援逸出万国码 (escaped Unicode,/uXXXX) 的文字编码
可惜的是在 Windows 2000 与 XP 上的 Notepad 没有第二项的支持,所以你必须用其它的编辑器。以下是一些建议:
1. UniRed : freeware,很好用
2. SC UniPad: 测试版有字元数限制,正式版太贵了,功能好但可能不适用。
这些程序的使用请参见 Mozilla 地方化的工具。
总结:自由软件领域,好像对BOM都非常不适应,而svn的作者可能是觉得没必要处理BOM也可以正确处理UTF-8文档,所以就这么干了。只是比较郁闷的是,我无法使用我最爱的编辑器了:记事本
附件: [前述将文件头部内容导出查看的小程序,它会打印出头10个字节的内容] dumphex.rar (2006-7-6 13:01, 18.39 K) / 该附件被下载次数 61
http://www.iusesvn.com/bbs/attachment.php?aid=11
辛苦劳动所得,欢迎转载,注明出处就可以了:http://blog.csdn.net/voyager512