Text-Vergleicher

Über den Textvergleich

Dieses Diff-Tool nutzt den LCS-Algorithmus (Longest Common Subsequence), um zwei Texte Zeile für Zeile zu vergleichen. Hinzugefügtes wird grün markiert, Gelöschtes rot. Wählen Sie die „Inline"-Ansicht, um alle Änderungen in einer Spalte zu sehen, oder „Nebeneinander", um Original und Änderung parallel zu vergleichen.

Häufige Anwendungsfälle

• Code-Änderungen vor dem Commit vergleichen
• Bearbeitete Dokumente oder Verträge prüfen
• Übersetzungsunterschiede prüfen
• Änderungen an Konfigurationsdateien validieren
• API-Antworten vergleichen

Häufige Fragen

Vergleicht das Tool zeichenweise?

Dieses Tool vergleicht zeilenweise. Sobald eine Zeile auch nur eine kleinste Änderung enthält (selbst ein einzelnes Zeichen), wird die ganze Zeile als geändert markiert. Das ist derselbe Ansatz, den Git und die meisten Diff-Tools verwenden.

Gibt es eine Größenbegrenzung?

Es gibt keine harte Grenze, aber sehr große Texte (über 10.000 Zeilen) brauchen möglicherweise einen Moment, da der Vergleich vollständig in Ihrem Browser läuft.

Was „diff“ eigentlich bedeutet

Ein Diff beschreibt, wie man einen Text mit der kleinsten Menge an Einfügungen und Löschungen in einen anderen überführt. Dafür gibt es unendlich viele Wege, der triviale lautet „jedes Zeichen von A löschen und dann jedes Zeichen von B einfügen“. Ein nützliches Diff ist das kürzeste Bearbeitungsskript, das das Gegenstück zum Problem der längsten gemeinsamen Teilfolge ist: Finde die längste Folge von Zeilen, die (in derselben Reihenfolge) in beiden Texten vorkommt, und alles andere ist eine Hinzufügung oder eine Löschung. Die meisten Diff-Algorithmen sind LCS-Algorithmen mit einem anderen Hut auf.

Ein feiner Punkt: Die längste gemeinsame Teilfolge ist nicht die längste gemeinsame Teilzeichenkette. Eine Teilfolge bewahrt die Reihenfolge, aber nicht die Benachbarung, daher teilen sich „ABCDE“ und „AXBYCZD“ die Teilfolge „ABCD“, obwohl in beiden kein zusammenhängender Lauf von drei Zeichen vorkommt.

Eine kurze Geschichte der Diff-Algorithmen

Das erste weit verbreitete Dateivergleichsprogramm war das Unix-diff, geschrieben von Douglas McIlroy bei den Bell Labs, mit dem zugrunde liegenden Algorithmus, der von James W. Hunt und McIlroy als Bell Labs Computing Science Technical Report #41 im Juni 1976 veröffentlicht wurde. McIlroy selbst beschrieb die viermonatige Entwicklung als „eine verzweifelte Anstrengung“. Der Hunt-McIlroy-Ansatz bildete von jeder Zeile der Datei B einen Hash, indizierte, wo jede eindeutige Zeile vorkam, und suchte nach der längsten monoton steigenden Kette von Übereinstimmungen. Es kam in Version 6 Unix und blieb über Jahrzehnte im Wesentlichen derselbe Algorithmus in /usr/bin/diff auf den meisten Unix-Systemen.

Eugene W. Myers veröffentlichte 1986 den modernen Industriestandard, „An O(ND) Difference Algorithm and Its Variations“ in Algorithmica Bd. 1, Nr. 2. Myers formulierte LCS als ein Kürzeste-Wege-Problem durch einen Bearbeitungsgraphen um: Lege A entlang der oberen Achse und B an der Seite an, zeichne eine Diagonale, wann immer zwei Zeilen übereinstimmen, und suche den Weg von oben links nach unten rechts mit den wenigsten nicht-diagonalen Kanten. Jede nicht-diagonale Kante ist eine Einfügung oder Löschung; jede Diagonale ist kostenlos. Entscheidend ist, dass der Algorithmus in O((N+M)·D) Zeit läuft, wobei D die Größe des Bearbeitungsskripts ist, das heißt, er wird schneller, je ähnlicher sich die Dateien sind. Bei typischen Versionskontroll-Diffs ist D winzig im Vergleich zu N+M, sodass Myers in der Praxis dramatisch schneller ist als der O(N·M)-Worst-Case. Sein Aufsatz enthält außerdem eine Verfeinerung für linearen Speicher mit einem „Middle-Snake“-Trick nach dem Teile-und-herrsche-Prinzip. Der Myers-Algorithmus ist die Standardgrundlage von GNU diff, git diff, Mercurial, Subversion, jsdiff, Pythons difflib und den meisten GUI-Diff-Viewern.

