FracturedJson

 (github.com/j-brooke)
6 Punkte von GN⁺ 2026-01-03 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Sammlung von Formatierungs-Utilities, die JSON-Daten menschenlesbar anordnen und dabei kompakt halten
  • Arrays und Objekte werden nach Möglichkeit in einer Zeile dargestellt, und bei ähnlichen Strukturen tabellarisch ausgerichtet
  • Unterstützt die Beibehaltung von Kommentaren und erhält Kommentare mit, die zwar nicht zum JSON-Standard gehören, in realen Einsatzumgebungen aber häufig sind
  • Nutzbar in verschiedenen Umgebungen, darunter .NET-Bibliothek, JavaScript/TypeScript-Paket, VS Code-Erweiterung und Browser-Formatter
  • Ein Werkzeug, das die Grenzen der Lesbarkeit bestehender JSON-Formatter verbessert und das visuelle Verständnis für Entwickler und Datenanalysten erhöht

Überblick über FracturedJson

  • FracturedJson ist eine Sammlung von Utilities zur Erzeugung eines menschenlesbaren und zugleich relativ kompakten JSON-Formats
    • Arrays und Objekte werden in einer Zeile ausgegeben, sofern sie nicht zu lang oder zu komplex sind
    • Mehrzeilige Strukturen mit ähnlichem Aufbau werden durch Ausrichtung der Felder tabellarisch dargestellt
    • Lange Arrays werden über mehrere Zeilen verteilt, wobei mehrere Elemente pro Zeile platziert werden
  • Über verschiedene Einstellungen lässt sich das Ausgabeformat steuern; in den meisten Fällen liefern bereits die Standardeinstellungen ein gut lesbares Ergebnis
  • Verfügbar als browserbasierte Formatter-Seite, .NET-Bibliothek, JavaScript/TypeScript-Paket und VS Code-Erweiterung
  • Eine Option für Python wird ebenfalls separat beschrieben

Motivation

  • Die meisten JSON-Bibliotheken bieten nur zwei Formate
    • Minified JSON: effizient, aber für Menschen schwer lesbar
    • Beautified/Indented JSON: zu stark ausgedehnt, sodass eine schnelle Erfassung schwierig ist
  • FracturedJson formatiert Daten so, als hätte ein Mensch sie direkt geschrieben
    • Außer wenn sie zu komplex oder zu lang sind, werden Container in einer Zeile gehalten
    • Ähnliche Arrays oder Objekte werden tabellarisch ausgerichtet

Funktionsweise (How It Works)

  • FracturedJson verwendet vier Formatierungstypen
    1. Inlined: Kurze und einfache Objekte oder Arrays werden in einer Zeile dargestellt
      • Mit der Einstellung MaxInlineComplexity lässt sich die erlaubte Verschachtelungstiefe steuern
    2. Compact Multiline Array: Mehrere Elemente werden pro Zeile platziert, aber über mehrere Zeilen verteilt dargestellt
      • Mit MaxCompactArrayComplexity lässt sich die erlaubte Verschachtelung anpassen; mit -1 kann dies deaktiviert werden
    3. Table: Elemente mit ähnlicher Struktur werden spaltenweise ausgerichtet
      • Wenn innere Container zu komplex sind, werden nur Teile davon reduziert
      • Steuerbar über MaxTableRowComplexity und TableCommaPlacement
    4. Expanded: Wenn keine der obigen Bedingungen passt, wird jedes Element über mehrere Zeilen eingerückt dargestellt

Kommentarverarbeitung

  • Der JSON-Standard erlaubt keine Kommentare, aber FracturedJson unterstützt die Beibehaltung von Kommentaren
    • Kommentare bleiben zusammen mit dem zugehörigen Element erhalten; sowohl mehrzeilige Kommentare als auch Inline-Kommentare werden verarbeitet

