Часто с разных удаленных хостов FileZilla загружает .css
или .php
и вставляет пустые строки между существующими. Это разрушает хорошее форматирование.
ПК = Windows 10 Pro 64-битная.
Как мне это предотвратить?
Я пишу этот ответ, когда решение уже найдено OP. Цель моего ответа - объяснить, в чем заключалась проблема, чтобы помочь будущим пользователям с подобными проблемами. Существующий ответ дает решение, но не дает понимания. Это ответ:
Решением было изменить тип передачи с Auto на Binary.
Меню переноса> Тип переноса> бинарный
Как я и подозревал (в моем комментарии к вопросу), проблема заключалась в несоответствии с переводом окончаний строк. 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 работала как обычно. Это, безусловно, правильно и может быть названо лучшим решением - в некотором смысле: потому что оно имеет дело с корнем проблемы. Рассмотрите это решение, если вы администрируете сервер или можете связаться с администратором, или если у вас есть права перезаписать плохо отформатированный файл. Это пойдет на пользу и другим пользователям.
Даже если вы обратитесь к администратору, я думаю, что всегда быстрее изменить тип передачи и загрузить нужный файл, а не ждать внесения изменений на стороне сервера.
Решением было изменить тип передачи с Auto на Binary.
Меню переноса> Тип переноса> бинарный