Binärdaten in JSON-Zeichenfolge. Etwas besseres als Base64

614

Das JSON-Format unterstützt nativ keine Binärdaten. Die Binärdaten müssen maskiert werden, damit sie in JSON in ein Zeichenfolgenelement (dh null oder mehr Unicode-Zeichen in doppelten Anführungszeichen mit umgekehrten Schrägstrichen) eingefügt werden können.

Eine naheliegende Methode, um Binärdaten zu umgehen, ist die Verwendung von Base64. Base64 hat jedoch einen hohen Verarbeitungsaufwand. Außerdem werden 3 Bytes in 4 Zeichen erweitert, was zu einer Erhöhung der Datengröße um etwa 33% führt.

Ein Anwendungsfall hierfür ist der Entwurf v0.8 der CDMI-Cloud-Speicher-API-Spezifikation . Sie erstellen Datenobjekte über einen REST-Webservice mit JSON, z

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, um Binärdaten in JSON-Zeichenfolgen zu codieren?

dmeister
quelle
30
Zum Hochladen: Sie machen es nur einmal, es ist also keine so große Sache. Beim Herunterladen werden Sie möglicherweise überrascht sein, wie gut base64 unter gzip komprimiert wird. Wenn Sie also gzip auf Ihrem Server aktiviert haben, sind Sie wahrscheinlich auch in Ordnung.
Wolkenfüße
2
Eine weitere würdige Lösung msgpack.org für die Hardcore-Nerds: github.com/msgpack/msgpack/blob/master/spec.md
nicolallias
2
@cloudfeet, Einmal pro Benutzer und Aktion . Sehr große Sache.
Pacerier
2
Beachten Sie, dass Zeichen normalerweise jeweils 2 Byte Speicher umfassen . Daher könnte base64 + 33% (4/3) Overhead auf dem Draht verursachen, aber das Aufbringen dieser Daten auf den Draht, das Abrufen und Verwenden dieser Daten würde einen Overhead von + 166% (8/3) erfordern . Beispiel: Wenn eine Javascript-Zeichenfolge eine maximale Länge von 100.000 Zeichen hat, können Sie mit base64 nur 37,5 KB Daten darstellen, nicht 75 KB Daten, nicht 75 KB Daten. Diese Zahlen können ein Engpass in vielen Teilen der Anwendung sein, z JSON.parse. B. usw. ......
Pacerier
5
@Pacerier "normalerweise 2 Byte Speicher [pro Zeichen]" ist nicht genau. v8 verfügt beispielsweise über OneByte- und TwoByte-Zeichenfolgen. Zwei-Byte-Zeichenfolgen werden nur bei Bedarf verwendet, um einen grotesken Speicherverbrauch zu vermeiden. Base64 ist mit Ein-Byte-Zeichenfolgen codierbar.
ZachB

Antworten:

459

Es gibt 94 Unicode-Zeichen, die gemäß der JSON-Spezifikation als ein Byte dargestellt werden können (wenn Ihr JSON als UTF-8 übertragen wird). In diesem Sinne denke ich, dass das Beste, was Sie räumlich tun können, base85 ist, das vier Bytes als fünf Zeichen darstellt. Dies ist jedoch nur eine Verbesserung von 7% gegenüber base64, die Berechnung ist teurer und Implementierungen sind seltener als bei base64, sodass es wahrscheinlich kein Gewinn ist.

Sie können auch einfach jedes Eingabebyte dem entsprechenden Zeichen in U + 0000-U + 00FF zuordnen und dann die vom JSON-Standard erforderliche Mindestcodierung ausführen, um diese Zeichen zu übergeben. Der Vorteil hierbei ist, dass die erforderliche Decodierung nicht über die integrierten Funktionen hinausgeht, die Raumeffizienz jedoch schlecht ist - eine Erweiterung um 105% (wenn alle Eingangsbytes gleich wahrscheinlich sind) gegenüber 25% für base85 oder 33% für base64.

