图-FileZilla
善用佳软又拿了一篇关于filezilla的好文章出来，不过呢，说到filezilla的utf-8支持(也就是所谓的乱码问题)，还真是让人哭笑不得。
说来这个问题很简单，就是rfc 2640，里面规定的流程大概是这样的：
client: feat //这里是询问server支持哪些特性
server: blabla UTF8 blabla //server回答支持utf-8
然后client在收到UTF8字样时后面的通讯编码都必须采用utf-8，server也一样，之后就不会有乱码了，当然feat前的server welcome message仍然可能出现乱码，但是别的命令没有问题，因为前面其他命令都只用到了ascii码中的前127个字符(也许不到)，和utf-8兼容。
当然这个想法是很好的，大家都支持unicode，然后天下太平。但是，根据墨菲定律，凡事总是会朝着坏方向发展滴。
首先，不是所有的server一定支持回应feat命令，也不是所有client一定会发出feat命令，所以只要有一方出问题，那应该怎么办?是用utf-8还是本地ansi?
第二种则是更普遍的情况，client会询问feat，但是并不支持utf-8，这样的话如果server完全支持rfc 2640，那么server说的是utf-8而client说的是本地ansi，双方都不会意识到出错了，但是事实是出错了。
所以，rfc 2640其实是完全抛弃了不支持utf-8的client。当然从逻辑上来说也是有问题的，因为feat命令仅仅是查询server支持的feature，至于client要用到哪些feature，那完全是client的自由和权利，而现在的rfc 2640则是“反正server我是支持utf-8了，你必须无条件使用utf-8”，这显然违反了网络协议中的协商原则。
所以现在大部分支持utf-8的server和client的做法是，当client询问feat，server回应中有UTF8，则当client要求“OPTS UTF8 ON”而且server正确回应了时，双方才开始使用utf-8进行传送。
虽然OPTS UTF8 ON并不是rfc中的命令，但是显然更为合理，所以大部分的server/client都支持这个命令。
所以tommy大侠提交过一个patch，大致就是增加一个选项，可以在 收到OPTS UTF8 ON才使用utf-8 以及 当以UTF8回应feat时就开始使用utf-8 中切换。但是作者很不厚道，把tommy大侠的账户给ban了。
alcohol在新版里面加了个acid，我运行一看，不就是一个yasu么?原来yasu一度成为daemon tool专有，没想到dt随后内置了屏蔽虚拟光驱检测功能，使得yasu在dt下完全没有了用处，热脸贴了冷屁股。现在alcohol也搞个专有yasu，还挺有意思的。
[update]
Tommy大侠其实也是fud传播者，他说64位系统内存消耗较大的原因是因为int64比int32占地方，其实不对。
首先在64位系统上跑的32位程序用的依然是int32，占用内存也不会更多，对于64位程序来说，自然int64用法和int32有所不同，二者是并存的而不是谁取代谁的关系，而且至少在C中默认的int就是int32，无论是不是for x86-64的程序。
第二，64位系统占用较多内存的真正原因是系统需要load双份dll，一份给32位程序调用，一份给64位程序调用。7-zip无论是64还是32位版本，其右键菜单在64位系统下均不能完全正常地工作，因为对于64位的7-zip只有64位的右键菜单dll，所以tc等32位程序是无法调用的;而32位7-zip又只有32位的dll，所以在64位的explorer下是无法工作的。而winrar就聪明得多，一份32位的exe+32/64位的dll，这样无需选择安装文件而且在64/32位程序下都能正常使用。当然咯，要让64位的dll和32位的exe协调工作还是有些技巧的，再比如mark大侠的process explorer本身是32位程序，但是在64位系统下运行时会释放出一个64位的可执行文件，和原可执行文件协同运作，至今我没有在mark以外的人手上见过这样的编写技巧。
[update]
验证了一下filezilla3 client的行为，当对方的server不是filezilla而且收到的feat里面有UTF8时，的确会接着发送OPTS UTF8 ON，酱紫还不错，不过feat前面一直是用utf8处理的，如果是ansi的welcome message就会乱码，不过说回来，无论怎么规定，welcome message都有乱码的可能，除非client能像某些文本编辑器一样精准地判断编码。
server方面，filezilla现在还是老样子，对于client发过来的feat响应了UTF8时，后面不会关闭UTF8处理，无论client如何回应。当然client支持UTF8的话就会发送OPTS UTF8 ON，然后filezilla server就会回一个don't care(汗啊)，然后双方可以使用utf-8通信了;对于不支持utf-8的client，比如那个很操蛋的cuteftp，不会发送OPTS UTF8 ON也不会使用utf-8，然后双方一个讲utf-8一个讲ansi，乱码就出现了。
另外，当filezilla自家的server和client通信时，server会发一个MDTM的feat，然后client会随机选择一个文件进行时差校对。这很有意思，因为别家的client即使收到了MDTM也不会去对时，而filezilla的client在连别家的server时也是如此，也就是说，只有filezilla自家的client连server才会对时。
通过文章的描述，我们不难发现：Filezilla的utf-8支持出错已解决，希望对大家有所帮助！
【编辑推荐】
- FileZilla Server提权
- FileZilla使用测评
- FileZilla实用功能之文件存在处理
- FileZilla实用功能之分组管理
- 如何实现FileZilla防掉线（反空闲、闲置保护）
- FileZilla文件关联
- FileZilla 支持多种语言
- FileZilla实用功能之文件过滤器
