JSON

Grundidee und Einsatz

JSON (JavaScript Object Notation) ist ein kompaktes Datenformat in gut lesbarer Textform. Es dient dem Datenaustausch zwischen Anwendungen und ist unabhängig von Programmiersprachen. Parser, also Programme zum Einlesen, und Generatoren, also Programme zum Erzeugen von JSON, gibt es in den meisten verbreiteten Programmiersprachen. Die übliche Dateiendung ist .json, der MIME-Type ist application/json. JSON ist durch RFC 8259 und ECMA-404 standardisiert; diese Standards sind inhaltlich gleich.

JSON wird verwendet, um strukturierte Daten zu speichern oder zu übertragen. Besonders häufig ist es bei Webanwendungen und mobilen Apps, zum Beispiel zusammen mit JavaScript, Ajax oder WebSockets, wenn Daten zwischen Client und Server übertragen werden. Diese Übertragung strukturierter Daten in ein speicher- oder übertragbares Format heißt Serialisierung.

Aufbau und Datentypen

JSON-Daten können beliebig verschachtelt werden. Ein Array kann zum Beispiel Objekte enthalten, und diese Objekte können wiederum Arrays oder weitere Objekte enthalten. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8; UTF-16 und UTF-32 sind ebenfalls möglich.

JSON kennt mehrere Elementtypen: Der Nullwert wird mit null geschrieben. Boolesche Werte, also Wahrheitswerte, werden mit true und false dargestellt; sie sind keine Zeichenketten und stehen deshalb nicht in Anführungszeichen. Zahlen bestehen aus Ziffern 0–9, können ein negatives Vorzeichen -, einen Dezimalpunkt . und einen Exponenten e oder E enthalten; beim Exponenten kann zusätzlich ein Vorzeichen + oder - folgen.

Eine Zeichenkette beginnt und endet mit doppelten geraden Anführungszeichen ("). Sie kann Unicode-Zeichen und Escape-Sequenzen enthalten, die mit \ eingeleitet werden. Ein Array beginnt mit [ und endet mit ]; es enthält eine durch Kommata getrennte, indizierte Liste von Elementen gleichen oder verschiedenen Typs. Leere Arrays sind erlaubt.

Ein Objekt beginnt mit { und endet mit }. Es enthält eine durch Kommata getrennte, ungeordnete Liste von Eigenschaften. Auch leere Objekte sind erlaubt. Eine Eigenschaft besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt: Schlüssel : Wert. Der Schlüssel ist eine Zeichenkette, der Wert kann ein beliebiges JSON-Element sein. Schlüssel sollten eindeutig sein, weil Parser mit mehrfach vorkommenden Schlüsseln unterschiedlich umgehen. ECMA-404 setzt keine Eindeutigkeit voraus, RFC 7159 fordert jedoch, dass Schlüssel innerhalb eines Objekts eindeutig sind.

Leerraum außerhalb von Zeichenketten ist nicht bedeutend und wird beim Interpretieren ignoriert. Erlaubt sind Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009) sowie Zeilenumbrüche mit LF und/oder CR (U+000A bzw. U+000D).

Grenzen des Formats

JSON ist bewusst einfach gehalten und bildet nicht alle Datentypen ab, die in Programmiersprachen vorkommen. Für Zahlen erlaubt JSON nicht die in IEEE 754 definierten Sonderwerte für Unendlich und NaN. Außerdem gibt es keine eigenen Wertetypen für Datums- und Zeitwerte, reguläre Ausdrücke, Funktionsliterale oder Fehlertypen.

Wenn solche Werte in JSON serialisiert werden sollen, müssen sie ersetzt oder anders dargestellt werden. Nicht abbildbare Werte können zum Beispiel durch null ersetzt werden. Bei Datums- und Zeitwerten ist es üblich, sie als Zeichenkette nach ISO 8601 zu speichern.

JSON unterstützt keine Kommentare, die beim Einlesen ignoriert würden. Viele JSON-Programmbibliotheken erlauben optional Abweichungen vom Standard, um diese Einschränkungen zu umgehen. Sie können dann zum Beispiel Unendlich und NaN akzeptieren oder Kommentare ignorieren, statt einen Fehler zu melden. Solche Erweiterungen gehören aber nicht zum eigentlichen JSON-Standard.

Beispiel und Schema

Ein typisches JSON-Beispiel kann die Daten einer Kreditkarte und ihres Inhabers speichern. Darin stehen einfache Eigenschaften wie "Herausgeber": "Xema", "Nummer": "1234-5678-9012-3456", "Deckung": 2e+6 und "Waehrung": "EURO". Der Inhaber ist als verschachteltes Objekt dargestellt und enthält unter anderem "Name": "Mustermann", "Vorname": "Max", den booleschen Wert "Teilnahme am Bonusprogramm": true, das Array "Hobbys": ["Reiten", "Golfen", "Lesen"], die Zahl "Alter": 42, ein leeres Array "Kinder": [] und den Nullwert "Partner": null.

JSON Schema ist ein JSON-basiertes Format, mit dem die Struktur von JSON-Daten beschrieben werden kann. Es dient der Validierung, Dokumentation und Interaktionssteuerung. Validierung bedeutet, zu prüfen, ob Daten die geforderte Form haben. Ein JSON Schema enthält einen Vertrag darüber, welche JSON-Daten eine bestimmte Anwendung braucht und wie diese Daten geändert werden können.

