§

Options

Vista
Granularità
Preprocessing
§

Input

I team di sviluppo italiani incontrano superfici di diff decine di volte al giorno: revisioni di pull request su GitHub e GitLab, tracciamento delle modifiche ai contratti in Microsoft Word, workflow di revisione tra pari in Google Docs. Le organizzazioni che rispettano il GDPR e le linee guida del Garante per la Protezione dei Dati Personali devono spesso confrontare file di configurazione e liste di controllo accessi prima di effettuare modifiche, e incollare quei frammenti in un servizio SaaS pubblico è solitamente una violazione delle policy. Eseguire il confronto in un tab del browser — nessun upload, nessun account, nessun log di terze parti — mantiene il flusso di lavoro veloce per gli sviluppatori e accettabile per chi redige le policy di trattamento dei dati.

Come funzionano gli algoritmi diff

Ogni vista diff in questa pagina è prodotta dall’algoritmo Myers — una tecnica del 1986 di Eugene W. Myers che trova lo script di modifica più breve tra due sequenze di token in tempo O((N+M)D), dove D è la distanza di modifica. L’algoritmo si basa sul problema del Longest Common Subsequence e il motore gira interamente nel tuo browser usando la libreria open source jsdiff.

  1. Tokenizzazione degli input — Prima del confronto, l’algoritmo divide ogni input in una sequenza di token. La granularità per riga divide sui newline; la granularità per parola divide sui confini di spazio bianco e punteggiatura; la granularità per carattere tratta ogni code point Unicode come un token a sé.
  2. Costruzione del grafo delle modifiche — L’algoritmo Myers modella il confronto come un percorso attraverso una griglia 2D dove spostarsi a destra significa "elimina dall’originale", spostarsi in basso significa "inserisci dal modificato" e spostarsi diagonalmente significa "il token è presente in entrambi". L’algoritmo trova il percorso più breve con più mosse diagonali.
  3. Estrazione della LCS — Le mosse diagonali nel percorso più breve tracciano il Longest Common Subsequence — i token che compaiono in entrambi gli input nello stesso ordine relativo. Ogni token nella LCS è "invariato"; tutto il resto è un’aggiunta o un’eliminazione.
  4. Applicazione delle opzioni di pre-elaborazione — Se si abilita "Ignora maiuscole/minuscole", entrambi gli input vengono convertiti in minuscolo prima del passaggio LCS in modo che "CIAO" e "ciao" contino come identici. "Ignora spazi bianchi" comprime più spazi in uno. "Taglia ogni riga" rimuove gli spazi iniziali e finali per riga prima del confronto.
  5. Rendering della vista selezionata — L’output è lo stesso risultato LCS visualizzato in tre modi: Affiancata mostra l’originale a sinistra e il modificato a destra in una griglia a due colonne con evidenziazione rossa e verde delle righe. Unificata mostra una singola colonna con righe prefissate da − e +, come l’output di git diff. Inline mostra le eliminazioni come testo rosso barrato e le aggiunte come testo verde sottolineato all’interno dello stesso flusso di testo.
  6. Calcolo della barra di riepilogo — Dopo il rendering, lo strumento conta quanti token sono stati aggiunti, rimossi e mantenuti, poi calcola la somiglianza come rapporto tra token invariati e il maggiore tra le due lunghezze degli input. Una somiglianza del 100% significa che gli input sono identici dopo la pre-elaborazione.

Perché usare un diff checker

  • Code review senza un client Git — Incolla due versioni di un file di configurazione, una migrazione SQL o uno script shell e vedi cosa è cambiato senza clonare una repository, cambiare branch o aspettare una pipeline CI. Lo strumento è comodo per revisioni rapide durante il pair programming, per le consegne dei contractor dove l’altra parte non ha condiviso la propria cronologia Git, e per codebase legacy che precedono il controllo di versione. La vista unificata produce output che puoi copiare direttamente in un thread di chat o in un ticket.
  • Revisione di contratti e documenti — Il diff per parola mostra quali termini sono cambiati tra le bozze di contratto più velocemente del pannello Revisioni di Word. Incolla la clausola A dalla prima bozza e la clausola B dalla copia eseguita e la sostituzione si illumina in rosso-su-verde nella frase esatta che è cambiata. Paralegal e uffici acquisti lo usano per verificare che le modifiche dell’ultimo minuto non siano sfuggite alla revisione prima della firma del contratto.
  • Revisioni di saggi e bozze — Gli scrittori che confrontano una prima bozza con una versione modificata possono passare alla granularità per parola per vedere ogni sostituzione, inserimento e taglio senza rileggere entrambe le copie. Lo stesso flusso di lavoro funziona per i traduttori che verificano le modifiche rispetto al testo sorgente, per i redattori che controllano che una revisione abbia preservato la voce dell’autore, e per i team giornalistici che riconciliano un articolo pubblicato con la bozza presentata.
  • Confronto di log e configurazioni — I sysadmin che confrontano due snapshot di configurazione del server, due pianificazioni cron o due output di ps aux possono usare la granularità per riga per localizzare il singolo parametro cambiato in un file di 200 righe in pochi secondi. Abbinalo all’opzione Ignora-spazi-bianchi e un diff rumoroso fatto solo di allineamenti collassa ai cambiamenti dei parametri che contano davvero.

