Kostenloser JSON-Validator

JSON-Validierung: zwei Schichten, zwei verschiedene Fragen

Ein JSON-Validator beantwortet eine binäre Frage, ist dieses JSON-Dokument wohlgeformt?, indem er die Eingabe an denselben Parser übergibt, den der Browser intern verwendet, und meldet, ob er die Syntax akzeptiert. Dieses Tool tut genau das und nur das. Es prüft nicht, ob die Daten im Dokument das bedeuten, was Sie beabsichtigten. Diese zweite Frage, hat das Dokument die Form, die Typen und die Einschränkungen, die Ihre Anwendung erwartet?, ist Schema-Validierung, das Terrain von Werkzeugen wie Ajv (unten behandelt). Die beiden Aktivitäten ergänzen einander und beantworten verschiedene Fragen; das eine zu verwenden, wenn man das andere wollte, ist ein Kategorienfehler. Eine nützliche Analogie ist die Unterscheidung Rechtschreib-/Grammatikprüfung in Textverarbeitungen: Rechtschreibprüfung (Syntax) sagt Ihnen, ob jedes Wort ein echtes Wort ist; Grammatikprüfung (Schema) sagt Ihnen, ob der Satz Sinn ergibt; beide sind nützlich, keine ersetzt die andere, und keine sagt Ihnen, ob der Aufsatz gut ist. {"phoneNumber": 12345} ist wohlgeformtes JSON, aber wenn Ihre Anwendung eine Zeichenkette im Format "+1-555-555-1234" erwartete, ist es falsch, und ein Syntax-Validator kann es nicht sagen.

Über die Syntax-Prüfung hinaus bietet dieses Tool auch einen Best-Effort-„Häufige Probleme beheben"-Durchgang an, der die vier häufigsten Arten umschreibt, wie Entwickler versehentlich ungültiges JSON schreiben: nachfolgende Kommata, einfach-gequotete Zeichenketten, ungequotete Schlüssel und undefined-Literale (umgeschrieben zu null). Es ist eine Heuristik, kein Parser, also überprüfen Sie immer die korrigierte Ausgabe vor der Übernahme.

Eine kurze Geschichte von JSON

