Filezilla的utf-8支持
圖-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實用功能之文件過濾器
