JSON

JSON
Dateiendung: .json
MIME-Type: application/json
Standard(s): RFC 8259,[1] ECMA-404[2]
https://json.org/

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 den meisten verbreiteten Sprachen.

JSON wurde ursprünglich 2001[3] von Douglas Crockford spezifiziert.[4] Derzeit (Stand Ende 2017) wird es durch zwei inhaltlich gleiche Standards spezifiziert – RFC 8259[1] sowie ECMA-404.[2]

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.

Nullwert
wird durch das Schlüsselwort null dargestellt.
Boolescher Wert
wird durch die Schlüsselwörter true und false dargestellt. Dies sind keine Zeichenketten. Sie werden daher, wie null, nicht in Anführungszeichen gesetzt.
Zahl
ist eine Folge der Ziffern 09. Diese Folge kann durch ein negatives Vorzeichen - eingeleitet und durch einen Dezimalpunkt . unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein optionales Vorzeichen + oder - und eine Folge der Ziffern 09 folgt.
Zeichenkette
beginnt und endet mit doppelten geraden Anführungszeichen ("). Sie kann Unicode-Zeichen und durch \ eingeleitete Escape-Sequenzen enthalten.
Array
beginnt mit [ und endet mit ]. Es enthält eine durch Kommata geteilte, indizierte Liste von Elementen gleichen oder verschiedenen Typs. Leere Arrays sind zulässig.
Objekt
beginnt mit { und endet mit }. Es enthält eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften. Objekte ohne Eigenschaften („leere Objekte“) sind zulässig.
Eigenschaft
besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt (Schlüssel : Wert). Die Schlüssel sollten eindeutig sein, da unterschiedliche Parser mit mehrfach vorkommenden Schlüsseln unterschiedlich umgehen. Während ECMA-404 keine Eindeutigkeit voraussetzt, fordert RFC 7159,[4] dass Schlüssel innerhalb eines Objekts eindeutig sind.
  • der Schlüssel ist eine Zeichenkette.
  • der Wert ist ein beliebiges Element.

Nicht signifikante Leerraum-Zeichen sind erlaubt, also Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009), Zeilenumbrüche mittels LF und/oder CR (U+000A bzw. U+000D).[5] 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.[4] Außerdem fehlen Wertetypen für zum Beispiel Datums- und Zeitwerte, reguläre Ausdrücke, Funktionsliterale und Fehlertypen.[4] 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.[6]

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[7] unterstützt werden können oder wodurch Kommentare ignoriert werden, statt zu Fehlern zu führen[8].

Beispiel

Ein (nicht nach Entitäten normalisiertes) Beispiel mit den Daten einer Kreditkarte und ihres Inhabers:

