Zum Hauptinhalt springen

RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format

  • Status: Proposed Standard
  • Veröffentlicht: March 2014
  • Stream: IETF
  • Ersetzt: RFC4627, RFC7158
  • Ersetzt durch: RFC8259
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

JavaScript Object Notation (JSON) ist ein leichtgewichtiges, textbasiertes, sprachunabhängiges Datenaustauschformat. Es stammt aus dem ECMAScript-Programmiersprachen-Standard. JSON definiert einen kleinen Satz von Formatierungsregeln für die portable Darstellung strukturierter Daten.

Dieses Dokument beseitigt Inkonsistenzen mit anderen JSON-Spezifikationen, behebt Spezifikationsfehler und bietet erfahrungsbasierte Interoperabilitätsrichtlinien.

JSON-Kernkonzepte​

Datentypen​

JSON unterstützt folgende Datentypen:

Primitive Typen (Primitive Types):

  • string - Zeichenkette
  • number - Zahl
  • boolean - Boolescher Wert (true/false)
  • null - Nullwert

Strukturierte Typen (Structured Types):

  • object - Objekt (ungeordnete Sammlung von Schlüssel-Wert-Paaren)
  • array - Array (geordnete Sequenz von Werten)

Syntaxbeispiele​

Objekt (Object):

{
  "name": "张三",
  "age": 30,
  "city": "北京"
}

Array:

[1, 2, 3, 4, 5]

Verschachtelte Struktur:

{
  "users": [
    {"name": "Alice", "age": 25},
    {"name": "Bob", "age": 30}
  ],
  "total": 2
}

Hauptänderungen gegenüber RFC 4627​

  1. Lockerere JSON-Text-Definition: Erlaubt JSON-Text als beliebigen JSON-Wert, nicht nur Objekte oder Arrays
  2. Fehlerbehebungen: Behebt in RFC 4627 gemeldete Fehler
  3. Interoperabilitätsrichtlinien: Bietet mehr Ratschläge zur Implementierungs-Interoperabilität
  4. Kodierungsklarheit: Betont die Verwendung von UTF-8-Kodierung
  • Offizieller Originaltext: RFC 7159 (TXT)
  • Offizielle Seite: RFC 7159 DataTracker
  • Obsoletes: RFC 4627 (alte JSON-Spezifikation)
  • Obsoleted by: Wurde durch RFC 8259 ersetzt
  • Medientyp: application/json
  • Dateierweiterung: .json

Schnellreferenz​

MIME-Typ​

Content-Type: application/json; charset=UTF-8

Häufig verwendete Tools​

Online-Validierung:

Programmiersprachen-Unterstützung:

JavaScript:

const obj = JSON.parse('{"name":"Alice"}');
const str = JSON.stringify({name: "Bob"});

Python:

import json
obj = json.loads('{"name":"Alice"}')
str = json.dumps({"name": "Bob"})

Java:

// Mit Jackson oder Gson Bibliothek
ObjectMapper mapper = new ObjectMapper();
MyObject obj = mapper.readValue(jsonString, MyObject.class);

Wichtiger Hinweis: RFC 7159 wurde durch RFC 8259 ersetzt, bleibt aber ein wichtiges Dokument zum Verständnis der JSON-Entwicklungsgeschichte. Moderne Anwendungen sollten RFC 8259 als aktuellen Standard verwenden.

1. Introduction (Einführung)​

JavaScript Object Notation (JSON) ist ein Textformat zur Serialisierung strukturierter Daten. Es leitet sich von Objektliteralen in JavaScript ab, wie im ECMAScript-Programmiersprachen-Standard, dritte Edition [ECMA-262], definiert.

JSON kann vier primitive Typen (Strings, Zahlen, Boolesche Werte und null) sowie zwei strukturierte Typen (Objekte und Arrays) darstellen.

Ein String ist eine Sequenz von null oder mehr Unicode-Zeichen [UNICODE]. Beachten Sie, dass dieser Verweis auf die neueste Version von Unicode verweist, nicht auf eine bestimmte Version. Es wird erwartet, dass zukünftige Änderungen an der Unicode-Spezifikation die Syntax von JSON nicht beeinflussen.

Ein Objekt ist eine ungeordnete Sammlung von null oder mehr Name/Wert-Paaren, wobei ein Name ein String ist und ein Wert ein String, eine Zahl, ein Boolescher Wert, null, ein Objekt oder ein Array sein kann.

Ein Array ist eine geordnete Sequenz von null oder mehr Werten.

Die Begriffe "Objekt" und "Array" stammen aus den Konventionen von JavaScript.

