Binäre Daten in JSON-String. Etwas Besseres als Base64

Question

があります。 JSON-Format unterstützt von Haus aus keine Binärdaten. Die binären Daten müssen escaped werden, damit sie in ein String-Element (d. h. null oder mehr Unicode-Zeichen in Anführungszeichen mit Backslash-Escapes) in JSON eingefügt werden können.

Eine offensichtliche Methode zur Entschlüsselung von Binärdaten ist die Verwendung von Base64. Base64 ist jedoch mit einem hohen Verarbeitungsaufwand verbunden. Außerdem werden 3 Bytes in 4 Zeichen expandiert, was zu einer Erhöhung der Datengröße um etwa 33 % führt.

Ein Anwendungsfall hierfür ist der Entwurf v0.8 des Spezifikation der CDMI-Wolkenspeicher-API . Sie erstellen Datenobjekte über einen REST-Webservice unter Verwendung von JSON, z.B.

PUT /MyContainer/BinaryObject HTTP/1.1
Host: cloud.example.com
Accept: application/vnd.org.snia.cdmi.dataobject+json
Content-Type: application/vnd.org.snia.cdmi.dataobject+json
X-CDMI-Specification-Version: 1.0
{
    "mimetype" : "application/octet-stream",
    "metadata" : [ ],
    "value" :   "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
    IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
    dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
    dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
    ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=",
}

Gibt es bessere Möglichkeiten und Standardmethoden zur Kodierung von Binärdaten in JSON-Strings?

Answer 1

Es gibt 94 Unicode-Zeichen, die nach der JSON-Spezifikation als ein Byte dargestellt werden können (wenn Ihr JSON als UTF-8 übertragen wird). In Anbetracht dessen denke ich, dass das Beste, was Sie platztechnisch tun können, ist Basis85 was vier Bytes als fünf Zeichen darstellt. Dies ist jedoch nur eine 7 %ige Verbesserung gegenüber base64, die Berechnung ist teurer, und Implementierungen sind weniger verbreitet als bei base64, so dass es wahrscheinlich kein Gewinn ist.

Sie könnten auch einfach jedes Eingabebyte auf das entsprechende Zeichen in U+0000-U+00FF abbilden und dann die vom JSON-Standard geforderte Mindestkodierung durchführen, um diese Zeichen weiterzugeben; der Vorteil hier ist, dass die erforderliche Dekodierung über die eingebauten Funktionen hinaus gleich Null ist, aber die Raumeffizienz ist schlecht - eine 105%ige Expansion (wenn alle Eingabebytes gleich wahrscheinlich sind) gegenüber 25% für base85 oder 33% für base64.

Endgültige Entscheidung: base64 gewinnt meiner Meinung nach, weil es verbreitet, einfach und nicht schlecht ist. genug um einen Austausch zu rechtfertigen.

Siehe auch: Basis91 et Basis122

Answer 2

Ich bin auf das gleiche Problem gestoßen und dachte, ich könnte eine Lösung anbieten: multipart/form-data.

Beim Senden eines mehrteiligen Formulars senden Sie zunächst als String Ihre JSON-Metadaten und dann separat als Rohbinärdatei (Bild(er), wavs, etc.), indiziert durch den Inhalt-Disposition Name.

Hier ist eine schöne Lehrgang wie man das in Obj-C macht, und hier ist ein Blog-Artikel die erklärt, wie man die Zeichenkettendaten mit der Formulargrenze partitioniert und von den Binärdaten trennt.

Die einzige Änderung, die Sie wirklich vornehmen müssen, ist auf der Serverseite; Sie müssen Ihre Metadaten erfassen, die die POST'ed-Binärdaten entsprechend referenzieren sollten (durch Verwendung einer Content-Disposition-Grenze).

Zugegeben, es erfordert zusätzliche Arbeit auf der Serverseite, aber wenn Sie viele oder große Bilder versenden, ist es das wert. Kombinieren Sie dies mit gzip-Komprimierung, wenn Sie möchten.

IMHO ist das Senden von base64-kodierten Daten ein Hack; der RFC multipart/form-data wurde für Probleme wie dieses geschaffen: Senden von Binärdaten in Kombination mit Text oder Metadaten.

Answer 3

