乐而为之

首先是在Windows上用Filezilla连接Ubuntu时看到的中文文件名全是乱码，但是用Putty通过SSH连接Ubuntu却是正常的（原先是乱码，后来改设置为UTF－8编码就好了，不过Filezilla没有类似的设置可改）。如果用Filezilla向Ubuntu上传本地的中文文件，则在Filezilla里看到Remote端的文件名是正确的，但在Putty里看到是乱码。

然后更严重的问题是：当我在Ubuntu上用Filezilla的SFTP从FreeBSD上下载文件时发现那些中文文件名都成了乱码。只好改用tar/tar.gz再试，结果还是乱。最后问了Google，但是结果并不理想，试过很多方法都无法解决，甚至为此特地在FreeBSD和Ubuntu上都装了p7zip试验，也还是不行。

折腾了好几天之后，我才想到应该研究一下几个系统上的locale设置究竟是如何的--坦白说，要不是因为搜到的资料里有提到这方面，我从前还真没注意到这回事。在FreeBSD和Ubuntu上分别运行了locale命令检查的结果是：

FreeBSD的LC_ALL为"C"，即"POSIX"的别名，似乎是一种无固定编码的方案，或者可以认为就是本地编码，默认的设置。
Ubuntu的LC_ALL为"zh_CN.UTF-8"，这个是我设置的。
Windows不必说了，肯定是本地编码--只是我没有想到的是，公司里用的英文版Windows居然也是本地编码，我一直以为是Unicode的，看来是为了保持兼容。

这样就好理解了，Filezilla不改变编码方式，所以当Remote端与本机的编码不一致时，必然乱码。所以在Windows上用Filezilla连接Ubuntu看到乱码，而我的Putty因为是设置为UTF－8编码，所以看到的是正确的--因为Ubuntu一端是UTF－8。而如果用Filezilla上传中文文件，则因为Windows是本地编码，所以上传以后仍然为本地编码（GB系），而Ubuntu是UTF－8所以是乱码。

FreeBSD那边的问题也是一样的，因为那些文件都是以前从Windows上传上去的，用的都是GB系编码，而早年我用Putty都是用默认的本地编码方案，所以一直没有发现问题。这样的话，因为FreeBSD是本地编码，与Ubuntu的UTF－8不一致，所以怎么弄都是乱码。

但是据说用7zip这样的工具打包以后是可以解决这样的编码不一致问题的，我试了却没有成功。后来才想明白，因为7zip是根据系统的locale设置来对文件名进行相应的处理，因为原来我处理的时候文件名是GB系的编码，而系统是设置为UTF－8，所以总也不对。