JSON Schema basiert auf Konzepten von XML Schema (XSD), ist aber selbst JSON-basiert. Dieselben Serialisierungs- und Deserialisierungsprogramme können sowohl für das Schema als auch für die Daten verwendet werden. JSON Schema ist selbstbeschreibend und in einem Internet-Entwurf der Internet Engineering Task Force festgelegt. Für verschiedene Programmiersprachen gibt es Validatoren mit unterschiedlichen Konformitätsstufen. Im Artikel zeigt ein Schema für einen "Politiker" zum Beispiel ein Objekt mit Pflichtfeldern wie "Vorname", "Nachname", "Geburtsdatum" und "Nationalität" und kann anschließend prüfen, ob ein Datenblock zu Ronald Reagan diese Struktur erfüllt.

Vergleich mit XML und JSONP

JSON und XML können beide die Struktur eines Datensatzes beschreiben. Datensätze können weitere Datensätze enthalten, sodass beliebig tief verschachtelte Strukturen möglich sind. In XML sind die einzelnen Knoten der Datenstruktur benannt, während Knoten in JSON unbenannt sind. XML kann einfache Zeichenketten sowohl als Attribut eines Elements als auch als eigenes Element darstellen; JSON macht diese Unterscheidung nicht. Dadurch kann XML flexibler sein, aber diese Flexibilität führt häufig zu unnötig unterschiedlichen Dokumentstrukturen.

Für JSON und XML gibt es Beschreibungssprachen, die festlegen können, wie gültige Dokumente aussehen. Die Syntax von JSON ist einfacher gestaltet und wirkt deshalb oft lesbarer und leichter schreibbar. In der Regel erzeugt JSON auch weniger Overhead als XML. Im Vergleichsbeispiel des Artikels ist das JSON-Objekt nach Entfernung optionaler Leerzeichen 226 Byte groß. Eine XML-Variante ist 279 Byte groß, also 23 % größer. Eine andere XML-Form mit Kindknoten statt Attributen ist 361 Byte groß, also 60 % größer als das JSON-Objekt.

Sowohl JSON als auch XML müssen mit einem speziellen Parser eingelesen werden. Obwohl jedes wohlgeformte JSON-Dokument traditionell ein gültiger JavaScript-Ausdruck ist, kann das unvorsichtige Ausführen mit eval() eine Sicherheitslücke darstellen und zum Beispiel Cross-Site-Scripting (XSS) ermöglichen. Beide Formate sind außerdem nicht gut geeignet, um Binärdaten darzustellen, weil sie zeichenbasiert und nicht bytebasiert sind.

JSONP, also JSON mit Padding, bindet JSON-Daten über ein script-Element ein und gibt sie zusammen mit einem Funktionsaufruf aus. Dadurch können JSON-Daten über Domaingrenzen übertragen werden. Dieses Verfahren ist jedoch mit Sicherheitsrisiken verbunden.

Verwandte und alternative Formate

Es gibt mehrere Formate und Techniken, die auf JSON beruhen oder mit JSON verwandt sind. GeoJSON dient zur Annotation von Geodaten. JSON-LD dient zur Einbettung von RDF-Daten. JSON-RPC wird für den Aufruf von Methoden in entfernten Computersystemen verwendet. JSON Feed beschreibt Web-Feeds. Die Hypertext Application Language (HAL) hilft bei HATEOAS in JSON-basierten REST-Schnittstellen. JSON Hyper-Schema annotiert Datentypen in JSON, und GBSON dient zur Annotation von Nucleinsäuresequenzen, also DNA und RNA.

Mehrere Datenserialisierungsformate sind Obermengen von JSON, also Erweiterungen, die JSON einschließen. Dazu gehören YAML, CSON, HOCON, JSON5 und Hjson. Sie erweitern JSON unter anderem um Kommentare und eine für Menschen leichter lesbare Syntax; zum Beispiel können Anführungszeichen für Schlüssel und Zeichenketten, Kommata am Zeilenende oder geschweifte Klammern teilweise optional sein. Jsonnet, Dhall und CUE sind ebenfalls Obermengen von JSON und bieten Funktionen wie Validierung. Für Datenströme gibt es JSON streaming mit Line-delimited JSON (LDJSON), Newline-delimited JSON (NDJSON) und JSON lines (JSONL). INI, YAML und TOML sind speziell für Konfigurationsdateien entworfen.

Binäre JSON-Varianten sind zum Beispiel BSON (Binary JSON), das unter anderem von MongoDB verwendet wird, sowie CBOR, ein schemaloses und platzsparendes Format, das auf schnelle Verarbeitung optimiert und als RFC-Standard verabschiedet wurde. MessagePack ist ähnlich und wird in RPC-Anwendungen genutzt. UBJSON ist auf leichte Lesbarkeit optimiert und führt keine weiteren Datentypen hinzu. UJO Binary Data Object Notation versucht ein Containerformat zu etablieren. JSONB, verwendet von PostgreSQL, ist ein datenbankoptimierter Abkömmling, der sich schneller einlesen und indizieren lässt.

Vor der Verbreitung von JSON war XML das bekannteste Datenserialisierungsformat. NeXTstep verwendete spätestens seit 1994 ähnliche Property Lists, die bis heute in macOS vorkommen. Sie speichern unter anderem Arrays, Dictionaries, boolesche Werte, Binärdaten, Daten, Zahlen und Zeichenketten. Die Tool Command Language kennt Dictionaries (dict), die verschachtelte, benannte Strukturen als strukturierte Zeichenketten enthalten können. Ihr Overhead ist gegenüber JSON geringer, allerdings gibt es dort keine klare Trennung zwischen Objektstrukturen und Arrays.