JSON hat eine bemerkenswert kurze Biografie. Das Akronym wurde bei State Software, Inc. geprägt, einer kleinen Beratungsfirma, die Douglas Crockford und Chip Morningstar im März 2001 gegründeten, um das zu bauen, was später Ajax-Webanwendungen genannt würde. Die erste JSON-Nachricht wurde im April 2001 von einem Computer in Morningstars Garage in der Bay-Area gesendet. Crockford behauptet nicht, JSON erfunden zu haben, das Format existierte bereits in der JavaScript-Sprache als Objekt-Literal-Untermenge; sein Beitrag bestand darin, es herauszulösen, ihm einen Namen zu geben, eine Website zu erstellen (json.org ging 2002 online mit einer Beschreibung der Grammatik in drei Notationen und einem JavaScript-Referenzparser) und für die Adoption zu werben. Dezember 2005 ist der Moment, den die meisten Historiker als JSONs Eintritt in den Mainstream nennen: in jenem Monat begann Yahoo!, einige seiner Webdienste in JSON anzubieten. Die IETF griff es als Nächstes auf: RFC 4627 („The application/json Media Type for JSON"), von Crockford selbst verfasst, wurde im Juli 2006 als informelles Dokument veröffentlicht, nicht Standards Track. Standardisierungsgremien holten 2013-2014 nach: ECMA-404 1. Ausgabe im Oktober 2013 (bewusst minimal, sechs Seiten substanziellen Inhalts), RFC 7159 im März 2014 (lockerte die Top-Level-Beschränkung, sodass jeder JSON-Wert, nicht nur Objekte und Arrays, ein vollständiges Dokument sein konnte), und das aktuelle Paar im Dezember 2017: RFC 8259 (jetzt Internet Standard STD 90) und ECMA-404 2. Ausgabe normativ damit abgestimmt. Die beiden sind verpaart: jede referenziert die andere normativ und enthält ein Bekenntnis zur Konsistenz. Auch als ISO/IEC 21778:2017 veröffentlicht.

Die JSON-Grammatik in 200 Wörtern

Ein JSON-Dokument ist ein einzelner Wert, optional von Leerraum umgeben. Es gibt genau sechs Werttypen: Objekt, eine ungeordnete Sammlung von null oder mehr Name/Wert-Paaren, geschrieben {"k": v, "k2": v2}; Array, eine geordnete Sequenz, [v, v2, v3] (Arrays bewahren die Reihenfolge per Spec); String, eine in doppelte Anführungszeichen gefasste Unicode-Zeichenfolge (einfache Anführungszeichen nicht erlaubt; Backslash-Escapes \", \\, \/, \b, \f, \n, \r, \t plus \uXXXX; Steuerzeichen U+0000 bis U+001F müssen escapet werden); Zahl, eine strikte ASCII-Form (optionales Minuszeichen, ganzzahliger Teil ohne führende Nullen, optionaler Bruchteil, optionaler Exponent mit e oder E); true / false, die JSON-Booleans, nur Kleinbuchstaben; null, die Abwesenheit eines Wertes, nur Kleinbuchstaben. Leerraum zwischen Tokens ist erlaubt und wird ignoriert. Keine Kommentare. Keine nachfolgenden Kommata. Objekt-Schlüssel müssen in doppelten Anführungszeichen stehen. Die Grammatik passt auf eine Seite. Die strikte Zahlenform verbietet Hex (0xFF), Oktal (0777), +-Zeichen, Infinity, NaN und nachfolgende Dezimalpunkte wie 1.; das erwischt jeden, der JSON von Hand in Umgebungen schreibt, die die lockereren ECMAScript-Zahlenformen akzeptieren, am häufigsten jeden, der je einen Hex-Farbcode in eine JSON-Datei eingefügt hat.

Warum die Grammatik so strikt ist, Crockfords Designentscheidungen

Zwei bewusste Auslassungen erklären den Großteil der Reibung, die Benutzer beim manuellen Schreiben von JSON spüren. Keine Kommentare. JavaScript hat sowohl // als auch /* */-Kommentare; JSON, die JavaScript-Untermenge, hat keine. Crockfords erklärter Grund, 2012 auf Google+ gepostet, wurde seither Tausende Male zitiert: „Ich habe Kommentare aus JSON entfernt, weil ich sah, dass Leute sie verwendeten, um Parsing-Direktiven zu halten, eine Praxis, die die Interoperabilität zerstört hätte. Ich weiß, dass das Fehlen von Kommentaren manche traurig macht, aber es sollte nicht." Das Argument lautet, Kommentare laden zur Erweiterung ein, wenn // @schema foo.json in Ihrer Config steht und Ihr Tool es liest, ist Ihre Config-Datei kein JSON mehr. Keine nachfolgenden Kommata. Ein Komma ist ein Trenner, kein Terminator. [1, 2, 3] ist legal, aber [1, 2, 3,] nicht. Der Grund ist derselbe wie bei Kommentaren: Einfachheit der Grammatik und Uniformität über Parser hinweg. Der Preis ist, dass jeder, der ein mehrzeiliges JSON-Objekt bearbeitet, eine Eigenschaft hinzufügt, Eigenschaften umsortiert, die letzte löscht, an das Komma denken muss. Kein undefined. JavaScript hat undefined; JSON nicht. Verwenden Sie null oder lassen Sie die Eigenschaft ganz weg. BOM in der Eingabe. Ein Byte-Order-Mark (U+FEFF) am Anfang eines JSON-Dokuments ist in übertragenem JSON verboten, aber Parser DÜRFEN eines ignorieren, wenn es auftaucht. In der Praxis brechen Dateien, die ältere Windows-Editoren als „UTF-8 with BOM" speichern, manche Parser stillschweigend und funktionieren in anderen stillschweigend.

Häufige JSON-Fehler:

• Nachgestellte Kommas: Das letzte Element in einem Objekt oder Array darf kein Komma haben
• Einfache statt doppelte Anführungszeichen: JSON erlaubt nur doppelte Anführungszeichen für Strings
• Schlüssel ohne Anführungszeichen: Objektschlüssel müssen immer in doppelten Anführungszeichen stehen
• Kommentare: JSON unterstützt keine Kommentare (manche Tools erlauben sie dennoch)
• Nicht escapeter Backslash. Innerhalb eines JSON-Strings ist \ das Escape-Zeichen. "C:\Users\Alice" schlägt fehl, weil \U und \A keine erkannten Escapes sind. Die Heilung besteht darin, jeden Backslash zu verdoppeln: "C:\\Users\\Alice".
• Nicht escapete Steuerzeichen. Ein wörtlicher Zeilenumbruch, Tab oder anderes Zeichen in U+0000-U+001F innerhalb eines JSON-Strings ist verboten. Die meisten Benutzer stoßen darauf, wenn sie einen mehrzeiligen String in einen JSON-Wert einfügen, ohne die Zeilenumbrüche als \n zu escapen.
• NaN und Infinity. Außerhalb der JSON-Grammatik. Das JSON.parse des Browsers lehnt sie ab. JSON.stringify produziert null, wenn aufgefordert, NaN oder Infinity zu serialisieren, sodass der Round-Trip stillschweigend Information verliert.
• Leere Eingabe. Wirft „Unexpected end of JSON input." Der Haken ist, dass eine HTTP-Antwort, die mit Content-Type: application/json aber leerem Body zurückkam, diesen Fehler in fetch().then(r => r.json())-Ketten produziert.

JSON Schema, der Standard für die Validierung der Form

JSON Schema ist ein JSON-basiertes Vokabular zur Beschreibung der Struktur und Einschränkungen von JSON-Dokumenten. Der erste Vorschlag wurde von Kris Zyp im Oktober 2007 eingereicht; die IETF-Internet-Draft-Serie begann mit draft-zyp-json-schema-00 am 5. Dezember 2009. Aufeinanderfolgende Drafts entwickelten sich über ein halbes Dutzend Autoren und Editoren im nächsten anderthalb Jahrzehnt. Die aktuelle stabile Version ist der 2020-12-Draft (der Name „2020-12" bezieht sich auf den Entwicklungs-Snapshot, von dem er abgeleitet wurde; das tatsächliche formelle Release war am 16. Juni 2022). Die vier meistgenutzten Assertion-Schlüsselwörter tragen den Großteil der täglichen Arbeit: type (beschränkt einen Wert auf einen der sechs JSON-Typen oder eine Liste akzeptabler Typen), required (eine Liste von Eigenschaftsnamen, die ein Objekt enthalten muss), properties (eine Karte von Eigenschaftsname auf Sub-Schema für den Wert) und items (ein Schema, das auf jedes Element eines Arrays angewandt wird). In Kombination mit minimum, maximum, minLength, maxLength, pattern (Regex), format (date-time, E-Mail, IPv4 usw.) und den zusammengesetzten Schlüsselwörtern (allOf, anyOf, oneOf, not) kann JSON Schema fast jede „Form"-Einschränkung ausdrücken, die Ihre Daten erfüllen müssen. Das Schema ist selbst ein JSON-Dokument, was auf eine Weise rekursiv ist, die manche elegant und manche schwindelerregend finden.

Ajv, der dominante JavaScript-Schema-Validator

Wenn Sie Schema-Validierung in JavaScript machen wollen, ist die kanonische Antwort Ajv (Another JSON Schema Validator) von Evgeny Poberezkin. Sein Trick besteht darin, das Schema in optimiertes JavaScript zu kompilieren: anstatt das Schema und den Datenbaum zur Laufzeit zu durchlaufen, generiert er eine Funktion, die jede Prüfung fest codiert und mit nativer Geschwindigkeit läuft. Das macht ihn auf großen Dokumenten und heißen Validierungspfaden dramatisch schneller als naive Validatoren. Ajv unterstützt JSON Schema Drafts 04, 06, 07, 2019-09 und 2020-12; er ist der eingebaute Validator in express-validator, der Request-Validierung von AWS API Gateway und vielen großen Node.js-Frameworks. Für Python ist die kanonische Wahl jsonschema von Julian Berman; für Java der json-schema-validator von Networknt. Der Punkt ist, dass Schema-Validierung ein gelöstes, reifes, gut ausgestattetes Problem ist, aber es ist ein Problem, in das man durch das Schreiben des Schemas einsteigen muss. Dieses Tool schreibt das Schema nicht für Sie; es macht nur syntaktische Validierung.

JSON5 und JSONC, die entspannten Übermengen

JSON5 ist eine formelle Übermenge von JSON, spezifiziert auf json5.org, ursprünglich von Aseem Kishore 2012 entworfen und jetzt von Jordan Tucker gewartet. Es erlaubt alles, was striktes JSON verbietet: Kommentare (// und /* */), nachfolgende Kommata, einfach-gequotete Strings, ungequotete Objekt-Schlüssel (wenn sie gültige ECMAScript-Bezeichner sind), hexadezimale Zahlen, führende/nachfolgende Dezimalpunkte (.5 oder 5.), Infinity und NaN sowie vorzeichenbehaftete Zahlen. JSON5-Dokumente verwenden typischerweise die Endung .json5 und werden von Bibliotheken wie dem npm-Paket json5 geparst. JSONC ist Microsofts informeller „JSON with Comments"-Modus, verwendet in VS Codes Einstellungsdateien (settings.json, launch.json, tasks.json). Kommentare sind per Spec erlaubt; nachfolgende Kommata werden vom Referenzparser toleriert, aber mit Warnungen markiert. Die entspannten Formen sind für menschen-bearbeitete Konfigurationsdateien, in denen die Disziplin strikten JSONs stört; für Maschine-zu-Maschine-Datenaustausch ist striktes JSON weiterhin die richtige Wahl. Dieses Tool verwendet das strikte JSON.parse des Browsers und wird daher beide ablehnen, entfernen Sie Kommentare und nachfolgende Kommata vor dem Einfügen oder verwenden Sie einen JSON5/JSONC-Parser, um zuerst in striktes JSON umzuwandeln.

Streaming-Validatoren für sehr große Eingaben

Browser-JSON.parse lädt das gesamte Dokument als einzelnen Objektbaum in den Speicher. Für die meisten Eingaben ist das in Ordnung; für Log-Dateien, mehrere Gigabyte große API-Exporte oder Sensordaten-Dumps nicht. Der Streaming-Ansatz besteht darin, das Dokument als Token-Stream zu konsumieren und Ereignisse („Array-Start", „String-Wert", „Objekt-Schlüssel") auszugeben, ohne die ganze Struktur jemals im Speicher zu halten. clarinet von Marak Squires ist der kanonische Streaming-JSON-Parser für Node.js, dem SAX-XML-Parser-Muster nachempfunden. Oboe.js von Jim Higson (entstanden in seiner Dissertation von 2013) ist das browserfreundliche Äquivalent, entworfen, um JSON über fetch während des Streamings zu konsumieren und Ereignisse für jeden passenden JSONPath auszugeben; es wird nicht mehr aktiv gewartet, aber die von ihm pionierte Technik ist weiterhin nützlich. JSONStream auf npm wickelt clarinet für pipe-freundliche Node-Verwendung ein. Ein reines Browser-Tool wie dieses ist durch den verfügbaren Speicher begrenzt; wenn Sie Gigabyte-großes JSON validieren, führen Sie einen Streaming-Parser in Node aus oder verwenden Sie jq --stream auf der Kommandozeile.

Wo JSON-Validierung in echten Workflows zählt

Konfigurationsdateien sind der Fall mit höchstem Hebel: tsconfig.json, package.json, ESLint- und Prettier-Configs, Docker Compose, AWS IAM Policies. Ein einziges ungültiges Zeichen kann den Build brechen; ein syntaktischer Validator fängt es vor dem Build ab. API-Antworten sind als Nächstes: gegen eine externe API zu entwickeln bedeutet oft, auf einen Payload zu starren und zu fragen „ist das tatsächlich gültiges JSON?", bevor man einen Parsing-Bug tiefer im Code jagt. Webhook-Payloads, Stripe-Events, GitHub-Actions-Trigger, Slack Incoming Webhooks, sind JSON; ein schnelles Einfügen-und-Validieren fängt die Fälle ab, in denen eine fehlerhafte Signatur oder ein verirrtes Byte den Body korrumpiert hat. Log-Einträge (strukturierte Logs von Splunk, Datadog, Loki) sind zeilengetrenntes JSON; eine fehlerhafte Zeile bricht die gesamte Ingest-Pipeline. Generierte JSON-Dateien (Lockfiles, Build-Manifeste, Test-Fixtures) driften manchmal auf laute Weise während normaler Entwicklung; ein Syntax-Validator fängt die Fälle ab, in denen der Generierungsschritt selbst fehlgeschlagen ist.

Die ehrlichen Grenzen eines reinen Syntax-Validators

Ein syntaktischer Validator kann keine Logikfehler erwischen. Er kann Ihnen nicht sagen, dass ein „phone number"-Feld eine Ganzzahl statt einer Zeichenkette enthält; dass eine „date"-Zeichenkette fehlerhaft ist, aber zufällig eine gültige Zeichenkette ist; dass ein erforderliches Feld fehlt; dass eine Zahl, die positiv sein sollte, negativ ist; dass zwei Felder, die übereinstimmen sollten, das nicht tun. All das sind Schema-Validierungsprobleme. Die richtige Pipeline für ein Produktionssystem ist: (1) syntaktische Validierung als erstes Tor, parst das überhaupt als JSON? (2) Schema-Validierung als zweites Tor, hat es die erwartete Form? (3) Geschäftslogik-Validierung als drittes Tor, ergeben die Daten angesichts anderer Zustände Sinn? Werkzeuge existieren für alle drei Schichten; dieses bewältigt nur die erste. Der Vorteil, einen Payload zuerst in einen syntaktischen Validator zu kleben, ist, dass es den günstigsten, häufigsten Fehlermodus (ein verirrtes Komma, eine fehlende Klammer) von den teureren Schema-Fehlern isoliert, die ihn sonst übertönen würden.

Datenschutz: Warum nur-Browser hier zählt

JSON-Validierung auf einem Server erfordert das Hochladen des Dokuments. Für gewöhnliche öffentliche Datenbeispiele ist das harmlos. Für API-Antworten, die Authentifizierungstokens, Kunden-PII, interne Mitarbeiter-Datensätze, Konfigurations-Geheimnisse oder unveröffentlichte Produktdaten enthalten, ist es das nicht. Selbst mit der gewissenhaftesten Löschpolitik sitzt der Upload in Server-Logs, möglicherweise in einem CDN-Cache, möglicherweise in einer Analytics-Pipeline, möglicherweise in einem Backup. Dieses Tool führt JSON.parse in Ihrem Browser per JavaScript aus. Das eingefügte Dokument überquert niemals das Netz, prüfen Sie im Network-Tab der DevTools beim Klick auf einen Button oder schalten Sie die Seite nach dem Laden offline (Flugmodus) und bestätigen Sie, dass der Validator weiterhin funktioniert. Sicher zum Validieren von Webhook-Payloads mit Geheimnissen, API-Antworten mit Auth-Headern, Config-Dateien mit Datenbank-Anmeldedaten oder beliebigen anderen JSONs, die Sie nicht auf der Festplatte eines Fremden kopiert sehen wollen.

Häufig gestellte Fragen

Was ist gültiges JSON?

Gültiges JSON muss einer dieser Typen sein: Objekt ({}), Array ([]), String (""), Zahl, Boolean (true/false) oder null. Alle Strings und Objektschlüssel müssen doppelte Anführungszeichen verwenden. Zahlen dürfen keine führenden Nullen haben. Whitespace zwischen Elementen ist erlaubt.

Was macht „Häufige Probleme beheben"?

Die Fix-Funktion versucht, häufige Fehler automatisch zu korrigieren: nachgestellte Kommas, einfache zu doppelten Anführungszeichen, Schlüssel ohne Anführungszeichen und „undefined"-Werte zu null. Es ist ein Best-Effort-Tool und behebt möglicherweise nicht alle Probleme, überprüfen Sie das Ergebnis sorgfältig.

Wie validiere ich JSON in meiner Anwendung?

In JavaScript: JSON.parse() verwenden und Fehler abfangen. In Node.js: fs.readFileSync() + JSON.parse(). In Python: json.loads() oder json.load(). Die meisten Sprachen haben eingebaute JSON-Validierungs-Bibliotheken.

Kann ich JSON5 oder JSONC (JSON mit Kommentaren) validieren?

Nicht direkt. Dieses Tool verwendet das strikte JSON.parse des Browsers, das RFC 8259 folgt, Kommentare, nachfolgende Kommata, einfache Anführungszeichen und ungequotete Schlüssel sind Syntaxfehler. Wenn Ihre Eingabe JSON5 (json5.org, Aseem Kishore 2012, gewartet von Jordan Tucker) oder VS Codes JSONC ist, installieren Sie das npm-Paket json5 oder das Paket jsonc-parser, konvertieren Sie in striktes JSON und validieren Sie dann. Der „Häufige Probleme beheben"-Durchgang behandelt eine Untermenge der Unterschiede, ist aber kein vollständiger JSON5- / JSONC-Parser.

Gibt es eine Größenbeschränkung?

Keine harte Grenze, aber das JSON.parse des Browsers lädt das gesamte Dokument als einzelnen Objektbaum in den Speicher. Zehntausende Zeilen funktionieren bequem; mehrere Gigabyte große Log-Dumps werden den Speicher erschöpfen. Für sehr großes JSON führen Sie einen Streaming-Parser wie clarinet (Marak Squires) oder Oboe.js (Jim Higson, 2013) aus oder verwenden Sie jq --stream auf der Kommandozeile, das Dokumente beliebiger Größe verarbeiten kann, ohne jemals den ganzen Inhalt zu laden.

Werden meine JSON-Dokumente hochgeladen?

Nein. JSON.parse läuft in Ihrem Browser per JavaScript. Das eingefügte Dokument überquert niemals das Netz, prüfen Sie im Network-Tab der DevTools beim Klick auf Validate oder schalten Sie die Seite nach dem Laden offline und bestätigen Sie, dass das Tool weiterhin funktioniert. Sicher zum Validieren von Webhook-Payloads mit Geheimnissen, API-Antworten mit Auth-Headern oder Config-Dateien mit Datenbank-Anmeldedaten.