json_repair: kaputtes JSON aus LLM-Antworten in Python reparieren
Repair malformed JSON from LLMs, APIs, logs, and user input in Python.
Auf einen Blick
- Was ist das?
- Die Bibliothek json_repair versucht sich an fehlenden Anführungszeichen, Kommas und Klammern in JSON-Strings und liefert bei Bedarf direkt Python-Objekte. Ein nüchterner Blick auf Mechanik, Grenzen und den Preis der Fehlertoleranz.
- Für wen ist es gedacht?
- Wer LLM-Ausgaben, Logzeilen oder Nutzereingaben verarbeitet und dabei regelmäßig an fehlenden Anführungszeichen oder abgeschnittenen Werten scheitert, findet hier eine schlanke Bibliothek mit MIT-Lizenz und einer dokumentierten Rückfalllogik. Wer dagegen strikte Validierung gegen ein Schema benötigt oder nicht bereit ist, stillschweigend reparierte Daten zu akzeptieren, sollte bei json.loads() bleiben oder einen Schema-Validator davorschalten.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 6 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem json_repair adressiert
Sprachmodelle liefern selten exakt das, was ein strikter Parser erwartet. Mal fehlt ein schließendes Komma, mal ein Anführungszeichen um einen Schlüssel, mal hängt ein Satz Prosa vor der eigentlichen Struktur. Die README beschreibt genau diese Ausgangslage: Manche Modelle seien etwas unzuverlässig, wenn es um wohlgeformtes JSON gehe, und die Fehler seien meist einfach genug, um sie zu beheben, ohne den Inhalt zu zerstören. Der Autor gibt an, kein leichtgewichtiges Python-Paket gefunden zu haben, das dieses Problem zuverlässig löst, und deshalb selbst eines geschrieben zu haben.
Die Zielgruppe ist damit klar umrissen: Entwicklerinnen und Entwickler, die Ausgaben von LLMs, Antworten unzuverlässiger APIs, Logzeilen oder Nutzereingaben weiterverarbeiten wollen, ohne bei jedem fehlenden Komma eine Ausnahme zu kassieren. Es geht nicht um Datenintegrität im strengen Sinn, sondern um Pragmatismus an der Grenze zwischen unstrukturiertem Text und einem Python-Objekt. Wer diese Grenze täglich überquert, kennt das Problem.
Reparaturpfad statt Parser-Neubau
Der Mechanismus ist im Kern ein zweistufiger Ablauf. Laut README versucht json_repair standardmäßig zuerst den JSON-Loader der Standardbibliothek und fällt nur dann auf den Reparaturparser zurück, wenn das strikte Parsen fehlschlägt. Das ist die zentrale Designentscheidung: Der Normalfall bleibt schnell, der Sonderfall wird abgefangen.
Die README nennt die Kategorien, die der Reparaturpfad abdeckt. Fehlende Anführungszeichen, falsch platzierte Kommas, nicht maskierte Zeichen und unvollständige Schlüssel-Wert-Paare. Dazu kommen fehlende schließende Klammern, Kommentare im Text und überzählige Nicht-JSON-Zeichen. Bei abgeschnittenen Strukturen ergänzt die Bibliothek laut Dokumentation fehlende Elemente oder setzt Standardwerte wie null oder den leeren String. Ein interessantes Detail: Komma-separierte Klammerausdrücke im Python-Stil werden als JSON-Array interpretiert, ein einzelner Klammerausdruck dagegen als Skalar. Innerhalb von Arrays, Objekten und Tupeln werden true, false, null und None laut README ohne Rücksicht auf Groß- und Kleinschreibung als JSON-Boolesche Werte oder null erkannt.
Das ist Heuristik, keine Grammatik. Wer verstehen will, was im Einzelfall passiert, muss sich die Reparaturregeln ansehen oder die Live-Demo bemühen, die die README verlinkt.
Installation und die zwei Aufrufwege
Die Installation erfolgt über pip install json-repair. Danach stehen zwei Schnittstellen zur Verfügung. Wer einen reparierten String zurückbekommt, nutzt repair_json:
from json_repair import repair_json good_json_string = repair_json(bad_json_string)
Die README weist ausdrücklich darauf hin, dass diese Funktion bei sehr kaputten Eingaben einen leeren String zurückgibt. Wer direkt ein Objekt will, verwendet loads:
import json_repair decoded_object = json_repair.loads(json_string)
Alternativ lässt sich repair_json mit return_objects=True aufrufen. Für Dateien gibt es ein drop-in für json.load sowie die Funktion from_file. Wichtig: IO-bedingte Ausnahmen fängt die Bibliothek laut README nicht ab, die muss der aufrufende Code behandeln.
Ein dokumentierter Anti-Pattern ist der manuelle try/except-Block um json.loads mit anschließendem json_repair.loads im Fehlerfall. Die README nennt das verschwenderisch, weil json_repair diese Prüfung ohnehin standardmäßig durchführt. Der empfohlene Ablauf ist schlicht der direkte Aufruf von json_repair.loads.
skip_json_loads und der Preis der Abkürzung
Für den Fall, dass die Eingabe bereits bekannt fehlerhaft ist, dokumentiert die README den Parameter skip_json_loads=True. Damit wird die Validierung über die Standardbibliothek übersprungen und direkt der Reparaturparser aufgerufen:
from json_repair import repair_json good_json_string = repair_json(bad_json_string, skip_json_loads=True)
Die README bezeichnet das ausdrücklich als Abwägung. Standardverhalten: erst validieren, nur bei Bedarf reparieren. Mit skip_json_loads=True entfällt der schnelle Pfad. Der Hinweis in der README ist eindeutig: Der Parameter ist nur für Eingaben gedacht, die bereits als ungültig bekannt sind. Der Gedanke dahinter ist nachvollziehbar. Bei Streaming-Ausgaben von Modellen weiß man oft, dass der letzte Chunk unvollständig ankommt, und spart sich die doppelte Arbeit. Bei Nutzereingaben oder API-Antworten wäre die Abkürzung dagegen riskant, weil gültiges JSON dann durch den heuristischen Pfad läuft und im Zweifel anders interpretiert wird als vom Standardparser.
Nicht-Latin-Zeichen und durchgereichte dumps-Parameter
Ein Punkt, der in der Praxis regelmäßig übersehen wird: Bei nicht-lateinischen Zeichen, etwa Chinesisch, Japanisch oder Koreanisch, muss ensure_ascii=False übergeben werden, damit die Zeichen im Ergebnis erhalten bleiben. Die README zeigt das an einem Beispiel mit chinesischen Schriftzeichen. Ohne den Parameter landet die Unicode-Escape-Sequenz im Ausgabestring, mit dem Parameter bleiben die Originalzeichen stehen.
Darüber hinaus akzeptiert repair_json laut README alle Parameter, die json.dumps akzeptiert, und reicht sie durch, indent eingeschlossen. Das ist praktisch, weil sich damit die Ausgabe direkt formatieren lässt, ohne den Umweg über einen zweiten Aufruf. Die README geht an dieser Stelle allerdings nicht ins Detail, welche Parameter im Reparaturpfad tatsächlich Wirkung zeigen und welche nur im Normalfall greifen. Wer sich darauf verlässt, sollte das mit einem eigenen Testfall absichern.
Wo die Fehlertoleranz zur Falle wird
Die zentrale Einschränkung steht implizit in der Funktionsweise: Ein Reparaturparser, der fehlende Werte mit null oder dem leeren String auffüllt, erfindet Struktur. Aus einer abgeschnittenen Liste wird ein gültiges Array mit weniger Elementen, aus einem fehlenden Wert ein null. Das ist genau das gewünschte Verhalten, wenn man eine Anzeige retten will. Es ist das falsche Verhalten, wenn nachgelagerte Logik zwischen einem echten null und einem rekonstruierten null unterscheiden muss.
Die README benennt diesen Trade-off nicht als Risiko. Sie beschreibt die Auto-Vervollständigung als Feature. Wer json_repair als drop-in für json.loads einsetzt, verliert damit die Garantie, dass die zurückgegebenen Daten tatsächlich im Original so standen. Für Prototyping, Log-Auswertung oder das Befüllen einer Vorschau ist das vertretbar. Für Buchhaltungsdaten, Konfigurationsdateien oder alles, was später gegen ein Schema validiert wird, ist es das falsche Werkzeug. Ein weiterer Punkt: Die README erwähnt, dass repair_json bei sehr kaputten Eingaben einen leeren String zurückgibt. Der Aufrufer muss also auch diesen Fall behandeln, sonst wandert ein leerer String weiter durch die Pipeline.
Alternative: strikt parsen und ablehnen
Die naheliegende Alternative ist der Verzicht auf Reparatur. Pydantic etwa validiert eingehende Daten gegen ein deklariertes Modell und wirft bei Abweichungen einen Validierungsfehler, statt fehlende Felder stillschweigend zu ergänzen. Der Unterschied liegt nicht in der Geschwindigkeit, sondern in der Fehlerbehandlung: Pydantic liefert eine strukturierte Beschreibung, was nicht passt, und zwingt den Aufrufer, darauf zu reagieren. json_repair liefert ein Objekt und überlässt es dem Aufrufer zu erkennen, dass etwas rekonstruiert wurde.
Für Anwendungen, in denen ein Modell per Structured Output oder Function Calling an ein Schema gebunden wird, ist der strikte Weg oft der bessere, weil das Modell dann gar nicht erst die Freiheit hat, ungültiges JSON zu produzieren. json_repair ist die Rückfalloption für alles, was außerhalb dieser Kontrolle liegt: Freitext-Antworten, ältere APIs, Logdateien mit gemischten Formaten. Die Bibliothek selbst listet json-schema, pydantic und structured-output als Topics, was nahelegt, dass sie in solchen Pipelines als nachgelagerte Stufe gedacht ist, nicht als Ersatz für die Validierung.
Wartung, Lizenz und was vor dem Einsatz zu prüfen ist
Das Repository steht unter MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung des Lizenzhinweises. Rechtlich verbindliche Aussagen sind das nicht, im Zweifel gehört die Lizenz selbst gelesen.
Zur Wartung: Die letzten Releases liegen dicht beieinander. v0.63.4 erschien am 25. August 2026, v0.63.3 am 19. August, v0.63.2 am 14. August. Der letzte Push auf den main-Branch datiert vom 3. September 2026. Das deutet auf ein aktiv gepflegtes Projekt mit häufigen Patch-Releases hin. Die Versionsnummer im 0.63er-Bereich zeigt zugleich, dass die API noch nicht als stabil im Sinne von 1.0 markiert ist. Wer die Bibliothek produktiv einsetzt, sollte bei Upgrades die Release Notes lesen, weil sich Reparaturheuristiken zwischen Patch-Versionen ändern können und das Verhalten bei Grenzfällen dann anders ausfällt.
Die README bittet um Sponsoring und weist darauf hin, dass die Bibliothek als Nebenprojekt gepflegt wird. Das ist ein Hinweis auf das Wartungsmodell, kein Qualitätsurteil. Wer auf langfristige Zusicherungen angewiesen ist, sollte diesen Punkt bei der Auswahl berücksichtigen. Vor dem Einsatz lohnt es sich, eine Handvoll echter Fehlerfälle aus der eigenen Pipeline durch beide Pfade zu schicken, mit und ohne skip_json_loads, und die Ergebnisse zu vergleichen. Die Live-Demo unter mangiucugna.github.io/json_repair kann dabei als erster Anlaufpunkt dienen, ersetzt aber keinen Test mit den eigenen Daten.
Redaktionelles Fazit
Wer LLM-Ausgaben, Logzeilen oder Nutzereingaben verarbeitet und dabei regelmäßig an fehlenden Anführungszeichen oder abgeschnittenen Werten scheitert, findet hier eine schlanke Bibliothek mit MIT-Lizenz und einer dokumentierten Rückfalllogik. Wer dagegen strikte Validierung gegen ein Schema benötigt oder nicht bereit ist, stillschweigend reparierte Daten zu akzeptieren, sollte bei json.loads() bleiben oder einen Schema-Validator davorschalten. Vor dem Einsatz lohnt es sich, die eigene Fehlerverteilung zu prüfen: Enthält sie überwiegend abgeschnittene Strings am Ende eines Streams, ist skip_json_loads=True der naheliegende Hebel; dominieren strukturelle Brüche mitten im Dokument, entscheidet die Qualität der Heuristik über den Nutzen.
Community-Notizen