JavaScript Object Notation

Die JavaScript Object Notation (JSON [ˈdʒeɪsən]) ist ein kompaktes Datenformat in einer einfach lesbaren Textform für den Datenaustausch zwischen Anwendungen. JSON ist von Programmiersprachen unabhängig. Parser und Generatoren existieren in allen verbreiteten Sprachen.

JavaScript Object Notation
Dateiendung:	.json
MIME-Type:	application/json
Standard(s):	RFC 8259, ECMA-404
Website:	https://json.org/

JSON wurde ursprünglich 1997 von Douglas Crockford spezifiziert. Derzeit (Stand Ende 2017) wird es durch zwei inhaltlich gleiche Standards spezifiziert – RFC 8259 sowie ECMA-404.

Einsatzgebiete

JSON wird zur Übertragung und zum Speichern strukturierter Daten eingesetzt. Es dient als Datenformat bei der Datenübertragung (Serialisierung). Insbesondere bei Webanwendungen und mobilen Apps wird es in Verbindung mit JavaScript, Ajax oder WebSockets zum Übertragen von Daten zwischen dem Client und dem Server häufig genutzt.

Datenstruktur und Formatdefinition

Zeichencodierung und Datentypen

Die Daten können beliebig verschachtelt werden, beispielsweise ist eine indizierte Liste (englisch „array“) von Objekten möglich, welche wiederum arrays oder Objekte enthalten. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8. Auch UTF-16 und UTF-32 sind möglich.

JSON kennt die folgenden Typen von Elementen.

Nicht signifikante Leerraum-Zeichen sind erlaubt, also Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009), Zeilenumbrüche mittels LF und / oder CR (U+000D und U+000A). Diese Zeichen werden außerhalb von Zeichenketten bei der Interpretation ignoriert.

Einschränkungen

Im Gegensatz zu JavaScript und vielen anderen Programmiersprachen erlaubt JSON für Zahlen nicht die in IEEE 754 definierten Sonderwerte für Unendlich und NaN. Außerdem fehlen Wertetypen für zum Beispiel Datums- und Zeitwerte, reguläre Ausdrücke, Funktionsliterale und Fehlertypen. Beim Serialisieren nach JSON können solche nicht abbildbaren Werte entweder durch null ersetzt werden, oder sie müssen auf andere Weise umgesetzt werden. Bei Datums- und Zeit-Werten ist beispielsweise die Konvertierung in eine Zeichenkette gemäß ISO 8601 üblich.

JSON unterstützt ebenfalls keine Kommentare, die beim Einlesen der Daten ignoriert werden würden.

Um diese Einschränkungen zu umgehen, erlauben viele JSON-Programmbibliotheken (optional) die Verletzung des JSON-Standards, womit beispielsweise Werte für Unendlich und NaN unterstützt werden können oder wodurch Kommentare ignoriert werden, statt zu Fehlern zu führen.

Beispiel

{  "Herausgeber": "Xema",  "Nummer": "1234-5678-9012-3456",  "Deckung": 2e+6,  "Waehrung": "EURO",  "Inhaber":  {  "Name": "Mustermann",  "Vorname": "Max",  "maennlich": true,  "Hobbys": ["Reiten", "Golfen", "Lesen"],  "Alter": 42,  "Kinder": [],  "Partner": null  } } 

JSON Schema

JSON Schema gibt ein JSON-basiertes Format an, um die Struktur von JSON-Daten für die Validierung, Dokumentation und Interaktionssteuerung zu definieren. Es enthält einen Vertrag für die JSON-Daten, die für eine bestimmte Anwendung erforderlich sind, und wie diese Daten geändert werden können.

Das JSON Schema basiert auf den Konzepten des XML Schemas, ist jedoch JSON-basiert. Wie in XSD können dieselben Serialisierungs- und Deserialisierungsprogramme sowohl für das Schema als auch für die Daten verwendet werden. Es ist selbstbeschreibend und in einem Internet-Entwurf der Internet Engineering Task Force festgelegt. Für verschiedene Programmiersprachen stehen mehrere Validatoren mit jeweils unterschiedlichen Konformitätsstufen zur Verfügung.

