Schema und Nutzdaten prüfen

JSON Schema ValidatorVom betroffenen Wert zur verletzten Regel

Starten Sie mit dem Beispiel. Die reine Schemaprüfung benötigt keine Nutzdaten; die Datenprüfung verarbeitet beide Eingaben.

JSON Schema Validator

JSON Schema

JSON-Daten

Eingaben und Referenzen werden in diesem Browser verarbeitet; keine Prüfdaten werden hochgeladen oder entfernte Referenzen geladen.

Prüfoptionen

Aus: format bleibt eine Anmerkung. Ein: ajv-formats prüft bekannte Formate; unbekannte führen zum Kompilierungsfehler.

Lokale Referenzen

Bis zu zehn JSON-Dateien, jeweils mit eindeutiger absoluter $id ohne # an der Wurzel. Dateinamen lösen keine Referenzen auf.

Keine Referenzdateien.

    Bereit für die manuelle Prüfung.

    Ein JSON Schema Validator erkennt Zeichenketten statt erwarteter Ganzzahlen, fehlende Pflichtfelder und unerwartete Eigenschaften. Korrekte JSON-Syntax allein erfüllt keinen API-Vertrag. Vergleichen Sie die aufgezeichnete Antwort direkt mit den Regeln, bevor Sie die Ursache im Anwendungscode suchen.

    JSON Schema validieren bedeutet hier, die vorhandenen Werte zu prüfen. Ein fehlender Schlüssel ist etwas anderes als null. Auch ein default ergänzt keine Daten, und eine Zahl in Anführungszeichen bleibt eine Zeichenkette.

    Warum dieser JSON Schema Validator?

    Die richtige Regel zum Wert finden

    Der JSON Schema Validator zeigt Datenpfad und Schemapfad zusammen. /users/0/age führt zum betroffenen Wert; bei required kann der Pfad auf das übergeordnete Objekt zeigen. Die Parameter nennen dann die fehlende Eigenschaft.

    Ein markierter Datenknoten ist mit der zugehörigen Bedingung in einem zweiten Baum verbunden.

    Gemeinsame Definitionen getrennt halten

    Importieren Sie Abhängigkeiten, ohne sie in das Hauptschema einzufügen. Die absolute $id registriert jede Datei. Relative Verweise werden gegen die Basis-URI aufgelöst; der Dateiname dient ausschließlich der Anzeige.

    Ein Hauptschema verbindet zwei lokale Referenzdateien mit einem gemeinsamen Prüfergebnis.

    Den Prüfkontext vorbereiten

    01

    Den deklarierten Dialekt wählen

    Voreingestellt ist 2020-12. Eine widersprechende $schema-Deklaration führt zum Fehler. Tupel verwenden in Draft-07 ein items-Array, in 2020-12 prefixItems. Der Wechsel im Menü migriert keine bestehenden Regeln.

    02

    Zuerst nur das Schema prüfen

    Die Schemaprüfung liest, prüft und kompiliert das Hauptschema sowie alle importierten Abhängigkeiten, ohne die Daten auszuwerten. Jede Referenzdatei benötigt eine eindeutige absolute $id ohne Fragment. Ein fehlender Verweis stoppt die Kompilierung.

    03

    Nach Änderungen neu ausführen

    Ctrl/Cmd+Enter startet die manuelle Prüfung. Änderungen an Eingaben, Optionen oder Dateien beenden alte Aufgaben und sperren den Export. Beispielwechsel, Leeren und Entfernen einer Referenz zeigen zunächst eine Vorschau. Nach Anwenden stellt Rückgängig den vorherigen Zustand wieder her.

    Was der Prüflauf unterscheidet

    Drei ausdrücklich gewählte Dialekte

    Dieser JSON Schema Validator verwendet Ajv für draft-07, 2019-09 und 2020-12. Bedingungen und Kombinationen folgen dem gewählten Dialekt. Unbekannte Schlüsselwörter stoppen die Kompilierung, statt unbemerkt wirkungslose Regeln zu erzeugen.

    Formate bewusst aktivieren

    Bei der JSON-Schema-Validierung ist format zunächst deaktiviert. Mit aktiviertem Schalter prüft ajv-formats unter anderem email, date-time, URI und UUID. Unbekannte Formate scheitern dann bereits beim Kompilieren. pattern wird unabhängig davon geprüft.

    Schemafehler und Datenverstöße trennen

    Wenn Sie JSON Schema online prüfen, bleiben Syntaxfehler, fehlerhafte Regeln, unaufgelöste Verweise und Datenverstöße unterscheidbar. Nur abgeschlossene Berichte lassen sich exportieren. Die Oberfläche ist lokalisiert; technische Meldungen der Engine bleiben im englischen Original.

    Berichte mit nachvollziehbaren Pfaden

    Die Prüfung bricht möglichst früh ab; zusammengesetzte Regeln können trotzdem mehrere Zweigfehler liefern. Lesen Sie instancePath, schemaPath, keyword und Parameter gemeinsam. Die Liste zeigt jeweils 50 Einträge, der Download den vollständigen akzeptierten Bericht.

    Grenzen des Prüfprofils

    Keine Downloads über Referenzadressen
    Aufgelöst werden interne Verweise und importierte Schemas. HTTP-Ziele werden nicht geladen. Referenzdateien brauchen eine absolute $id ohne # am Wurzelobjekt; doppelte IDs schlagen fehl. Dateinamen ersetzen keine Kennung.
    Keine Reparatur der Nutzdaten
    Typumwandlung, default-Ergänzung und Entfernen zusätzlicher Eigenschaften sind ausgeschaltet. Alle Dokumente müssen striktes JSON sein. Kommentare, abschließende Kommas, JSON5 und doppelte Schlüssel werden abgewiesen, bevor überschriebene Werte das Ergebnis verfälschen.
    Keine beliebigen Erweiterungen
    Nur die drei genannten Drafts sind verfügbar. Eigene Metaschemas, $vocabulary, $async, $data und unbekannte Schlüsselwörter werden nicht unterstützt. Verwenden Sie ein kompatibles Schemafragment; ein vollständiges OpenAPI-Dokument gehört nicht in dieses Prüfprofil. Ajv strictSchema kann auch ignorierte Regeln wie then ohne if zurückweisen. Exakte __proto__-Schlüssel in properties, patternProperties oder dependencies werden wegen einer Engine-Grenze abgewiesen; gleichnamige Schlüssel in Nutzdaten sind davon nicht betroffen.
    Keine beliebige Zahlengenauigkeit
    Nichtendliche Zahlen, mathematische Ganzzahlen außerhalb des sicheren Bereichs und Dezimalwerte mit verändertem Number-Rundlauf werden abgewiesen. 1.0 und 1e0 sind zulässig. Normale Dezimalzahlen nutzen weiterhin IEEE 754, weshalb multipleOf an Gleitkommagrenzen scheitern kann.
    Begrenzte Dokumente und Laufzeit
    Je Dokument gelten 500.000 Zeichen, 50.000 Knoten und Tiefe 40. Insgesamt sind 1.000.000 Zeichen und zehn Referenzdateien erlaubt. Nach fünf Sekunden wird der Worker beendet. Ein Zeitlimit bedeutet unvollständig, niemals gültig oder ungültig.
    Kein vollständiges Fehlerinventar
    allErrors ist deaktiviert. Beheben Sie den gemeldeten Verstoß und prüfen Sie erneut. Der Bericht darf höchstens 1.000 Fehler und 500.000 Zeichen enthalten; eine Überschreitung verwirft den gesamten Bericht. Ein erfolgreicher Beispieldatensatz beweist keine allgemeine Vertragstreue.

    Fragen zum JSON Schema Validator

    Welche Draft-Versionen kann ich prüfen?

    Sie können draft-07, 2019-09 und 2020-12 wählen. Die Voreinstellung ist 2020-12. Eine vorhandene $schema-Deklaration muss zur Auswahl passen; ältere oder eigene Dialekte werden nicht stillschweigend als kompatibel behandelt.

    Wie unterscheidet sich die Schemaprüfung von der Syntaxprüfung?

    Die Syntaxprüfung fragt, ob sich der Text als JSON lesen lässt. Erst danach wird geprüft, ob Werte die Typen, Pflichtfelder und weiteren Bedingungen des Schemas erfüllen. Eine syntaktisch gültige Zeichenkette kann deshalb an einer Ganzzahlregel scheitern.

    Welche Informationen enthält ein Fehlerbericht?

    Datenverstöße enthalten den Instanzpfad, den Schemapfad, das auslösende Schlüsselwort und Zusatzparameter. Die Engine-Meldung bleibt auf Englisch. Syntaxfehler werden nach Dokument und nach Möglichkeit mit Zeile und Spalte gekennzeichnet.

    Welche Dateigröße ist zulässig?

    Je Dokument gelten 500.000 Zeichen, 50.000 Knoten und Tiefe 40, zusammen 1.000.000 Zeichen. Bis zu zehn Referenzdateien sind möglich. Das sind Zeichen- und Strukturgrenzen, kein pauschales Megabyte-Versprechen; zusätzlich gilt das Zeitlimit.

    Was sagt der Fehlerpfad über die betroffene Stelle aus?

    Ein JSON Pointer wie /items/0/name zeigt die Eigenschaft name des ersten Arrayelements. Die leere Zeichenkette bezeichnet die Wurzel; / bezeichnet dagegen einen leeren Schlüsselnamen. Bei required nennt ein Parameter die fehlende Eigenschaft am Elternobjekt.

    Ein Schemafall braucht eine zweite Prüfung?

    Auch Gegenbeispiele prüfen

    Nutzen Sie den JSON Schema Validator mit erlaubten und abgelehnten Datensätzen. Halten Sie Dialekt und Formateinstellung beim Bericht fest, um Unterschiede zwischen Umgebungen zu erklären.