Die Designziele von JSON waren es, minimal, portabel, textbasiert und ein Subset von JavaScript zu sein.

1.1. Conventions Used in This Document (In diesem Dokument verwendete Konventionen)​

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.

Die Grammatikregeln in diesem Dokument sind wie in [RFC5234] beschrieben zu interpretieren.

1.2. Specifications of JSON (JSON-Spezifikationen)​

Dieses Dokument aktualisiert [RFC4627], das JSON beschrieben und den Medientyp "application/json" registriert hat.

Eine Beschreibung von JSON in ECMAScript-Begriffen erscheint in Version 5.1 der ECMAScript-Spezifikation [ECMA-262], Abschnitt 15.12. JSON wird auch in [ECMA-404] beschrieben.

Alle JSON-Grammatikspezifikationen stimmen in den syntaktischen Elementen der Sprache überein.

1.3. Introduction to This Revision (Einführung in diese Revision)​

In den Jahren seit der Veröffentlichung von RFC 4627 hat JSON sehr breite Verwendung gefunden. Diese Erfahrung hat bestimmte Muster aufgedeckt, die, obwohl von den Spezifikationen erlaubt, zu Interoperabilitätsproblemen geführt haben.

Darüber hinaus wurden eine kleine Anzahl von Errata gemeldet (siehe RFC-Erratum-IDs 607 [Err607] und 3607 [Err3607]).

Das Ziel dieses Dokuments ist es, diese Errata anzuwenden, Inkonsistenzen mit anderen JSON-Spezifikationen zu beseitigen und Praktiken hervorzuheben, die zu Interoperabilitätsproblemen führen können.

2. JSON Grammar (JSON-Grammatik)​

Ein JSON-Text ist eine Sequenz von Token. Der Token-Satz umfasst sechs strukturelle Zeichen, Strings, Zahlen und drei literale Namen.

Ein JSON-Text ist ein serialisierter Wert. Beachten Sie, dass bestimmte frühere JSON-Spezifikationen einen JSON-Text auf ein Objekt oder ein Array beschränkten. Implementierungen, die nur Objekte oder Arrays erzeugen, wo ein JSON-Text erforderlich ist, werden interoperabel sein, da alle Implementierungen diese als konforme JSON-Texte akzeptieren werden.

JSON-text = ws value ws

Dies sind die sechs strukturellen Zeichen:

begin-array     = ws %x5B ws  ; [ linke eckige Klammer
begin-object    = ws %x7B ws  ; { linke geschweifte Klammer
end-array       = ws %x5D ws  ; ] rechte eckige Klammer
end-object      = ws %x7D ws  ; } rechte geschweifte Klammer
name-separator  = ws %x3A ws  ; : Doppelpunkt
value-separator = ws %x2C ws  ; , Komma

Unbedeutender Whitespace ist vor oder nach einem der sechs strukturellen Zeichen erlaubt.

ws = *(
        %x20 /              ; Leerzeichen (Space)
        %x09 /              ; Horizontaler Tabulator (Horizontal tab)
        %x0A /              ; Zeilenvorschub (Line feed or New line)
        %x0D )              ; Wagenrücklauf (Carriage return)

7. Strings (Zeichenketten)​

Die Darstellung von Strings ähnelt den Konventionen der C-Familie von Programmiersprachen. Ein String beginnt und endet mit Anführungszeichen. Alle Unicode-Zeichen können innerhalb der Anführungszeichen platziert werden, mit Ausnahme der Zeichen, die escaped werden müssen: Anführungszeichen, Backslash und Steuerzeichen (U+0000 bis U+001F).

Jedes Zeichen kann escaped werden. Wenn das Zeichen in der Basic Multilingual Plane (BMP) (U+0000 bis U+FFFF) liegt, kann es als Sechs-Zeichen-Sequenz dargestellt werden: ein Backslash, gefolgt vom Kleinbuchstaben u, gefolgt von vier Hexadezimalziffern, die den Codepunkt des Zeichens kodieren. Die Hexadezimalbuchstaben A bis F können groß oder klein geschrieben werden. So kann beispielsweise ein String, der nur ein einzelnes Backslash-Zeichen enthält, als "\u005C" dargestellt werden.

Alternativ gibt es Zwei-Zeichen-Sequenz-Escape-Darstellungen für einige häufig verwendete Zeichen. So kann beispielsweise ein String, der nur ein einzelnes Backslash-Zeichen enthält, kompakter als "\\" dargestellt werden.