Beispiel

{  "$schema": "http://json-schema.org/draft/2019-09/schema",  "title": "Politiker",  "type": "object",  "required": ["Vorname", "Nachname", "Geburtsdatum", "Nationalität"],  "properties":  {  "Vorname":  {  "type": "string"  },  "Nachname":  {  "type": "string"  },  "Geburtsdatum":  {  "type": "date"  },  "Nationalität":  {  "type": "string"  },  "Partei":  {  "type": "object",  "properties":  {  "Name":  {  "type": "string"  },  "Hauptsitz":  {  "type": "string"  },  "Gründungsdatum":  {  "type": "date"  },  "Gründungsort":  {  "type": "string"  }  }  },  "Amt":  {  "type": "string"  }  } } 

Das obige JSON Schema kann verwendet werden, um die Gültigkeit des folgenden Datenblocks zu testen:

{  "Vorname": "Ronald",  "Nachname": "Reagan",  "Geburtsdatum": "1911-02-06",  "Nationalität": "US-amerikanisch",  "Partei":  {  "Name": "Republican Party",  "Hauptsitz": "Washington, D.C.",  "Gründungsdatum": "1854-03-20",  "Gründungsort": "Ripon"  },  "Amt": "US-Präsident" } 

Vergleich mit XML

Sowohl JSON als auch XML beschreiben die Struktur eines Datensatzes. Der Datensatz kann weitere Datensätze enthalten, dadurch sind beliebig tief verschachtelte Strukturen möglich.

In XML sind die einzelnen Knoten der Datenstruktur benannt, während die Knoten in JSON unbenannt sind.

In XML können einfache Zeichenketten sowohl als Attribut eines Elements als auch als eigenständiges Element beschrieben sein, in JSON gibt es diese Unterscheidung nicht. Diese in den meisten Fällen irrelevante Flexibilität führt dazu, dass sich die Struktur von XML-Dokumenten häufig unnötigerweise unterscheidet.

Sowohl für JSON als auch für XML gibt es Beschreibungssprachen, um weiter einzugrenzen, wie „gültige“ Dokumente aussehen, im Gegensatz zu „wohlgeformten“ Dokumenten.

Die Syntax von JSON ist sehr viel einfacher gestaltet und erscheint daher oft lesbarer und insbesondere leichter schreibbar. In der Regel produziert JSON auch geringeren Overhead im Vergleich zu XML.

Sowohl JSON als auch XML müssen von einem speziellen Parser eingelesen werden. Traditionell ist jedes wohlgeformte JSON-Dokument ein gültiger JavaScript-Ausdruck, das sorglose Interpretieren von JSON-Dokumenten mit eval() führt jedoch zu Sicherheitslücken.

Sowohl JSON als auch XML sind nicht gut zum Repräsentieren von Binärdaten geeignet, da beide Datenformate als Grundelement zeichenbasiert sind und nicht bytebasiert.

Zum Vergleich das oben genannte Beispiel in einer XML-Form:

<Kreditkarte Herausgeber="Xema" Nummer="1234-5678-9012-3456" Deckung="2e+6" Waehrung="EURO">  <Inhaber Name="Mustermann" Vorname="Max" maennlich="true" Alter="42" Partner="null">  <Hobbys>  <Hobby>Reiten</Hobby>  <Hobby>Golfen</Hobby>  <Hobby>Lesen</Hobby>  </Hobbys>  <Kinder />  </Inhaber> </Kreditkarte> 

Nach Entfernung der optionalen Leerzeichen ist das JSON-Objekt 226 Byte, das XML-Objekt 279 Byte groß – ein Zuwachs um 23 %.
Oftmals können Attribute auch als Kindknoten formuliert werden, das Beispiel könnte dann wie folgt aussehen:

