Freqüentemente, de diferentes hosts remotos, o FileZilla baixa um arquivo .cssou .phpe insere linhas em branco entre as linhas existentes. Isso destrói a boa formatação.
Computador = Windows 10 Pro de 64 bits.
Como posso evitar isso?
Responder1
Minha resposta vs. resposta do OP
Estou escrevendo esta resposta quando a solução já foi encontrada pelo OP. O objetivo da minha resposta é explicar qual era o problema para ajudar futuros usuários com problemas semelhantes.A resposta existente fornece uma solução, mas nenhum insight. Esta é a resposta:
A solução foi alterar o tipo de transferência de Automático para Binário.
Menu de transferência > Tipo de transferência > binário
Histórico do problema: ASCII vs. binário
Como eu suspeitava (em meu comentário à pergunta), o problema era uma incompatibilidade com a tradução dos finais de linha. OWiki do FileZillacobre o assunto. Estes são os fragmentos relevantes (todas as citações que se seguem são retiradas deles, algumas frases são adicionalmenteenfatizoupor mim):
Os arquivos podem ser transferidos entre um cliente e um servidor FTP de diferentes maneiras. A especificação FTP (RFC 959) os chama de “tipo de dados” (...)
Os diferentes tipos de dados são:
- ASCII
- binário
- (...)
O tipo ASCII é usado para transferir arquivos de texto.O problema com arquivos de texto é que diferentes plataformas possuem diferentes tipos de finais de linha. O Microsoft Windows, por exemplo, usa um par CR+LF (retorno de carro e alimentação de linha), enquanto sistemas Unix (semelhantes), incluindo Linux e MacOS X, usam apenas LF e sistemas MacOS tradicionais (MacOS 9 ou mais antigos) usam apenas CR.O objetivo do tipo ASCII é garantir que os finais de linha sejam alterados adequadamente para o que está correto na plataforma.De acordo com a especificação FTP, os arquivos ASCII são sempre transferidos usando um par CR+LF como final de linha.
Portanto caso o arquivo seja transferido do cliente para o servidor, o cliente deve certificar-se de que CR+LF seja utilizado. (...)
O mesmo acontece quando um arquivo é baixado do servidor para o cliente: o servidor garante que os finais de linha sejam CR+LF ao enviar o arquivo e o cliente então retira o que não for necessário como final de linha em sua plataforma.
(...)
Comparado ao tipo ASCII, o tipo binário é o mais fácil: o arquivo é transferido como está e nenhuma tradução de final de linha é feita.
O que aconteceu?
Um dos exemplos de quando as coisas dão errado corresponde ao caso do OP. Acho que foi isso que aconteceu:
Um arquivo de texto do Windows (CR+LF) foi carregado em um servidor FTP baseado em Unix em binário. Se esse arquivo for baixado em ASCII, o servidor FTP traduz LF para CR+LF para que os finais de linha CR+LF sejam convertidos para CR+CR+LF. O FileZilla no Windows espera que o arquivo já use a codificação de linha CR+LF (de acordo com a especificação FTP), portanto, nenhuma tradução será feita.Dependendo do editor de texto utilizado, as linhas podem agora ser separadas por uma linha vazia adicional.
Solução
A solução do OP é alterar o tipo de transferência deAutoparaBinárioComeçando deTransferircardápio.O artigo também fornece outras maneiras de alterá-lo:
Você pode alterar o tipo de dados de transferência de três maneiras com o FileZilla:
- Nas preferências do FileZilla
- No menu principal emTransferir->Tipo de transferência
- Clicando com o botão direito no indicador de tipo de dados na barra de status do FileZilla.
Fazendobinárioa opção padrão no Windows pode levar à situação em que .cssou .phpoutro arquivo de texto baixado de um 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, conforme explicado em outro fragmento:
Então, quando você não tiver certeza do que usar, opte sempre pelo tipo binário.Hoje em dia, quase todos os (bons) editores de texto podem lidar com os três finais de linha possíveis, e outros arquivos textuais como os de linguagens de script como Perl ou PHP, assim como arquivos XML (quase) sempre funcionam com qualquer final de linha também.
Esta solução pode ser a melhor em muitos casos porque sempre é possível alterar o tipo de transferência.
Solução alternativa
O título da pergunta sugere que linhas adicionais foram criadas pelo FileZilla do OP. Não é verdade, não havia nada de errado com a configuração do FileZilla do OP. Esse problema se origina no lado do servidor, onde há arquivos de texto com finais de linha incompatíveis com o sistema operacional do servidor.A solução indicada acima é apenas uma correção do lado do cliente para o problema do lado do servidor.
A solução alternativa é corrigir os arquivos (seus finais de linha) no lado do servidor, então a transferência ASCII funciona como deveria em primeiro lugar. Esta é obviamente a coisa certa a fazer e pode ser considerada a melhor solução – num 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 se você entrar em contato com o administrador, acho que é sempre mais rápido alterar o tipo de transferência e baixar o arquivo desejado em vez de esperar que as alterações sejam feitas no servidor.
Responder2
A solução foi alterar o tipo de transferência de Automático para Binário.
Menu de transferência > Tipo de transferência > binário