Diff-Checker
Vergleichen Sie zwei Texte und heben Sie Unterschiede sofort hervor.
Vergleichen Sie zwei Texte und heben Sie Unterschiede sofort hervor.
Der Diff Checker vergleicht zwei Textblöcke und zeigt genau, was sich geändert hat — Hinzufügungen, Löschungen und Inline-Änderungen — in geteilter und einheitlicher Ansicht. Er ist gedacht für die Prüfung einer Vertragsrevision, das Erkennen von Unterschieden zwischen zwei Konfigurationsdateien, den Abgleich eines überarbeiteten Absatzes mit dem Original oder die Bestätigung, dass zwei Exporte wirklich identisch sind. Fügen Sie beide Fassungen ein, und die Unterschiede werden sofort markiert, ohne dass eine davon hochgeladen wird.
Jeder Vergleich zeigt drei Dinge zugleich. Gelöschter Inhalt wird auf der Originalseite markiert, hinzugefügter Inhalt auf der geänderten Seite, und unveränderter Kontext bleibt dazwischen unmarkiert, damit Sie sehen, wo jede Änderung sitzt. Wird eine Zeile nicht ersetzt, sondern bearbeitet, hebt das Tool die konkreten Wörter oder Zeichen hervor, die sich innerhalb der Zeile unterscheiden — genau das unterscheidet einen brauchbaren Diff von einer Wand aus Rot und Grün.
In der einheitlichen Ansicht leisten die Präfixe die Arbeit: Eine Zeile mit − existiert nur im Original, + nur in der geänderten Fassung, und ein führendes Leerzeichen bedeutet unveränderter Kontext. Wer schon einmal git diff gelesen hat, erkennt das Format wieder. Ein häufiges Missverständnis beim ersten Blick: Rot und Grün zeigen nicht „gut“ und „schlecht“, sondern nur Original und geänderte Fassung. Welche Seite die gewünschte ist, entscheiden Sie; bei einem Vergleich zweier Entwürfe kann die rechte Spalte ebenso gut die ältere Fassung sein.
Beispiel 1 — eine Konfigurationsänderung. Zwei Versionen einer nginx.conf unterscheiden sich in einer einzigen Anweisung. Auf Zeilenebene wird die geänderte proxy_read_timeout-Zeile markiert, während die Dutzenden umgebenden Zeilen Kontext bleiben. Ein Leser kann die Änderung in Sekunden freigeben, statt beide Dateien zu durchscrollen.
Beispiel 2 — ein bearbeiteter Absatz. In einem 400-Wörter-Absatz wird ein Satz umformuliert. Der zeilenweise Vergleich markiert den ganzen Absatz als geändert; der Wechsel auf Wortebene isoliert die sechs Wörter, die sich tatsächlich verschoben haben — der Unterschied zwischen „dieser Absatz wurde neu geschrieben“ und „diese Klausel hat sich geändert“ in einer Vertragsprüfung.
Beispiel 3 — einen Export verifizieren. Ein Datenexport wird nach einer Schema-Anpassung neu erzeugt. Der Vergleich der alten und neuen CSV-Datei bestätigt, dass genau eine Spalte hinzugekommen ist und keine Zeile verschoben wurde — eine Kontrolle, die reine Zeilenzahlen übersehen würden.
Scheint ein Unterschied unauffindbar, wechseln Sie auf eine feinere Ebene: Die Änderung ist meist kleiner, als die grobe Ansicht vermuten lässt. Werden zwei „identische“ Zeilen markiert, verdächtigen Sie Leerraum oder Zeilenenden statt einer echten Inhaltsänderung.
Ein praktischer Ablauf: Starten Sie auf Zeilenebene, um die groben Änderungsstellen zu finden, und wechseln Sie nur für verdächtige Stellen auf Wort- oder Zeichenebene. So behalten Sie den Überblick und verlieren sich nicht in Details, die für die eigentliche Frage unerheblich sind.
Dieselbe Art des Vergleichs liegt der Versionsverwaltung zugrunde. Wenn Sie git diff ausführen oder eine Patch-Datei erzeugen, ist die Ausgabe ein zeilenweiser Diff im einheitlichen Format: unveränderte Zeilen tragen ein führendes Leerzeichen, Entfernungen ein −, Hinzufügungen ein +, und ein Kopf wie @@ -12,7 +12,9 @@ markiert, wo der Block sitzt und wie viele Zeilen er umfasst. Das Üben mit der einheitlichen Ansicht macht das Lesen echter Patches und Merge-Konflikte deutlich leichter, denn die Struktur ist identisch — nur das umgebende Werkzeug ändert sich.
Ein zeilenbasierter Diff kennt keinen Begriff des Verschiebens. Er meldet die kleinstmögliche Menge an Zeilenänderungen, die eine Version in die andere überführt, und eine Verschiebung wird als Löschung an der alten und Einfügung an der neuen Position ausgedrückt. Manche Tools erkennen verschobene Blöcke heuristisch, aber der zugrunde liegende Algorithmus kann „verschoben“ nicht als eigene Operation darstellen.
Die geteilte Ansicht stellt Original und geänderte Fassung nebeneinander, was zu zwei Dokumenten ähnlicher Länge passt, die an vielen Stellen auseinandergegangen sind. Die einheitliche Ansicht verschränkt beide Versionen in einer Spalte mit +- und −-Markern, liest sich eher wie ein Patch und ist für das Prüfen einer kurzen Änderungsmenge meist einfacher.
Nutzen Sie die Zeilenebene für Code, Konfigurationen und jede strukturierte Datei, in der eine Zeile eine sinnvolle Einheit ist — das entspricht der Denkweise der Versionsverwaltung. Nutzen Sie Wort- oder Zeichenebene für Prosa, wo das Umformulieren eines Satzes innerhalb eines langen Absatzes sonst die ganze Zeile als geändert markiert und die eigentliche Änderung verdeckt.
Unsichtbare Unterschiede: nachgestellte Leerzeichen, ein Tabulator statt Leerzeichen, ein anderes Zeilenende (LF statt CRLF) oder ein geschütztes Leerzeichen statt eines normalen. Machen Sie die Leerraum-Anzeige des Tools sichtbar oder kopieren Sie beide Fassungen in einen zeichenweisen Vergleich, um zu sehen, was sich wirklich unterscheidet.
Texte von einigen hundert Kilobyte werden sofort verglichen; sehr große Eingaben (mehrere Megabyte) können den Browser langsam machen, weil der Aufwand des Algorithmus mit der Änderungsmenge wächst, nicht nur mit der Dateigröße. Vergleichen Sie riesige Dateien stattdessen in einem Versionskontrollsystem oder einem spezialisierten Diff-Tool.
Sie sind der Blockkopf und beschreiben, wo ein Änderungsblock sitzt. Der Teil `-12,7` bezieht sich auf die Originaldatei ab Zeile 12 über sieben Zeilen, der Teil `+12,9` auf die geänderte Fassung ab Zeile 12 über neun Zeilen. Die Zahlen sagen Ihnen also, an welcher Stelle Sie sich befinden und wie viele Zeilen der Block je Version umfasst.
Geprüft vom HandyTools-Hub-Team · Zuletzt aktualisiert