Discussions

  • Es gibt einen Bereich für GitHub Discussions für Nutzerfragen, Feedback und Vorschläge
  • Diskussionen rund um das Projekt und Verbesserungsvorschläge sind möglich

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-03
Hacker-News-Kommentare

  • Derzeit gibt es für dieses Projekt zwei gepflegte Implementierungen.
    Eine ist die C#-Version (FracturedJson .NET Library), die andere die TypeScript-/JavaScript-Version (FracturedJsonJs).
    Früher gab es auch eine reine Python-Version, diese wird inzwischen aber nicht mehr gepflegt und wurde stattdessen durch einen Python-Wrapper um den C#-Code ersetzt (fractured-json).
    Als Nachteil ist bei dieser Python-Version angegeben, dass sie eine .NET-Laufzeitumgebung benötigt, sodass die Installation nicht einfach nur mit pip install erledigt ist.
    Ich halte das für eine gute Gelegenheit, eine sprachunabhängige Conformance Suite zu erstellen — also einen datengestützten Testsatz, mit dem sich prüfen lässt, ob mehrere Implementierungen identisch arbeiten.
    Die frühere Python-Version nutzte übrigens bereits Tests in genau dieser Form (compact-json-Testdaten).

    • Ich habe es gerade nach Rust portiert und plane, es künftig zu warten.
      Das könnte man wohl dem ursprünglichen Kommentar hinzufügen.
      Details gibt es im fracturedjson-rs GitHub und im crates.io-Paket.
      Der zugehörige Erläuterungskommentar ist hier.
    • Gute Idee, aber ich denke, über Testfälle hinaus bis zu einer Garantie der Programmgleichwertigkeit zu kommen, ist schwierig.
    • Das hier ist fast eine reine Funktion, daher ist ein Test-Harness sehr leicht zu schreiben.
    • Datengestützte Tests sind sehr effektiv, um Vertrauen in eine Bibliothek aufzubauen.
      html5lib-tests oder auch mein eigenes xss-bench sind solche Beispiele.

  • Ich habe eine nach Rust portierte Version erstellt, und über ein CLI-Tool lässt sich JSON in dieses Format umwandeln.
    Installierbar über fracturedjson-rs und das crates.io-Paket (cargo install fracturedjson).
    Es bietet verschiedene Optionen und erlaubt eine feine Steuerung etwa von Kommentierungsstil, Einrückungsstil und Zeilenbreitenbegrenzung.

    • Auch die portierte Version ist ein abgeleitetes Werk, daher sollte der Copyright-Hinweis des ursprünglichen Autors erhalten bleiben.

  • Dieses Projekt ist wirklich großartig.
    Mir gefällt die Richtung, JSON menschenlesbarer zu machen.
    Ich entwickle dagegen bonjson, das JSON eher maschinenfreundlicher macht.
    Es hat exakt dieselben Fähigkeiten und Einschränkungen wie JSON und kann 35-mal schneller lesen und schreiben.
    Es gibt keine neuen Typen oder Funktionen, sondern tut genau das, was JSON auch kann.

    • JSON ist eine einfache Notation, daher finde ich, dass es ein formalisiertes Datenmodell braucht.
      Zum Beispiel sind Bitbreite von Zahlen oder die Unterscheidung zwischen Integer und Gleitkommazahl nicht festgelegt.
      Mit so einem Modell wäre eine 1:1-Abbildung zwischen Repräsentationen möglich.
      Zu diesem Thema schreibe ich gerade diesen Text.
    • Interessant, aber angesichts der Behauptung „kann alles, was JSON kann“ wirken die sicherheitsbedingten Einschränkungen etwas überraschend.
      Zum Beispiel ist "a\u0000b" ein gültiger JSON-String; wenn sich so etwas nicht serialisieren lässt, trifft die Behauptung nicht vollständig zu.
    • Mich würde interessieren, was der Auslöser war, das zu bauen.
      Ich habe einmal einen Serializer geschrieben, der JSON und Binärdateien über eine gemeinsame Schnittstelle speichert und lädt.
      Meiner Erfahrung nach war JSON ein Format mit vielen Einschränkungen und wenigen Vorteilen.
      Deshalb habe ich es in ein lockeres Format umgewandelt, in dem Kommas, Doppelpunkte und Anführungszeichen weggelassen werden können und mehrzeilige Strings sowie Kommentare erlaubt sind.
      Es wäre schön, wenn JSON nicht mehr so getan würde, als sei es immer ein „menschenfreundliches“ Format.
      Es braucht eine standardisierte Alternative für Umgebungen, die nicht auf JSON zentriert sind.
    • Das erinnert mich an das kürzlich erschienene Lite3.
    • Ich frage mich, wie es bei der Kompressionsrate aussieht.

  • Überraschend.
    Ich habe etwas mit ähnlicher Funktionalität selbst in Python in ungefähr 200 Zeilen umgesetzt und wusste nicht, dass es bereits so eine Bibliothek gibt.

  • Ich frage mich, ob es wie jq eine Option gibt, Pipe-Eingaben zu verarbeiten.

    • Wenn man sich den C#-CLI-Code im Repository ansieht, kann man Standard-Ein/Ausgabe oder Dateien angeben.
      Die JavaScript-Version und der Python-Wrapper bieten dasselbe CLI-Tool ebenfalls an.
    • RCL führt standardmäßig Pretty-Printing aus.
      Mit rcl e sieht man das RCL-Format, mit rcl je die JSON-Ausgabe.
      Es hat keine Tabellenausrichtung wie FracturedJson, verwendet aber den Algorithmus Philip Wadlers A Prettier Printer und bricht Zeilen automatisch passend zur Breite um.
    • Mit der Prozesssubstitution <() kann man auch eine temporäre Datei erzeugen und so arbeiten.
    • In den meisten Fällen kann man vom stdin lesen, wenn man als Eingabedateinamen - angibt.

  • Ich habe einen JSON-Formatter namens Virtuous gebaut, und das hier ist so beeindruckend, dass ich fast meinen eigenen Formatter aufgeben möchte.
    Wirklich hervorragende Arbeit.

  • Ich habe ein Groovy-Skript namens „mommyjson“ geschrieben.
    Statt das JSON-Format beizubehalten, zeigt es die Elternbeziehung jedes Elements — also Array-Index, Objektname usw. — in einer Zeile an, damit man die Position der Daten intuitiv erfassen kann.
    Code ansehen
    Groovy ist nicht besonders populär, daher wäre es schön, wenn es einen Python-Port gäbe.

    • Gute Idee! Dass es mehrere solcher Werkzeuge gibt, zeigt, dass das offenbar eine Funktion ist, die viele Menschen brauchen.
      Typische Beispiele sind gron und mein eigenes jstream.
      Mit einer Beispielausgabe wäre es vermutlich noch leichter zu verstehen.
    • Ich frage mich, ob es eine Beispielausgabe gibt.

  • Ich bin nicht sicher, ob JSON wirklich ein Format ist, das menschenlesbarer gemacht werden muss.
    Es gibt viele bessere Wege, Daten Nutzern zu zeigen, und ich denke, JSON sollte eher für die Datenübertragung zwischen Systemen verwendet werden.

    • Solche Werkzeuge nutzt man normalerweise, wenn es kein klares Schema oder keine Visualisierungstools gibt.
      In Debugging-Situationen, in denen man komplex verschachtelte Daten schnell erfassen muss, ist das nützlich.
      Das passiert besonders häufig bei Integrationscode für externe Systeme.
    • Ich nutze auch oft jq oder python -m json.tool, um JSON-Daten zu lesen.
      Wenn so ein Tool das besser darstellt, ist es absolut sinnvoll.
    • Wenn man den menschenlesbaren Aspekt aufgibt, ist JSON eine ineffiziente Kodierung.
      Der Vorteil von JSON ist letztlich, dass es von Menschen und Maschinen lesbar ist, also bleibt es für Debugging weiterhin sinnvoll.

  • Mir gefällt diese Idee wirklich sehr.
    Der Hauptgrund für die langsame Verbreitung ist derzeit der fehlende Support in den meisten Sprachen und Paketmanagern (homebrew usw.).
    Wenn man die .NET-Bibliothek als C-kompatible Shared Library kompilieren würde, ließe sie sich leicht in vielen Sprachen nutzen.

  • Interessanter Ansatz.
    Es wäre schön, wenn Code-Formatter auch so arbeiten würden.
    Die heutigen Formatter sind zu starr, wodurch die Struktur schwer zu erkennen ist.

    • Ich habe einen C++-Formatter gebaut, der nur zwei Arten von Objekten verwendet: tabulatorausgerichtete Tabellen und einzeilige Blöcke.
      Kommentare werden rechtsbündig ausgerichtet und sauber platziert.
      Dank dieser Struktur lassen sich auch switch-case-Blöcke oder Makro-Tabellen leicht zweidimensional ausrichten.
      Die Basisschicht habe ich in einer Stunde geschrieben, und ich arbeite gerade an einer Kombination aus LSP und Code-Observation, um Blöcke automatisch zu erkennen.
    • Früher habe ich selbst einmal einen XML-Formatter gebaut, damit XML eher tabellarisch aussieht.
      Im Idealfall hätte man XML einfach abgeschafft, aber wegen Legacy-Einschränkungen ging das leider nicht.