{
  "Herausgeber": "Xema",
  "Nummer": "1234-5678-9012-3456",
  "Deckung": 2e+6,
  "Waehrung": "EURO",
  "Inhaber":
  {
    "Name": "Mustermann",
    "Vorname": "Max",
    "Teilnahme am Bonusprogramm": 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.

JSON Schema basiert auf den Konzepten von XML Schema (XSD), 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.[9]

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[10] 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() stellt jedoch potentiell eine Sicherheitslücke dar und kann beispielsweise Cross-Site-Scripting (XSS) ermöglichen.[11]

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" Teilnahme_am_Bonusprogramm="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>
    <Teilnahme_am_Bonusprogramm>true</Teilnahme_am_Bonusprogramm>
    <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

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.

Verwandte Techniken

JSON-basierte Formate

Alternative Formate

  • YAML, CSON[15] (CoffeeScript-Object-Notation), HOCON[16] (Human-Optimized Config Object Notation), JSON5[17] und Hjson[18] sind Datenserialisierungsformate, deren Syntax eine Obermenge von JSON ist. Sie erweitern JSON u. a. um Kommentare und erlauben eine für Menschen einfacher lesbare Syntax. Beispielsweise sind Anführungszeichen für Schlüssel und Zeichenketten, Kommas am Zeilenende und geschweifte Klammern teilweise optional.
  • Jsonnet,[19] Dhall[20] und CUE[21] 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. Ebenfalls an JSON orientiert ist das schemalose und auf platzsparende Serialisierung und Prozessierungsgeschwindigkeit hin optimierte CBOR, das als RFC-Standard verabschiedet wurde. Dazu ähnlich ist MessagePack, das in RPC-Anwendungen Verwendung findet. Universal Binary JSON (UBJSON) ist für leichte Lesbarkeit optimiert und führt keine weiteren Datentypen hinzu. Die UJO Binary Data Object Notation versucht hingegen ein Containerformat zu etablieren.[22] Mit JSONB, verwendet von PostgreSQL existiert ebenfalls ein für Datenbanken optimierter Abkömmling, der sich schneller einlesen und indizieren lässt.[23]

Vorgänger-Formate

Vor der Verbreitung von JSON war XML das bekannteste Datenserialisierungsformat.

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.[24][25]

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.

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

Einzelnachweise

  1. a b Douglas Crockford: RFC: 8259 – The JavaScript Object Notation (JSON) Data Interchange Format. 2017 (englisch).
  2. a b ECMA-404
  3. Douglas Crockford: The JSON Saga (Talk bei Yahoo!). Abgerufen am 18. September 2025 (englisch).
  4. a b c d Tim Bray: RFC: 7159 – The JavaScript Object Notation (JSON) Data Interchange Format. März 2014 (englisch).
  5. Douglas Crockford: RFC: 4627 – The application/json Media Type for JavaScript Object Notation (JSON). Juli 2006, Abschnitt 2: JSON Grammar. (englisch).
  6. Date/Time processing · JSONata. In: docs.jsonata.org. Abgerufen am 21. Mai 2023 (englisch).
  7. JsonReadFeature (Jackson-core 2.10.0 API). Abgerufen am 21. Mai 2023 (englisch).
  8. JsonReadFeature (Jackson-core 2.10.0 API). Abgerufen am 21. Mai 2023 (englisch).
  9. JSON Schema. Abgerufen am 8. August 2020 (englisch).
  10. JSON Documentation. In: file-types.com. 18. Januar 2020, abgerufen am 10. Oktober 2021 (englisch).
  11. Amakiri Welekwe: What is a JSON Injection and How to Prevent it? In: comparitech.com. 9. März 2022, abgerufen am 16. Dezember 2023 (englisch).
  12. Mike Kelly: JSON Hypertext Application Language. IETF Network Working Group, 12. Oktober 2016, abgerufen am 7. Dezember 2016 (englisch).
  13. Austin Wright, Geraint Luff: JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON. IETF, 13. August 2016, archiviert vom Original (nicht mehr online verfügbar) am 7. Dezember 2016; abgerufen am 7. Dezember 2016 (englisch).
  14. GBSON. A new annotation file format based on JSON. Abgerufen am 12. November 2021 (englisch).
  15. CSON. In: github.com. Abgerufen am 16. Dezember 2023 (englisch).
  16. HOCON. In: github.com. Abgerufen am 16. Dezember 2023 (englisch).
  17. JSON5 – JSON for Humans. In: json5.org. Abgerufen am 16. Dezember 2023 (englisch).
  18. Hjson, a user interface for JSON. In: hjson.github.io. Abgerufen am 16. Dezember 2023 (englisch).
  19. Jsonnet. In: jsonnet.org. Abgerufen am 16. Dezember 2023 (englisch).
  20. The Dhall configuration language. In: dhall-lang.org. Abgerufen am 16. Dezember 2023 (englisch).
  21. CUE: Configure Unify Execute. In: cuelang.org. Abgerufen am 16. Dezember 2023 (englisch).
  22. Maik Wojcieszak: Binäre Austauschformate: Kompakte Daten nicht nur im Internet of Things. In: Java Magazin 6.2015. Abgerufen am 2. August 2026.
  23. PostgreSQL 12 Documentation, 8.14. JSON Types. PostgreSQL Global Development Group, abgerufen am 16. Dezember 2023 (englisch).
  24. Introduction to Property Lists. In: developer.apple.com. Abgerufen am 6. November 2011 (englisch).
  25. NSString Class Cluster – propertyList Methode. In: NeXTStep 3.3 Developer Documentation Manuals. nextcomputers.org, 30. Juni 2000, abgerufen am 20. Juli 2022 (englisch).

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.