Häufige JSON-Syntaxfehler verstehen und beheben: RFC 8259 Leitfaden

1. Syntaxvalidierung vs. JSON-Schema vs. Geschäftsregeln

Ein häufiges Missverständnis unter Entwicklern besteht darin, alle Prüfungen von JSON-Daten als denselben Vorgang zu betrachten. In der Praxis unterscheiden Softwaresysteme drei voneinander getrennte Validierungsstufen:

• RFC 8259 Syntaxvalidierung: Prüft, ob ein Text exakt der grammatikalischen Spezifikation von JSON entspricht: geschweifte und eckige Klammern, doppelt quotierte Schlüssel und Zeichenketten, Kommatrennung und gültige Literale (Zeichenketten, Zahlen, Booleans, null). Fehlt ein Anführungszeichen oder eine Klammer, handelt es sich nicht um gültiges JSON.
• JSON-Schema-Validierung: Überprüft, ob ein syntaktisch valides JSON-Dokument einer vordefinierten Datenstruktur ($schema-Regeln, erwartete Datentypen, Pflichtfelder, Wertebereiche) entspricht. Ein Dokument kann syntaktisch makellos sein, aber dennoch sein Schema verletzen.
• Geschäftsregel-Validierung: Erzwingt anwendungsspezifische Fachlogik (z. B. Kontostand darf nicht negativ sein, Enddatum muss nach dem Startdatum liegen). Weder Syntax-Parser noch generische Schemas prüfen domänenspezifische Invarianten.

Das GoToolstack-Werkzeug führt eine strikte RFC 8259 Syntaxvalidierung und AST-Formatierung durch; es führt weder eine JSON-Schema-Prüfung noch Geschäftsregel-Validierungen durch.

2. Formatierung bedeutet keine automatische Fehlerkorrektur

JSON-Formatierer (Pretty-Printer und Minifier) ordnen Leerzeichen, Einrückungen und Zeilenumbrüche eines bereits syntaktisch gültigen Abstract Syntax Tree (AST) neu an. Sie sind keine automatischen Reparaturwerkzeuge.

Wird fehlerhafter Text eingegeben, stoppt die Engine sofort am ersten unzulässigen Zeichen, zeigt eine präzise Fehlermeldung mit Position an (z. B. Trailing comma in object is not allowed at position 45) und leert das Ausgabefeld. Das Werkzeug rät nicht nach Entwicklerabsichten, fügt keine fehlenden Klammern ein, löscht keine überzähligen Kommas und konvertiert keine einfachen Anführungszeichen automatisch. Syntaxfehler müssen vor der Formatierung manuell korrigiert werden.

3. Die 5 häufigsten JSON-Syntaxfehler

{
  "name": "GoToolstack",
  "active": true,
}

{'status': 'success'}

{count: 42}

{"path": "C:\programme\daten.json"}

// Server-Konfiguration
{"port": 8080}

4. Die 64-Bit-Ganzzahl-Falle: Verlustfreie Token-Erhaltung vs. Präzisionsverlust in Fremdsystemen

Standard-JavaScript speichert Zahlen als IEEE 754 64-Bit-Gleitkommazahlen mit doppelter Genauigkeit. Die Grenze für sichere Ganzzahlen liegt bei:

Number.MAX_SAFE_INTEGER = 9.007.199.254.740.991 (2^53 - 1)

Wenn eine API große 64-Bit-IDs oder Transaktionsnummern (z. B. 9007199254740993) überträgt, rundet ein natives JSON.parse() den Wert unbemerkt auf 9007199254740992 ab, wodurch Daten unwiderruflich verfälscht werden.

GoToolstack verwendet einen maßgeschneiderten verlustfreien Parser, der numerische Werte als exakte Text-Token speichert. Bei der Formatierung bleiben alle Ziffern unverändert erhalten. Diese Erhaltung garantiert jedoch keine Sicherheit in nachgelagerten Systemen: Wenn ein Fremdsystem, Datenbanktreiber oder Frontend die Daten anschließend mit einem Standard-Gleitkomma-Parser liest, tritt der Rundungsverlust dort erneut auf. In verteilten Systemen sollten 64-Bit-Ganzzahlen als Zeichenketten (z. B. "9007199254740993") übertragen werden.

5. Doppelte Objektschlüssel und Parser-Mehrdeutigkeiten nach RFC 8259

Betrachten wir ein Objekt mit duplizierten Schlüsseln:

{"benutzer": "alice", "benutzer": "bob"}

Der AST-Parser von GoToolstack behält beide Schlüssel-Wert-Paare in ihrer Reihenfolge bei, ohne frühere Einträge zu verwerfen. Allerdings stellt RFC 8259 Abschnitt 4 klar, dass das Verhalten von Parsern bei doppelten Schlüsseln unvorhersehbar ist:

• Manche Parser übernehmen nur den ersten Schlüssel und ignorieren spätere Duplikate.
• Viele Standard-Bibliotheken (einschließlich JSON.parse() in JS und json.loads() in Python) überschreiben den Wert und behalten nur den letzten Eintrag.
• Strenge Parser verweigern die Verarbeitung vollständig mit einem Syntaxfehler.

Dass GoToolstack doppelte Schlüssel in der Textausgabe erhält, garantiert keineswegs eine einheitliche Interpretation durch Empfängersysteme. Produktionsdaten sollten stets eindeutige Schlüssel verwenden.

6. Technische Grenzen und Leistungsumfang des Werkzeugs

• Keine Baumansicht oder Schema-Validierung: Das Werkzeug bietet einen schnellen, zweigeteilten Rohtext-Editor mit Live-Diagnose. Eine interaktive DOM-Baumansicht oder JSON-Schema-Prüfung ist nicht integriert.
• Unzulässige Werte: NaN, Infinity und -Infinity sind in RFC 8259 unzulässig. JavaScript undefined, Funktionen und zirkuläre Referenzen können nicht serialisiert werden.
• Clientseitige Ausführung: Sämtliche Berechnungen laufen lokal im Speicher des Browsers ab; keine Daten werden an externe Server übertragen.