【工具应用】关于FileZilla传输文件时的Transfer type设定问题

        在工作中经常会使用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的情况。