Um ein erweitertes Zeichen zu escapen, das nicht in der Basic Multilingual Plane liegt, wird das Zeichen als 12-Zeichen-Sequenz dargestellt, die ein UTF-16-Surrogat-Paar kodiert. So kann beispielsweise ein String, der nur das G-Schlüssel-Zeichen (U+1D11E) enthält, als "\uD834\uDD1E" dargestellt werden.

string = quotation-mark *char quotation-mark

char = unescaped /
    escape (
        %x22 /          ; "    Anführungszeichen  U+0022
        %x5C /          ; \    Backslash          U+005C
        %x2F /          ; /    Schrägstrich       U+002F
        %x62 /          ; b    Backspace          U+0008
        %x66 /          ; f    Form Feed          U+000C
        %x6E /          ; n    Zeilenvorschub     U+000A
        %x72 /          ; r    Wagenrücklauf      U+000D
        %x74 /          ; t    Tabulator          U+0009
        %x75 4HEXDIG )  ; uXXXX                   U+XXXX

escape = %x5C              ; \

quotation-mark = %x22      ; "

unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

8. String and Character Issues (Zeichenketten- und Zeichenprobleme)​

8.1. Character Encoding (Zeichenkodierung)​

JSON-Text SHALL mit UTF-8, UTF-16 oder UTF-32 kodiert werden. Die Standardkodierung ist UTF-8, und JSON-Text, der in UTF-8 kodiert ist, ist interoperabel, da er von der größten Anzahl von Implementierungen erfolgreich gelesen wird; es gibt viele Implementierungen, die Texte in anderen Kodierungen (wie UTF-16 und UTF-32) nicht erfolgreich lesen können.

Implementierungen MÜSSEN NICHT ein Byte-Order-Mark (BOM) am Anfang eines JSON-Texts hinzufügen. Für die Interoperabilität KÖNNEN Implementierungen, die JSON-Text parsen, die Anwesenheit eines Byte-Order-Marks ignorieren, anstatt es als Fehler zu behandeln.

8.2. Unicode Characters (Unicode-Zeichen)​

Wenn alle im JSON-Text dargestellten Strings vollständig aus Unicode-Zeichen [UNICODE] bestehen (unabhängig davon, wie sie escaped sind), ist dieser JSON-Text interoperabel, da alle Softwareimplementierungen, die ihn parsen, über den Inhalt von Namen und String-Werten in Objekten und Arrays übereinstimmen werden.

Das ABNF in dieser Spezifikation erlaubt jedoch, dass Mitgliedsnamen und String-Werte Bitsequenzen enthalten, die keine Unicode-Zeichen kodieren können; zum Beispiel "\uDEAD" (ein einzelnes ungepaartes UTF-16-Surrogat). Es wurden Instanzen dieser Situation beobachtet, beispielsweise wenn Bibliotheken UTF-16-Strings abschneiden, ohne zu prüfen, ob das Abschneiden ein Surrogat-Paar trennt. Das Verhalten von Software, die JSON-Text mit solchen Werten empfängt, ist unvorhersehbar; zum Beispiel können Implementierungen unterschiedliche Werte für die Länge von String-Werten zurückgeben oder sogar fatale Laufzeitausnahmen erleiden.

8.3. String Comparison (String-Vergleich)​

Softwareimplementierungen müssen häufig die Gleichheit von Objektmitgliedsnamen testen. Implementierungen, die die Textdarstellung in eine Sequenz von Unicode-Codeeinheiten umwandeln und dann einen numerischen Vergleich Codeeinheit für Codeeinheit durchführen, sind interoperabel, da Implementierungen in allen Fällen über die Gleichheit oder Ungleichheit zweier Strings übereinstimmen werden. Zum Beispiel könnten Implementierungen, die bedingungslos escaped Strings vergleichen, fälschlicherweise feststellen, dass "a\\b" und "a\u005Cb" nicht gleich sind.

9. Parsers (Parser)​

Ein JSON-Parser konvertiert JSON-Text in eine andere Darstellung. Ein JSON-Parser MUSS alle Texte akzeptieren, die der JSON-Grammatik entsprechen. Ein JSON-Parser KANN Nicht-JSON-Formen oder Erweiterungen akzeptieren.

Eine Implementierung kann Grenzen für die Größe der akzeptierten Texte setzen. Eine Implementierung kann Grenzen für die maximale Verschachtelungstiefe setzen. Eine Implementierung kann Grenzen für den Bereich und die Präzision von Zahlen setzen. Eine Implementierung kann Grenzen für die Länge und den Zeicheninhalt von Strings setzen.

10. Generators (Generatoren)​

