通常，FileZilla 会从不同的远程主机下载一个.css或.php文件，并在现有行之间插入空行。这会破坏良好的格式。
PC = Windows 10 Pro 64 位。
我该如何防止这种情况发生？
答案1
我的回答与原帖者的回答
我在原作者已经找到解决方案时写下此答案。我回答的目的是解释问题所在，以帮助将来遇到类似问题的用户。现有的答案给出了解决方案，但没有提供见解。这是答案：
解决方案是将传输类型从自动更改为二进制。
传输菜单>传输类型>二进制
问题背景：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 的偏好设置中
- 在主菜单中转移->传输类型
- 通过右键单击 FileZilla 状态栏中的数据类型指示器。
制作二进制Windows 中的默认选项可能会导致以下情况：.css从.php非 Windows 系统下载的文本文件将以单个 LF 或 CR 保存，而不是 Windows 特定的 CR+LF。这可能不是问题，如另一个片段所述：
因此，当您不确定使用什么时，请始终选择二进制类型。如今，几乎所有（好的）文本编辑器都可以处理这三种可能的行尾，并且其他文本文件（例如 Perl 或 PHP 等脚本语言的文本文件）以及 XML 文件（几乎）也总是可以使用任何行尾。
在许多情况下，这种解决方案可能是最好的，因为人们可以随时改变传输类型。
替代解决方案
问题标题暗示原作者的 FileZilla 生成了额外的行。但事实并非如此，OP 的 FileZilla 配置没有任何问题。此问题源于服务器端，其中存在行尾与服务器操作系统不匹配的文本文件。上述解决方案只是客户端对服务器端问题的修复。
另一种解决方案是在服务器端修复文件（它们的行尾），因此 ASCII 传输首先可以正常工作。这显然是正确的做法，并且可以称为最佳解决方案——在某种意义上：因为它解决了问题的根源。如果您管理服务器，或者您可以联系管理员，或者您有权覆盖格式错误的文件，请考虑此解决方案。这也将使其他用户受益。
即使您联系管理员，我认为更改传输类型并下载所需文件总是比等待服务器端进行更改更快。
答案2
解决方案是将传输类型从自动更改为二进制。
传输菜单>传输类型>二进制