圖-FileZilla

　　善用佳軟又拿了一篇關(guān)于filezilla的好文章出來，不過呢，說到filezilla的utf-8支持(也就是所謂的亂碼問題)，還真是讓人哭笑不得。

　　說來這個(gè)問題很簡單，就是rfc 2640，里面規(guī)定的流程大概是這樣的：

　　client: feat //這里是詢問server支持哪些特性

　　server: blabla UTF8 blabla //server回答支持utf-8

　　然后client在收到UTF8字樣時(shí)后面的通訊編碼都必須采用utf-8，server也一樣，之后就不會(huì)有亂碼了，當(dāng)然feat前的server welcome message仍然可能出現(xiàn)亂碼，但是別的命令沒有問題，因?yàn)榍懊嫫渌疃贾挥玫搅薬scii碼中的前127個(gè)字符(也許不到)，和utf-8兼容。

　　當(dāng)然這個(gè)想法是很好的，大家都支持unicode，然后天下太平。但是，根據(jù)墨菲定律，凡事總是會(huì)朝著壞方向發(fā)展滴。

　　首先，不是所有的server一定支持回應(yīng)feat命令，也不是所有client一定會(huì)發(fā)出feat命令，所以只要有一方出問題，那應(yīng)該怎么辦?是用utf-8還是本地ansi?

　　第二種則是更普遍的情況，client會(huì)詢問feat，但是并不支持utf-8，這樣的話如果server完全支持rfc 2640，那么server說的是utf-8而client說的是本地ansi，雙方都不會(huì)意識(shí)到出錯(cuò)了，但是事實(shí)是出錯(cuò)了。

　　所以，rfc 2640其實(shí)是完全拋棄了不支持utf-8的client。當(dāng)然從邏輯上來說也是有問題的，因?yàn)閒eat命令僅僅是查詢server支持的feature，至于client要用到哪些feature，那完全是client的自由和權(quán)利，而現(xiàn)在的rfc 2640則是“反正server我是支持utf-8了，你必須無條件使用utf-8”，這顯然違反了網(wǎng)絡(luò)協(xié)議中的協(xié)商原則。

　　所以現(xiàn)在大部分支持utf-8的server和client的做法是，當(dāng)client詢問feat，server回應(yīng)中有UTF8，則當(dāng)client要求“OPTS UTF8 ON”而且server正確回應(yīng)了時(shí)，雙方才開始使用utf-8進(jìn)行傳送。

　　雖然OPTS UTF8 ON并不是rfc中的命令，但是顯然更為合理，所以大部分的server/client都支持這個(gè)命令。

　　所以tommy大俠提交過一個(gè)patch，大致就是增加一個(gè)選項(xiàng)，可以在 收到OPTS UTF8 ON才使用utf-8 以及 當(dāng)以UTF8回應(yīng)feat時(shí)就開始使用utf-8 中切換。但是作者很不厚道，把tommy大俠的賬戶給ban了。

　　alcohol在新版里面加了個(gè)acid，我運(yùn)行一看，不就是一個(gè)yasu么?原來yasu一度成為daemon tool專有，沒想到dt隨后內(nèi)置了屏蔽虛擬光驅(qū)檢測功能，使得yasu在dt下完全沒有了用處，熱臉貼了冷屁股。現(xiàn)在alcohol也搞個(gè)專有yasu，還挺有意思的。

　　[update]

　　Tommy大俠其實(shí)也是fud傳播者，他說64位系統(tǒng)內(nèi)存消耗較大的原因是因?yàn)閕nt64比int32占地方，其實(shí)不對(duì)。

　　首先在64位系統(tǒng)上跑的32位程序用的依然是int32，占用內(nèi)存也不會(huì)更多，對(duì)于64位程序來說，自然int64用法和int32有所不同，二者是并存的而不是誰取代誰的關(guān)系，而且至少在C中默認(rèn)的int就是int32，無論是不是for x86-64的程序。

　　第二，64位系統(tǒng)占用較多內(nèi)存的真正原因是系統(tǒng)需要load雙份dll，一份給32位程序調(diào)用，一份給64位程序調(diào)用。7-zip無論是64還是32位版本，其右鍵菜單在64位系統(tǒng)下均不能完全正常地工作，因?yàn)閷?duì)于64位的7-zip只有64位的右鍵菜單dll，所以tc等32位程序是無法調(diào)用的;而32位7-zip又只有32位的dll，所以在64位的explorer下是無法工作的。而winrar就聰明得多，一份32位的exe+32/64位的dll，這樣無需選擇安裝文件而且在64/32位程序下都能正常使用。當(dāng)然咯，要讓64位的dll和32位的exe協(xié)調(diào)工作還是有些技巧的，再比如mark大俠的process explorer本身是32位程序，但是在64位系統(tǒng)下運(yùn)行時(shí)會(huì)釋放出一個(gè)64位的可執(zhí)行文件，和原可執(zhí)行文件協(xié)同運(yùn)作，至今我沒有在mark以外的人手上見過這樣的編寫技巧。

　　[update]

　　驗(yàn)證了一下filezilla3 client的行為，當(dāng)對(duì)方的server不是filezilla而且收到的feat里面有UTF8時(shí)，的確會(huì)接著發(fā)送OPTS UTF8 ON，醬紫還不錯(cuò)，不過feat前面一直是用utf8處理的，如果是ansi的welcome message就會(huì)亂碼，不過說回來，無論怎么規(guī)定，welcome message都有亂碼的可能，除非client能像某些文本編輯器一樣精準(zhǔn)地判斷編碼。

　　server方面，filezilla現(xiàn)在還是老樣子，對(duì)于client發(fā)過來的feat響應(yīng)了UTF8時(shí)，后面不會(huì)關(guān)閉UTF8處理，無論client如何回應(yīng)。當(dāng)然client支持UTF8的話就會(huì)發(fā)送OPTS UTF8 ON，然后filezilla server就會(huì)回一個(gè)don't care(汗啊)，然后雙方可以使用utf-8通信了;對(duì)于不支持utf-8的client，比如那個(gè)很操蛋的cuteftp，不會(huì)發(fā)送OPTS UTF8 ON也不會(huì)使用utf-8，然后雙方一個(gè)講utf-8一個(gè)講ansi，亂碼就出現(xiàn)了。

　　另外，當(dāng)filezilla自家的server和client通信時(shí)，server會(huì)發(fā)一個(gè)MDTM的feat，然后client會(huì)隨機(jī)選擇一個(gè)文件進(jìn)行時(shí)差校對(duì)。這很有意思，因?yàn)閯e家的client即使收到了MDTM也不會(huì)去對(duì)時(shí)，而filezilla的client在連別家的server時(shí)也是如此，也就是說，只有filezilla自家的client連server才會(huì)對(duì)時(shí)。

通過文章的描述，我們不難發(fā)現(xiàn)：Filezilla的utf-8支持出錯(cuò)已解決，希望對(duì)大家有所幫助！

【編輯推薦】

1. FileZilla Server提權(quán)
2. FileZilla使用測評(píng)
3. FileZilla實(shí)用功能之文件存在處理
4. FileZilla實(shí)用功能之分組管理
5. 如何實(shí)現(xiàn)FileZilla防掉線（反空閑、閑置保護(hù)）
6. FileZilla文件關(guān)聯(lián)
7. FileZilla 支持多種語言
8. FileZilla實(shí)用功能之文件過濾器