JSON minifizieren

Der schnelle Weg, JSON zu verkleinern, ist, alle Leerzeichen und Zeilenumbrüche zu entfernen. Er ist auch falsch, denn Leerraum innerhalb einer Zeichenkette gehört zu den Daten. Ein `"Vor- und Nachname"` wird dabei zu `"Vor-undNachname"`, und weil das Ergebnis weiterhin gültiges JSON ist, fällt es erst weit hinten auf.

Hier wird das Dokument stattdessen mit dem eingebauten Parser gelesen und neu geschrieben. Was herauskommt, ist damit garantiert dieselbe Datenstruktur — es gibt keine Eingabe, bei der die Verkleinerung den Inhalt ändert, weil an keiner Stelle Text als Text bearbeitet wird.

Die angezeigte Ersparnis ist in UTF-8-Bytes gerechnet, und das ist die Zahl, die zählt: Ein Umlaut belegt zwei Bytes, ein Emoji vier, ein chinesisches Zeichen drei. Ein Dokument mit deutschen Texten ist in Bytes deutlich größer, als seine Zeichenzahl vermuten lässt.

Wer die Ersparnis in Zeichen misst, bekommt bei einem Payload voller ASCII fast dieselbe Zahl und bei einem mit viel Text in nicht-lateinischer Schrift eine, die um ein Drittel danebenliegt. Weil es hier immer um eine Leitung oder ein Speicherfeld geht und beide Bytes zählen, wird auch in Bytes gerechnet.

Fast jede API antwortet komprimiert, und Gzip ist gegen wiederholten Leerraum außerordentlich gut — vier Leerzeichen am Zeilenanfang, tausendmal, kosten nach der Kompression fast nichts. Die Ersparnis auf der Leitung ist deshalb viel kleiner als die Zahl hier vermuten lässt, oft im niedrigen einstelligen Prozentbereich.

Wo sich Minifizieren dennoch lohnt, ist überall dort, wo nichts komprimiert wird: in einer Umgebungsvariablen, in einem Datenbankfeld mit Längenbegrenzung, in einem Log, in einer Nachricht auf einer Queue mit Größenlimit. Dort ist die rohe Byte-Zahl die Grenze, und dort ist der Unterschied real.

JSON-Objekte haben keine definierte Reihenfolge, zwei Dienste können dieselben Daten also in verschiedener Reihenfolge ausliefern. Ein Textvergleich meldet dann einen Unterschied, wo keiner ist — der übliche Grund, warum ein Vertragstest rot wird, obwohl beide Seiten dasselbe meinen.

Beide Dokumente sortiert zu minifizieren erzeugt eine Form, in der ein simpler Zeichenvergleich die richtige Antwort gibt. Dasselbe Verfahren steht hinter Cache-Schlüsseln und Signaturen über JSON: Was gehasht wird, muss eine kanonische Form haben, sonst hängt der Hash von der Laune des Serialisierers ab.

Für Signaturen gibt es mit RFC 8785 eine echte Spezifikation, und die regelt mehr als die Reihenfolge: wie Zahlen geschrieben werden, wie Sonderzeichen maskiert werden, wie sortiert wird — nämlich nach UTF-16-Codeeinheiten und nicht nach dem, was eine Sprache für alphabetisch hält.

Das Sortieren hier ist die praktische Variante für Vergleiche und Diffs, nicht die normgerechte für kryptografische Signaturen. Für einen Diff reicht es vollständig; wer eine Signatur über JSON bildet, sollte die Spezifikation lesen, denn dort machen genau die Details den Unterschied, die im Alltag niemandem auffallen.

JSON schreibt Zahlen als Text, JavaScript liest sie als Fließkommazahlen mit doppelter Genauigkeit. Ganzzahlen über etwa 9 Billiarden verlieren dabei Stellen — eine 19-stellige ID kommt verändert wieder heraus, und weil das Ergebnis wie eine gültige Zahl aussieht, merkt es niemand.

