notepad ++ adicionando linhas extras a um arquivo

Question

Estou com esse problema há anos e tentei ignorá-lo, mas quando abro arquivos pela primeira vez salvos de uma caixa mac / unix, vejo uma quebra de linha extra após cada linha:

something like

this

which is pretty

annoying

O que eu costumo fazer é apenas fazer uma das muitas correções para esse comportamento no google, como a solução TextFX para excluir todas as linhas em branco.

Mas estou curioso para saber por que isso acontece. Por quê? Por que isso não acontece novamente mesmo se eu salvar o arquivo, enviá-lo para o repositório do git (e quando ele for editado por outro usuário em um mac / unix) eu não recebo mais esse problema?

EDITAR

o problema git era um problema que eu tinha antes, mas o nosso problema atual é que estamos carregando arquivos usando o clipe de papel, que salva no sistema de arquivos (estamos usando uma máquina windows). quando abrimos os arquivos, vemos isso como "macintosh" "ansi" mesmo se o servidor estiver rodando no windows. Existe uma maneira de torná-lo aberto com a codificação adequada por padrão?

    

Answer 1

Eu tenho lutado com o mesmo problema por vários anos, mas depois de ler este post e tentar algumas configurações no Notepad ++ ele não parece ser o Notepad ++ que está mudando as configurações de LF ou CR.

Meu 'problema' foi causado por uma configuração do Filezilla, com a qual eu faço o download dos arquivos do meu site para editá-los no Notepad ++.

No Filezilla, eu tinha muitas extensões na configuração 'Classificação automática de tipo de arquivo' (vá para Editar > Configurações > Transferências > Tipos de arquivo ). Depois que eu limpei todos eles e baixei novamente o meu arquivo, ele abriu muito bem no Notepad ++, sem mais quebras de linha extras. Também testado para editar o arquivo, carregá-lo, baixá-lo e editá-lo novamente.

Então, no Notepad ++, minha configuração padrão para novos arquivos é:

• Codificação: ANSI
• Formato: Windows

E no Filezilla as configurações são:

• Tipo de transferência: Auto
• Classificações automáticas de tipo de arquivo: a lista de extensões está vazia

Isso resolveu meu problema.

Espero que ajude.

    

Answer 2

Ajudaria a obter mais algumas informações, como

1. Qual editor você está usando no Mac / Unix?
2. Quando você o abre no Notepad ++, o que ele diz na barra de status? Dos / Unix / Mac?
3. Isso acontece também se o arquivo não passar pelo git?

Os finais de linha têm sido problemáticos por um longo tempo ao passar arquivos entre sistemas e você pode ler mais sobre isso em Wikipedia . O problema vem do Windows usando CR + LF como quebras de linha, Mac usando apenas CR e Unix usando apenas LF (eu sei que isso não é uma regra dura e rápida, mas em geral).

Ao usar um editor esperando um arquivo no formato Unix e receber um arquivo no formato Windows, o editor pode interpretar incorretamente o CR + LF como duas quebras de linha em vez de uma. Também é comum que isso se mostre como caracteres finais em cada linha, geralmente um quadrado ou outro absurdo.

Você deve ser capaz de verificar se isto é o que está acontecendo com você no Notepad ++, indo para Exibir- > Mostrar símbolo- > Mostrar o fim da linha. Você também deve poder corrigir isso usando a função de Conversão de EOL de edição & gt ;.

Também é possível que isso seja causado por ou possa ser resolvido nas configurações do seu git. O Git tem três configurações, core.eol, core.safecrlf e core.autocrlf que você pode ler mais no git config manpage

    

Answer 3

Eu tentei as soluções acima e nenhuma delas estava funcionando para mim, mas aconteceu que era o FileZilla.

Encontrei uma recomendação em um de seus fóruns para transferir usando < em> binary mode em vez de auto . Depois que eu mudei isso, meu problema foi resolvido. :)

Exerpt:

Set Transfer type (menu Transfer) from Auto to Binary and upload your script.