Ferramentas para desenvolvedores · Comparação de texto
Por que o Windows e o Unix discordam nas terminações de linha: a história de CR, LF e CRLF
· Fundo
diferença de texto finais de linha histórico do software
Rastreia terminações de linha de máquinas de escrever e teletipos até sistemas operacionais modernos e explica por que duas convenções ainda coexistem em todos os projetos de plataforma cruzada.
Um personagem invisível, décadas de atrito – começa com o persistente aborrecimento entre plataformas
Os finais de linha são invisíveis em editores comuns, mas podem ser importantes para arquivos e protocolos. Em ToolAcre, entretanto, CR, LF e CRLF são normalizados antes da comparação de linha. Um par que difere apenas nesses separadores produz a mesma matriz linear e um resultado idêntico.
Esse comportamento resolve a questão prática desta rota, ao mesmo tempo que limita o que ela pode diagnosticar. A comparação não pode provar quais bytes de nova linha os arquivos originais continham depois que o texto chega aos seus editores. Uma ferramenta com reconhecimento de bytes é necessária para preservação ou verificações de protocolo.
Retorno de carro e alimentação de linha em uma máquina de escrever – explica as duas ações físicas que os personagens descreveram originalmente
Os termos retorno de carro e alimentação de linha têm significados físicos e históricos, mas o repositório não contém nenhuma fonte de máquina de escrever. Repetir de memória uma história de origem mecânica violaria o contrato de evidências, mesmo que o relato parecesse familiar.
Este artigo, portanto, trata CR como o ` ` code unit and LF as ` `somente onde a implementação os utiliza. A explicação histórica deve ser acrescentada posteriormente a partir de padrões primários ou arquivos, em vez de ser emprestada de um esboço que explicitamente não é uma fonte.
Os significados da máquina de escrever são afirmações históricas que requerem fontes externas
Da mesma forma, os arquivos de origem não documentam convenções de teletipo ou decisões iniciais do sistema operacional. Eles revelam apenas uma opção de compatibilidade no JavaScript atual: substitua cada CRLF ou CR solitário por LF antes da divisão.
Essa transformação aceita texto colado produzido sob diversas convenções sem preencher a saída com alterações somente finais. É uma decisão de implementação visível em uma expressão regular e fixada por testes para todos os três formulários.
A linhagem do teletipo e do sistema operacional está fora da evidência do repositório
É comum associar Unix com LF, Windows com CRLF e sistemas mais antigos com CR solitário, mas o repositório atual não pode servir como prova histórica dessas adoções. A reivindicação segura está operacional: todas as três entradas tornam-se LF dentro de `splitLines`.
Um terminal LF não cria uma linha final vazia, enquanto as linhas em branco no meio permanecem. Esta distinção significa que o conteúdo lógico é mantido mesmo que as diferenças do separador físico sejam apagadas. A comparação é orientada por linha, não por preservação de bytes.
O código prova que três convenções são normalizadas; não prova por que os sistemas os adotaram
Alguns protocolos de rede e de mensagens especificam terminadores de linha exatos, mas seus requisitos devem vir de suas especificações. A normalização de ToolAcre o torna inadequado para provar a conformidade com esse formato de ligação porque a evidência do separador original é removida intencionalmente.
Use um visualizador hexadecimal ou validador de protocolo antes de analisar quando as sequências CRLF exatas são importantes. Um resultado limpo de comparação de texto pode confirmar linhas lógicas correspondentes e, simultaneamente, ocultar um defeito no nível de transporte. Ambas as observações podem ser verdadeiras porque as ferramentas respondem a questões diferentes.
Os requisitos do protocolo precisam de especificações próprias e são omitidos aqui
Compare `alpha beta`, `alpha beta` e `alpha beta` em pares. Cada um produz duas linhas, alfa e beta, e sem adições ou remoções. Ignorar espaços em branco não causa essa igualdade; a normalização já aconteceu durante a divisão.
Adicione espaços à direita a uma linha beta e o modo normal agora reportará uma diferença. Habilite Ignorar espaços em branco e ele pode desaparecer. A sequência separa o tratamento de nova linha do tratamento de espaços em branco de chave de linha e evita creditar a opção errada.
Exemplo resolvido: todos os três formulários finais são comparados como iguais antes das opções de espaço em branco
Esta rota não configura editores, reescreve arquivos, define atributos Git ou terminações de conversão em massa. Também não expõe o separador original nas linhas de resultados. As strings coladas entram em um pipeline de comparação, não em um utilitário de migração de nova linha.
A causalidade histórica e os padrões de protocolo são omitidos como fontes pendentes. Essa restrição deixa um artigo menor, mas exato: o que três convenções fazem nesta implementação, quais linhas em branco permanecem e por que a igualdade aqui não estabelece a identidade de bytes.
Conclusão: saiba qual convenção seu texto carrega - resume a história e como a comparação de texto de ToolAcre ajuda a confirmar se a diferença é apenas no final das linhas
Saiba quais evidências sobreviveram à ferramenta. Após a normalização, ToolAcre pode comparar o conteúdo da linha lógica entre separadores comuns. Ele não pode dizer qual convenção a fonte usou ou se um consumidor downstream requer uma sequência exata de bytes.
Use a comparação do navegador para revisão humana e uma verificação em nível de byte para aplicação de repositório ou protocolo. Uma ferramenta é confiável quando suas transformações são explícitas; os revisores permanecem responsáveis por selecionar aquele que preserva a propriedade que precisam verificar.