Zum Hauptinhalt springen

4. Konvertierung von Daten zwischen CBOR und JSON

Dieser Abschnitt gibt nicht-normative Hinweise zur Konvertierung zwischen CBOR und JSON. Implementierungen von Konvertern können die hier gegebenen Hinweise verwenden, welche sie möchten.

Es ist erwähnenswert, dass ein JSON-Text eine Folge von Zeichen ist, keine kodierte Folge von Bytes, während ein CBOR-Datenelement aus Bytes besteht, nicht aus Zeichen.

4.1. Konvertierung von CBOR nach JSON​

Die meisten Typen in CBOR haben direkte Entsprechungen in JSON. Manche jedoch nicht, und wer einen CBOR-nach-JSON-Konverter implementiert, muss überlegen, was in diesen Fällen zu tun ist. Die folgenden nicht-normativen Hinweise behandeln diese, indem sie sie in einen einzelnen Ersatzwert wie ein JSON-null konvertieren.

  • Eine ganze Zahl (Haupttyp 0 oder 1) wird zu einer JSON-Zahl.

  • Eine Byte-Zeichenfolge (Haupttyp 2), die nicht in ein Tag eingebettet ist, das eine vorgeschlagene Kodierung festlegt, wird ohne Padding in base64url kodiert und wird zu einer JSON-Zeichenfolge.

  • Eine UTF-8-Zeichenfolge (Haupttyp 3) wird zu einer JSON-Zeichenfolge. Hinweis: JSON erfordert die Maskierung ("escaping") bestimmter Zeichen (RFC 4627, Abschnitt 2.5): Anführungszeichen (U+0022), umgekehrter Schrägstrich (U+005C) und die "C0-Steuerzeichen" (U+0000 bis U+001F). Alle anderen Zeichen werden unverändert in die JSON-UTF-8-Zeichenfolge kopiert.

  • Ein Array (Haupttyp 4) wird zu einem JSON-Array.

  • Eine Map (Haupttyp 5) wird zu einem JSON-Objekt. Dies ist unmittelbar nur möglich, wenn alle Schlüssel UTF-8-Zeichenfolgen sind. Ein Konverter könnte auch andere Schlüssel in UTF-8-Zeichenfolgen konvertieren (beispielsweise indem er ganze Zahlen in Zeichenfolgen konvertiert, die deren Dezimaldarstellung enthalten); dies bringt jedoch die Gefahr eines Schlüsselkonflikts mit sich.

  • False (Haupttyp 7, zusätzliche Information 20) wird zu einem JSON-false.

  • True (Haupttyp 7, zusätzliche Information 21) wird zu einem JSON-true.

  • Null (Haupttyp 7, zusätzliche Information 22) wird zu einem JSON-null.

  • Ein Gleitkommawert (Haupttyp 7, zusätzliche Informationen 25 bis 27) wird zu einer JSON-Zahl, wenn er endlich ist (das heißt, wenn er in einer JSON-Zahl dargestellt werden kann); wenn der Wert nicht endlich ist (NaN oder positives oder negatives Infinity), wird er durch den Ersatzwert dargestellt.

  • Jeder andere einfache Wert (Haupttyp 7, jeder oben noch nicht behandelte Wert der zusätzlichen Informationen) wird durch den Ersatzwert dargestellt.

  • Ein Bignum (Haupttyp 6, Tag-Wert 2 oder 3) wird dargestellt, indem seine Byte-Zeichenfolge ohne Padding in base64url kodiert wird, und wird zu einer JSON-Zeichenfolge. Bei Tag-Wert 3 (negatives Bignum) wird vor den basis-kodierten Wert ein "~" (ASCII-Tilde) eingefügt. (Die Konvertierung in ein binäres Blob anstelle einer Zahl soll einen wahrscheinlichen numerischen Überlauf beim JSON-Decoder verhindern.)

  • Eine Byte-Zeichenfolge mit einem Kodierungshinweis (Haupttyp 6, Tag-Wert 21 bis 23) wird wie beschrieben kodiert und wird zu einer JSON-Zeichenfolge.

  • Bei allen anderen Tags (Haupttyp 6, jeder andere Tag-Wert) wird das eingebettete CBOR-Element als JSON-Wert dargestellt; der Tag-Wert wird ignoriert.

  • Elemente mit unbestimmter Länge werden vor der Konvertierung in Elemente mit bestimmter Länge umgewandelt.

4.2. Konvertierung von JSON nach CBOR​

Alle JSON-Werte lassen sich nach dem Dekodieren direkt auf einen oder mehrere CBOR-Werte abbilden. Wie bei jeder Art von CBOR-Erzeugung müssen Entscheidungen hinsichtlich der Zahlendarstellung getroffen werden. Bei einer vorgeschlagenen Konvertierung:

  • JSON-Zahlen ohne Bruchteile (ganze Zahlen) werden als ganze Zahlen dargestellt (Haupttypen 0 und 1, möglicherweise Haupttyp 6, Tag-Wert 2 und 3), wobei die kürzeste Form gewählt wird; ganze Zahlen, die länger als ein implementierungsdefinierter Schwellenwert sind (der üblicherweise entweder 32 oder 64 Bit beträgt), können stattdessen als Gleitkommawerte dargestellt werden. (Wenn das JSON von einer JavaScript-Implementierung erzeugt wurde, ist seine Genauigkeit bereits auf maximal 53 Bit begrenzt.)

  • Zahlen mit Bruchteilen werden als Gleitkommawerte dargestellt. Vorzugsweise wird die kürzeste exakte Gleitkommadarstellung verwendet; beispielsweise wird 1.5 in einem 16-Bit-Gleitkommawert dargestellt (allerdings werden nicht alle Implementierungen in der Lage sein, die Minimalform effizient zu finden). Es kann eine implementierungsdefinierte Grenze für die Genauigkeit geben, die sich auf die Genauigkeit der dargestellten Werte auswirkt. Die Dezimaldarstellung sollte nur verwendet werden, wenn dies in einem Protokoll festgelegt ist.

CBOR ist so entworfen, dass es im Allgemeinen eine kompaktere Kodierung bietet als JSON. Eine Implementierungsstrategie, die in den Sinn kommen könnte, besteht darin, eine JSON-nach-CBOR-Kodierung an Ort und Stelle in einem einzigen Puffer durchzuführen. Diese Strategie müsste eine Reihe pathologischer Fälle sorgfältig berücksichtigen, etwa dass manche Zeichenfolgen, die mit keinen oder sehr wenigen Maskierungen dargestellt werden und länger (oder viel länger) als 255 Bytes sind, sich bei der Kodierung als UTF-8-Zeichenfolgen in CBOR ausdehnen können. Ebenso könnten einige der binären Gleitkommadarstellungen eine Ausdehnung gegenüber manchen kurzen Dezimaldarstellungen (1.1, 1e9) in JSON verursachen. Dies kann schwer richtig hinzubekommen sein, und etwaige daraus entstehende Schwachstellen könnten von einem Angreifer ausgenutzt werden.