通常，FileZilla 會從不同的遠端主機下載一個.css或.php文件，並在現有行之間插入空白行。這會破壞良好的格式。
PC = Windows 10 專業版 64 位元。
我該如何防止這種情況？
答案1
我的答案與OP的答案
當OP已經找到解決方案時，我正在寫這個答案。我回答的目的是解釋問題是什麼，以幫助未來有類似問題的使用者。現有答案提供了解決方案，但沒有洞察力。這是答案：
解決方案是將傳輸類型從“自動”變更為“二進位”。
傳輸選單 > 傳輸類型 > 二進位
問題背景：ASCII 與二進位
正如我懷疑的那樣（在我對問題的評論中）問題是與行結尾翻譯不匹配。這維基百科涵蓋了主題。這些是相關片段（以下所有引文均來自其中，一些短語是另外添加的）強調由我）：
檔案可以透過不同的方式在 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 中的預設選項可能會導致從非 Windows 系統下載的.css或.php或其他文字檔案將以單一 LF 或 CR 保存，而不是 Windows 特有的 CR+LF 保存。這可能不是問題，正如另一個片段所解釋的：
因此，當您不確定要使用什麼時，請始終選擇二進位類型。如今，幾乎所有（好的）文字編輯器都可以處理三種可能的行結尾，而其他文字檔案（例如Perl 或PHP 等腳本語言的文字檔案）以及XML 檔案（幾乎）也總是可以處理任何行結尾。
在許多情況下，這種解決方案可能是最好的，因為人們總是可以更改傳輸類型。
替代解決方案
問題標題顯示額外的行是由 OP 的 FileZilla 建立的。這不是真的，OP的FileZilla配置沒有任何問題。此問題源自於伺服器端，其中存在行結尾與伺服器作業系統不符的文字檔案。上述解決方案只是客戶端修復伺服器端問題。
另一種解決方案是在伺服器端修復檔案（它們的行結尾），因此 ASCII 傳輸首先就按其應有的方式工作。這顯然是正確的做法，並且可以被稱為最佳解決方案——從某種意義上說：因為它解決了問題的根源。如果您管理伺服器或您可以聯絡管理員或您有權覆蓋格式錯誤的文件，請考慮此解決方案。這也將使其他用戶受益。
即使您聯繫管理員，我認為更改傳輸類型並下載您想要的檔案總是比等待伺服器端進行更改更快。
答案2
解決方案是將傳輸類型從“自動”變更為“二進位”。
傳輸選單 > 傳輸類型 > 二進位