§

Options

Vista
Granularidade
Preprocessing
§

Input

As equipas de engenharia portuguesas e brasileiras encontram uma superfície de diff dezenas de vezes por dia: revisões de pull requests no GitHub e GitLab, rastreamento de alterações de contratos no Microsoft Word, fluxos de revisão por pares no Google Docs. Empresas que trabalham sob a LGPD frequentemente precisam de comparar ficheiros de configuração e listas de controlo de acesso antes de confirmar alterações em ambientes que processam dados pessoais, e colar esses trechos numa ferramenta de comparação SaaS pública é geralmente uma violação de política. Executar a comparação num separador do navegador — sem upload, sem conta, sem registo de terceiros — mantém o fluxo de trabalho rápido para os engenheiros e aceitável para quem redige as políticas de tratamento de dados.

Como funcionam os algoritmos de diff

Cada vista de diff nesta página é produzida pelo algoritmo Myers — uma técnica de 1986 de Eugene W. Myers que encontra o script de edição mais curto entre duas sequências de tokens em tempo O((N+M)D), onde D é a distância de edição. O algoritmo é construído em torno do problema da Subsequência Comum Mais Longa, e o motor corre inteiramente no seu navegador usando a biblioteca de código aberto jsdiff.

  1. Tokenizar as entradas — Antes de comparar, o algoritmo divide cada entrada numa sequência de tokens. A granularidade de linha divide nas novas linhas; a granularidade de palavra divide nos limites de espaços em branco e pontuação; a granularidade de caractere trata cada ponto de código Unicode como o seu próprio token.
  2. Construir o grafo de edições — O algoritmo Myers modela a comparação como um caminho numa grelha 2D onde mover para a direita significa "eliminar do original", mover para baixo significa "inserir do alterado", e mover na diagonal significa "token coincide em ambos". O algoritmo encontra o caminho mais curto com mais movimentos diagonais.
  3. Extrair a LCS — Os movimentos diagonais no caminho mais curto traçam a Subsequência Comum Mais Longa — os tokens que aparecem em ambas as entradas na mesma ordem relativa. Cada token na LCS é "sem alterações"; tudo o resto é uma adição ou uma remoção.
  4. Aplicar opções de pré-processamento — Se ativar "Ignorar maiúsculas/minúsculas", ambas as entradas são convertidas para minúsculas antes da passagem LCS para que "OLÂ" e "olá" contem como idênticos. "Ignorar espaços em branco" colapsa múltiplos espaços em um. "Cortar cada linha" remove os espaços em branco no início e no fim de cada linha antes da comparação.
  5. Renderizar a vista selecionada — O resultado é o mesmo resultado LCS exibido de três formas: Lado a lado mostra o original à esquerda e o alterado à direita numa grelha de duas colunas com destaques de linha vermelhos e verdes. Unificada mostra uma única coluna com linhas com prefixo − e +, como o resultado de git diff. Em linha mostra as remoções como tachado vermelho e as adições como sublinhado verde dentro do mesmo fluxo de texto.
  6. Calcular o resumo — Após a renderização, a ferramenta conta quantos tokens foram adicionados, removidos e mantidos, depois calcula a semelhança como a razão entre tokens não alterados e o maior dos dois comprimentos de entrada. Uma semelhança de 100% significa que as entradas são idênticas após o pré-processamento.

Por que usar um verificador de diff

  • Revisão de código sem cliente Git — Cole duas versões de um ficheiro de configuração, uma migração SQL ou um script de shell e veja o que mudou sem clonar um repositório, mudar de branch ou esperar por um pipeline de CI. A ferramenta é útil para revisões rápidas durante programação em par, para entregas de contratados onde a outra parte não partilhou o histórico Git, e para bases de código legadas que são anteriores ao controlo de versões. A vista unificada produz um resultado que pode copiar diretamente para um thread de chat ou um ticket.
  • Alterações em contratos e documentos — O diff de palavras mostra quais os termos que mudaram entre rascunhos de contratos mais rapidamente do que o painel de Controlo de Alterações do Word. Cole a cláusula A do primeiro rascunho e a cláusula B da cópia executada e a substituição aparece a vermelho sobre verde na frase exata que mudou. As equipas jurídicas e de procurement usam isto para verificar se alterações de última hora não passaram despercebidas pela revisão antes de um contrato ser assinado.
  • Revisões de ensaios e rascunhos — Os escritores que comparam um primeiro rascunho com uma versão editada podem mudar para granularidade de palavra para ver cada substituição, inserção e corte sem reler ambas as cópias. O mesmo fluxo de trabalho funciona para tradutores a auditar alterações em relação ao texto fonte, para editores a verificar se uma edição de texto preservou a voz do autor, e para equipas de jornalismo a reconciliar um artigo publicado com o rascunho arquivado.
  • Comparação de registos e configurações — Administradores de sistemas a comparar dois instantâneos de configuração de servidor, dois agendamentos cron ou dois resultados de ps aux podem usar a granularidade de linha para localizar o único parâmetro alterado num ficheiro de 200 linhas em segundos. Use-a em conjunto com a opção Ignorar espaços em branco e um diff ruidoso com apenas alinhamento colapsa para as alterações de parâmetros que realmente importam.

