[原创] Subversion是否可以控制中文目录的访问权限？可以！ 中文, 权限Subversion, 权限, 目录, 中文, 访问

PCplayer

经常有朋友问到Subversion是否可以对中文目录进行权限控制，如果可以，该如何配置。

经过测试，发现subversion是可以很好地控制中文目录的权限的。

方法很简单，就是将你的权限控制文件的格式转换为UTF-8格式，
将权限文件改成UTF-8格式我使用的是UltraEdit的菜单"ASCII to UTF-8 (Unicode Editing)"。


关于配置权限控制文件，请参考郑新星发表的
《Subversion之路－－利用 svnserve.exe 实现精细的目录访问控制》
http://bbs.iusesvn.com/viewthread.php?tid=6&extra=page%3D1

有关中文目录权限控制的讨论，也可以参考
http://bbs.iusesvn.com/viewthread.php?tid=25&extra=page%3D1

郑新星

今晚抽空做了测试，部分结论如下：
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格式），两者完全一样，看不出区别，不知道究竟区别何在？

郑新星

查资料说，对于UTF-8文件，应该是 EF BB BF 31，而对于UNICODE文件，应该是 FF FE 00 31
难道是Ultraedit显示的二进制格式，是经过加工的，而不是最原始的？

还有，为什么微软的“记事本”出来的UTF-8格式，会有两个FF FE FF FE呢？

PCplayer

我试了一下，在UltraEdit中
不管UTF-8还是Unicode都是FF FE 31 00
对于微软的“记事本”，经常是有问题的，现在都不敢相信它，只相信UltraEdit

郑新星

晚上写了个小程序测试了一下，终于弄懂了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

强，这种钻研精神我要好好学习先！
另外我要找找UTF-8等编码的标准文档。

郑新星

下面摘自  http://xiushen.com/blog/read.php/114.htm ，说明了BOM的存在对PHP脚本的影响

如果您在修改任何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 地方化的工具。

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

总结：自由软件领域，好像对BOM都非常不适应，而svn的作者可能是觉得没必要处理BOM也可以正确处理UTF-8文档，所以就这么干了。只是比较郁闷的是，我无法使用我最爱的编辑器了：记事本

ekylin

版主，http apache 认证方式无法识别中文啊？

PCplayer

中文是可以识别的
请楼上的详细描述你的问题

小宇

打个标记先~把基础问题解决了再来研究~
看了教导主任的帖子
有种不敢说话的感觉……

PCplayer

悄悄地问一下：为什么不敢说话

szhuiwang

SVN可以对中文目录设置权限,却不能对中文库设置权限.是什么原因?(服务器端是Linux操作系统)

rolkey

大家的UltraEdit是哪个版本啊？我这个10.20只有转换成unicode的功能，没有转换成UTF-8的功能，不知道在哪里设置啊？

PCplayer

我的是v11

paleswd

SVN是可以很好地控制中文目录的权限的。
就是将你的权限控制文件的格式转换为UTF-8格式
我用EditPlus转的就没什么问题…
不过似乎没必要非用中文目录

yy611612

楼主的这种专研精神值得学习！

kaikai325107

很好啊　

fbt2222

read kk

GoldenSea0

我没有成功！

配置是：Windows2003+Apache2.2.4+SVN1.4.4

为什么啊？

zhangzzs

我是用svnmanager管理权限的，好像中文的目录没有办法的，大家有人遇到这样的问题吗？