阻止 Filezilla 在文本文件中插入空行

Question

通常，从不同的远程主机，FileZilla 会下载一个.css或.php文件并在现有行之间插入空行。这会破坏漂亮的格式。

PC = Windows 10 专业版 64 位。

我如何防止这种情况？

Answer 1

我的答案与 OP 的答案

当 OP 已经找到解决方案时，我正在写这个答案。我的回答的目的是解释问题是什么，以帮助未来遇到类似问题的用户。现有答案提供了解决方案，但没有洞察力。这是答案：

解决方案是将传输类型从自动更改为二进制。

传输菜单 > 传输类型 > 二进制

问题背景：ASCII 与二进制

正如我怀疑的那样（在我对问题的评论中）问题是与行尾翻译不匹配。该FileZilla的维基涵盖的主题。这些是相关的片段（以下所有引文均出自其中，我还额外强调了一些短语）：

文件可以以不同的方式在 FTP 客户端和服务器之间传输。FTP 规范 (RFC 959) 称它们为“数据类型”(...)

不同的数据类型是：

• ASCII码
• 二进制
• （……）

ASCII 类型用于传输文本文件。文本文件的问题在于不同的平台有不同种类的行尾。例如，Microsoft Windows 使用 CR+LF 对（回车和换行），而 Unix（类）系统，包括 Linux 和 MacOS X，仅使用 LF，而传统的 MacOS 系统（MacOS 9 或更早版本）仅使用 CR。ASCII 类型的目的是确保行尾正确更改为平台上的正确内容。根据 FTP 规范，ASCII 文件始终使用 CR+LF 对作为行尾进行传输。

因此，如果文件从客户端传输到服务器，客户端必须确保使用 CR+LF。（……）

当文件从服务器下载到客户端时，也会发生同样的情况：服务器在发送文件时确保行尾为 CR+LF，然后客户端将删除不需要的任何内容作为其平台上的行尾。

（……）

与 ASCII 类型相比，二进制类型更容易：文件只是按原样传输，不进行行尾转换。

发生了什么？

出现问题的示例之一与 OP 的情况相符。我认为这就是发生的事情：

一个 Windows (CR+LF) 文本文件以二进制形式上传到基于 Unix 的 FTP 服务器。如果该文件以 ASCII 格式下载，FTP 服务器会将 LF 转换为 CR+LF，因此 CR+LF 行尾将转换为 CR+CR+LF。Windows 上的 FileZilla 确实希望文件已经使用 CR+LF 行编码（根据 FTP 规范），因此不再进行转换。根据所使用的文本编辑器，行现在可能会被额外的空行分隔。

解决方案

OP 的解决方案是从传输菜单开始将传输类型从自动更改为二进制。文章还给出了其他改变它的方法：

您可以使用 FileZilla 以三种方式更改传输数据类型：

• 在 FileZilla 的首选项中
• 在Transfer -> Transfer type下的主菜单中
• 通过右键单击 FileZilla 状态栏中的数据类型指示器。

制作二进制Windows中的默认选项可能会导致这种情况时，.css或.php从非Windows系统下载或其他文本文件将保存与单个LF或CR而不是Windows的特定CR + LF。正如另一个片段中所解释的那样，这可能不是问题：

因此，当您不确定要使用什么时，请始终使用二进制类型。如今，几乎所有（好的）文本编辑器都可以处理三种可能的行尾，而其他文本文件（如 Perl 或 PHP 等脚本语言的文本文件，以及 XML 文件（几乎））也始终适用于任何行尾。

这种解决方案在许多情况下可能是最好的，因为人们可以随时更改传输类型。

替代方案

问题标题表明额外的行是由 OP 的 FileZilla 创建的。事实并非如此，OP 的 FileZilla 配置没有任何问题。此问题源于服务器端，其中存在行尾与服务器操作系统不匹配的文本文件。上述解决方案只是对服务器端问题的客户端修复。

另一种解决方案是在服务器端修复文件（它们的行尾），这样 ASCII 传输就可以正常工作。这显然是正确的做法，可以称为最佳解决方案——从某种意义上说：因为它解决了问题的根源。如果您管理服务器，或者您可以联系管理员，或者您有权覆盖格式错误的文件，请考虑使用此解决方案。这也将使其他用户受益。

即使您联系管理员，我认为更改传输类型并下载您想要的文件总是更快，而不是等待在服务器端进行更改。