Como comparar dois textos com um diff checker

Você recebeu dois arquivos de configuração que "deveriam ser iguais", mas um ambiente sobe e o outro não. Abre os dois lado a lado no editor, rola pra cima e pra baixo, e jura que estão idênticos. Trinta minutos depois descobre que alguém trocou um true por um True numa linha perdida. O olho humano é péssimo nisso, e quanto mais parecidos os textos, pior fica. É exatamente o tipo de tarefa que uma máquina resolve em milissegundos.

Este post é sobre o que um diff checker faz por baixo dos panos, como ler o resultado e quando essa abordagem realmente compensa. Comparação de texto e resolução de conflito são primos próximos — se o seu problema é mesclar branches que divergiram, vale ler antes como resolver conflitos de merge, porque a ferramenta é a mesma família mas o contexto muda tudo.

O que um algoritmo de diff realmente faz

Diff não é "comparar caractere por caractere e marcar diferença". O problema central é mais interessante: dado o texto A e o texto B, qual é a menor sequência de edições (inserções e remoções) que transforma A em B? Isso é o problema da Longest Common Subsequence (LCS), e a maioria das ferramentas usa alguma variação do algoritmo de Myers, publicado em 1986 e ainda o padrão de fato no git diff.

A granularidade muda o resultado por completo:

• Line diff: trata cada linha como uma unidade atômica. É o padrão do Git e o mais comum. Rápido e ótimo pra código.
• Word diff: quebra por palavra. Útil pra revisão de texto, onde uma linha mudou em uma única palavra e você não quer ver a linha inteira marcada como alterada.
• Char diff: granularidade máxima. Mostra exatamente quais caracteres mudaram dentro de uma palavra. Bom pra caçar aquele caractere invisível que quebra um parser.

A escolha errada de granularidade gera ruído. Um line diff num contrato jurídico marca o parágrafo inteiro como "mudou" porque uma vírgula virou ponto. Um char diff num arquivo de código vira sopa de letrinhas. Saber qual usar é metade do trabalho.

Lendo um unified diff sem sofrer

O formato unified diff é o que você vê em pull requests e na saída de git diff. Ele assusta no começo, mas tem três peças:

@@ -12,7 +12,7 @@ def connect(host):
-    timeout = 30
+    timeout = 10
     retries = 3
     return Connection(host, timeout, retries)

A linha @@ -12,7 +12,7 @@ é o hunk header. Lê-se assim: a partir da linha 12 do arquivo original, 7 linhas; a partir da linha 12 do novo, 7 linhas. As linhas com - saíram, as com + entraram, e as sem prefixo são contexto que não mudou — estão ali só pra você se localizar. Quando você entende que -/+ são "antigo"/"novo" e não "errado"/"certo", o diff para de parecer um julgamento e vira o que é: um mapa de mudanças.

Onde isso resolve problema de verdade

Os casos reais raramente são "dois arquivos .txt". São situações como:

• Config drift: o .env de staging e o de produção divergiram em algum momento e ninguém sabe quando. Um diff colado lado a lado mata a dúvida em segundos.
• Revisão de contrato: a versão que o jurídico mandou de volta tem 200 páginas e dizem que "só mudaram uma cláusula". Word diff confirma — ou desmente.
• Comparação de logs: o request que funcionou e o que falhou, lado a lado. O diff destaca o header ou o campo de payload que diverge.
• Revisão de copy: marketing reescreveu a landing page e quer saber exatamente o que mudou em relação ao texto aprovado.

Em todos esses, o padrão é o mesmo: dois textos quase iguais onde a diferença importa e é difícil de achar no olho. Pra colar duas versões e ver a diferença destacada na hora, um comparador de texto no browser resolve sem você precisar abrir terminal nem instalar nada. É o tipo de tarefa que não justifica git, mas justifica não confiar no próprio olho.

Os limites: ruído de whitespace e encoding

Diff é literal, e essa é tanto a força quanto a armadilha. Espaço em branco no fim da linha, tab versus espaço, \r\n versus \n — tudo isso conta como diferença. Você compara dois arquivos que renderizam idêntico e a ferramenta acusa 40 linhas alteradas, porque um foi salvo no Windows e o outro no Linux.

# normalizar line endings antes de comparar
git diff --ignore-cr-at-eol
git diff --ignore-all-space

Encoding é o vilão silencioso. Um arquivo em UTF-8 com BOM e outro sem BOM diferem no primeiro byte, mesmo com texto idêntico. Acentuação em Latin-1 versus UTF-8 também explode o diff. Antes de gastar tempo investigando "diferenças" que não existem semanticamente, normalize: mesmo encoding, mesmas line endings, e considere ignorar whitespace se ele não for relevante pro seu caso.

Por que o diff visual ganha do olho

A objeção comum é "eu consigo comparar no olho". Não, você não consegue — não de forma confiável, e não com textos longos. O cérebro humano é otimizado pra perceber a forma geral, não pra detectar que o caractere 4.213 mudou. É por isso que erros de digitação passam batido em textos que relemos cinco vezes.

Um diff visual remove essa carga. Ele faz o trabalho determinístico (achar a menor edição) e usa cor pra direcionar sua atenção exatamente onde algo mudou. Você deixa de procurar e passa a julgar — que é onde o seu cérebro de fato agrega valor. A regra prática: se a corretude da comparação importa, não confie no olho. Cole nos dois lados e deixe o algoritmo apontar.

Perguntas frequentes

Qual a diferença entre line diff, word diff e char diff?

Line diff compara linha inteira por linha inteira, char diff compara caractere por caractere, e word diff fica no meio, comparando palavra por palavra. Use line diff pra código, word diff pra texto corrido e char diff quando precisa caçar um caractere específico dentro de uma palavra.

Por que o diff acusa diferenças se os textos parecem iguais?

Quase sempre é whitespace ou encoding. Espaços no fim da linha, tab versus espaço, line endings de Windows versus Unix, ou BOM no início do arquivo são invisíveis na tela mas contam como diferença. Normalize encoding e line endings antes de comparar.

Diff checker serve só pra código?

Não. Serve pra qualquer texto onde duas versões precisam ser comparadas: contratos, logs, configs, copy de marketing, traduções. O algoritmo não liga pro tipo de conteúdo, só pra sequência de caracteres.

Preciso instalar algo pra comparar dois textos?

Não necessariamente. Pra arquivos versionados, git diff já resolve. Pra duas versões soltas que você só quer comparar uma vez, um diff checker no browser faz o trabalho sem instalação.

O que levar daqui

Diff é um problema resolvido há quase quatro décadas, e ainda assim a gente insiste em fazer no olho e errar. A ferramenta certa transforma uma caçada frustrante numa leitura de mapa: escolha a granularidade certa pro tipo de texto, normalize whitespace e encoding antes de confiar no resultado, e leia o unified diff como um registro de mudanças, não como veredito. O olho serve pra julgar a mudança — não pra encontrá-la.