Endgültiges Urteil: base64 gewinnt meiner Meinung nach mit der Begründung, dass es üblich, einfach und nicht schlecht genug ist , um einen Ersatz zu rechtfertigen.

Siehe auch: Base91 und Base122

Hobbs
quelle
5
Warten Sie, wie ist nur die Verwendung des tatsächlichen Bytes beim Codieren der Anführungszeichen eine 105% ige Erweiterung und base64 nur 33%? Ist base64 nicht 133%?
jjxtra
17
Base91 ist eine schlechte Idee für JSON, da es ein Zitat im Alphabet enthält. Im schlimmsten Fall (alle Anführungszeichen werden ausgegeben) nach der JSON-Codierung beträgt sie 245% der ursprünglichen Nutzlast.
Jarnoh
25
Python 3.4 enthält base64.b85encode()und b85decode()jetzt. Eine einfache Codierungs- / Decodierungs-Timing-Messung zeigt, dass b85 mehr als 13-mal langsamer als b64 ist. Wir haben also einen Größengewinn von 7%, aber einen Leistungsverlust von 1300%.
Pieter Ennes
3
@hobbs JSON gibt an, dass Steuerzeichen maskiert werden müssen. RFC20-Abschnitt 5.2 definiert DELals Steuerzeichen.
Tino
2
@Tino ECMA-404 listet speziell die Zeichen auf, die maskiert werden müssen: das doppelte Anführungszeichen U + 0022, der umgekehrte Schrägstrich U + 005C und "die Steuerzeichen U + 0000 bis U + 001F".
Hobbs
249

Ich stieß auf dasselbe Problem und dachte, ich würde eine Lösung teilen: mehrteilige / Formulardaten.

Durch das Senden eines mehrteiligen Formulars senden Sie zuerst Ihre JSON-Metadaten als Zeichenfolge und dann separat als rohe Binärdatei (Bilder, Wellen usw.), die durch den Namen der Inhaltsdisposition indiziert ist .

Hier ist ein nettes Tutorial, wie dies in obj-c gemacht wird, und hier ist ein Blog-Artikel , in dem erklärt wird, wie die Zeichenfolgendaten mit der Formulargrenze partitioniert und von den Binärdaten getrennt werden.

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

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

IMHO ist das Senden von Base64-codierten Daten ein Hack; Die RFC-Multipart- / Formulardaten wurden für folgende Probleme erstellt: Senden von Binärdaten in Kombination mit Text oder Metadaten.

Ælex
quelle
4
Die Google Drive-API macht das übrigens folgendermaßen: developer.google.com/drive/v2/reference/files/update#examples
Mathias Conradt
2
Warum ist diese Antwort so niedrig, wenn native Funktionen verwendet werden, anstatt zu versuchen, einen runden (binären) Stift in ein quadratisches (ASCII) Loch zu drücken? ...
Mark K Cowan
5
Das Senden von Base64-codierten Daten ist ein Hack, ebenso wie Multipart- / Formulardaten. Sogar der Blog-Artikel, den Sie verlinkt haben, lautet: Wenn Sie die mehrteiligen / Formulardaten des Inhaltstyps verwenden, geben Sie an, dass das, was Sie senden, tatsächlich ein Formular ist. Aber es ist nicht. Daher denke ich, dass der base64-Hack nicht nur viel einfacher zu implementieren, sondern auch zuverlässiger ist. Ich habe einige Bibliotheken gesehen (zum Beispiel für Python), deren Inhaltstyp für mehrteilige / Formulardaten fest codiert war.
t3chb0t
4
@ t3chb0t Der Medientyp Multipart / Formulardaten wurde für den Transport von Formulardaten entwickelt. Heute wird er jedoch außerhalb der HTTP / HTML-Welt häufig verwendet, insbesondere zum Codieren von E-Mail-Inhalten. Heute wird es als generische Codierungssyntax vorgeschlagen. tools.ietf.org/html/rfc7578
Lorenzo
3
@MarkKCowan Wahrscheinlich, weil dies zwar für den Zweck der Frage hilfreich ist, die gestellte Frage jedoch nicht beantwortet wird. Dies ist effektiv "Binär-zu-Text-Codierung mit geringem Overhead für die Verwendung in JSON". Diese Antwort führt jedoch zu einer vollständigen Beeinträchtigung von JSON.
Chinoto Vokro
34

