Мой ответ против ответа ОП
Я пишу этот ответ, когда решение уже найдено OP. Цель моего ответа - объяснить, в чем заключалась проблема, чтобы помочь будущим пользователям с подобными проблемами. Существующий ответ дает решение, но не дает понимания. Это ответ:
Решением было изменить тип передачи с Auto на Binary.
Меню переноса> Тип переноса> бинарный
Фон проблемы: ASCII против двоичного
Как я и подозревал (в моем комментарии к вопросу), проблема заключалась в несоответствии с переводом окончаний строк. FileZilla Wiki охватывает эту тему. Это соответствующие фрагменты (все цитаты, которые следуют далее из них, некоторые фразы, которые дополнительно подчеркнуто мной):
Файлы могут передаваться между 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 двоичный тип является более простым: файл просто передается как есть, и перевод строки не заканчивается.
Что случилось?
Один из примеров, когда что-то идет не так, соответствует случаю ОП. Я думаю, что это то, что случилось:
Текстовый файл Windows (CR + LF) был загружен на FTP-сервер Unix в двоичном формате. Если этот файл загружен в ASCII, сервер FTP преобразует LF в CR + LF, поэтому окончания строки CR + LF будут преобразованы в CR + CR + LF. FileZilla в Windows ожидает, что файл уже будет использовать строковое кодирование CR + LF (согласно спецификации FTP), поэтому перевод больше не производится. В зависимости от используемого текстового редактора, строки теперь могут быть разделены дополнительной пустой строкой.
Решение
Решение OP - изменить тип передачи с Auto на Binary, начиная с меню Transfer . В статье приведены и другие способы его изменения:
Вы можете изменить тип передаваемых данных тремя способами с помощью FileZilla:
- В настройках FileZilla
- В главном меню под Transfer -> Transfer type
- Щелкнув правой кнопкой мыши индикатор типа данных в строке состояния FileZilla.
Установка бинарного параметра по умолчанию в Windows может привести к ситуации, когда .cssили .phpдругой текстовый файл, загруженный из системы, отличной от Windows, будет сохранен с одним LF или CR вместо специфичного для Windows CR + LF. Это не может быть проблемой, как объяснено в другом фрагменте:
Поэтому, когда вы не уверены, что использовать, всегда выбирайте двоичный тип. В настоящее время почти все (хорошие) текстовые редакторы могут обрабатывать три возможных конца строки, а другие текстовые файлы, такие как языки сценариев, такие как Perl или PHP, а также файлы XML (почти) всегда работают с любым концом строки.
Это решение может быть лучшим во многих случаях, потому что всегда можно изменить тип передачи.
Альтернативное решение
Заголовок вопроса предполагает, что дополнительные строки были созданы FileZilla ОП. Это неправда, в конфигурации FileZilla OP не было ничего плохого. Эта проблема возникает на стороне сервера, где есть текстовые файлы с окончаниями строк, не соответствующие ОС сервера. Вышеупомянутое решение - только решение проблемы стороны сервера к стороне клиента .
Альтернативное решение состоит в том, чтобы исправить файлы (их окончания строк) на стороне сервера, чтобы в первую очередь передача ASCII работала как надо. Это, безусловно, правильно и может быть названо лучшим решением - в некотором смысле: потому что оно имеет дело с корнем проблемы. Рассмотрите это решение, если вы администрируете сервер или можете связаться с администратором, или если у вас есть права перезаписать плохо отформатированный файл. Это пойдет на пользу и другим пользователям.
Даже если вы обратитесь к администратору, я думаю, что всегда быстрее изменить тип передачи и загрузить нужный файл, а не ждать внесения изменений на стороне сервера.