最近，我花了将近两个小时才意识到，在将项目文件从一台服务器下载并上传到本地（Linux Mint）再上传到另一台服务器后，使用 Filezilla 上传文件会损坏文件（例如添加不需要的空格或损坏特殊的 UTF-8 字符）。虽然 99.9% 的文件完全没问题，但极少数文件出现了这个问题，导致项目无法再运行。
假设我只有 FTP 连接可用。我也更喜欢 SFTP 或更好的 SSH，但有些客户端的主机根本不提供它。因此，我想知道哪种方式是通过 FTP 传输数据的安全方式，它可能以不同的方式编码并包含不同的字符。
我注意到 Filezilla 中有一个针对 ASCII 与二进制模式的设置。我发现了以下解释：
使用 FTP 传输文件有两种不同的模式：“ASCII”和“二进制”模式。之所以有两种不同的模式，是因为在文本或 ASCII 文件中，有两种不同的方法来表示行尾。在 UNIX 计算机上，行尾用字符表示。该字符是控制-J。某些 UNIX 命令（如 od(1)）用“\n”表示该字符。例如，如果您有一个名为“foo”的 UNIX 文件：
$ cat foo 这是对用枪射击的终端的测试。 $ od -c foo 00000000000 thisisatesto 00000000020 f \ntheterminalt 00000000040 hatis \nshotfrom 00000000060 gu ns .\n 00000000067
在 PC 上（以及大型计算机上），行尾用 表示，后面跟着一个字符。即 Control-M 后面跟着 Control-J。
在 FTP 中，如果您指定“ASCII”模式，则在将文件从 UNIX 系统发送到 PC 时，文件中的每个 control-J 之前都会添加一个 control-M。这将确保 ASCII/文本文件在 PC 上可读。相反，如果您以“ASCII”模式将文件从 PC 发送到 UNIX 系统，则组合 control-M control-J 将更改为 control-J。从 PC 发送到 UNIX 系统时，文件大小每行将减少一个字节；从 UNIX 系统发送到 PC 时，文件大小每行将增加一个字节。在两台 PC 或两个 UNIX 系统之间发送时，以“ASCII”模式发送的文件将保持不变。
以“二进制”模式发送的文件会从一个系统发送到另一个系统，且不会发生任何修改。在二进制传输中，文件大小始终保持不变。
使用 FTP 在两台 PC 之间发送单个文本文件时，适合使用“ASCII”模式。发送其他文件时，适合使用“二进制”模式：TAR 文件、压缩文件、gzip 文件、CA-Alexandria 二进制文件等。如果在 PC 和 UNIX 系统之间以“ASCII”模式发送二进制文件，则二进制文件的内容将被修改，使其不再可读；必须从原始系统以二进制模式重新发送该文件。通常，当客户向我们发送在我们的机器上无法读取的 TAR 或压缩文件时，这就是问题的根源。
此外，每个人都应该记住，由于我们的 ftp 站点是 NT 服务器，因此默认传输模式是 ascii。我们的典型客户是 UNIX 系统管理员。他们习惯于默认为二进制的站点。当要求他们将文件放到我们的站点上时，提醒他们默认为 ascii，并且他们需要设置二进制模式。
（来源：https://knowledge.broadcom.com/external/article/28212/ftp-ascii-vs-binary-mode-what-it-means.html）
据此我认为二进制模式始终是一种安全的方式，而 ASCII 模式可能会导致各种问题？我的假设正确吗是否有任何进一步的设置需要考虑（例如关于字符集）以避免将来 FTP GUI 客户端出现类似的问题？