Bram Cohen (später besser bekannt als Erfinder von BitTorrent) entwarf um 2002 Patience Diff für das Versionskontrollsystem Bazaar. Das motivierende Problem: Myers-Diff richtet jede übereinstimmende Zeile aus, auch sehr häufige, sodass das Verschieben einer Funktion in C ein verrauschtes Diff erzeugen kann, in dem die schließende Klammer der verschobenen Funktion mit der schließenden Klammer einer unverwandten Funktion ausgerichtet wird. Patience Diff verankert das Diff an Zeilen, die in jeder Datei genau einmal vorkommen (typischerweise Funktionssignaturen, Kommentarköpfe, markante Log-Meldungen), berechnet die LCS nur dieser Anker mittels Patience Sort und rekursiert über die Lücken. Das Ergebnis richtet sich an bedeutungstragenden Zeilen aus und liest sich für Quellcode besser. Git unterstützt es über git diff --patience. Histogram Diff ist eine um 2010 zu git hinzugefügte Verfeinerung, die ein Histogramm der Zeilenvorkommen erstellt und niederfrequente Anker gegenüber strikt eindeutigen bevorzugt; ab git 2.45 ist es bei vielen Konfigurationen die Voreinstellung.

Levenshtein vs. LCS

Ein verwandtes Konzept, das man unterscheiden sollte. Die Levenshtein-Distanz (Vladimir Levenshtein, 1965) zählt die minimale Anzahl von Einfügungen, Löschungen und Ersetzungen einzelner Zeichen, um eine Zeichenkette in eine andere zu überführen. Das LCS-basierte Diff ist eng verwandt, aber etwas anders: Klassisches Diff behandelt eine „Änderung“ als ein Paar aus Löschen und Einfügen statt als einzelne Ersetzung, weil sich das besser auf zeilenorientierte Dateien abbilden lässt. Levenshtein beantwortet „wie verschieden sind diese Zeichenketten?“ und gibt Ihnen eine Zahl; LCS beantwortet „was sich konkret geändert hat?“ und gibt Ihnen ein tatsächliches Bearbeitungsskript. Rechtschreibprüfungen und „Meinten Sie?“-Funktionen wollen das Erste; Diff-Werkzeuge wollen das Zweite. Die Damerau-Levenshtein-Variante (1964) erweitert Levenshtein um einen Transpositionsoperator zur Tippfehlererkennung.

Granularität: Zeile, Wort und Zeichen

Diff kann mit verschiedenen Granularitäten berechnet werden, jede mit Kompromissen:

• Zeilenebene: Jede Zeile ist ein Token; zwei Zeilen stimmen entweder genau überein oder nicht. Schnell, bildet sauber ab, wie Programmierer Code bearbeiten, erzeugt knappe Patches, die patch(1) anwenden kann. Kosten: Das Umformatieren eines einzigen Zeichens in einer 200 Zeichen langen Zeile markiert die ganze Zeile als geändert. Die Voreinstellung für diff, git, SVN und dieses Werkzeug.
• Wortebene: Jedes durch Leerraum getrennte Token ist eine Einheit, sodass eine Zeile, in der sich ein Wort geändert hat, nur dieses Wort hervorgehoben zeigt. Hervorragend für Fließtext, Verträge, Blogentwürfe. Verwendet von git diff --word-diff, dem „Vorschlagen“-Modus von Google Docs, der „Änderungen verfolgen“-Funktion von Microsoft Word, dem Compare-Words-Modus von Diffchecker.
• Zeichenebene: Jeder Unicode-Codepunkt ist eine Einheit. Erfasst Tippfehler einzelner Zeichen, ideal für juristisches Redlining, bei dem ein Wort die Bedeutung umkehren kann. Langsam bei großen Eingaben und bei langen Änderungen mitunter unleserlich.

