在工作中經常會使用FileZilla軟件（FTP工具）上傳或者下載文件，最近遇到一個下載文件內容異常的問題，涉及到該軟件中的Transfer type設置，於是進行了一些深入的學習，在此與君共享，以作前車之鑑。
問題概述
在Win10環境下，使用FileZilla下載文件，其中主要包含兩種後綴名：*.bin和*.ko。
在Linux環境下，下載後的部分ko文件出現無法掛載的情況。
使用Beyond Compare軟件對比文件，如下圖所示，異常文件的部分內容丟失。
在網上找到以下兩個帖子算是比較相關的：
【已解決】FileZilla傳輸（上傳或下載）文件過程中，文件大小會變化
該帖詳細描述了作者在使用FileZilla時發現文件異常問題以及解決的過程。結論爲，對於客戶端和服務器之間的文件傳輸，若上傳和下載使用的默認傳輸類型均爲自動，那麼對於文本文件，有可能會檢測到服務器是Linux，而客戶端是Windows，從而在傳輸過程中，進行各自對應的結束符轉換，導致下載的文件大小發生變化，並且對應的文本文件在Notepad++打開時出現顯示問題。
Important Notice: Do you use Filezilla? Avatars and Attachments lost?
該帖作者遇到的問題是，使用Auto類型進行文件傳輸時，對於無後綴名的文件發生異常的情況。解決方法在於“Treat files without extension as ASCII file”的設定，文中同樣提到了關於傳輸類型選擇的問題，並且提供一些自己的想法和建議。
雖然都跟我遇到的問題不一樣，但是按照其中的建議，將傳輸類型修改爲Binary之後，確實能夠下載到正常的文件內容，因此只能先懷疑是FileZilla的Auto類型功能對應的判斷邏輯中存在隱藏的Bug。
FTP的數據傳輸類型
文件傳輸協議（File Transfer Protocol，FTP）是用於在網絡上進行文件傳輸的一套標準協議，它工作在應用層，即OSI模型的第七層（TCP 模型的第四層），使用TCP傳輸。客戶在與服務器建立連接前，需要經過“三次握手”的過程，以保證連接和數據傳輸的可靠性。
FTP 的目標是提高文件的共享性，它基於客戶/服務器（C/S）模型而設計，在客戶端與 FTP 服務器之間建立兩個TCP連接，分別傳輸數據與命令。任何基於 FTP 的客戶端軟件都必須遵循 FTP 的工作原理，如下圖所示。
FTP標準（RFC 959）中所定義的數據類型有四種，即ASCII，Binary，EBCDIC和Iocal。但是，大多數情況下，只會用到ASCII和Binary兩種，兩者的區別主要是在不同操作系統中回車符與換行符的使用上，從而會導致文件大小和內容的差異出現。（詳情可參閱FileZilla參考文檔）
CR（Carriage Return）表示回車，'\r'，ASCII碼（0x0D）
LF（Line Feed）表示換行，'\n'，ASCII碼（0x0A）
同樣對於下一行的表示，Dos和Windows使用（CR+LF）；UNIX/Linux使用（LF）；MAC OS使用（CR）。
因此，同一個文本文件在不同的操作系統中需要進行相應的轉換，才能夠正常地顯示和使用。
在ASCII類型的傳輸中，FTP通常會自動地調整文件的內容，以便於把文件解釋成本地計算機存儲文本文件的相應格式，有可能會造成數據損壞。
在二進制類型的傳輸中，保存文件的位序，以便原始和拷貝的是逐位一一對應的。
FileZilla的傳輸類型（Transfer type）設置
在FileZilla軟件中，可以通過以下兩種方式設置傳輸類型，可選類型項目包括：Auto，ASCII，Binary。
1）Edit --> Settings --> Transfers --> FTP: File Types
2）Transfer --> Transfer type
建議
- 進行文件傳輸時，首先確認傳輸內容是否與傳輸類型設置相匹配。
- 對於無法準確判斷的文件，最好使用二進制（Binary）類型，以保證傳輸內容不做任何改動。
- 全部使用壓縮文件，則無需考慮默認傳輸類型爲Auto的情況。