JavaScript Object Notation


aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von JSON)
Wechseln zu: Navigation, Suche
Datei:JSON vector logo.svg
JSON-Logo

Die JavaScript Object Notation, kurz JSON . Es enthält eine durch Kommata geteilte, geordnete Liste von Werten 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). Jeder Schlüssel darf in einem Objekt nur einmal enthalten sein.
  • der Schlüssel ist eine Zeichenkette.
  • der Wert ist ein Objekt, ein Array, eine Zeichenkette, eine Zahl oder einer der Ausdrücke true, false oder null.

Nicht signifikante Leerraum-Zeichen sind verwendbar.<ref>RFC 4627. 2. JSON Grammar</ref>

Einschränkungen

JSON unterstützt nicht alle von JavaScript unterstützten Datentypen. Daher werden bei der Serialisierung

  • NaN, Infinity und -Infinity zu null serialisiert,
  • Date-Objekte als String in das ISO-8601-Format konvertiert, und
  • Function-, RegExp- und Error-Objekte verworfen.

Beispiel

<syntaxhighlight lang="javascript"> { 

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

} </syntaxhighlight>

Unterschied zu XML

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

In XML könnten viele Werte und Eigenschaften potenziell sowohl als Attribute als auch als Kindknoten beschrieben werden, was zu Problemen führen kann, wenn dies nicht durch sehr strikte Spezifizierung verhindert wird. In JSON kann dieses Problem nicht auftreten.

Eine Stärke von JSON ist die Tatsache, dass es sich bei der Definition selbst bis auf wenige Einschränkungen<ref name="subset" /> um valides JavaScript handelt. Damit lässt sich eine JSON-Definition in JavaScript direkt mit der eval()-Funktion in ein JavaScript-Objekt umsetzen. Bei Daten aus potentiell unsicheren Quellen sollte aber unbedingt ein Parser verwendet werden, da eval auch ggf. schädliche Programmanweisungen ausführt.

XML ist eine Auszeichnungssprache und somit vielseitiger einsetzbar als JSON, das ein Datenaustauschformat ist. XML ist weiter verbreitet, wird jedoch von JSON aufgrund seiner Einfachheit dort zurückgedrängt, wo keine komplizierten Auszeichnungen notwendig sind. Beide Formate sind nicht gut zum Repräsentieren von Binärdatenmengen geeignet, da beide keinen Binärdatentyp unterstützen und zeichenweise Interpretiert werden müssen.

Zum Vergleich das oben genannte Beispiel in einer XML-Form: <syntaxhighlight lang="xml"> <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> </syntaxhighlight>

Nach Entfernung der optionalen Leerzeichen ist das JSON-Objekt 226 Byte, das XML-Objekt 279 Byte (ein Zuwachs um 23 %) groß. Oftmals können Attribute auch als Kindknoten formuliert werden, das Beispiel könnte dann wie folgt aussehen: <syntaxhighlight lang="xml"> <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> </syntaxhighlight> Dieses Objekt wäre mit Entfernung der Leerzeichen 361 Byte (ein Zuwachs um 60 %) groß.

JSONP (JSON mit Padding)

JSONP (JSON mit Padding) ermöglicht die Übertragung von (JSON-)Daten über Domaingrenzen, ist jedoch mit Sicherheitsrisiken behaftet.

Ü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.

Die Grundidee: JSON-Abfragen über Script-Tags

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.

Padding

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 über einen Query String der URL mitgeteilt; beispielsweise:

<syntaxhighlight lang="html4strict"> <script type="text/javascript" 

       src="http://example.com/getjson?jsonp=Rueckruf">

</script> </syntaxhighlight>

Script-Element-Injektion (Einfügen von Programmcode)

Für jeden JSONP-Aufruf ist ein eigenes <script>-Element erforderlich. Daher muss der Browser für jeden Aufruf ein neues <script>-Element in den DOM-Knotenbaum der aktuellen Webseite einfügen.

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 Request Forgery

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).<ref>Jeremiah Grossman: Advanced Web Attack Techniques using GMail. 27. Januar 2006. Abgerufen am 23. Januar 2011.</ref> Das Problem tritt dann auf, wenn sensible Daten vor Dritten geschützt werden sollen.

Geschichte

JSONP wurde 2005 von Bob Ippolito vorgestellt<ref>Remote JSON – JSONP. In: from __future__ import *. Bob.pythonmac.org. 5. Dezember 2005. Abgerufen am 23. Januar 2011.</ref> und wird jetzt von vielen Web-2.0-Anwendungen wie Dojo Toolkit, jQuery<ref>jQuery API. Abgerufen am 23. Januar 2011.</ref>, Google Web Toolkit Applications<ref>GWT Tutorial: How to Read Web Services Client-Side with JSONP. In: Google Web Toolkit Applications. 6. Februar 2008. Abgerufen am 23. Januar 2011.</ref> und Web Services unterstützt. Für dieses Protokoll wurden Erweiterungen vorgeschlagen, die zusätzliche Eingabeparameter ermöglichen, wie z. B. JSONPP<ref>Jonas Almeida: JSON, JSONP, JSONPP?. S3DB. 11. Juni 2008. Abgerufen am 23. Januar 2011.</ref>.

Cross-Origin Resource Sharing

Mit Cross-Origin Resource Sharing (CORS) existiert eine vergleichbare Technologie, die den Zugriff über Domaingrenzen hinweg ermöglicht.

Ähnliche Techniken

Mit YAML existiert eine ähnliche Technik. Allerdings ist YAML eine Markup-Sprache zur reinen Serialisierung und in keiner Sprache gültiger Code. Aber auch hierbei handelt es sich um einen „Document Object Model“-Dateityp. YAML kann als Obermenge von JSON angesehen werden, da jedes JSON-Dokument auch ein valides YAML-Dokument ist.<ref>YAML Ain’t Markup Language (YAML™) Version 1.2</ref>

Binäre JSON-Varianten existieren mit BSON (Binary JSON)<ref>bsonspec.org</ref>, verwendet u. a. von MongoDB, und mit JSONB, verwendet von PostgreSQL<ref>PostgreSQL 9.4.0 Documentation, 8.14. JSON Types</ref>. Einen ähnlichen Ansatz verfolgen Googles Protocol Buffers (protobuf), denen im Vergleich zu JSON bzw. BSON ein Schema zugrunde liegt.<ref>What Are Protocol Buffers?</ref><ref>Protocol Buffers – Google’s data interchange format</ref>

NeXTstep und MacOS X kennen eine ähnliche Technik, um einfache Objektbäume zu laden oder zu speichern. Sie heißen dort Property Lists. Diese erlauben ebenfalls die Speicherung von Werten der Typen Array, Dictionary, boolescher Wert, Binärdaten, Datum, Zahl und Zeichenketten. Diese sind entweder als XML, als kompaktes Binärformat oder als ASCII bzw. UTF-8 kodiert.<ref>developer.apple.com: Introduction to Property Lists. Abgerufen am 6. November 2011 (english).</ref>

Weblinks

Einzelnachweise

<references />