去年年底实训的时候就发生过类似的事情,当时觉得是不是VSS把文件弄坏了:
在自己机上好好的sln文件,传到VSS上之后再checkout出来就变成“无法识别版本”的sln文件了。当时diff了一下,发觉是文件的头部有几个字节的东西被砍掉了。
然后最近打开别人的一些sln文件居然也这样了。虽说解决的办法很简单——在文件的开头把那几个字节加回去就行,但到底是什么地方造成了这个corruption还是没弄清楚。或者有什么地方配置一下就能让没有头上那几个字节的sln文件也被识别出来?
“那几个字节”说起来怪神秘的,其实就是UTF-8的BOM(byte order mark)而已。
也就是:EF BB BF。
没这几个字节的全英文文件会被认为是ASCII编码的吧。VS只认UTF-8的sln文件了么。
-------------------------------------------------------------------------------------------
最近编码问题真烦人。土豆同学已经给编码问题烦了半个星期了吧。他写了个Java程序要生成UTF-8的XML文件,然后在Eclipse里编译后运行,结果总是错的;拿到外面用命令行编译就完全没问题。太奇怪了,源代码明明转到UTF-8了啊……
在自己机上好好的sln文件,传到VSS上之后再checkout出来就变成“无法识别版本”的sln文件了。当时diff了一下,发觉是文件的头部有几个字节的东西被砍掉了。
然后最近打开别人的一些sln文件居然也这样了。虽说解决的办法很简单——在文件的开头把那几个字节加回去就行,但到底是什么地方造成了这个corruption还是没弄清楚。或者有什么地方配置一下就能让没有头上那几个字节的sln文件也被识别出来?
“那几个字节”说起来怪神秘的,其实就是UTF-8的BOM(byte order mark)而已。
也就是:EF BB BF。
没这几个字节的全英文文件会被认为是ASCII编码的吧。VS只认UTF-8的sln文件了么。
-------------------------------------------------------------------------------------------
最近编码问题真烦人。土豆同学已经给编码问题烦了半个星期了吧。他写了个Java程序要生成UTF-8的XML文件,然后在Eclipse里编译后运行,结果总是错的;拿到外面用命令行编译就完全没问题。太奇怪了,源代码明明转到UTF-8了啊……