解决:SVN提交数据失败问题(提示 svn:MKACTIVITY ... 403 Forbidden )

原来是文件的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脚本的影响

QUOTE:
如果您在修改任何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的要求:

QUOTE:
选择编辑器

要编辑中文语言档案,你必需要有合适的编辑器。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 地方化的工具。




QUOTE:
2. .dtd 文件是 UTF-8 格式,注意 .dtd 文件不得有 BOM 开头字元


总结:自由软件领域,好像对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


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值