Das Problem mit UTF-8 ist, dass es nicht die platzsparendste Codierung ist. Einige zufällige binäre Byte-Sequenzen sind auch ungültig UTF-8-Codierung. Sie können eine zufällige binäre Byte-Sequenz also nicht einfach als UTF-8-Daten interpretieren, da dies eine ungültige UTF-8-Codierung ist. Der Vorteil dieser Einschränkung bei der UTF-8-Codierung besteht darin, dass es robust und möglich ist, Multi-Byte-Zeichen zu finden, die beginnen und enden, egal welches Byte wir betrachten.

Wenn für die Codierung eines Bytewerts im Bereich [0..127] nur ein Byte für die UTF-8-Codierung erforderlich wäre, wären für die Codierung eines Bytewerts im Bereich [128..255] 2 Bytes erforderlich! Schlimmer als das. In JSON dürfen die Steuerzeichen "und \ nicht in einer Zeichenfolge erscheinen. Daher müssten für die Binärdaten einige Transformationen ordnungsgemäß codiert werden.

Mal sehen. Wenn wir gleichmäßig verteilte zufällige Bytewerte in unseren Binärdaten annehmen, wird durchschnittlich die Hälfte der Bytes in einem Byte und die andere Hälfte in zwei Bytes codiert. Die UTF-8-codierten Binärdaten hätten 150% der ursprünglichen Größe.

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

Was ist mit einer anderen Basiscodierung? In UTF-8 ist die Codierung der 128 ASCII-Werte am platzsparendsten. In 8 Bits können Sie 7 Bits speichern. Wenn wir also die Binärdaten in 7-Bit-Blöcke schneiden, um sie in jedem Byte einer UTF-8-codierten Zeichenfolge zu speichern, würden die codierten Daten nur auf 114% der ursprünglichen Größe anwachsen. Besser als Base64. Leider können wir diesen einfachen Trick nicht verwenden, da JSON einige ASCII-Zeichen nicht zulässt. Die 33 Steuerzeichen von ASCII ([0..31] und 127) und "und \" müssen ausgeschlossen werden. Dies lässt nur 128-35 = 93 Zeichen übrig.

Theoretisch könnten wir also eine Base93-Codierung definieren, die die codierte Größe auf 8 / log2 (93) = 8 * log10 (2) / log10 (93) = 122% erhöht. Eine Base93-Codierung wäre jedoch nicht so praktisch wie eine Base64-Codierung. Base64 muss die Eingangsbyte-Sequenz in 6-Bit-Blöcke schneiden, für die eine einfache bitweise Operation gut funktioniert. Neben 133% sind es nicht viel mehr als 122%.

Aus diesem Grund bin ich unabhängig zu dem allgemeinen Schluss gekommen, dass Base64 in der Tat die beste Wahl ist, um Binärdaten in JSON zu codieren. Meine Antwort ist eine Rechtfertigung dafür. Ich bin damit einverstanden, dass es aus Sicht der Leistung nicht sehr attraktiv ist, aber berücksichtigen Sie auch den Vorteil der Verwendung von JSON mit seiner von Menschen lesbaren Zeichenfolgendarstellung, die in allen Programmiersprachen leicht zu manipulieren ist.

Wenn die Leistung kritisch ist, sollte eine reine Binärcodierung als Ersatz für JSON betrachtet werden. Aber mit JSON ist meine Schlussfolgerung, dass Base64 das Beste ist.

