JSON-Syntax-Spickzettel

Die sechs strukturellen Zeichen

Sechs Satzzeichen tragen die gesamte Struktur in JSON: die geschweiften Klammern { }, die Objekte umschließen, die eckigen Klammern [ ], die Arrays umschließen, der Doppelpunkt :, der einen Schlüssel von seinem Wert trennt, und das Komma , das Paare innerhalb eines Objekts oder Werte innerhalb eines Arrays trennt. Nichts anderes in der Grammatik leistet strukturelle Arbeit – jedes andere Zeichen in einem Dokument steckt entweder in einem String oder ist eines der vier Whitespace-Zeichen. Ein Komma ist strikt ein Trennzeichen: Es darf zwischen zwei Elementen stehen, nie vor einer schließenden Klammer.

{"name":"Ada","tags":["math","pioneer"]}

{"name":"Ada","tags":["math","pioneer"],}

Whitespace: genau vier Zeichen

Außerhalb von Strings erlaubt JSON genau vier Whitespace-Zeichen: das Leerzeichen (U+0020), den horizontalen Tabulator (U+0009), den Line Feed (U+000A) und den Carriage Return (U+000D). Alles andere – vertikaler Tab, Form Feed, geschütztes Leerzeichen, ein Byte-Order-Mark – ist ein Syntaxfehler, auch wenn viele Editoren diese Zeichen unsichtbar darstellen. Deshalb scheitert aus einer Textverarbeitung eingefügtes JSON so oft an der Validierung: Das Dokument sieht auf dem Bildschirm sauber aus und enthält Zeichen, von denen die Grammatik nie gehört hat.

Whitespace ist auch das, was Formatieren überhaupt möglich macht. Weil die Grammatik diese vier Zeichen zwischen Tokens ignoriert, kann dasselbe Dokument auf der Leitung eine lange Zeile sein und in Ihrem Editor ein eingerückter Baum; beide Formen sind semantisch identisch – kein Parser kann sie nach dem Lesen unterscheiden.

{"a":1,"b":[2,3]}

{
  "a": 1,
  "b": [
    2,
    3
  ]
}

Strings: doppelte Anführungszeichen und die neun Escapes

Ein JSON-String steht in doppelten Anführungszeichen – niemals in einfachen. Innen leitet der Backslash \ ein Escape ein, und RFC 8259 definiert genau neun zweizeichige Escapes: Zwei sind obligatorisch, \\" für ein literales doppeltes Anführungszeichen und \\\\ für einen literalen Backslash, weil diese beiden Zeichen den String sonst beenden oder beschädigen würden. Sechs weitere sind optionale Kurzformen – \/ für den Schrägstrich und \b \f \n \r \t für die fünf Steuerzeichen, die in Text am häufigsten vorkommen. Die neunte Form ist \uXXXX, die jeden Unicode-Codepunkt über seine vierstellige Hexadezimalzahl schreibt.

Jedes Zeichen außerhalb des Escape-Sets darf literal als UTF-8 erscheinen, und beide Formen sind gleichwertig: Ein Parser liefert in beiden Fällen denselben String. Escaping ist Schreibweise, keine Daten – ein Punkt, den der Escaping-Leitfaden in die Tiefe führt.

"quote": "she said \"hi\""
"path": "C:\\Users\\ada"
"e-acute": "\u00e9"

quote:   she said "hi"
path:    C:\Users\ada
e-acute: é

Zahlen: ECMAScript ohne die Erweiterungen

Eine Zahl ist ein Integer oder Dezimalwert in gewöhnlicher Notation, mit optionalem Exponenten. RFC 8259 übernimmt die ECMAScript-Zahlengrammatik und streicht ihre Erweiterungen: kein Hexadezimal, kein Oktal, keine führenden Nullen, kein führendes Plus, kein nackter abschließender Punkt. Ein Exponent verwendet e oder E mit optionalem Vorzeichen, und das einzige Vorzeichen, mit dem eine Zahl beginnen darf, ist der schlichte Bindestrich. NaN, Infinity und -Infinity sind kein JSON – Sprachen mit solchen Konstanten schreiben stattdessen null, so die Konvention.

Die Präzision bleibt bewusst den Implementierungen überlassen: Die Grammatik sagt nichts darüber, wie viele Ziffern ein Parser berücksichtigen muss, sodass sehr lange Zahlen stillschweigend verändert ankommen können. Interoperable Erzeuger halten Integers innerhalb des Bereichs, den die Zielplattform exakt darstellt – bei den IEEE-754-Doubles hinter JavaScript sind das bis zu 2^53 − 1.

Die drei Literale und die fünf klassischen Zurückweisungen

Drei nackte Tokens vervollständigen die Wertmenge: true, false und null. Sie sind klein geschrieben und ohne Anführungszeichen – True, FALSE und None sind Syntaxfehler, keine kreative Großschreibung. Um sie herum zieht die Grammatik fünf Linien, die fast jedes in der Wildnis zurückgewiesene Dokument erklären:

• Keine Kommentare. RFC 8259 kennt keine Kommentarsyntax; // oder /* */ an jeder Stelle ist ein Syntaxfehler. Kommentieren Sie, wo das Format in Ihrer Hand liegt, mit einem Geschwister-Schlüssel wie "_comment".
• Keine nachgestellten Kommas. [1, 2, 3,] und {"a":1,} sind ungültig, so freundlich sie auch aussehen – das Komma ist ein Trennzeichen, und es kann kein Element von nichts trennen.
• Keine einfachen Anführungszeichen und keine Schlüssel ohne Anführungszeichen. {name:'ada'} ist ungültiges JSON; {"name":"ada"} ist die einzige Schreibweise der Grammatik.
• Keine doppelten Schlüssel – zumindest offiziell. Die Grammatik erlaubt, dass ein Name zweimal auftaucht, aber RFC 8259 §4 überlässt es den Implementierungen, welcher Wert gewinnt; ein Dokument, das sich auf Duplikate verlässt, hat also keine definierte Bedeutung.
• Jeder Wert auf oberster Ebene. Seit RFC 8259 darf ein ganzes Dokument ein nackter String, eine Zahl, ein Boolean oder null sein – die Nur-Objekte-und-Arrays-Regel von RFC 4627 ist gestrichen, und "hello" oder 42 sind vollwertige JSON-Dokumente.

Kodierung: UTF-8 und die Regeln auf Byte-Ebene

RFC 8259 §8.1 legt die Byte-Kodierung fest: JSON-Text, der zwischen Systemen ausgetauscht wird, die nicht Teil eines geschlossenen Ökosystems sind, muss in UTF-8 kodiert sein. UTF-16- oder UTF-32-JSON gibt es auf offener Leitung nicht, und Erzeuger dürfen kein Byte-Order-Mark voranstellen – ein Parser darf ein führendes BOM ignorieren, statt einen Fehler zu werfen, aber nichts Konformes gibt eines aus. Beachten Sie, wie sich die Ebenen trennen: \uXXXX-Escaping ist eine Notationswahl innerhalb einzelner Strings, während UTF-8 eine Eigenschaft des ganzen Dokuments ist; beide lösen unterschiedliche Probleme.

Damit ist die Grammatik abgeschlossen. Am schnellsten werden diese Regeln bleibend, wenn Sie eigene Dokumente dagegen laufen lassen – formatieren Sie eine echte Nutzlast, brechen Sie jedes Mal genau eine Regel, und lesen Sie jeden Validator-Fehler. Zehn Minuten absichtlichen Scheiterns lehren mehr als ein weiterer Durchgang durch diese Seite.