<Kreditkarte>  <Herausgeber>Xema</Herausgeber>  <Nummer>1234-5678-9012-3456</Nummer>  <Deckung>2e+6</Deckung>  <Waehrung>EURO</Waehrung>  <Inhaber>  <Name>Mustermann</Name>  <Vorname>Max</Vorname>  <maennlich>true</maennlich>  <Hobbys>  <Hobby>Reiten</Hobby>  <Hobby>Golfen</Hobby>  <Hobby>Lesen</Hobby>  </Hobbys>  <Alter>42</Alter>  <Kinder />  <Partner>null</Partner>  </Inhaber> </Kreditkarte> 

Dieses Objekt wäre mit Entfernung der Leerzeichen 361 Byte groß – ein Zuwachs um 60 % zum JSON-Objekt.

JSONP (JSON mit Padding)

Bei JSONP (JSON mit Padding) werden die JSON-Daten über ein <script>-Element eingebunden und inklusive eines Funktionsaufrufs ausgegeben. Dies ermöglicht die Übertragung von JSON-Daten über Domaingrenzen, ist jedoch mit Sicherheitsrisiken behaftet.

JSONP wurde 2005 von Bob Ippolito vorgestellt und wird jetzt von vielen Web-2.0-Anwendungen wie Dojo Toolkit, jQuery, Google Web Toolkit Applications und Web Services unterstützt. Für dieses Protokoll wurden Erweiterungen vorgeschlagen, die zusätzliche Eingabeparameter ermöglichen, wie z. B. JSONPP.

Funktionsweise

Üblicherweise erfolgen Ajax-Datenabfragen an Server über das XMLHttpRequest-Objekt eines Webbrowsers. Aufgrund der Same-Origin-Policy funktioniert das nicht, wenn die in einem Webbrowser angezeigte Webseite über dieses Objekt auf einen Server zuzugreifen versucht, der in einer anderen Domain als die angezeigte Webseite liegt. Das Problem kann durch JSONP umgangen werden. Im src-Attribut eines <script>-Elements ist es möglich, beliebige URLs anzugeben. Für dieses Attribut greift die Same-Origin-Policy nicht. Es ist also möglich, eine URL in einer anderen Domain anzugeben, die beispielsweise JSON-Daten zurückgibt. Dieses Script hätte aber keinen Effekt.

Um die JSON-Daten auf dem Client verarbeiten zu können, verpackt der Server diese als Parameter in eine JavaScript-Funktion, die im Webbrowser bereits definiert ist. Der Name dieser Funktion wird dem Server üblicherweise im Query-String der URL mitgeteilt, wobei das genaue Format oder der Name des Parameters nicht genormt ist.

Beispiel:

Im HTML-Code einer Webseite werden die JSONP-Daten wie folgt eingebunden:

<script type="text/javascript" src="https://example.com/getjson?jsonp=exampleCallback"> </script> 

Der Server erzeugt daraufhin einen JavaScript-Codeschnipsel, in dem die eigentlichen Daten an die genannte Funktion übergeben werden:

 exampleCallback( {"name":"Jane Doe", "value":4711} ); 

Der Browser führt diesen Funktionsaufruf daraufhin aus, als ob er direkt in der HTML-Seite niedergeschrieben worden wäre, und kann so die JSON-Daten aus dem Aufruf verarbeiten.

Üblicherweise ist für jeden JSONP-Aufruf ein eigenes <script>-Element erforderlich.

Sicherheitsrisiken

<script>-Elemente ermöglichen es einem Server, beliebige Inhalte (nicht nur JSON-Objekte) an den Webbrowser zu übermitteln. Dies kann dazu führen, dass ein bösartiger Web-Service über die zurückgesendeten Daten private Informationen im Webbrowser ausspäht oder in seinem Sinne verändert (Cross-Site-Scripting).

Da das <script>-Element die Same-Origin-Policy nicht beachtet, kann eine bösartige Webseite JSONP-Daten anfordern und auswerten, die nicht für sie bestimmt sind (Cross-Site-Request-Forgery). Das Problem tritt dann auf, wenn sensible Daten vor Dritten geschützt werden sollen.