chmike
quelle
Was ist mit Base128, aber dann den JSON-Serializer dem "und \" entkommen lassen? Ich denke, es ist vernünftig zu erwarten, dass der Benutzer eine JSON-Parser-Implementierung verwendet.
Jcalfee314
1
@ jcalfee314 Dies ist leider nicht möglich, da Zeichen mit ASCII-Code unter 32 in JSON-Zeichenfolgen nicht zulässig sind. Codierungen mit einer Basis zwischen 64 und 128 wurden bereits definiert, aber die erforderliche Berechnung ist höher als base64. Der Gewinn an codierter Textgröße ist es nicht wert.
Chmike
Wenn Sie eine große Anzahl von Bildern in base64 laden (sagen wir 1000) oder über eine sehr langsame Verbindung laden, würden base85 oder base93 jemals für den reduzierten Netzwerkverkehr (ohne oder ohne gzip) bezahlen? Ich bin gespannt, ob es irgendwann einen Punkt gibt, an dem die kompakteren Daten für eine der alternativen Methoden sprechen würden.
Vol7ron
Ich vermute, dass die Rechengeschwindigkeit wichtiger ist als die Übertragungszeit. Bilder sollten natürlich auf der Serverseite vorberechnet werden. Die Schlussfolgerung ist jedenfalls, dass JSON schlecht für Binärdaten ist.
Chmike
Zu "Die Base64-Codierung wächst nur auf 133% der ursprünglichen Größe. Die Base64-Codierung ist also effizienter " ist völlig falsch, da die Zeichen normalerweise jeweils 2 Byte groß sind. Siehe Ausarbeitung unter stackoverflow.com/questions/1443158/…
Pacerier
34

BSON (Binary JSON) kann für Sie arbeiten. 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 nach einer Liebe auf der C # -Serverseite suchen.

DarcyThomas
quelle
1
"In einigen Fällen verwendet BSON aufgrund der Längenpräfixe und expliziten Array-Indizes mehr Speicherplatz als JSON." en.wikipedia.org/wiki/BSON
Pawel Cioch
Gute Nachrichten: BSON unterstützt nativ Typen wie Binary, Datetime und einige andere (besonders nützlich, wenn Sie MongoDB verwenden). Schlechte Nachrichten: Die Codierung besteht aus binären Bytes. Es handelt sich also nicht um eine Antwort auf das OP. Es wäre jedoch nützlich über einen Kanal, der Binärdaten nativ unterstützt, z. B. RabbitMQ-Nachricht, ZeroMQ-Nachricht oder einen benutzerdefinierten TCP- oder UDP-Socket.
Dan H
19

Wenn Sie mit Bandbreitenproblemen zu tun haben, versuchen Sie zuerst, Daten auf der Clientseite und dann auf base64-it zu komprimieren.

Ein gutes Beispiel für solche Magie finden Sie unter http://jszip.stuartk.co.uk/. Weitere Informationen zu diesem Thema finden Sie in der JavaScript-Implementierung von Gzip

andrej
quelle
2
Hier ist eine JavaScript-Zip-Implementierung, die eine bessere Leistung beansprucht: zip.js
Janus Troelsen
Beachten Sie, dass Sie auch danach (normalerweise über Content-Encoding) noch komprimieren können (und sollten ), da base64 ziemlich gut komprimiert.
Mahmoud Al-Qudsi
@ MahmoudAl-Qudsi meintest du, dass du base64 (zip (base64 (zip (data))))? Ich bin mir nicht sicher, ob es eine gute Idee ist, eine weitere Zip-Datei hinzuzufügen und diese dann base64 (um sie als Daten senden zu können).
Andrej
18

yEnc könnte für Sie arbeiten:

http://en.wikipedia.org/wiki/Yenc