Das betrifft jede Verarbeitung, die durch einen JavaScript-Parser geht, diese hier eingeschlossen. Der übliche Auslöser sind Snowflake-IDs, wie sie Twitter und Discord verwenden, sowie manche Datenbank-Sequenzen. Die Lösung liegt beim Erzeuger: Solche Werte gehören als Zeichenkette in JSON, dann überstehen sie jede Station unverändert.

Kommentare gibt es nicht, abschließende Kommata gibt es nicht, einfache Anführungszeichen gibt es nicht, und Schlüssel ohne Anführungszeichen gibt es nicht. Jedes davon ist eine Gewohnheit aus JavaScript, und jedes lässt den Parser mit einer Fehlermeldung stehen, die den eigentlichen Ort selten trifft.

Wer Kommentare in einer Konfiguration braucht, hat drei Möglichkeiten: ein Format wählen, das sie kennt — YAML, TOML, JSON5 —, ein Feld namens `_comment` einführen, das ausdrücklich ignoriert wird, oder die Kommentare vor der Verarbeitung entfernen. Die dritte ist die verbreitetste und die fehleranfälligste, weil ein Schrägstrich auch in einer URL vorkommt.

Minifiziertes JSON in einer versionierten Datei macht jede Änderung zu einer geänderten Zeile. Der Diff zeigt dann alles oder nichts, ein Review ist unmöglich, und ein Merge-Konflikt betrifft grundsätzlich das gesamte Dokument statt der beiden Felder, um die es ging.

Die Arbeitsteilung, die sich bewährt hat: formatiert im Repository, minifiziert beim Ausliefern. Der Formatierer auf dieser Website macht den Weg zurück, und zwischen den beiden liegt genau der Schritt, den ein Build-Prozess ohnehin automatisch erledigen sollte.

Die Ausgabe hier endet ohne Zeilenumbruch, denn es ist eine Zeile und keine Datei. Wer sie in eine Datei schreibt, sollte einen anhängen: POSIX definiert eine Textzeile als mit einem Umbruch endend, und Werkzeuge von `cat` bis zu Git verhalten sich bei Dateien ohne ihn merkwürdig.

Praktisch relevant wird das beim Vergleich von Prüfsummen. Der Hash einer Datei mit abschließendem Umbruch weicht vollständig von dem ohne ab, obwohl beide dasselbe JSON enthalten — einer der Gründe, aus denen zwei Werte, die gleich sein müssten, es nicht sind.

Ein JSON-Payload enthält häufig genau das, was man nicht bewegen möchte: Kundendatensätze, Bestelldaten, ein Webhook mit Adressen darin. Weil hier in der Seite geparst und geschrieben wird, findet keine Übermittlung an uns statt und damit keine Auftragsverarbeitung für den Inhalt.

Nachweisbar ist das im Netzwerk-Panel: Während der Benutzung geht keine Anfrage hinaus, die dein Dokument trägt. Das ist der Grund, warum dieses Werkzeug auch dort benutzbar ist, wo eine Server-Variante an einer internen Richtlinie scheitern würde — und warum die Prüfung dieser Behauptung eine Minute dauert.

Formatieren und Minifizieren sind zwei Richtungen desselben Vorgangs, aber niemand sucht nach beidem gleichzeitig. Wer eine Wand aus JSON lesbar machen will, hat ein Anzeigeproblem; wer minifiziert, hat ein Größen- oder Transportproblem, und die beiden haben einander wenig zu sagen.

Beide Seiten benutzen denselben Parser und denselben Serialisierer — technisch ist es ein Werkzeug mit zwei Ausgaben. Getrennt sind die Seiten, weil die Erklärungen es sind: Hier steht, was Gzip vorwegnimmt und wo Bytes wirklich zählen, dort steht, wie man Einrückung wählt und warum die Reihenfolge der Schlüssel erhalten bleibt.