Applicazioni comuni

Il diff di testo compare alla fine di ogni ciclo di modifica nel lavoro di scrittura, sviluppo e operazioni.

  • Revisione di pull request: incolla due implementazioni di una funzione affiancate per capire il cambiamento logico prima di approvare, senza il sovraccarico di fare il checkout del branch.
  • QA dell’internazionalizzazione: confronta una stringa sorgente in inglese con il suo equivalente tradotto a livello di parola per rilevare inserimenti, omissioni o scambi di terminologia che il traduttore potrebbe aver introdotto.
  • Analisi degli incidenti: confronta due snapshot di manifest Kubernetes o due output di "docker inspect" a livello di riga per isolare il cambiamento di configurazione che ha preceduto un’interruzione del servizio.

Un esempio pratico

Prendi una configurazione di server a cinque righe. Originale: host=localhost, port=5432, dbname=app_db, user=app, password=secret. Modificato: host=db.prod.example.com, port=5432, dbname=app_db, user=app_prod, password=secret. Con granularità per riga e vista Affiancata, la riga 1 mostra rosso a sinistra (host=localhost) e verde a destra (host=db.prod.example.com), la riga 4 mostra rosso (user=app) e verde (user=app_prod), e le righe 2, 3 e 5 restano invariate su entrambi i lati. La barra di riepilogo riporta 2 aggiunte, 2 eliminazioni, 3 invariate e una somiglianza del 60% — tre righe su cinque mantenute. Passa alla granularità per parola e il diff si restringe ulteriormente: solo i valori a destra del = nelle righe 1 e 4 si illuminano, le chiavi restano invariate e la somiglianza sale a circa l’85% perché la LCS conta ora host, user e la punteggiatura circostante come mantenuti.

Questo gira nel mio browser?

Sì. L’intero calcolo del diff avviene lato client usando la libreria open source jsdiff caricata con la pagina. Nulla di ciò che digiti, incolli o confronti viene inviato a nessun server. Puoi verificarlo tu stesso: apri DevTools del browser, passa alla scheda Rete, cancella il log, clicca Confronta e conferma che non parte nessuna richiesta di rete per il passaggio di confronto.

Cosa significa la percentuale di somiglianza?

La somiglianza è calcolata come token invariati / max(totale token nell’originale, totale token nel modificato). Un punteggio del 100% significa che i due input sono identici dopo l’applicazione delle opzioni di pre-elaborazione (normalizzazione delle maiuscole, compressione degli spazi, taglio delle righe). Un punteggio dello 0% significa che nessun token è condiviso tra gli input. La metrica è un’approssimazione approssimativa della distanza di modifica — utile come indicatore rapido — non un punteggio di plagio o originalità.

Posso fare un diff semantico di JSON / YAML / XML?

Non in questo strumento. Questo è un diff a livello di testo, quindi la sola riformattazione degli spazi bianchi di JSON o XML mostra molte modifiche anche quando i dati sono logicamente identici. Il riordinamento delle chiavi degli oggetti in JSON mostra anche modifiche, anche se la maggior parte dei parser tratta l’ordine delle chiavi come insignificante. Per un vero diff semantico che confronta alberi di oggetti analizzati e ignora l’ordine delle chiavi e la formattazione, è in programma uno strumento dedicato di JSON Diff. Per ora, normalizza entrambi gli input alla stessa indentazione e ordine delle chiavi prima di incollarli qui.

Come differiscono le viste unificata e affiancata?

Affiancata rende due colonne: l’originale a sinistra e la versione modificata a destra, con le righe rimosse evidenziate in rosso a sinistra e le righe aggiunte evidenziate in verde a destra. Le righe invariate appaiono in entrambe le colonne allineate alla stessa riga. Unificata rende una singola colonna con prefisso e sfondo rosso per le righe rimosse e prefisso + e sfondo verde per le righe aggiunte — lo stesso layout che git diff stampa nel terminale. Usa Unificata quando vuoi copiare il risultato come file patch o incollarlo in un thread di code review. Usa Affiancata quando l’allineamento visivo di cosa ha sostituito cosa conta più del testo patch grezzo.

Incolla l’originale a sinistra, la versione modificata a destra, scegli una vista e una granularità, e il confronto appare in millisecondi. Attiva la modalità live e il diff riesegue a ogni tasto premuto mentre modifichi uno dei lati. Scarica il risultato come file unificato standard .patch che git apply consuma direttamente. Nessun upload, nessun account, nessuna chiave API, nessuna quota.