Benutzer:Ocrho/JSONP

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
Dieser Artikel (JSONP) ist im Entstehen begriffen und noch nicht Bestandteil der freien Enzyklopädie Wikipedia.
Wenn du dies liest:
  • Der Text kann teilweise in einer Fremdsprache verfasst, unvollständig sein oder noch ungeprüfte Aussagen enthalten.
  • Wenn du Fragen zum Thema hast, nimm am besten Kontakt mit dem Autor Ocrho auf.
Wenn du diesen Artikel überarbeitest:
  • Bitte denke daran, die Angaben im Artikel durch geeignete Quellen zu belegen und zu prüfen, ob er auch anderweitig den Richtlinien der Wikipedia entspricht (siehe Wikipedia:Artikel).
  • Nach erfolgter Übersetzung kannst du diese Vorlage entfernen und den Artikel in den Artikelnamensraum verschieben. Die entstehende Weiterleitung kannst du schnelllöschen lassen.
  • Importe inaktiver Accounts, die länger als drei Monate völlig unbearbeitet sind, werden gelöscht.
Vorlage:Importartikel/Wartung-2023-06
Ocrho/JSONP
Dateiendung: .json
MIME-Type: application/json
Standard(s): RFC 8259, ECMA-404
http://json.org/

Die JavaScript Object Notation, kurz JSON [ˈdʒeɪsən], ist ein kompaktes Datenformat in einer einfach lesbaren Textform zum Zweck des Datenaustauschs zwischen Anwendungen. Jedes gültige JSON-Dokument soll ein gültiges JavaScript sein und per eval() interpretiert werden können. Aufgrund kleiner Abweichungen in der Menge der erlaubten Unicode-Zeichen ist es jedoch möglich, JSON-Objekte zu erzeugen, die von einem normkonformen JavaScript-Interpreter nicht akzeptiert werden.[1] Davon abgesehen ist JSON aber unabhängig von der Programmiersprache. Parser existieren in praktisch allen verbreiteten Sprachen.

JSON wurde ursprünglich von Douglas Crockford spezifiziert. Aktuell wird es durch zwei konkurrierende Standards spezifiziert, RFC 8259[2] von Douglas Crockford, und ECMA-404.[3]

Einsatzgebiete

[Bearbeiten | Quelltext bearbeiten]

JSON wird zur Übertragung und zum Speichern von strukturierten 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

[Bearbeiten | Quelltext bearbeiten]

Zeichencodierung und Datentypen

[Bearbeiten | Quelltext bearbeiten]

Die Daten können beliebig verschachtelt werden, beispielsweise ist ein Array von Objekten möglich. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8. Auch UTF-16 und UTF-32 sind möglich.

JSON kennt folgende Datentypen:

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 einen Dezimalpunkt . unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein Vorzeichen + oder - und eine Folge der Ziffern 0–9 folgt.
Zeichenkette
beginnt und endet mit doppelten geraden Anführungszeichen ("). Sie kann Unicode-Zeichen und Escape-Sequenzen enthalten.
Array
beginnt mit [ und endet mit ]. 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). 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 sein sollen.
  • der Schlüssel ist eine Zeichenkette.
  • der Wert ist einer der Datentypen.

Nicht signifikante Leerraum-Zeichen sind verwendbar.[4]

Einschränkungen

[Bearbeiten | Quelltext bearbeiten]

JSON unterstützt nicht alle von JavaScript unterstützten Datentypen. Bei nicht unterstützten Datentypen wird folgendermaßen serialisiert:

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

Beispiel

[Bearbeiten | Quelltext bearbeiten]
{
  "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
  }
}

Unterschied zu XML

[Bearbeiten | Quelltext bearbeiten]

XML ist eine strukturbeschreibende Sprache, JSON im Gegensatz dazu eine Syntax-Konvention und überhaupt nicht deklarativ. Mit JSON werden präsente Instanzen strukturierter Daten definiert. Die sinnvollen Einsatzgebiete von XML/SGML vs. JSON lassen sich jeweils klar abgrenzen. Für den Datenaustausch an einer rigiden Schnittstelle ist XML deutlich besser geeignet. JSON zeigt seine Stärken insbesondere im Umgang mit flexiblen Schnittstellen.

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.

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[1] 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: 

<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)

[Bearbeiten | Quelltext bearbeiten]
JSONP (JSON mit Padding)
Dateiendung: .jsonp
MIME-Type: application/json-p
Standard(s): RFC 7159, RFC 4329
json-p.org[5]

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[6] und wird jetzt von vielen Web-2.0-Anwendungen wie Dojo Toolkit, jQuery[7], Google Web Toolkit Applications[8] und Web Services unterstützt. Für dieses Protokoll wurden Erweiterungen vorgeschlagen, die zusätzliche Eingabeparameter ermöglichen, wie z. B. JSONPP.[9]

Funktionsweise