"yEnc ist ein Binär-zu-Text-Codierungsschema zum Übertragen von Binärdateien in [Text]. Es reduziert den Overhead gegenüber früheren US-ASCII-basierten Codierungsmethoden durch Verwendung einer erweiterten 8-Bit-ASCII-Codierungsmethode. Der Overhead von yEnc ist häufig (wenn Jeder Byte-Wert erscheint ungefähr mit der gleichen Häufigkeit im Durchschnitt (nur 1–2%, verglichen mit 33% –40% Overhead für 6-Bit-Codierungsmethoden wie Uuencode und Base64. ... Bis 2003 wurde yEnc zum De-facto-Standard Codierungssystem für Binärdateien im Usenet. "

YEnc ist jedoch eine 8-Bit-Codierung. Das Speichern in einer JSON-Zeichenfolge hat also die gleichen Probleme wie das Speichern der ursprünglichen Binärdaten. Wenn Sie dies auf naive Weise tun, bedeutet dies eine 100% ige Erweiterung, die schlechter als base64 ist.

richardtallent
quelle
42
Da viele Leute diese Frage immer noch zu sehen scheinen, möchte ich erwähnen, dass ich nicht denke, dass yEnc hier wirklich hilft. yEnc ist eine 8-Bit-Codierung, daher hat das Speichern in einer JSON-Zeichenfolge die gleichen Probleme wie das Speichern der ursprünglichen Binärdaten. Wenn Sie dies auf naive Weise tun, bedeutet dies eine 100% ige Erweiterung, die schlechter ist als base64.
Hobbs
In Fällen, in denen die Verwendung von Codierungen wie yEnc mit großen Alphabeten mit JSON-Daten als akzeptabel angesehen wird, kann Escapeeless eine gute Alternative sein, um einen im Voraus bekannten Overhead bereitzustellen .
Ivan Kosarev
10

Es stimmt zwar, dass base64 eine Expansionsrate von ~ 33% aufweist, aber es ist nicht unbedingt richtig, dass der Verarbeitungsaufwand erheblich höher ist: Dies hängt wirklich von der von Ihnen verwendeten JSON-Bibliothek / dem von Ihnen verwendeten Toolkit ab. Codierung und Decodierung sind einfache, unkomplizierte Operationen und können sogar für die Zeichencodierung optimiert werden (da JSON nur UTF-8/16/32 unterstützt) - base64-Zeichen sind für JSON-Zeichenfolgeneinträge immer Einzelbyte. Auf der Java-Plattform gibt es beispielsweise Bibliotheken, die die Arbeit ziemlich effizient erledigen können, sodass der Overhead hauptsächlich auf die erweiterte Größe zurückzuführen ist.

Ich stimme zwei früheren Antworten zu:

  • base64 ist ein einfacher, häufig verwendeter Standard, daher ist es unwahrscheinlich, dass es etwas Besseres für die Verwendung mit JSON gibt (base-85 wird von Postscript usw. verwendet; die Vorteile sind jedoch bestenfalls marginal, wenn Sie darüber nachdenken).
  • Die Komprimierung vor dem Codieren (und nach dem Decodieren) kann je nach den von Ihnen verwendeten Daten sehr sinnvoll sein
StaxMan
quelle
10

Lächeln-Format

Es ist sehr schnell zu kodieren, zu dekodieren und zu kompaktieren

Geschwindigkeitsvergleich (Java-basiert, aber dennoch aussagekräftig): https://github.com/eishay/jvm-serializers/wiki/

Es ist auch eine Erweiterung von JSON, mit der Sie die Base64-Codierung für Byte-Arrays überspringen können

Smile-codierte Zeichenfolgen können komprimiert werden, wenn der Speicherplatz kritisch ist

Stefano Fratini
quelle
3
... und der Link ist tot. Dieser scheint auf dem neuesten Stand zu sein: github.com/FasterXML/smile-format-specification
Zero3
4

( 7 Jahre später bearbeiten: Google Gears ist weg. Ignorieren Sie diese Antwort.)


