Wie man zwei JSON-Dateien vergleicht und Änderungen findet

Der schnellste Weg, zwei JSON-Dateien zu vergleichen, besteht darin, beide in ein nebeneinander angeordnetes Diff-Tool einzufügen, sie gleich zu formatieren und die hervorgehobenen Zeilen zu lesen. Das Schwierige ist meist nicht der Vergleich selbst. Es ist das Rauschen: umgeordnete Schlüssel, unterschiedliche Einrückung und verstreute abschließende Kommas können dazu führen, dass zwei nahezu identische Dateien aussehen, als hätten sie nichts gemeinsam.

Dieser Leitfaden erklärt, wie man einen sauberen, zuverlässigen Diff erhält. Wir schauen uns an, warum JSON-Dateien auf dem Papier auseinander driften, während sie inhaltlich gleich bleiben, die wenigen Methoden, die es wert sind zu kennen, und ein ausgearbeitetes Beispiel, dem man folgen kann. Wer einfach nur das Tool möchte, kann auf unserer JSON-Vergleichsseite all das im Browser erledigen.

Warum JSON-Dateien trügerisch schwer zu vergleichen sind

JSON hat eine kleine, strenge Grammatik (siehe die Spezifikation auf json.org), gibt Autoren aber viel Freiheit bei der Textformatierung. Zwei Dateien können dasselbe Objekt beschreiben und trotzdem Byte für Byte unterschiedlich sein. Ein einfacher Textvergleich weiß nichts davon und markiert daher alles pflichtbewusst.

Hier ist das Wichtigste, das man vor dem Start verinnerlichen sollte: Objektschlüssel in JSON haben keine Reihenfolge. Die Spezifikation (RFC 8259) definiert ein Objekt als ungeordnete Menge von Name/Wert-Paaren. Also sind {"name":"Ada","id":7} und {"id":7,"name":"Ada"} gleich, auch wenn ein Zeilendiff sie rot und grün anzeigt.

Sieht wie eine Änderung aus, ist es meist nicht

Was man im Diff sieht	Ist es eine echte Änderung?	Was zu tun ist
Schlüssel in anderer Reihenfolge	Nein, Objekte sind ungeordnet	Schlüssel auf beiden Seiten sortieren
2-Leerzeichen vs. 4-Leerzeichen-Einrückung	Nein	Beide Seiten gleich formatieren
Minimiert vs. hübsch gedruckt	Nein	Beide Seiten formatieren
Abschließender Zeilenumbruch am Dateiende	Nein	Ignorieren oder Leerzeichen entfernen
Ein Wert änderte sich von "7" zu 7	Ja, String vs. Zahl	Untersuchen, das ist real
Array-Elemente in anderer Reihenfolge	Möglicherweise, Arrays sind geordnet	Entscheiden, ob die Reihenfolge hier wichtig ist

Die letzte Zeile überrascht viele. Arrays behalten ihre Reihenfolge, Objekte nicht. Also sind [1, 2, 3] und [3, 2, 1] wirklich unterschiedlich, aber die Schlüssel innerhalb eines Objekts können frei umsortiert werden. Wer die Details dazu nachlesen möchte, wie JavaScript all das parst, findet bei MDN eine solide Referenz zum JSON-Objekt.

Vier Methoden zum Vergleichen von JSON und wann man zu welcher greift

Es gibt keine einzige beste Methode. Es hängt davon ab, wo die Dateien liegen und was man herausfinden möchte. So schneiden die gängigen Optionen ab.

Methode	Am besten für	Aufwand	Versteht JSON?
Manuell durchlesen	Winzige Dateien, ein oder zwei Felder	Gering	Nein, man ist der Parser
Online-Diff-Tool	Schnelle Prüfungen, Einfügen von überall	Gering	Mit Format + Schlüsselsortierung ja
Befehlszeile (jq, diff)	Dateien auf der Festplatte, Scripting, große Dateien	Mittel	Ja, wenn man zuerst sortiert
IDE oder git diff	Dateien bereits in einem Repository	Gering bei Commits	Standardmäßig zeilenbasiert

Für die meisten Menschen gewinnt ein Browser-Tool an Geschwindigkeit, weil nichts installiert werden muss und man einen Ausschnitt direkt aus einem Protokoll oder einem API-Aufruf einfügen kann. Der Haken ist Formatierungsrauschen, das wir als nächstes behandeln. Wer viel im Terminal arbeitet, sollte jq kennenlernen, und wir zeigen das eine Flag, das wichtig ist.

Der schnellste saubere Vergleich, Schritt für Schritt

Das ist die Vorgehensweise, die ich verwende, wenn mir jemand zwei Konfigurationsdateien gibt und fragt: "Was ist anders?" Es dauert etwa fünfzehn Sekunden.