Ein verbreitetes Muster in modernen Diff-Oberflächen ist, das Diff zunächst auf Zeilenebene zu berechnen und dann für jedes Paar aus „entfernten/hinzugefügten Nachbarn“ ein zweites Diff auf Wortebene nur für diese beiden Zeilen durchzuführen und die Änderungen innerhalb der Zeile hervorzuheben. Genau so arbeiten sowohl die PR-Ansicht von GitHub als auch die Bibliothek diff-match-patch.

Drei Diff-Anzeigemodi, die Ihnen begegnen

• Unified Diff (das Format jeder .patch-Datei), Hunks eingeleitet durch @@ -oldStart,oldLen +newStart,newLen @@ mit standardmäßig drei Kontextzeilen darüber und darunter. Entstand um 1990 mit Wayne Davisons -u-Flag von GNU diff. Kompakt und maschinenlesbar durch patch(1), weshalb git, E-Mail-Patches im Kernel-Stil und SVN es alle verwenden.
• Nebeneinander: Original links, geändert rechts, Zeile für Zeile ausgerichtet. diff -y erzeugt eine primitive ASCII-Version; Beyond Compare, Meld, WinMerge und die obige Ansicht „Side by Side“ verwenden alle dieses Format. Am besten für die visuelle Durchsicht und das Korrekturlesen von Fließtext.
• Inline (gestapelt): eine einzelne Spalte, in der gelöschte und hinzugefügte Zeilen verschachtelt sind. Die PR-Ansicht von GitHub verwendet dies als Voreinstellung. Das platzsparendste Format für schmale Bildschirme und kleine Änderungen.

Nützliche git-diff-Varianten

• git diff: Index vs. Arbeitsverzeichnis.
• git diff --staged: HEAD vs. Index.
• git diff main..feature: Branch-Spitzen. main...feature vergleicht gegen die Merge-Basis, also das, was der PR einbringen wird.
• git diff --word-diff und --color-words: markup-freundliches und farblich getöntes Diff auf Wortebene.
• git diff --no-index a.txt b.txt: funktioniert mit Dateien außerhalb jedes git-Repos. Praktisch als improvisiertes eigenständiges Diff mit Patience- oder Histogram-Algorithmen.
• git diff -w: ignoriert allen Leerraum (entspricht dem Kontrollkästchen „Leerraum ignorieren“ oben).
• git diff --histogram: Algorithmus pro Befehl wechseln.

Wann Sie zu einem Browser-Diff greifen würden

• Code-Review. Fügen Sie zwei Versionen einer Datei ein, überfliegen Sie, was sich geändert hat, und entscheiden Sie, ob die Änderung sinnvoll ist.
• KI-bearbeiteten Code prüfen. Vergleichen Sie Ihr Original mit der von einem LLM überarbeiteten Version, um Abweichungen oder Halluzinationen zu erkennen.
• Juristisches Vertrags-Redlining. Bestätigen Sie, dass sich zwischen Version 3 und Version 4 nur die vereinbarten Klauseln geändert haben.
• Übersetzungs-QA. Vergleichen Sie zwei französische Übersetzungen desselben Absatzes oder vergleichen Sie vorherige und aktualisierte Lokalisierungsdateien, wenn sich nur eine Handvoll Zeichenketten geändert haben sollte.
• Konfigurationsabweichung. Vergleichen Sie nginx.conf aus der Produktion mit der Staging-Umgebung.
• SQL-Schemavergleich. Geben Sie die CREATE TABLE-Anweisungen aus zwei Datenbanken aus und vergleichen Sie sie, um fehlende Indizes oder Abweichungen bei Spaltentypen zu finden.
• Spezifikationsabweichung. Vergleichen Sie zwei Versionen einer OpenAPI-/Swagger-YAML, um zu prüfen, ob Breaking Changes dokumentiert sind.
• Markdown-Blogentwürfe. Erkennen Sie, was ein Mitautor bearbeitet hat.
• Compliance-Audits. Vergleichen Sie eine Datenschutzerklärung Monat für Monat für Aufsichtsbehörden.
• Lock-Datei-Forensik. Vergleichen Sie package-lock.json oder yarn.lock, um ein Abhängigkeits-Upgrade zu verstehen.