Alternative

Mit Cross-Origin Resource Sharing (CORS) existiert ein vergleichbares Verfahren, das den Zugriff über Domaingrenzen hinweg ermöglicht, ohne jedoch der abgefragten Ressource die Möglichkeit einzuräumen, beliebigen JavaScript-Code auszuführen. Beide Verfahren erfordern die Unterstützung durch die entsprechende Ressource, wobei CORS einfacher zu implementieren ist. Gleichzeitig erlaubt CORS eine einfache Einschränkung seitens der Ressource, von welchen Datenquellen (englisch „origins“, das sind URLs, Domänen o. ä.) sie genutzt werden kann.

CORS ist gegenüber JSONP meist zu bevorzugen, da CORS insgesamt einfacher und sicherer ist.

Verwandte Techniken

JSON-basierte Formate

• GeoJSON dient zur Annotation von Geodaten.
• JSON-LD dient zur Einbettung von RDF-Daten.
• JSON-RPC dient zum Aufruf von Methoden in entfernten Computersystemen.
• JSON Feed dient zur Beschreibung von Web-Feeds.
• Die Hypertext Application Language (HAL) dient zur Implementierung von HATEOAS in auf JSON basierten REST-Schnittstellen.
• JSON Hyper-Schema dient zur Annotation von Datentypen in JSON.
• GBSON dient zur Annotation von Nucleinsäuresequenzen (DNA und RNA).

Alternative Formate

• YAML, CSON (CoffeeScript-Object-Notation), HOCON (Human-Optimized Config Object Notation), JSON5 und Hjson sind Datenserialisierungformate, deren Syntax eine Obermenge von JSON ist. Sie erweitern JSON u. a. um Kommentare und erlauben eine für Menschen einfacher lesbare Syntax. Z. B. sind Anführungszeichen für Schlüssel und Zeichenketten, Kommas am Zeilenende und geschweifte Klammern teilweise optional.
• Jsonnet, Dhall und CUE sind ebenfalls Obermengen von JSON und bieten Funktionen wie z. B. Validierung.
• JSON streaming mit den drei Varianten Line-delimited JSON (LDJSON), Newline-delimited JSON (NDJSON) und JSON lines (JSONL).
• INI, YAML und TOML sind Formate, die speziell für Konfigurationsdateien entworfen wurden.

Binäre Formate

Binäre JSON-Varianten gibt es mit BSON (Binary JSON), verwendet u. a. von MongoDB, und mit JSONB, verwendet von PostgreSQL. Einen ähnlichen Ansatz verfolgen Googles Protocol Buffers (protobuf), denen im Unterschied zu JSON bzw. BSON ein Schema zugrunde liegt. Ebenfalls an JSON orientiert ist das schemalose und auf platzsparende Serialisierung und Prozessierungsgeschwindigkeit hin optimierte CBOR.

Vorgänger-Formate

Vor der Verbreitung von JSON war XML das bekannteste Datenserialisierungformat.

NeXTstep verwendete bereits einige Jahre früher, spätestens seit 1994, eine ähnliche Technik, um einfache Objektbäume zu laden oder zu speichern. Sie heißen dort Property Lists und sind bis heute in macOS in Verwendung. Diese erlauben ebenfalls die Speicherung von Werten der Typen Array, Dictionary, boolescher Wert, Binärdaten, Datum, Zahl und Zeichenketten.

Die Tool Command Language kennt Dictionaries (dict), die ebenfalls beliebig geschachtelte, benannte Strukturen enthalten können. Diese sind gleichfalls strukturierte Zeichenketten. Der Zusatzaufwand (englisch „overhead“) ist gegenüber JSON deutlich vermindert, weil keine Doppelpunkte oder Anführungsstriche benötigt werden. Eine klare Trennung zwischen Objektstrukturen (Eigenschaft/Wert) und Tabellen („arrays“, hier als Listen bezeichnet) gibt es allerdings nicht. Daher ist eine Überführung von JSON-Daten in ein dict immer eindeutig und leicht möglich, umgekehrt jedoch nicht.

