A solução foi mudar o tipo de transferência de Auto para Binário.
Menu de transferência > Tipo de transferência > binário
Geralmente, de hosts remotos diferentes, o FileZilla faz o download de um arquivo .css ou .php e insere linhas em branco entre as linhas existentes. Isso destrói a boa formatação.
PC = Windows 10 Pro de 64 bits.
Como evito isso?
Estou escrevendo esta resposta quando a solução já foi encontrada pelo OP. O objetivo da minha resposta é explicar qual foi o problema para ajudar futuros usuários com problemas semelhantes. A resposta existente fornece uma solução, mas não fornece uma visão. Esta é a resposta:
Solution was to change the transfer type from Auto to Binary.
Transfer menu > Transfer type > binary
Como eu suspeitava (no meu comentário à pergunta), o problema era uma incompatibilidade com a tradução de finais de linha. O Wiki do FileZilla aborda o assunto. Estes são os fragmentos relevantes (todas as citações que seguem são daí, algumas frases são adicionalmente enfatizadas por mim):
Files can be transferred between an FTP client and server in different ways. The FTP specification (RFC 959) calls them "data type" (...)
The different data types are:
- ASCII
- binary
- (...)
ASCII type is used to transfer text files. The problem with text files is that different platforms have different kinds of line endings. Microsoft Windows for example uses a CR+LF pair (carriage return and line feed), while Unix(-like) systems, including Linux and MacOS X, only use LF and traditional MacOS systems (MacOS 9 or older) only use CR. The purpose of ASCII type is to ensure that line endings are properly changed to what is right on the platform. According to the FTP specification, ASCII files are always transferred using a CR+LF pair as line ending.
So in case the file is transferred from the client to the server, the client has to make sure CR+LF is used. (...)
The same happens when a file is downloaded from the server to the client: the server makes sure the line endings are CR+LF when sending the file and the client then strips away whatever is not needed as line ending on its platform.
(...)
Compared to ASCII type, binary type is the easier one: the file is just transferred as-is, and no line ending translation is done.
Um dos exemplos quando as coisas dão errado corresponde ao caso do OP. Acho que foi o que aconteceu:
A Windows (CR+LF) text file was uploaded to a Unix-based FTP server in binary. If that file is downloaded in ASCII, the FTP server translates LF to CR+LF so the CR+LF line endings will be converted to CR+CR+LF. FileZilla on Windows does expect the file to already use CR+LF line encoding (per FTP specification), so no more translation is done. Depending on the text editor used, lines might be separated by an additional empty line now.
A solução do OP é mudar o tipo de transferência de Auto para Binário a partir do menu Transferir . artigo dá também outras maneiras de mudá-lo:
You can change the transfer data type in three ways with FileZilla:
- In the preferences of FileZilla
- In the main menu under Transfer -> Transfer type
- By right-clicking the data type indicator in the status bar of FileZilla.
Tornar binário a opção padrão no Windows pode levar à situação em que .css ou .php ou outro arquivo de texto baixado do sistema não Windows será salvo com LF ou CR único em vez de CR + LF específico do Windows. Pode não ser um problema, como explicado em outro fragmento:
So when you are not sure what to use, always go for binary type. Nowadays, nearly all (good) text editors can handle the three possible line endings, and other textual files like the ones of scripting languages such as Perl or PHP, as well as XML files (nearly) always work with any line ending as well.
Esta solução pode ser a melhor em muitos casos, porque sempre é possível alterar o tipo de transferência.
O título da questão sugere que linhas adicionais foram criadas pelo FileZilla do OP. Não é verdade , não havia nada errado com a configuração do FileZilla do OP. Esse problema se origina em um lado do servidor onde há arquivos de texto com finais de linha incompatíveis com o sistema operacional do servidor. A solução mencionada acima é apenas uma correção do lado do cliente para o problema do lado do servidor .
A solução alternativa é consertar os arquivos (seus terminais de linha) no lado do servidor , de modo que a transferência ASCII funcione como deveria, em primeiro lugar. Esta é obviamente a coisa certa a fazer e pode ser chamada de a melhor solução - em certo sentido: porque lida com a raiz do problema. Considere esta solução se você administrar o servidor ou se puder entrar em contato com o administrador ou se tiver direitos para substituir o arquivo mal formatado. Isso beneficiará outros usuários também.
Mesmo que você entre em contato com o administrador, acho que é sempre mais rápido alterar o tipo de transferência e fazer o download do arquivo desejado, em vez de esperar que as alterações sejam feitas no servidor.