Ein JSON-Generator erzeugt JSON-Text. Der erzeugte Text MUSS strikt der JSON-Grammatik entsprechen.

12. Security Considerations (Sicherheitsüberlegungen)​

Im Allgemeinen gibt es Sicherheitsprobleme mit Skriptsprachen. JSON ist eine Teilmenge von JavaScript, schließt jedoch Zuweisungen und Aufrufe aus.

Da die Syntax von JSON von JavaScript entlehnt ist, ist es möglich, die "eval()"-Funktion dieser Sprache zu verwenden, um JSON-Text zu parsen. Dies stellt in der Regel ein inakzeptables Sicherheitsrisiko dar, da der Text ausführbaren Code sowie Datendeklarationen enthalten kann. Dieselben Überlegungen gelten für die Verwendung eval()-ähnlicher Funktionen in jeder anderen Programmiersprache, in der JSON-Text der Syntax dieser Sprache entspricht.

14. Contributors (Mitwirkende)​

RFC 4627 wurde von Douglas Crockford verfasst. Dieses Dokument wurde durch relativ wenige Änderungen an diesem Dokument erstellt; daher stammt der Großteil des hier enthaltenen Textes von ihm.

Appendix A. Changes from RFC 4627 (Änderungen gegenüber RFC 4627)​

Dieser Abschnitt listet die Änderungen zwischen diesem Dokument und dem Text von RFC 4627 auf.

  • Titel und Zusammenfassung des Dokuments geändert

  • Verweis auf [UNICODE] geändert, um nicht versionsspezifisch zu sein

  • "JSON-Spezifikationen"-Abschnitt hinzugefügt

  • "Einführung in diese Revision"-Abschnitt hinzugefügt

  • Definition von "JSON-Text" geändert, sodass er ein beliebiger JSON-Wert sein kann, wobei die Einschränkung entfernt wurde, dass er ein Objekt oder Array sein muss

  • Sprache zu doppelten Objektmitgliedsnamen, Mitgliedsreihenfolge und Interoperabilität hinzugefügt

  • Klargestellt, dass Werte in einem Array nicht vom gleichen JSON-Typ sein müssen

  • RFC 4627 Erratum #607 angewendet, um die Diagrammausrichtung der "object"-Definition zu korrigieren

  • Im "Zahlen"-Abschnitt "as sequences of digits" in "in the grammar below" geändert und die dezimale Basis klargestellt

  • Sprache zur Zahleninteroperabilität als IEEE754-Funktion hinzugefügt und IEEE754-Referenz hinzugefügt

  • Sprache zur Interoperabilität und Unicode-Zeichen sowie zum String-Vergleich hinzugefügt. Dazu wurde der alte "Kodierung"-Abschnitt in den Abschnitt "String- und Zeichenprobleme" mit drei Unterabschnitten umgewandelt: "Zeichenkodierung", "Unicode-Zeichen" und "String-Vergleich"

  • Anleitung im "Parser"-Abschnitt geändert, um anzugeben, dass Implementierungen Grenzen für Bereich "und Präzision" von Zahlen setzen können

  • "IANA-Überlegungen"-Abschnitt aktualisiert und aufgeräumt

  • Echten "Sicherheitsüberlegungen"-Abschnitt erstellt und Text aus dem vorherigen "IANA-Überlegungen"-Abschnitt extrahiert

  • RFC 4627 Erratum #3607 angewendet, indem die Sicherheitsüberlegung, die mit "A JSON text can be safely passed" beginnt, sowie der mit dieser Überlegung verbundene JavaScript-Code entfernt wurden

  • Hinweis im "Sicherheitsüberlegungen"-Abschnitt hinzugefügt, der auf das Risiko der Verwendung der "eval()"-Funktion in JavaScript oder jeder anderen Sprache hinweist, in der JSON-Text der Syntax dieser Sprache entspricht

  • Hinweis in "IANA-Überlegungen" hinzugefügt, der klarstellt, dass dem application/json-Medientyp ein "charset"-Parameter fehlt

  • Im ersten Beispiel "100" in 100 geändert und ein boolesches Feld hinzugefügt

  • Beispiele für JSON-Texte mit einfachen Werten (weder Objekt noch Array) hinzugefügt

  • "Mitwirkende"-Abschnitt hinzugefügt, um Douglas Crockford zu danken

  • Verweis auf RFC 4627 hinzugefügt

  • ECMAScript-Referenz von normativ zu informativ verschoben und aktualisiert, um auf ECMAScript 5.1 zu verweisen, und Verweis auf ECMA 404 hinzugefügt