[Bearbeiten | Quelltext bearbeiten]

Ü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="http://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

[Bearbeiten | Quelltext bearbeiten]

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

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).[10] Das Problem tritt dann auf, wenn sensible Daten vor Dritten geschützt werden sollen.

Alternative

[Bearbeiten | Quelltext bearbeiten]

Mit Cross-Origin Resource Sharing (CORS) existiert eine vergleichbare Technologie, die den Zugriff über Domaingrenzen hinweg ermöglicht, ohne jedoch der abgefragten Ressource die Möglichkeit einzuräumen, beliebigen JavaScript-Code auszuführen. Beide Technologien 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 Origins (URLs, Domänen) sie genutzt werden kann.

Daher ist CORS gegenüber JSONP im Allgemeinen zu bevorzugen, da CORS insgesamt einfacher und sicherer ist.

Erweiterungen zu JSON

[Bearbeiten | Quelltext bearbeiten]

JSON-LD dient zur Einbettung von RDF-Daten.

Die Hypertext Application Language[11] (HAL) dient zur Implementierung von HATEOAS in auf JSON basierten REST-Schnittstellen.

JSON Hyper-Schema[12] dient zur Annotation von Datentypen in JSON.

JSON streaming mit den drei Varianten Line-delimited JSON (LDJSON), Newline-delimited JSON (NDJSON) und JSON lines (JSONL).

Ähnliche Techniken

[Bearbeiten | Quelltext bearbeiten]

Hjson bietet eine alternative Syntax an, welche flexibler ist und damit die Erstellung durch Menschen vereinfacht. Der Einsatz wird jedoch aufgrund der geringeren Performance nur für Konfigurationsdateien empfohlen.

YAML ist ein ähnliches Datenformat. YAML 1.2 kann als Obermenge von JSON angesehen werden, da jedes JSON-Dokument auch ein valides YAML-Dokument ist.[13]

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

NeXTstep und macOS 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.[19]

Die Tool Command Language kennt Dictionaries (dict), die ebenfalls beliebig geschachtelte, benannte Strukturen enthalten können. Diese sind gleichfalls strukturierte Zeichenketten. Der Overhead ist gegenüber JSON deutlich vermindert, weil keine Doppelpunkte oder Anführungsstriche benötigt werden. Eine klare Trennung zwischen Objektstrukturen (Eigenschaft/Wert) und 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.

[Bearbeiten | Quelltext bearbeiten]
Commons: Ocrho/JSONP – Sammlung von Bildern, Videos und Audiodateien

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ a b http://timelessrepo.com/json-isnt-a-javascript-subset
  2. ↑ Douglas Crockford: The JavaScript Object Notation (JSON) Data Interchange Format. 2017 (online [PDF; abgerufen am 5. Januar 2017]).
  3. ↑ ECMA International: The JSON Data Interchange Format. 2013 (online [PDF; abgerufen am 22. April 2014]).
  4. ↑ RFC 4627. 2. JSON Grammar
  5. ↑ web archive (Memento vom 4. März 2016 im Internet Archive)
  6. ↑ Remote JSON – JSONP. In: from __future__ import *. Bob.pythonmac.org, 5. Dezember 2005, abgerufen am 23. Januar 2011.
  7. ↑ jQuery API. Abgerufen am 23. Januar 2011.
  8. ↑ GWT Tutorial: How to Read Web Services Client-Side with JSONP. In: Google Web Toolkit Applications. 6. Februar 2008, archiviert vom Original am 17. Januar 2013; abgerufen am 23. Januar 2011.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@2Vorlage:Webachiv/IABot/www.gwtapps.com
  9. ↑ Jonas Almeida: JSON, JSONP, JSONPP? S3DB, 11. Juni 2008, abgerufen am 23. Januar 2011.
  10. ↑ Jeremiah Grossman: Advanced Web Attack Techniques using GMail. 27. Januar 2006, abgerufen am 23. Januar 2011.
  11. ↑ Mike Kelly: JSON Hypertext Application Language. IETF Network Working Group, 12. Oktober 2016, abgerufen am 7. Dezember 2016 (englisch).
  12. ↑ Austin Wright, Geraint Luff: JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON. IETF, 13. August 2016, abgerufen am 7. Dezember 2016 (englisch).
  13. ↑ YAML Ain’t Markup Language (YAML™) Version 1.2
  14. ↑ bsonspec.org
  15. ↑ PostgreSQL 9.4.0 Documentation, 8.14. JSON Types
  16. ↑ What Are Protocol Buffers?
  17. ↑ Protocol Buffers – Google’s data interchange format
  18. ↑ CBOR — Concise Binary Object Representation | Overview. Abgerufen am 16. Februar 2019.
  19. ↑ developer.apple.com: Introduction to Property Lists. Abgerufen am 6. November 2011 (englisch).

Json Json Json

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Benutzer:Ocrho/JSONP&oldid=234767494“