Comparar Textos

Como funciona a comparação?

Os dois textos são quebrados em linhas e a diferença sai do algoritmo LCS (Longest Common Subsequence). Quem ficou igual aparece em cinza, o que foi acrescentado em verde e o que saiu em vermelho.

Na hora de comparar, só os espaços do começo e do fim de cada linha são ignorados. Maiúsculas, minúsculas e pontuação entram na conta.

Acontece tudo no navegador, sem mandar nenhum texto para fora.

Quando comparar textos: revisão de código, contratos, documentos, traduções

Comparar dois trechos de texto é uma daquelas tarefas que parecem triviais até você precisar fazer isso em documentos que importam. Bater os olhos em dois parágrafos lado a lado tentando achar o que mudou é cansativo e pouco confiável. Uma ferramenta de diff remove essa carga cognitiva alinhando mecanicamente as duas versões e destacando apenas as partes diferentes, de modo que o olho vai direto para as edições relevantes em vez de reler centenas de linhas idênticas.

Em revisão de código, o diff é a unidade de conversa. Pull requests no GitHub, GitLab, Bitbucket e sistemas como Gerrit ou Phabricator apresentam mudanças no formato unified diff. Revisores comentam em linhas específicas adicionadas ou removidas, e o mesmo formato alimenta linters, scripts de CI e ferramentas de merge. Sem uma representação determinística de diff, revisão assíncrona em escala não existiria.

No jurídico, a mesma ideia se chama redlining. Advogados comparam minutas de contratos, NDAs, termos de uso e atos normativos para saber exatamente quais cláusulas a contraparte alterou entre rodadas de negociação. O recurso "Comparar Documentos" do Microsoft Word, o Workshare Compare, o Litera Compare e o DraftAble implementam diff especializado para prosa jurídica. Uma alteração não percebida em um limite de responsabilidade ou em uma cláusula de foro pode custar milhões, então a precisão da comparação automática não é luxo, é controle de risco.

Em tradução e localização, diffs identificam o que mudou no texto-fonte entre releases para que tradutores retoquem só os segmentos afetados em vez de revisitar o arquivo inteiro. Memórias de tradução como Trados, memoQ e Smartcat dependem de diffs por segmento, e fluxos CAT (computer-assisted translation) costumam exibir um comparativo lado a lado para o revisor ver os dois idiomas alinhados.

Na escrita acadêmica, periódicos frequentemente exigem que autores enviem uma "resposta aos revisores" com versão controlada por alterações do manuscrito. Em detecção de plágio, serviços comparam submissões de alunos contra corpora para sinalizar trechos copiados literalmente. Em engenharia de dados, exportar dois CSVs e fazer diff é a forma mais barata de validar que um script de migração preservou as linhas esperadas. Comparar textos é, em resumo, um bloco de construção universal.

Algoritmos: LCS, Myers (1986), Patience, Histogram

Todo diff textual é, no fundo, uma busca pela Maior Subsequência Comum (LCS, do inglês Longest Common Subsequence) entre as duas entradas. A LCS é a sequência mais longa de elementos que aparece em ambos os arquivos na mesma ordem relativa, sem precisar ser contígua. Depois de conhecida a LCS, tudo que está fora dela é adição (presente só no novo arquivo) ou remoção (presente só no antigo). A versão clássica via programação dinâmica roda em O(m * n) de tempo e memória, o que serve para dois parágrafos mas é inviável para arquivos com dezenas de milhares de linhas.

O salto prático foi o artigo de 1986 de Eugene W. Myers, "An O(ND) Difference Algorithm and Its Variations", em que N é o comprimento total das entradas e D é o tamanho do script mínimo de edição. Para arquivos majoritariamente parecidos, D é pequeno e Myers roda quase linear. Este é o algoritmo padrão do GNU diff, do Git via --diff-algorithm=myers, da maioria das bibliotecas padrão das linguagens e da rotina JavaScript que move esta ferramenta.

