JSON Validator

Zu den häufigsten JSON-Syntaxfehlern gehören: nachgestellte Kommas (das letzte Komma vor ] oder }, das in striktem JSON nicht zulässig ist), fehlende Kommas zwischen Array-Elementen oder Objekteigenschaften (das Kommatrennzeichen wird vergessen), Eigenschaftsnamen ohne oder mit einfachen Anführungszeichen (JSON erfordert doppelte Anführungszeichen für alle Schlüssel), nicht geschlossene Zeichenfolgenliterale (das abschließende Anführungszeichen fehlt häufig aufgrund von Sonderzeichen), ungültige Escape-Sequenzen (\q, \x ohne Hexadezimalziffern usw.), fehlende oder nicht übereinstimmende Klammern und geschweifte Klammern (strukturelle Nichtübereinstimmung zwischen [/{ und ]/}) und unerwartete Token (wie JavaScript undefined, NaN oder Funktionsaufrufe, die kein gültiges JSON sind). Der Validator lokalisiert jeden Fehler mit exakter Zeile und Spalte, erklärt, was schief gelaufen ist, und bietet für viele häufige Fehler eine automatische Korrektur an, die Sie mit einem Klick anwenden können.

Der strikte Modus erzwingt die exakte Einhaltung von RFC 8259: Nur Zeichenfolgen in doppelten Anführungszeichen, Eigenschaftsnamen müssen in doppelten Anführungszeichen stehen, keine Kommentare sind zulässig, keine abschließenden Kommas, kein abschließender Inhalt nach dem Stammwert und nur null ist zulässig (nicht undefiniert oder NaN). Dies ist der Modus, der bei der Validierung von JSON für APIs, Datenbanken und Produktionssysteme verwendet wird, die absolute Standardkonformität erfordern. Der milde Modus (JSON5-kompatibel) erlaubt: Kommentare (sowohl // einzeilig als auch /* * / mehrzeilig), nachgestellte Kommas in Arrays und Objekten, Schlüssel ohne Anführungszeichen (falls gültige JavaScript-Bezeichner), Zeichenfolgen in einfachen Anführungszeichen, mehrzeilige Zeichenfolgen, führende oder nachgestellte Dezimalstellen in Zahlen und zusätzliche Zahlenformate (hexadezimal, positive Unendlichkeit). Verwenden Sie den nachsichtigen Modus für Konfigurationsdateien (TypeScript tsconfig.b. json-, ESLint-, VS-Code-Einstellungen) und Situationen, in denen Menschen JSON von Hand schreiben und von einer entspannten Syntax profitieren.

Der Validator behandelt alle UTF-8 / Unicode-Zeichen und codiert sie in der Fehlerberichterstattung entsprechend. Häufige Szenarien sind: Escapezeichen in Zeichenfolgen (\n, \t, \\, \", \/ und \uXXXX Unicode-Escapezeichen müssen gültig sein), literale Unicode-Zeichen (Chinesisch, Japanisch, Arabisch, Emoji sind in JSON-Zeichenfolgen ohne Escapezeichen gültig), BOM-Zeichen (Byte Order Mark) am Anfang von Dateien unterbrechen häufig die Analyse (der Validator erkennt und meldet das Vorhandensein von Stücklisten) und ungültige UTF-8-Byte-Sequenzen (der Validator fängt diese ab, bevor die JSON-Analyse beginnt). Bei der Fehlerberichterstattung normalisiert das Tool die Fehlerposition, um Multibyte-Zeichen zu berücksichtigen, sodass die Spaltennummern auch bei Inhalten mit gemischter Sprache korrekt sind. Bei der Behebung von Fehlern maskiert der Validator alle Zeichen, die in JSON-Zeichenfolgen maskiert werden müssen, ordnungsgemäß.

Ja, die JSON-Validierung sollte Teil jedes Entwicklungsworkflows sein. Verwenden Sie für CI / CD-Pipelines Befehlszeilenvalidatoren wie ajv-cli für Python jsonschema oder eslint-plugin-json für Pre-Commit-Hooks, die JSON-Dateien vor dem Commit validieren. Für unseren Online-Validator können Sie ihn als schnelle manuelle Überprüfung verwenden. Betten Sie für die programmgesteuerte Verwendung die JSON-Validierung mit schnellen JSON-Parsing-Bibliotheken (JSON.analysieren Sie in JavaScript, json.Marschall in Go, json.lädt in Python), die bei ungültigen Eingaben eindeutige Fehler auslösen. Verwenden Sie in Code-Editoren die JSON-Sprachunterstützung (VS Code verfügt über eine integrierte JSON-Validierung mit JSON-Schema-Unterstützung), die Echtzeit-Fehlerhervorhebung und IntelliSense bietet. Erzwingen Sie für die API-Entwicklung die JSON-Validierung auf Gateway-Ebene: API-Frameworks wie Express.js, FastAPI und Spring Boot können eingehende JSON-Dateien anhand von Schemata validieren, bevor Sie Ihre Geschäftslogik erreichen.

Wenn die Validierung erfolgreich ist, Ihre Anwendung den JSON jedoch immer noch nicht korrekt verwendet, geht das Problem wahrscheinlich über die Syntax hinaus: Typinkongruenzen (der JSON ist gültig, aber Ihr Code erwartet eine Zahl, in der eine Zeichenfolge angegeben ist), Schemaverletzungen (der JSON ist syntaktisch gültig, stimmt jedoch nicht überein Die erwartete Struktur, wie fehlende Pflichtfelder oder falsche Verschachtelung), Codierungsprobleme (die Datei wird möglicherweise korrekt analysiert, aber die Anwendung empfängt sie mit einer falschen Codierungsspezifikation), Größenbeschränkungen (sehr große JSON-Dateien können HTTP-Body-Größenbeschränkungen oder Datenbankfeldgrößen überschreiten), semantische Fehler (gültiger JSON, aber ungültige Daten wie ein E-Mail-Feld, das kein an enthält), semantische Fehler (gültiger JSON, aber ungültige Daten wie ein E-Mail-Feld, das kein an enthält) -e-Mail) und Versionsinkongruenzen (die JSON-Struktur hat sich geändert, aber Ihr Code erwartet das alte Schema). So debuggen Sie diese Probleme: Überprüfen Sie anhand eines JSON-Schemas (nicht nur der Syntax), überprüfen Sie beim Senden über HTTP, ob der Inhaltstyp-Header application / json lautet, stellen Sie sicher, dass die Feldtypen mit den Erwartungen Ihres Codes übereinstimmen, und testen Sie mit dem genauen JSON Ihre Anwendung erhält (keine neu formatierte Version).