Weblinks

Commons: JavaScript Object Notation – Sammlung von Bildern, Videos und Audiodateien

• json.org/json-de.html – deutsche Einführung auf der offiziellen JSON-Seite (weitere Sprachen verfügbar)
• Speeding Up AJAX with JSON Einführung in JSON, bei der die Unterschiede zu XML herausgearbeitet werden (englisch)
• Parsing JSON is a Minefield – Übersicht der verschiedenen Standards und Implementierungen (englisch)
• JSON Viewer Online-Plattform zum Formatieren, Validieren und Austausch von JSON-Daten (englisch)
• jsonp.eu – Erklärungen und Programmierbeispiele zu JSON with Padding (JSONP)

Einzelnachweise

1. Douglas Crockford: RFC 8259 – The JavaScript Object Notation (JSON) Data Interchange Format. 2017 (englisch).
2. ECMA-404
3. Tim Bray: RFC 7159 – The JavaScript Object Notation (JSON) Data Interchange Format. März 2014 (englisch).
4. Douglas Crockford: RFC 4627 – The application/json Media Type for JavaScript Object Notation (JSON). Juli 2006, Abschnitt 2: JSON Grammar. (englisch).
5. Date/Time processing · JSONata. Abgerufen am 21. Mai 2023 (englisch). 
6. JsonReadFeature (Jackson-core 2.10.0 API). Abgerufen am 21. Mai 2023. 
7. JsonReadFeature (Jackson-core 2.10.0 API). Abgerufen am 21. Mai 2023. 
8. JSON Schema
9. JSON Documentation. 18. Januar 2020, abgerufen am 10. Oktober 2021 (englisch). 
10. Remote JSON – JSONP. In: Bob.pythonmac.org. 5. Dezember 2005, abgerufen am 23. Januar 2011 (englisch, from __future__ import *). 
11. jQuery API. Abgerufen am 23. Januar 2011 (englisch). 
12. GWT Tutorial: How to Read Web Services Client-Side with JSONP. (Nicht mehr online verfügbar.) In: Google Web Toolkit Applications. 6. Februar 2008, ehemals im Original; abgerufen am 23. Januar 2011 (englisch).@1@2Vorlage:Toter Link/www.gwtapps.com (Seite nicht mehr abrufbar. Suche in Webarchiven.)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis. 
13. Jonas Almeida: JSON, JSONP, JSONPP? S3DB, 11. Juni 2008, abgerufen am 23. Januar 2011 (englisch). 
14. Jeremiah Grossman: Advanced Web Attack Techniques using GMail. 27. Januar 2006, abgerufen am 23. Januar 2011 (englisch). 
15. Mike Kelly: JSON Hypertext Application Language. IETF Network Working Group, 12. Oktober 2016, abgerufen am 7. Dezember 2016 (englisch). 
16. Austin Wright, Geraint Luff: JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON. IETF, 13. August 2016, abgerufen am 7. Dezember 2016 (englisch). 
17. GBSON. A new annotation file format based on JSON. Abgerufen am 12. November 2021 (englisch). 
18. CSON
19. HOCON
20. JSON5
21. Hjson
22. Jsonnet
23. Dhall
24. CUE
25. bsonspec.org
26. PostgreSQL 12 Documentation, 8.14. JSON Types
27. What Are Protocol Buffers?
28. Protocol Buffers – Google’s data interchange format
29. CBOR – Concise Binary Object Representation | Overview. Abgerufen am 16. Februar 2019. 
30. Introduction to Property Lists. In: developer.apple.com. Abgerufen am 6. November 2011 (englisch). 
31. NSString Class Cluster – propertyList Methode. In: NeXTStep 3.3 Developer Documentation Manuals. nextcomputers.org, 30. Juni 2000, abgerufen am 20. Juli 2022 (englisch). 

Normdaten (Sachbegriff): GND: 1105592812 (lobid, OGND) | LCCN: sh2014000515