1. Das JSON-Vergleichstool öffnen.
2. Das Original links einfügen, die neue Version rechts.
3. Auf beiden Seiten auf Formatieren klicken, damit sie die gleiche Einrückung verwenden.
4. Schlüssel sortieren (kanonisieren) aktivieren, damit umgeordnete Schlüssel nicht mehr als Änderungen erscheinen.
5. Das Ergebnis lesen. Grün bedeutet hinzugefügt, rot bedeutet entfernt, und ein geänderter Wert erscheint als eines von beidem.

Schritt drei und vier sind der eigentliche Trick. Sobald beide Dateien identisch formatiert und ihre Schlüssel sortiert sind, bleibt nur noch hervorgehoben, was sich tatsächlich geändert hat. Unser Diff-Engine basiert auf Googles diff-match-patch, das zuerst zeilenweise vergleicht und so auch bei langen Dateien schnell bleibt.

Ein ausgearbeitetes Beispiel

Angenommen, man prüft eine Änderung an einem Benutzerdatensatz. Hier ist der Vorher-Stand:

{
  "name": "Ada Lovelace",
  "role": "editor",
  "active": true,
  "seats": 3
}

Und hier ist der Nachher-Stand, wie ein Teammitglied ihn übergeben hat:

{
  "active": true,
  "name": "Ada Lovelace",
  "role": "admin",
  "seats": 5,
  "team": "platform"
}

Wirft man diese in einen einfachen Zeilendiff, sieht es aus, als hätte sich fast jede Zeile verschoben, weil die Schlüssel in anderer Reihenfolge sind. Formatiert und sortiert man beide, ist die eigentliche Geschichte kurz:

Was sich tatsächlich geändert hat

Feld	Vorher	Nachher	Änderung
role	editor	admin	Geändert
seats	3	5	Geändert
team	—	platform	Hinzugefügt
name	Ada Lovelace	Ada Lovelace	Keine Änderung
active	true	true	Keine Änderung (nur verschoben)

Drei echte Bearbeitungen: eine Rollenerhöhung, eine Sitzanzahl und ein neues Team-Feld. Die Umsortierung war Rauschen. Diese Beförderung von editor zu admin ist genau die Art von Sache, die man im Review erkennen möchte, und sie ist leicht zu übersehen, wenn sie unter zwanzig Zeilen falscher Positivmeldungen vergraben ist.

Formatierungsrauschen in der Befehlszeile beseitigen

Wenn die Dateien bereits auf der Festplatte liegen, funktioniert die gleiche "Formatieren und Sortieren"-Idee mit zwei kurzen Befehlen. Das Flag -S weist jq an, Objektschlüssel zu sortieren; das Pipen normalisiert beide Dateien, sodass ein einfacher Diff ehrlich ist:

jq -S . old.json > old.sorted.json
jq -S . new.json > new.sorted.json
diff old.sorted.json new.sorted.json

Jetzt meldet diff nur noch Werte, die sich wirklich geändert haben, weil beide Dateien die gleiche Einrückung und die gleiche Schlüsselreihenfolge haben. Das ist das Terminal-Äquivalent zu Formatieren und Schlüssel sortieren im Browser.

Textdiff vs. struktureller Diff

Alles oben Genannte ist ein Text-Diff: schnell, visuell und perfekt für einen Menschen, der eine Änderung liest. Ein struktureller Diff geht weiter und beschreibt die Änderung als Daten. Der Standard dafür ist JSON Patch, definiert in RFC 6902, das Bearbeitungen als Operationen wie replace und add an einem bestimmten Pfad ausdrückt. Man möchte einen strukturellen Diff, wenn ein Programm die Änderung anwenden muss, nicht nur eine Person, die ihn durchschaut. Für den täglichen Review ist ein Textdiff mit sortierten Schlüsseln vollkommen ausreichend.

Häufige Fallstricke, auf die man achten sollte

Fallstrick	Warum er zuschlägt	Lösung
Zahlengenauigkeit	Ganzzahlen über 2^53 − 1 verlieren Genauigkeit in JavaScript	Große IDs als Strings vergleichen; siehe MAX_SAFE_INTEGER
Unicode-Escapes	"café" und "café" sind derselbe String, aber unterschiedliche Bytes	Beide Seiten formatieren, was die Kodierung normalisiert
Doppelte Schlüssel	Die meisten Parser behalten stillschweigend den letzten	JSON validieren, bevor man dem Diff vertraut
Abschließende Kommas	Kein gültiges JSON; eine Datei lässt sich möglicherweise gar nicht parsen	Zuerst die Syntax reparieren, der Validator meldet es
String vs. Zahl	"5" und 5 sehen ähnlich aus, sind aber unterschiedliche Typen	Das ist eine echte Änderung, nicht ignorieren

Verwandte Tools

JSON ist selten das einzige Format, mit dem man zu tun hat. Wenn man Konfigurationen zwischen Umgebungen vergleicht, wendet YAML-Vergleich dieselbe Idee auf YAML an. Änderungen zwischen zwei API-Aufrufen zu überprüfen ist genau das, wofür das API-Antwort-Diff gebaut wurde, und Abhängigkeitsaktualisierungen lassen sich am einfachsten auf der package.json diff-Seite lesen.