Aplicações comuns

O diff de texto aparece no final de cada ciclo de edição em trabalhos de escrita, desenvolvimento e operações.

  • Revisão de pull requests: cole duas implementações de função lado a lado para compreender a alteração lógica antes de aprovar, sem o overhead de fazer checkout do branch.
  • QA de internacionalização: compare uma string fonte em inglês com o seu equivalente traduzido ao nível de palavras para detetar inserções, omissões ou trocas de terminologia que o tradutor possa ter introduzido.
  • Análise de incidentes: compare dois instantâneos de manifesto Kubernetes ou dois resultados de "docker inspect" ao nível de linha para isolar a alteração de configuração que precedeu uma interrupção.

Um exemplo prático

Considere uma configuração de servidor de cinco linhas. Original: host=localhost, port=5432, dbname=app_db, user=app, password=secret. Alterado: host=db.prod.example.com, port=5432, dbname=app_db, user=app_prod, password=secret. Com granularidade de linha e vista Lado a lado, a linha 1 mostra vermelho à esquerda (host=localhost) e verde à direita (host=db.prod.example.com), a linha 4 mostra vermelho (user=app) e verde (user=app_prod), e as linhas 2, 3 e 5 ficam sem alterações em ambos os lados. O resumo indica 2 adições, 2 remoções, 3 sem alterações e uma semelhança de 60% — três de cinco linhas mantidas. Mude para granularidade de palavra e o diff afina-se ainda mais: apenas os valores à direita do = nas linhas 1 e 4 ficam destacados, as chaves mantêm-se sem alterações, e a semelhança sobe para cerca de 85% porque a LCS conta agora host, user e a pontuação circundante como mantidos.

Isto corre no meu navegador?

Sim. Todo o cálculo de diff corre do lado do cliente usando a biblioteca de código aberto jsdiff carregada com a página. Nada do que escreve, cola ou compara é enviado para qualquer servidor. Pode verificar isso mesmo: abra as DevTools do navegador, mude para o separador Network, limpe o registo, clique em Comparar e confirme que zero pedidos de rede são feitos para o passo de comparação.

O que significa a percentagem de semelhança?

A semelhança é calculada como tokens sem alterações / máx(total de tokens no original, total de tokens no alterado). Uma pontuação de 100% significa que as duas entradas são idênticas após aplicar as suas opções de pré-processamento (converter maiúsculas, colapsar espaços em branco, cortar linhas). Uma pontuação de 0% significa que nenhum token é partilhado entre as entradas. A métrica é uma aproximação grosseira da distância de edição — útil como indicador rápido — não uma pontuação de plágio ou originalidade.

Posso comparar JSON / YAML / XML semanticamente?

Não nesta ferramenta. Este é um diff a nível de texto, portanto a reformatação com apenas espaços em branco de JSON ou XML ainda mostra muitas alterações mesmo quando os dados são logicamente idênticos. Reordenar as chaves de objetos em JSON também aparece como alterações mesmo que a maioria dos parsers trate a ordem das chaves como insignificante. Para um verdadeiro diff semântico que compare árvores de objetos analisados e ignore a ordem das chaves e a formatação, estamos a planear uma ferramenta dedicada de Diff JSON. Entretanto, normalize ambas as entradas para a mesma indentação e ordem de chaves antes de as colar aqui.

Como diferem as vistas unificada e lado a lado?

Lado a lado renderiza duas colunas: o original à esquerda e a versão alterada à direita, com linhas removidas destacadas a vermelho à esquerda e linhas adicionadas destacadas a verde à direita. As linhas sem alterações aparecem em ambas as colunas alinhadas na mesma linha. Unificada renderiza uma única coluna com prefixo e fundo vermelho para linhas removidas e prefixo + e fundo verde para linhas adicionadas — o mesmo layout que git diff imprime no terminal. Use a unificada quando quiser copiar o resultado como um ficheiro de patch ou colá-lo num thread de revisão de código. Use lado a lado quando o alinhamento visual do que substituiu o quê importa mais do que o texto bruto do patch.

Cole o original à esquerda, a versão alterada à direita, escolha uma vista e uma granularidade, e a comparação aparece em milissegundos. Ative o modo ao vivo e o diff reexecuta em cada tecla pressionada enquanto edita qualquer um dos lados. Descarregue o resultado como um ficheiro .patch unificado padrão que o git apply consome diretamente. Sem upload, sem conta, sem chave de API de fornecedor, sem quota.