Das Google Gears-Team ist auf das Problem des Mangels an binären Datentypen gestoßen und hat versucht, es zu beheben:

Blob-API

JavaScript verfügt über einen integrierten Datentyp für Textzeichenfolgen, jedoch nichts für Binärdaten. Das Blob-Objekt versucht, diese Einschränkung zu beheben.

Vielleicht kannst du das irgendwie einweben.

ein bezahlter Nerd
quelle
Wie ist der Status von Blobs in Javascript und Json? Wurde es fallen gelassen?
chmike
w3.org/TR/FileAPI/#blob-section Nicht so performant wie base64 für Speicherplatz. Wenn Sie nach unten scrollen, stellen Sie fest, dass die Codierung mithilfe der utf8-Map erfolgt (als eine der Optionen, die in der Antwort von hobbs angezeigt werden). Und keine json Unterstützung, soweit ich weiß
Daniele Cruciani
3

Da Sie nach der Möglichkeit suchen, Binärdaten in ein streng textbasiertes und sehr begrenztes Format umzuwandeln, ist der Overhead von Base64 meiner Meinung nach im Vergleich zu dem Komfort, den Sie mit JSON erwarten, minimal. Wenn Verarbeitungsleistung und Durchsatz ein Problem darstellen, müssen Sie wahrscheinlich Ihre Dateiformate überdenken.

jsoverson
quelle
2

Nur um der Diskussion den Ressourcen- und Komplexitätsstandpunkt hinzuzufügen. Da Sie PUT / POST und PATCH ausführen, um neue Ressourcen zu speichern und zu ändern, sollten Sie bedenken, dass die Inhaltsübertragung eine genaue Darstellung des Inhalts ist, der gespeichert wird und der durch Ausgeben einer GET-Operation empfangen wird.

Eine mehrteilige Nachricht wird oft als Retter verwendet, aber aus Gründen der Einfachheit und für komplexere Aufgaben bevorzuge ich die Idee, den Inhalt als Ganzes zu geben. Es ist selbsterklärend und einfach.

Und ja, JSON ist etwas Verkrüppelndes, aber am Ende ist JSON selbst ausführlich. Und der Aufwand für die Zuordnung zu BASE64 ist viel zu gering.

Wenn Sie mehrteilige Nachrichten korrekt verwenden, müssen Sie entweder das zu sendende Objekt zerlegen, einen Eigenschaftspfad als Parameternamen für die automatische Kombination verwenden oder ein anderes Protokoll / Format erstellen, um nur die Nutzdaten auszudrücken.

Auch der BSON-Ansatz ist nicht so weit verbreitet und einfach zu unterstützen, wie man es gerne hätte.

Grundsätzlich vermissen wir hier nur etwas, aber das Einbetten von Binärdaten als base64 ist gut etabliert und ein guter Weg, es sei denn, Sie haben wirklich die Notwendigkeit einer echten Binärübertragung erkannt (was selten der Fall ist).

Martin Kersten
quelle
1