Myers gera o script de edição mais curto, mas nem sempre o mais legível. Quando o código é refatorado, Myers pode casar linhas sem relação que apenas compartilham espaços em branco ou chaves, produzindo um diff confuso. O algoritmo Patience, criado por Bram Cohen (autor do BitTorrent) e batizado em homenagem ao jogo de cartas, ataca esse problema localizando linhas que aparecem exatamente uma vez em ambos os arquivos e usando-as como âncoras de alinhamento; depois recorre nos segmentos entre âncoras. O resultado é um diff que respeita fronteiras de funções e lê mais naturalmente.

O algoritmo Histogram, disponível no Git via --diff-algorithm=histogram, refina o Patience contando a frequência de cada linha e preferindo as mais raras como âncoras. Costuma ser mais rápido que o Patience e produzir saída igual ou melhor, motivo pelo qual muitas equipes o configuram como padrão. Algoritmos mais antigos incluem o Hunt-McIlroy (1976), pioneiro da técnica de k-candidates no Bell Labs e inspiração do diff Unix original, e o Wagner-Fischer para distância de edição em nível de caractere.

Formato unified diff: linhas +/-, contexto, cabeçalho @@

O formato unified diff, introduzido pelo GNU diff em 1990 e adotado pelo Git, é a língua franca para representar mudanças textuais. Um unified diff é texto puro que pode ser enviado por e-mail, colado em um ticket, aplicado com patch -p1 ou visualizado em qualquer ferramenta de review. Exemplo curto:

diff --git a/greet.py b/greet.py
index 5be4a4a..0123456 100644
--- a/greet.py
+++ b/greet.py
@@ -1,5 +1,6 @@
 def greet(name):
-    return "Hello " + name
+    if not name:
+        return "Hello stranger"
+    return f"Hello {name}"

 print(greet("Ada"))

O cabeçalho --- a/greet.py e +++ b/greet.py nomeia o arquivo antigo e o novo. O hunk header @@ -1,5 +1,6 @@ significa "começando na linha 1, cinco linhas do arquivo antigo correspondem a seis linhas do novo". Linhas começando com espaço são contexto (inalteradas, mostradas para orientação), linhas com - foram removidas e linhas com + foram adicionadas. O padrão é três linhas de contexto antes e depois de cada mudança, configurável com -U.

Uma linha especial \ No newline at end of file aparece quando uma das versões não termina com newline. Hunks podem opcionalmente mostrar o nome da função envolvente após o segundo @@, o que permite ler um diff do Git e identificar imediatamente qual função mudou sem ter que rolar o arquivo.

Comparação por linha vs palavra vs caractere

Os mesmos algoritmos operam sobre tokens diferentes, e essa escolha muda profundamente o resultado.

• Diff por linha é o padrão para código-fonte. Cada linha é um token. Rápido, fácil de ler, mas uma correção de um caractere em uma linha longa aparece como linha inteira removida e re-adicionada.
• Diff por palavra tokeniza por espaços e pontuação. Ideal para prosa e traduções porque destaca apenas as palavras de fato alteradas dentro de frases idênticas. Git suporta com git diff --word-diff.
• Diff por caractere compara um caractere por vez. Útil para strings curtas, identificadores, ou para evidenciar erros de digitação e mudanças de maiúsculas. O custo cresce quadraticamente, então não é prático para documentos inteiros.
• Diff semântico, como o difftastic, faz parse da árvore sintática e compara nós, ignorando ruído de formatação como linhas reflowed ou chaves movidas.

Ferramentas desktop e GUI

Além da linha de comando, ferramentas gráficas maduras servem desenvolvedores, escritores e engenheiros há décadas:

• diff (Unix, GNU diffutils) — o original, ainda incluído em todo sistema POSIX.
• Beyond Compare (Scooter Software, pago, Windows/macOS/Linux) — compara textos, pastas, PDFs, documentos Word, imagens e tabelas; merge a três vias.
• Meld (gratuito, código aberto, GNOME) — comparação de arquivos e pastas a duas e três vias com integração VCS.
• WinMerge (gratuito, código aberto, Windows) — clássico do Windows com syntax highlighting e sincronização de pastas.
• Kaleidoscope (pago, macOS) — interface polida, diff de imagens e textos, integração com Git, SVN e diversos editores.
• VS Code — diff lado a lado nativo, acessível via code --diff a.txt b.txt, além da visualização rica no painel SCM.
• P4Merge, Araxis Merge, DiffMerge, ExamDiff Pro — outras opções comerciais e gratuitas.

Cenários jurídicos: alterações em contratos e redlining

Em negociação contratual, cada revisão importa. Uma ferramenta de diff diz ao paralegal exatamente quais cláusulas a contraparte mexeu, se um número foi ajustado, se uma definição foi apertada ou afrouxada, se um "deverá" virou "poderá". O "Comparar Documentos" do Microsoft Word produz uma versão redlined com inserções, exclusões e formatações marcadas; ferramentas especializadas como Litera Compare, Workshare Compare e DraftAble são ajustadas para prosa jurídica, ignorando diferenças triviais de formatação e gerando relatórios que advogados assinam embaixo.

Para além de contratos, aplicações jurídicas incluem comparar leis entre edições, rastrear alterações em estatutos sociais, verificar se uma tradução de tratado bate com o original, e provar autenticidade em litígio. Em algumas jurisdições, um redline impresso é aceito como prova da alteração, o que faz o próprio diff virar parte dos autos.

Limites: arquivos binários e mudanças semânticas vs textuais

Ferramentas de diff textual assumem texto puro na entrada. Elas falham em arquivos binários como imagens, executáveis compilados, ZIPs, documentos Word (que internamente são XML zipado) e PDFs. O Git detecta conteúdo binário e imprime Binary files differ em vez do diff. Para binários é preciso uma ferramenta que conheça o formato: ImageMagick para imagens, pandoc para converter documentos Office em texto antes de comparar, ou produtos especializados como Beyond Compare e Diffchecker que têm modos para PDF e imagem.

Um segundo limite é a cegueira semântica. Diff textual enxerga caracteres, não significado. Renomear uma variável de x para total em uma função aparece como dezenas de linhas adicionadas e removidas mesmo que a lógica seja idêntica. Reformatar um JSON com indentação diferente gera um diff enorme sem mudança comportamental. Inversamente, um bug de um único caractere como >= virando > parece minúsculo no diff mas pode quebrar produção. Revisores precisam ter sempre em mente que tamanho do diff não é proxy de risco.

FAQ

Algo é enviado para um servidor?

Não. Este comparador roda inteiramente no seu navegador, em JavaScript. Os textos colados não saem da página, o que torna o uso seguro para contratos confidenciais, código-fonte interno ou manuscritos não publicados.

Qual algoritmo a ferramenta usa?

Uma comparação por linha baseada em Maior Subsequência Comum (LCS), equivalente ao comportamento padrão de Myers. Linhas inalteradas são preservadas, adições marcadas com + e remoções com -, seguindo a convenção unified diff.

Dá para comparar mais de dois arquivos?

Esta ferramenta trabalha com duas entradas. Para merges a três vias, comparando um ancestral comum com duas versões divergentes, use o próprio Git ou ferramentas desktop como Meld, Beyond Compare ou KDiff3.

Como ignorar diferenças de espaços em branco?

Por enquanto, normalize as entradas manualmente (tire espaços no final, padronize a indentação). Na linha de comando, git diff -w ignora qualquer whitespace e diff -b ignora mudanças apenas de espaço.

Por que minha refatoração gera um diff confuso?

Porque Myers minimiza edições sem entender estrutura. Para refatorações grandes, experimente um diff Patience ou Histogram no Git (git diff --histogram) ou uma ferramenta sintática como o difftastic.