Ehrliche Grenzen

• Reines Textdiff hat kein semantisches Verständnis. Das Umbenennen von foo in bar in einer ganzen Datei sieht im Aufwand identisch aus zu einer völlig unverwandten Neufassung. Werkzeuge wie difftastic parsen den AST der Sprache und erzeugen strukturelle Diffs („Funktion hinzugefügt“, „Argument umgeordnet“). Diese Seite tut das nicht, sie ist ein einfaches LCS-Zeilendiff.
• Leerraum und Zeilenenden verursachen unechte Diffs. CRLF vs. LF, nachgestellter Leerraum, Tabs vs. Leerzeichen. Der Schalter „Leerraum ignorieren“ oben entspricht gits -w.
• Binärdateien passen nicht. Diff ist ein Textkonzept. Für Binärdiffs gibt es Werkzeuge wie bsdiff, xdelta oder VBinDiff.
• Reihenfolgenempfindlichkeit. Zeilendiff geht davon aus, dass die Dokumente Zeile für Zeile bearbeitet wurden. Bei unsortierten CSVs oder umgeordneten JSON-Objektschlüsseln sollten Sie zuerst sortieren oder kanonisieren.
• Verschiebungserkennung. Klassisches LCS-Diff erkennt nicht, dass eine Funktion innerhalb einer Datei verschoben wurde, es zeigt die Verschiebung als Löschung plus Einfügung. Beyond Compare, Meld und difftastic versuchen eine Verschiebungserkennung; diese Seite nicht.

Weitere Fragen

Warum zeigt diese Seite keine Hervorhebungen auf Zeichenebene innerhalb geänderter Zeilen?

Weil der Durchlauf auf Zeilenebene für die meisten Anwendungsfälle ausreicht und bei langen Eingaben viel schneller läuft. Für eine Wort-für-Wort-Hervorhebung innerhalb der Zeile ist eine zweistufige Verfeinerung gängige Praxis, fügt aber Latenz hinzu. Wenn Ihnen der gesamte Zeilenunterschied wichtig ist (juristisches Redlining, Korrekturlesen von Fließtext), ist ein spezialisiertes Werkzeug auf Wortebene (einschließlich git diff --word-diff auf der Kommandozeile) die bessere Wahl.

Was ist der Unterschied zwischen Unified Diff und Nebeneinander?

Unified Diff ist das kompakte, maschinenlesbare Format, das jede .patch-Datei verwendet, drei Kontextzeilen, Hunks markiert mit @@. Nebeneinander zeigt die beiden Versionen in parallelen Spalten, was für die visuelle Durchsicht angenehmer fürs Auge ist, aber mehr horizontalen Platz braucht. Unified ist das, was Sie per E-Mail senden oder committen würden; Nebeneinander ist das, was Sie auf einem breiten Monitor lesen würden.

Gibt es für Quellcode bessere Algorithmen als Myers?

Für Quellcode mit verschobenen Funktionen oder großen Umstellungen ja, Patience Diff (Bram Cohen, 2002) und Histogram Diff (git, um 2010) sind darauf ausgelegt, sich an bedeutungstragenden, eindeutigen Zeilen statt an häufigen auszurichten, was eine besser lesbare Ausgabe ergibt. Beide sind über git diff --patience und git diff --histogram verfügbar. AST-bewusste Werkzeuge wie difftastic gehen weiter und parsen die tatsächliche Sprachstruktur.

Ist es sicher, vertraulichen Text hier einzufügen?

Ja, das Diff läuft vollständig in Ihrem Browser mit einer JavaScript-LCS-Implementierung. Nichts wird hochgeladen, keine Analyse der Eingabe, kein serverseitiges Protokoll des Textes. Dies ist die einzige Kategorie von Diff-Werkzeugen, die für NDAs, internen Quellcode oder unveröffentlichte Vertragsklauseln sicher ist; cloudbasierte Diff-Dienste sehen alles, was Sie einfügen.

Verwandte Tools