Das Problem mit UTF-8 ist, dass es nicht die platzsparendste Kodierung ist. Außerdem sind einige zufällige binäre Bytefolgen in der UTF-8-Kodierung ungültig. Man kann also nicht einfach eine zufällige binäre Bytefolge als UTF-8-Daten interpretieren, weil sie eine ungültige UTF-8-Kodierung ist. Der Vorteil dieser Einschränkung der UTF-8-Kodierung besteht darin, dass sie robust ist und es möglich macht, Mehrbyte-Zeichen am Anfang und am Ende zu lokalisieren, unabhängig davon, welches Byte wir zu Beginn betrachten.

Dies hat zur Folge, dass die Kodierung eines Byte-Wertes im Bereich [0..127] bei der UTF-8-Kodierung nur ein Byte benötigt, während die Kodierung eines Byte-Wertes im Bereich [128..255] 2 Bytes erfordert! Und es kommt noch schlimmer. In JSON dürfen Steuerzeichen, " und \ nicht in einer Zeichenfolge erscheinen. Die binären Daten müssten also umgewandelt werden, um richtig kodiert zu werden.

Mal sehen. Wenn wir von gleichmäßig verteilten, zufälligen Byte-Werten in unseren Binärdaten ausgehen, würde im Durchschnitt die Hälfte der Bytes in einem Byte und die andere Hälfte in zwei Bytes kodiert werden. Die UTF-8-kodierten Binärdaten hätten dann 150 % der ursprünglichen Größe.

Die Base64-Kodierung wächst nur auf 133 % der ursprünglichen Größe. Die Base64-Kodierung ist also effizienter.

Wie wäre es mit der Verwendung einer anderen Base-Kodierung? In UTF-8 ist die Kodierung der 128 ASCII-Werte am platzsparendsten. In 8 Bits können Sie 7 Bits speichern. Wenn wir also die binären Daten in 7-Bit-Stücke zerschneiden, um sie in jedem Byte einer UTF-8-kodierten Zeichenfolge zu speichern, würden die kodierten Daten nur auf 114 % der ursprünglichen Größe anwachsen. Besser als Base64. Leider können wir diesen einfachen Trick nicht anwenden, da JSON einige ASCII-Zeichen nicht zulässt. Die 33 Steuerzeichen von ASCII ( [0..31] und 127) und die " und \ müssen ausgeschlossen werden. Damit bleiben uns nur 128-35 = 93 Zeichen.

Theoretisch könnten wir also eine Base93-Kodierung definieren, die die kodierte Größe auf 8/log2(93) = 8*log10(2)/log10(93) = 122% erhöhen würde. Aber eine Base93-Kodierung wäre nicht so praktisch wie eine Base64-Kodierung. Bei Base64 muss die eingegebene Bytefolge in 6-Bit-Blöcke zerlegt werden, wofür eine einfache bitweise Operation gut geeignet ist. Außerdem ist 133% nicht viel mehr als 122%.

Deshalb bin ich unabhängig davon zu dem gemeinsamen Schluss gekommen, dass Base64 tatsächlich die beste Wahl für die Kodierung von Binärdaten in JSON ist. Meine Antwort enthält eine Rechtfertigung dafür. Ich stimme zu, dass es aus Sicht der Leistung nicht sehr attraktiv ist, aber bedenken Sie auch den Vorteil der Verwendung von JSON mit seiner menschenlesbaren Zeichenkettendarstellung, die in allen Programmiersprachen leicht zu bearbeiten ist.

Wenn die Leistung entscheidend ist, sollte eine rein binäre Kodierung als Ersatz für JSON in Betracht gezogen werden. Aber mit JSON ist meine Schlussfolgerung, dass Base64 die beste ist.

Answer 4

BSON (Binary JSON) könnte für Sie geeignet sein. http://en.wikipedia.org/wiki/BSON

Bearbeiten: Zu Ihrer Information: Die .NET-Bibliothek json.net unterstützt das Lesen und Schreiben von bson, wenn Sie auf der Suche nach etwas C# Server Seite Liebe sind.

Answer 5

Wenn Sie mit Bandbreitenproblemen zu kämpfen haben, versuchen Sie, die Daten zuerst auf der Client-Seite zu komprimieren und dann base64-it.

Ein schönes Beispiel für solche Magie finden Sie unter http://jszip.stuartk.co.uk/ und weitere Diskussionen zu diesem Thema finden Sie unter JavaScript-Implementierung von Gzip