Confronto e unione testo
Incolla due versioni di un testo e confrontale riga per riga con differenze a colori.
Risultato del confronto
Come funziona
- Incolla due testi: inserisci il testo originale nel pannello di sinistra e il testo rivisto in quello di destra.
- Consulta le differenze: le righe modificate sono evidenziate, verde per le aggiunte, rosso per le eliminazioni e giallo per le modifiche.
- Sfoglia il diff: scorri tra le modifiche colorate e copia o cattura come immagine le parti di cui hai bisogno.
Una breve storia di diff
Il moderno diffing del testo è iniziato ai Bell Labs. Douglas McIlroy (lo stesso McIlroy che ha inventato le pipe di Unix) e James W. Hunt hanno scritto il diff Unix originale all'inizio degli anni 1970; è stato distribuito come parte della 5a edizione di Unix nel 1974. L'algoritmo è stato documentato nel Bell Laboratories Computing Science Technical Report #41 (giugno 1976), un report interno intitolato "An Algorithm for Differential File Comparison". L'algoritmo Hunt-McIlroy è costruito sul problema della sottosequenza comune più lunga (LCS), trovare la sequenza più lunga di righe che appare, in ordine, in entrambi gli input, e tutto ciò che non è in quella sequenza è o una cancellazione o un inserimento. Un decennio dopo, Eugene W. Myers ha pubblicato "An O(ND) Difference Algorithm and Its Variations" in Algorithmica, Vol 1 Issue 2 (1986). Myers ha riformulato il problema come ricerca del percorso più breve su un "edit graph" e ha mostrato che poteva essere risolto in tempo e spazio O(ND), dove N è la dimensione dell'input e D è la dimensione dello script di edit minimo. Per input tipici, file che differiscono solo in pochi punti, D è piccolo, quindi l'algoritmo è veloce in pratica. Il documento di Myers è diventato la base per un'implementazione più veloce del diff Unix che girava da due a quattro volte più velocemente del suo predecessore e produceva output di qualità più alta. Patience diff (Bram Cohen, 2008) è un raffinamento LCS che dà priorità a righe di ancoraggio uniche, producendo diff più leggibili intorno a blocchi spostati. Il default attuale in git diff è l'algoritmo histogram in LibXDiff, generalmente considerato più veloce del Myers vaniglia e producendo diff più leggibili in presenza di blocchi spostati (è diventato il default di Git nella 2.11, rilasciata il 29 novembre 2016). I fondamenti matematici vanno ancora più in profondità: la distanza di Levenshtein (Vladimir Levenshtein, 1965) è la cugina a livello di carattere del problema LCS, e la soluzione di programmazione dinamica di Wagner-Fischer (1974) è ciò che ogni libreria di "fuzzy match" implementa ancora internamente.
Come viene renderizzato un diff
Ci sono quattro convenzioni visive comuni per visualizzare un diff. Side-by-side, due colonne, originale a sinistra, modificato a destra, con righe corrispondenti allineate. Buono per il confronto a colpo d'occhio; funziona bene alle larghezze desktop ma diventa illeggibile su viewport mobili stretti. Diff unificato inline, una singola colonna che mostra righe rimosse (tipicamente prefissate con - e colorate di rosso), righe aggiunte (+, verde) e righe di contesto invariate (nessun prefisso, testo semplice). Il layout che git diff usa di default. Scala bene al mobile ma perde il parallelismo spaziale del side-by-side. Diff a livello di parola, evidenziando solo le parole che sono cambiate all'interno delle righe modificate. Utile per il confronto di prosa dove la maggior parte del testo è invariata ma frasi specifiche sono state modificate. Diff a livello di carattere, evidenziando ogni carattere modificato individualmente. Utile per modifiche molto piccole (una correzione di refuso, una modifica di una singola cifra) dove il livello di parola evidenzierebbe l'intera parola. Le convenzioni di colore sono notevolmente coerenti in tutto l'ecosistema: verde per aggiunte, rosso per rimozioni, giallo o ambra per valori modificati, grigio neutro o senza stile per invariato. Questo strumento usa lo stile unificato inline con evidenziazione a livello di carattere all'interno delle righe modificate, un ibrido che scala bene al mobile preservando la precisione del confronto a livello di carattere per modifiche di prosa.
Merge a tre vie, quando due diff devono combinarsi
Un diff a due vie (questo strumento) ti dice cosa è cambiato tra la versione A e la versione B. Un merge a tre vie risponde a una domanda più difficile: dato un antenato comune e due revisioni divergenti, qual è il risultato combinato che incorpora entrambi gli insiemi di modifiche? Questa è l'operazione centrale di ogni sistema di controllo di versione, quando due sviluppatori modificano lo stesso file indipendentemente e uno cerca di fare il merge del loro lavoro, il sistema deve applicare entrambi i diff all'originale. L'algoritmo diff3 formalizzato da Khanna, Kunal e Pierce (2007) è la base. La convenzione del marker di conflitto a sette caratteri, <<<<<<<, =======, >>>>>>>, che Git inserisce nei file quando un merge automatizzato fallisce, viene direttamente da questa stirpe. I moderni strumenti di merge visivi (l'editor di merge a tre pannelli di VS Code, attivo di default dalla 1.69 di giugno 2022; Beyond Compare di Scooter Software, dal 1996; Meld; Kaleidoscope di Black Pixel per macOS) gestiscono i merge a tre vie con rendering side-by-side di tutte e tre le versioni più un quarto pannello per il risultato di merge proposto. Questo strumento si concentra sul confronto a due vie, il merge a tre vie appartiene a un vero flusso di lavoro di controllo di versione.
Casi d'uso comuni
- Code review. Incollare due versioni di una funzione o modulo per individuare rapidamente il cambiamento, specialmente quando si lavora fuori da un flusso Git (un frammento dall'email di un collega, una risposta Stack Overflow vs il tuo codice attuale).
- Confronto di contratti legali. Avvocati e negoziatori di contratti confrontano regolarmente due versioni di un contratto per vedere cosa ha cambiato l'altra parte. Il termine legal-tech è confronto "blackline" o "redline"; prodotti come Draftable si specializzano in questo.
- Editing di prosa. Confrontare la bozza di uno scrittore con la revisione di un editor, o due versioni di un articolo. Track Changes di Microsoft Word lo fa in-product; per bozze in testo semplice o Markdown, uno strumento diff è l'equivalente.
- Drift di configurazione. Confrontare un file di configurazione in produzione con la versione nel source control, il divario è il drift. Stesso flusso per configurazioni specifiche di ambiente (dev vs staging vs produzione).
- Confronto di log. Diffing di due file di log da diverse esecuzioni dello stesso processo per trovare il punto di divergenza.
- Revisione di localizzazione. I traduttori frequentemente fanno il diff di un nuovo sorgente inglese rispetto alla versione precedente per identificare esattamente cosa è nuovo e necessita di traduzione.
L'ecosistema dei diff nel 2026
Oltre a git diff e al diff Unix, diversi strumenti diff specializzati meritano menzione. Beyond Compare (Scooter Software, 1996) è lo storico strumento commerciale di confronto cartelle-e-file, popolare tra sviluppatori e professionisti IT per il diffing cross-machine. Meld (open source, basato su GTK) è il default di GNOME. Kaleidoscope (Black Pixel, macOS) si integra con il controllo di versione ed è la scelta de facto per molti sviluppatori Mac. L'editor diff integrato di VS Code gestisce confronti a due vie e a tre vie nativamente; l'editor di merge a tre pannelli è diventato attivo di default nella 1.69 (giugno 2022). Mergely (Wayne Stidolph, 2013, licenza MIT) è l'editor canonico di merge a due vie basato su browser costruito su CodeMirror. jsdiff (Kevin Decker, circa 2010) è la libreria JavaScript diff dominante, usata da ogni strumento diff basato su browser in cui hai mai incollato. diff-match-patch (Neil Fraser di Google, 2006) è la libreria alternativa che gestisce diffing, matching fuzzy e generazione di patch in una singola API; usata nella cronologia delle revisioni di Google Docs. Diffchecker è il dominante servizio diff online freemium, con tutte le funzionalità ma con privacy a pagamento (il tier gratuito invia il testo al loro server). text-compare.com è il sito diff web di testo puro più longevo, UI datata ma funzionale.
Privacy: perché il solo-browser conta soprattutto qui
Ogni diff rivela esattamente cosa è cambiato tra due versioni, e cosa è cambiato è spesso più sensibile di entrambe le versioni da sole. Tre scenari concreti dove questo conta acutamente. Patch di sicurezza: fare il diff di una versione vulnerabile di una funzione con la versione patchata rivela la posizione precisa e la natura di un bug di sicurezza, un attaccante che trova la patch può creare un exploit per la versione non patchata (l'attacco "patch gap" documentato da Tian et al. a USENIX Security 2017). Incollare una patch di sicurezza in uno strumento diff lato server è essenzialmente pubblicare la vulnerabilità. Negoziazione contrattuale: fare il diff di due versioni di un contratto rivela esattamente quali clausole interessano a ciascuna parte, che è esattamente l'informazione che non vuoi che l'altra parte (o chiunque guardi la rete) abbia durante la negoziazione. Decisioni editoriali pre-pubblicazione: fare il diff di un manoscritto prima e dopo l'editing rivela cosa un autore e un editor hanno deciso di tagliare o cambiare, spesso più rivelatore della versione finale pubblicata. Gli strumenti diff lato server caricano entrambe le versioni a una terza parte, dove rimangono nei log. Questo strumento gira interamente nel tuo browser tramite JavaScript, verifica nel tab Network di DevTools mentre clicchi Confronta, o porta la pagina offline (modalità aereo) dopo che si carica e lo strumento funziona ancora.
Domande frequenti
Posso confrontare file di codice?
Sì. Incolla qualsiasi testo, incluso codice, JSON, HTML, Markdown o testo semplice. Il diff è puramente testuale, quindi funziona per qualsiasi formato.
Ignora le differenze di spaziatura?
Attiva l'opzione «Ignora gli spazi» per saltare le differenze che sono solo spazi o fine riga. Utile per confrontare codice riformattato ma non modificato nella sostanza.
Che algoritmo usa questo?
L'algoritmo O(ND) di Myers (Eugene Myers, Algorithmica Vol 1 No 2, 1986), lo stesso algoritmo che GNU diff ha usato di default per decenni e la base per la maggior parte delle implementazioni di text-diff. Myers ha riformulato il problema della sottosequenza comune più lunga come ricerca del percorso più breve su un edit graph, rendendolo veloce in pratica per input che differiscono solo in pochi punti. Il più recente algoritmo histogram (il default attuale di Git dalla v2.11, novembre 2016) gestisce i blocchi spostati leggermente meglio ma è eccessivo per il tipico caso d'uso a due paste che questo strumento gestisce.
C'è un limite di dimensione?
Nessun limite rigido, ma il confronto gira nel tuo browser tramite JavaScript quindi il soffitto pratico è la memoria disponibile del tuo dispositivo. Decine di migliaia di righe funzionano comodamente. Input molto grandi (file di log multi-megabyte, romanzi interi) funzioneranno ma possono richiedere secondi notevoli per renderizzare. Per input veramente enormi usa il diff di Git da riga di comando, esegue lo streaming dell'output e gestisce file di dimensione arbitraria senza pressione di memoria.
Può fare merge a tre vie o applicare patch?
Non attualmente, questo strumento si concentra sul confronto a due vie (A vs B). Il merge a tre vie (l'algoritmo diff3 con marker di conflitto <<<<<<< / ======= / >>>>>>>) è l'operazione che Git usa quando fa il merge dei branch; richiede un antenato comune più due versioni divergenti. Per il merge a tre vie, usa un vero sistema di controllo di versione o uno strumento dedicato come l'editor di merge a tre pannelli di VS Code (attivo di default dalla 1.69 di giugno 2022).
I miei testi vengono caricati?
No. Il confronto gira interamente nel tuo browser tramite JavaScript. I testi che incolli non attraversano mai la rete, verifica nel tab Network di DevTools mentre clicchi Confronta, o porta la pagina offline (modalità aereo) dopo che si carica e lo strumento funziona ancora. Particolarmente sicuro per il diffing di patch di sicurezza (dove il diff stesso rivela la vulnerabilità), revisioni di contratti (dove il diff rivela posizioni di negoziazione), o bozze editoriali pre-pubblicazione.