Ich grabe ein bisschen mehr (während der Implementierung von base128 ) und stelle fest , dass wenn wir Zeichen senden, deren ASCII-Codes größer als 128 sind, der Browser (Chrome) tatsächlich ZWEI Zeichen (Bytes) anstelle von einem sendet :( . Der Grund ist, dass JSON Verwenden Sie standardmäßig utf8-Zeichen, für die Zeichen mit ASCII-Codes über 127 durch zwei Bytes codiert sind, was in der Antwort von chmike erwähnt wurde . Ich habe den Test folgendermaßen durchgeführt: Geben Sie chrome url bar chrome: // net-export / ein und wählen Sie "Include raw" Bytes ", starten Sie die Erfassung, senden Sie POST-Anforderungen (mithilfe des Snippets unten), beenden Sie die Erfassung und speichern Sie die JSON-Datei mit Rohanforderungsdaten. Dann schauen wir uns diese JSON-Datei an:

  • Wir können unsere base64-Anfrage finden, indem wir einen String finden, 4142434445464748494a4b4c4d4edessen Hex-Codierung ist, ABCDEFGHIJKLMNund wir werden das "byte_count": 639dafür sehen.
  • Wir können unsere obige 127-Anfrage finden, indem wir eine Zeichenfolge finden. C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38BDies sind Request-Hex-Utf8-Codes von Zeichen ¼½ÀÁÂÃÄÅÆÇÈÉÊË(jedoch sind die ASCII-Hex-Codes dieser Zeichen c1c2c3c4c5c6c7c8c9cacbcccdce). Das "byte_count": 703ist also 64 Bytes länger als die Base64-Anfrage, da Zeichen mit ASCII-Codes über 127 in der Anfrage Code für 2 Bytes sind :(

Tatsächlich haben wir also keinen Gewinn mit dem Senden von Zeichen mit Codes> 127 :(. Für base64-Zeichenfolgen beobachten wir kein derart negatives Verhalten (wahrscheinlich auch für base85 - ich überprüfe es nicht) - es kann jedoch eine Lösung für dieses Problem sein Senden von Daten im binären Teil der in Ælex answer beschriebenen POST-Multipart- / Formulardaten (in diesem Fall müssen wir jedoch normalerweise überhaupt keine Basiscodierung verwenden ...).

Der alternative Ansatz kann darauf beruhen, zwei Bytes Datenabschnitt in ein gültiges utf8-Zeichen abzubilden , indem er mit so etwas wie base65280 / base65k codiert wird, aber aufgrund der utf8-Spezifikation wäre er wahrscheinlich weniger effektiv als base64 ...

Kamil Kiełczewski
quelle
0

Der Datentyp betrifft wirklich. Ich habe verschiedene Szenarien zum Senden der Nutzdaten von einer RESTful-Ressource getestet. Für die Codierung habe ich Base64 (Apache) und für die Komprimierung GZIP (java.utils.zip. *) Verwendet. Die Nutzdaten enthalten Informationen zu Film, Bild und Audiodatei. Ich habe die Bild- und Audiodateien komprimiert und codiert, was die Leistung drastisch verschlechterte. Die Codierung vor der Komprimierung verlief gut. Bild- und Audioinhalte wurden als codierte und komprimierte Bytes [] gesendet.

Koushik
quelle
0

Siehe: http://snia.org/sites/default/files/Multi-part%20MIME%20Extension%20v1.0g.pdf

Es wird eine Möglichkeit beschrieben, Binärdaten zwischen einem CDMI-Client und -Server mithilfe von Operationen des Typs "CDMI-Inhaltstyp" zu übertragen, ohne dass die Binärdaten von base64 konvertiert werden müssen.

Wenn Sie die Operation "Nicht-CDMI-Inhaltstyp" verwenden können, ist es ideal, "Daten" zu / von einem Objekt zu übertragen. Metadaten können später als nachfolgende Operation 'CDMI-Inhaltstyp' zum / vom Objekt hinzugefügt / abgerufen werden.

Dheeraj Sangamkar
quelle
-1

Meine Lösung, XHR2, verwendet ArrayBuffer. Der ArrayBuffer als Binärsequenz enthält mehrteilige Inhalte, Video, Audio, Grafik, Text usw. mit mehreren Inhaltstypen. Alles in einer Antwort.

In modernen Browsern mit DataView, StringView und Blob für verschiedene Komponenten. Siehe auch: http://rolfrost.de/video.html für weitere Details.

Rolf Rost
quelle
Sie werden Ihre Daten + 100% wachsen lassen, indem Sie ein Array von Bytes serialisieren
Sharcoux
@ Sharcoux wot?
Mihail Malostanidis
Die Serialisierung eines Byte-Arrays in JSON ist ungefähr so: Das [16, 2, 38, 89]ist sehr ineffizient.
Sharcoux