最近一直在做一个项目，以SOA为理念基于SPS2003的三个应用系统。后端以WebService提供服务，前端为嵌入SPS的UserControl，WebService与UserControl之间由序列化的对象进行通讯。由于开发环境是VS.NET 2003，所以就直接使用VSS6d来管理代码了，结果问题就跟着来了：VSS6d不支持UTF-8编码的程序文件以文本方式储存，否则就只能二进制方式存储。在开始阶段主要是开发WebService并没有什么问题，但是随着大量的UserControl开发出来并部署到SPS2003当中的时候，测试人员报告界面乱码。手工把ascx文件转换成UTF-8编码后，问题消失。
这样貌似问题解决了，但是以后每次重新编译部署的时候，都要把上百的ascx文件的编码手工修改一遍。修改编码成了一个极其繁琐的体力劳动......自己研究了一下，又请教了一下微软的工程师，有三个解决方法：
- 在备份以后，重新把代码加入VSS的代码库，使用二进制方式存储代码。这会带来两个问题：一是二进制方式存储，在不同的代码版本之间不能做Different操作，二是二进制方式存储不再是层量存储，每签入一次，保存的都是一个完整的副本。
- 使用VS2005 TFS来做代码管理。这需要在VS.NET2003内安装TFS的插件。这种方法微软网站上面介绍过，没有实践过。
- 使用批量转换工具将ascx的编码转换过来。
我的项目现在只好使用第三种方式，但是找不到有批量的GB2312转UTF-8编码的工具，我只好自己写了一个。这个工具内部的转换引擎是GNU的libiconv，大家可以下载我编译好的版本直接使用，或者下载源代码自己研究。这个工具用.NET2.0写的，所以运行需要.Net Framework 2.0 Runtime。
细心的朋友会问我，为什么我只强调了ascx为什么没有提asmx呢？我当初也奇怪这个问题，后来研究了web.config文件里面的system.web段的globalization的fileEncoding属性约束了ASP.NET从本地读取程序文件的编码。在默认的ASP.NET项目的web.config里面是没有这个属性的，ASP.NET默认会以Windows的默认代码页来读取程序。而我们的asmx文件内部没有中文，即使有中文，ASP.NET也可以识别出来。
但是SPS2003创建的站点里面的web.config文件里面的system.web段的globalization的fileEncoding属性为"utf-8"。我测试了一下，这个属性删除以后，SPS也会有莫名其妙的错误，看来还是不能删除的。