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 0–9. 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 0–9 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, 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+000D und U+000A). Diese Zeichen werden außerhalb von Zeichenketten bei der Interpretation ignoriert.

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"
}

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.

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.