Binärdaten platzsparend in JSON speichern

[Sir Rufo]

Ja, darum kann man RTF (die zum Rendern benötigte Beschreibung mit Steuersequenzn und Text) auch in einem (Unicode-)String speichern.

Da so ein RTF aber auch sehr groß sein kann, macht es schon Sinn, den vor der Übertragung (z.B. per WebService nach Timbuktu) etwas kleiner zu machen.

Bearbeiten muss ich den auf jeden Fall, denn JSON ist UTF8 basiert und dann könnte die Größe u.U. explodieren (z.B. wenn jedes Zeichen im JSON als uXXXX dargestellt wird, dann hat man eine Vergrößerung der Daten um den Faktor 5)

Darum ist der Weg RTF-String ->

Delphi-Quellcode:

TEncoding.Unicode.GetBytes()

-> Komprimierung -> BASE64 -> JSON schon genau richtig.

Bei einem Projekt verwende ich genau dieses Verfahren (allerdings handelt es sich um (JPEG-)Bild-Daten, die dann BASE64-kodiert im JSON stehen).

[Phoenix]

Zitat:

Zitat von Sir Rufo (Beitrag 1309838)

Da so ein RTF aber auch sehr groß sein kann, macht es schon Sinn, den vor der Übertragung (z.B. per WebService nach Timbuktu) etwas kleiner zu machen.

Jain. Nicht zwangsläufig. Ein JSON (Text) via Webservice wird in den meisten Fällen eh für den Trip vom Webserver gzipped. Es müsste schon seeehr undankbar zugehen, wenn der abrufende Client kein gzip oder deflate versteht. Von daher ist der Gewinn an Platz hier eher irrelevant.

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1309838)

Bearbeiten muss ich den auf jeden Fall, denn JSON ist UTF8 basiert und dann könnte die Größe u.U. explodieren (z.B. wenn jedes Zeichen im JSON als uXXXX dargestellt wird, dann hat man eine Vergrößerung der Daten um den Faktor 5)

Warte mal ... JSON unterstützt so gut wie alle Unicode-Zeichen nicht-escaped in Strings. Im Schnitt sollte ein Text in UTF-8 nicht größer sein als mit UTF-16 (Widestring).

[Sir Rufo]

Zitat:

Zitat von BUG (Beitrag 1309840)

Zitat:

Zitat von Sir Rufo (Beitrag 1309838)

Bearbeiten muss ich den auf jeden Fall, denn JSON ist UTF8 basiert und dann könnte die Größe u.U. explodieren (z.B. wenn jedes Zeichen im JSON als uXXXX dargestellt wird, dann hat man eine Vergrößerung der Daten um den Faktor 5)

Warte mal ... JSON unterstützt so gut wie alle Unicode-Zeichen nicht-escaped in Strings. Im Schnitt sollte ein Text in UTF-8 nicht größer sein als mit UTF-16 (Widestring).

Kommt darauf an welche Zeichen kodiert werden müssen, dann ist entweder UTF8 oder UTF16 besser. Bei einer (Komprimierung und) BASE64 Kodierung habe ich aber zuverlässig eine Zeichenmenge die in UTF8 immer mit einem Byte dargestellt werden kann.

[Union]

Du solltest überlegen, ob Du die Nutzdaten nicht mit Multipart / FileStream überträgst und das JSON selber nur Infos dazu enthält (z.b. Größe, Checksumme, eine GUID etc.).

[bernau]

Zitat:

Zitat von Union (Beitrag 1309883)

Du solltest überlegen, ob Du die Nutzdaten nicht mit Multipart / FileStream überträgst und das JSON selber nur Infos dazu enthält (z.b. Größe, Checksumme, eine GUID etc.).

Also ich habe nicht gelesen, daß der die Daten versenden möchte. Er will sie nur speichern. (Oder habe ich etwas übersehen)?

[Sir Rufo]

Zitat:

Zitat von bernau (Beitrag 1309885)

Zitat:

Zitat von Union (Beitrag 1309883)

Du solltest überlegen, ob Du die Nutzdaten nicht mit Multipart / FileStream überträgst und das JSON selber nur Infos dazu enthält (z.b. Größe, Checksumme, eine GUID etc.).

Also ich habe nicht gelesen, daß der die Daten versenden möchte. Er will sie nur speichern. (Oder habe ich etwas übersehen)?

Reine Deduktion:

Ein Datenformat, welches nicht verändert werden kann, muss mindestens eine Abhängigkeit von einem anderen System haben. Dieses andere System wird mit diesen Daten arbeiten und um dieses zu erreichen, müssen die Daten in die Reichweite desselbigen gelangen. Dieses geschieht auf irgendeinem Transportweg. Die Daten gehen von seinem System zu einem anderen und das bezeichnet man durchaus als Senden.

Ein WebService wurde zwar nirgends erwähnt ist aber durchaus wahrscheinlich ;)

[Union]

Wenn es allerdings keine Abhängigkeiten gibt (REST) aber trotzdem JSON verwendet werden muss, bleibt nur noch die Möglichkeit dass der Ersteller dieser Vorgabe etwas minderbemittelt ist.
Niemand der Geschwindigkeit, Typsicherheit und effiziente Speicherung bzw. Übertragung benötigt setzt freiwillig JSON ein. Warum benutzt MongoDb denn BSON und warum hat Google zuerst Protocol Buffers und nun die noch simpleren Flatbuffers entwickelt? Vielleicht unter anderem weil diese Formate 10 mal kleiner und 100 mal schneller sind als XML oder JSON?

Hier ein Benchmark