Zwei JSON-Dokumente vergleichen

Original links einfügen, bearbeitete Fassung rechts, „Vergleichen“ drücken: Die Seite meldet jeden hinzugefügten, entfernten und geänderten Wert mit seinem Pfad — 7.143 Änderungen bei zwei Objekten mit je 50.000 Schlüsseln, aufgelistet in der Reihenfolge des Durchlaufs.

Das Ergebnis ist ein JSON Patch nach RFC 6902, der das erste Dokument in das zweite überführt: ein Array aus add-, remove- und replace-Operationen mit JSON-Pointer-Pfaden. Beide Felder werden in der Seite geparst und verglichen, es wird nichts hochgeladen, und nach einem Netzabbruch arbeitet der Vergleich unverändert weiter.

Das erste Dokument in das linke Feld einfügen, das zweite in das rechte. „Beispiel laden“ füllt beide mit einem kleinen Paar, wenn die Form der Ausgabe zuerst sichtbar sein soll.
„Vergleichen“ drücken. Über der Liste erscheinen die Zähler — hinzugefügt, entfernt, geändert — und jede Zeile trägt den Pointer auf den Wert samt einer Vorschau von höchstens 120 Zeichen.
Darunter den Patch lesen: das vollständige RFC-6902-Dokument, eingerückt, bereit für eine Testsuite, ein Migrationsskript oder eine HTTP-PATCH-Anfrage.
„Patch kopieren“ legt ihn in die Zwischenablage, „Leeren“ räumt beide Felder. Lässt sich ein Feld nicht parsen, nennt die Statuszeile das betroffene Dokument — Before JSON oder After JSON — samt Fehlerposition, und das vorige Ergebnis wird verworfen.

Was der Patch aussagt und was nicht

Was als Unterschied zählt

Die Reihenfolge der Schlüssel ist kein Unterschied: {"a":1,"b":2} gegen {"b":2,"a":1} ergibt 0 Änderungen. Zahlen werden als JavaScript-Doubles verglichen, deshalb gelten 1 und 1.0 als derselbe Wert, während 1e2 als 100 ankommt und als eine Änderung erscheint.

Typen werden nie umgewandelt: 1 gegen "1" ist eine Änderung, true gegen 1 ebenfalls, und ein Schlüssel mit null ist nicht dasselbe wie ein fehlender Schlüssel — null im ersten Dokument und nicht vorhanden im zweiten ergibt remove /a statt eines Treffers. Doppelte Schlüssel behalten den letzten Wert, weil das Feld mit JSON.parse gelesen wird: {"a":1,"a":2} gegen {"a":2} meldet 0 Änderungen.

Arrays werden über den Index verglichen

Eine move-Operation enthält die Ausgabe nicht. Ein Array wird Position für Position durchlaufen, eine Umsortierung erscheint daher als Folge von replace: [1,2] gegen [2,1] ergibt replace /0 mit 2 und replace /1 mit 1.

Längenänderungen kommen vom Ende her: [1,2,3,4] gegen [1,2] entfernt zuerst /3 und dann /2, [1,2] gegen [1,2,3,4] fügt /2 und /3 hinzu. In dieser Reihenfolge bleibt jede Operation gültig, wenn der Patch von oben nach unten angewendet wird.

Pointer, Escaping und leere Schlüssel

Jeder Pfad ist ein JSON Pointer nach RFC 6901. Ein Schlüssel mit Schrägstrich oder Tilde wird maskiert: a/b erscheint als /a~1b und c~d als /c~0d.

Auch ein leerer Schlüssel bekommt einen Pointer — der Pfad lautet dann / — und das Dokument selbst hat den leeren Pfad, sodass ein vollständiger Austausch eine einzige Operation mit path "" ist.

Wo der Vergleich läuft

Geparst und verglichen wird in der Seite. Beim Laden des Werkzeugs und beim Vergleich zweier Objekte mit je 50.000 Schlüsseln ging keine Anfrage über die Assets der Seite hinaus, die Dokumente verlassen den Browser also nicht; nach dem Laden arbeitet das Werkzeug auch ohne Netz.

Damit gelten die Grenzen des JSON-Parsers: Ganzzahlen über 2^53 verlieren an Genauigkeit, 9007199254740993 und 9007199254740992 gelten deshalb als identisch, und 20.000 Verschachtelungsebenen wurden noch fehlerfrei verglichen und gepatcht. Die Laufzeit hängt an der Zahl der Änderungen — 50.000 Schlüssel brauchten rund eine halbe Sekunde und ergaben einen Patch von 511 KB, 500.000 Schlüssel rund fünf Sekunden und 5,25 MB. Den Patch vor dem Anwenden auf Produktionsdaten durchlesen.