1.用FTP功能的时候用的是从别人那COPY过来的FTP（download）下载函数。在网上搜集资料加上自己扩充，增加了上传(upload)和列表（getlist）功能。
列表的时候出现问题，有些机器的编码不一样，读出来的中文是乱字符。
当然可以在代码里直接把streamreader的解码方式直接换成相应服务器的，但这样的话，ftp通用模块就是一句空话，每换一个服务器就要改一下代码。
也想过把相应服务器的编码方式变成可变的参数传到函数里来，不过还是太麻烦，不符合编程的细节透明的原则。再说人家FLASHFXP是怎么做到的呢？用FLASHFXP上任何服务器，从未碰上过编码混乱的问题。话说不久前，我用微软的VS2005的FTP远程发布时也碰上过类似问题，传到服务器上的中文文件名都是乱码，在网上查了很久无解。这个问题在网上也查了很久，比上次好点的是大家把问题的原因--本机文字编码讲出来了，然后多数人手一摊，无解。要么就是给出一个方法，很复杂，读取前三个字节，然后判断编码方式，也只能支持区区几种编码方式。再不就是发ftp命令，让服务器支持utf8编码。
还是自己用课外时间研究。
研究发现，encoding类的getencodings函数支持把本机支持的编码罗列出来。于是我试着用各种编码方式把读取出来的乱码还原，反复试，反复研究的过程中，发现解码编码是不可逆的。比如有时候把乱字符按他解错了的方式还原成byte数组，结果包含41个元素，而用Uncode把正确的string转化成相应编码的byte数组包含42个元素。当然“有时候”也是正确的。从编程角度而言，这条路不能走了。
罗列出来的编码方式多达140种，还只是本机支持的，要搞清楚为什么会出这种错误是不可能的，而且也是不划算的。于是我换个思路，把正确的string转化成正确的byte数组，然后再按不可逆的错误方式重读一变，生成的理应是唯一的错误的结果，然后把乱字符和这个错误的结果相比较，两者都是错误的，错的应该是一样的。
缺点是这种方法要是比较的工作扩大了140倍，比如当前目录100个文件，本来100次循环，现在要比较14000次。但说老实话说，基本上没感觉到速度变化。FTP函数最拖速度的是网络连接和获取响应，至于编码解码完全在本机进行，用的都是虚拟机内置的函数编，解码，应该是在内存中完成的，千万次以下的循环对于当前的CPU而言都是小case。
目前尚未发现问题，代码粘出来共享。
1 //默认streamreader创建
2 StreamReader reader = new StreamReader(response.GetResponseStream(),Encoding.Default);
3
4 /////////////////////////////////////////////////////////////////////////////
5
6 #region 编码判断
7 /// <summary>
8 /// 编码判断
9 /// </summary>
10 public static bool CompareWithEncodings(string ftp, string local)
11 {
12 EncodingInfo[] eis = Encoding.GetEncodings();
13 foreach (EncodingInfo ei in eis)
14 {
15 byte[] UnicodeLocal = Encoding.Unicode.GetBytes(local);
16 byte[] EiLocal = Encoding.Convert(Encoding.Unicode, ei.GetEncoding(), UnicodeLocal);
17 string strLocalToCompare = Encoding.Default.GetString(EiLocal);
18 if(strLocalToCompare.Equals(ftp))
19 {
20 return true;
21 }
22 }
23 return false;
24 }
25 #endregion
有这个函数，基本上FTP模块的文件名编码问题可以说一劳永逸的解决了。
2.关于SVN同时用客户端支持两个服务端地址的问题。svn不同版本的控制信息的文件夹是不一样的，早先用的是"_SVN"，现在用的是“.svn”，利用这个不同，让两个服务端安装不同版本的SVN服务器，然后在客户端分别装两个不同的客户端，比如smartsvn和tortoisesvn，这样版本就不会彼此覆盖了。
3.以上两个都不是大问题，解决方法也笨的可以，不过都凑合能用。下一步计划，利用公开的PDF文件标准做一个简单的阅读器