Warum ist ein doppelter Schlüssel hier eine Warnung und im Formatierer ein Fehler?

Weil die beiden Werkzeuge verschiedene Aufgaben haben. RFC 8259 sagt, Namen *sollten* eindeutig sein — ein SHOULD —, ein Dokument mit einer Wiederholung ist also weiterhin gültiges JSON, und die Aufgabe eines Validators ist zu beschreiben, was er sieht. Ein Formatierer muss eine Ausgabe erzeugen, also entscheiden, welcher Wert überlebt, und diese Entscheidung steht ihm nicht zu.

Ist 42 gültiges JSON?

Ja. Seit RFC 7159 ist jeder JSON-Wert ein vollständiges Dokument: eine Zahl, eine Zeichenkette, `true`, `null`. Das ältere RFC 4627 verlangte oben ein Objekt oder ein Array, weshalb manche alten Parser `42` noch ablehnen — gut zu wissen an dem Tag, an dem ein Validator ja und Ihre Bibliothek nein sagt.

Es sagt gültig, aber mein Programm lehnt die Datei ab. Warum?

Weil gültig heißt, dass die Syntax parst, nicht dass der Inhalt der erwartete ist. Ein fehlendes Pflichtfeld, eine Zahl, wo eine Zeichenkette deklariert war, ein Datum im falschen Format — nichts davon ist Syntax. Das zu prüfen braucht ein Schema, also ein anderes Werkzeug und eine andere Frage.

JSON-Validator — Zeile und Spalte zum Beheben

Prüfen, ob JSON parst — mit Zeile und Spalte, wenn nicht. Sie gehen direkt zu dem Zeichen, das es zerbrochen hat, statt danach zu suchen.

Sofort Privat Null Cookies

JSON-Eingabe

Result-Ausgabe

Was der Bericht sagt

Für ein Dokument, das parst: die Form des Wurzelwerts und die Größe.

✓ Valid JSON

Root: object (4 keys)
Size: 312 characters, 18 lines

Sonst: die Meldung des Parsers, mit der Position übersetzt in Zeile und Spalte — einmal, nicht zweimal.

Jeder JSON-Wert ist ein Dokument

42 ist gültiges JSON. "hallo" auch, true auch, null auch.

Das gilt seit RFC 7159 (2014); das ursprüngliche RFC 4627 verlangte auf oberster Ebene ein Objekt oder ein Array. Manche älteren Parser setzen die alte Regel noch durch — daran zu denken lohnt an dem Tag, an dem ein Validator ja und Ihre Bibliothek nein sagt.

Doppelte Schlüssel: eine Warnung, kein Fehler

{ "port": 8080, "port": 3000 }

Der Bericht erklärt das Dokument für gültig und fügt einen Hinweis mit der Position des zweiten port an.

Das ist ein bewusster Unterschied zum JSON-Formatierer, der dieselbe Eingabe ablehnt. RFC 8259 sagt, Objektnamen sollten eindeutig sein — ein SHOULD, kein MUST —, das Dokument ist also wirklich gültig, und ein Validator beschreibt, was er sieht.

Ein Formatierer muss etwas erzeugen, und erzeugen heißt entscheiden, welcher der beiden Werte überlebt. Parser entscheiden unterschiedlich: die meisten behalten den letzten, manche den ersten, manche lehnen ab. Diese Entscheidung gehört Ihnen, nicht einem Werkzeug: der Formatierer hält an, der Validator warnt.

Was „gültig“ nicht heißt

Es heißt nicht, dass die Datei sagt, was Sie glauben.

Ein fehlendes Pflichtfeld, eine Zeichenkette, wo eine Zahl hingehört, ein Datum in amerikanischer Schreibweise, eine URL mit einem Tippfehler — all das parst einwandfrei. Das zu prüfen braucht ein Schema — JSON Schema und einen Validator, der es liest —, also eine andere Frage als die, die diese Seite beantwortet.

Datenschutz ab Werk

Alles läuft lokal in deinem Browser mit JavaScript. Deine Daten werden nie hochgeladen, wodurch das Tool auch für sensible Inhalte sicher ist und offline funktioniert.

Häufige Fragen

Warum ist ein doppelter Schlüssel hier eine Warnung und im Formatierer ein Fehler?: Weil die beiden Werkzeuge verschiedene Aufgaben haben. RFC 8259 sagt, Namen *sollten* eindeutig sein — ein SHOULD —, ein Dokument mit einer Wiederholung ist also weiterhin gültiges JSON, und die Aufgabe eines Validators ist zu beschreiben, was er sieht. Ein Formatierer muss eine Ausgabe erzeugen, also entscheiden, welcher Wert überlebt, und diese Entscheidung steht ihm nicht zu.
Ist 42 gültiges JSON?: Ja. Seit RFC 7159 ist jeder JSON-Wert ein vollständiges Dokument: eine Zahl, eine Zeichenkette, `true`, `null`. Das ältere RFC 4627 verlangte oben ein Objekt oder ein Array, weshalb manche alten Parser `42` noch ablehnen — gut zu wissen an dem Tag, an dem ein Validator ja und Ihre Bibliothek nein sagt.
Es sagt gültig, aber mein Programm lehnt die Datei ab. Warum?: Weil gültig heißt, dass die Syntax parst, nicht dass der Inhalt der erwartete ist. Ein fehlendes Pflichtfeld, eine Zahl, wo eine Zeichenkette deklariert war, ein Datum im falschen Format — nichts davon ist Syntax. Das zu prüfen braucht ein Schema, also ein anderes Werkzeug und eine andere Frage.