JSON für binary Data?
0 0 0 0 0 
klawischnigg
0
0 dedlfix
0
JSON für binary Data?
hallo
In JSON gibt ja keine linebreaks und formfeeds mehr, sondern nur noch deren maskierte Varianten. Der Inhalt von JSON sollte also von den verschiedenen Konversionen zwischen Systemen nicht berührt sein.
Deshalb rein Interesse halber: Wird JSON auch schon mal als Übertragungsformat für binary Data benutzt, wenn solche Daten zusammen mit anderen Post-Daten gesendet werden? Ist so was verbreitet?
mfg
-
Wird JSON auch schon mal als Übertragungsformat für binary Data benutzt,
Das geht (e.g. Base64-codiert).
wenn solche Daten zusammen mit anderen Post-Daten gesendet werden?
???
Ist so was verbreitet?
Definiere "verbreitet". Ich würde es machen, wenn es mir im konkreten Anwendungsfall Vorteile verspricht. Beispielsweise kann ich mit einem "XMLHttp"-Request Daten und Base64-codiertes Foto (aber eher nicht in 6000*4000px) einer Person abholen, statt erst die Daten (und damit die URL des Fotos) und dann das Foto.
Der Nachteil ist nämlich, dass a) durch die notwendige Base64-Kodierung die zu übertragende Datenmenge stark steigt und b) (wegen der parallel übertragenen Daten, die aktuell sein sollen) ggf. Caches deaktiviert werden. Da muss also sehr genau abgewogen werden.
-
Definiere "verbreitet". Ich würde es machen, wenn es mir im konkreten Anwendungsfall Vorteile verspricht. Beispielsweise kann ich mit einem "XMLHttp"-Request Daten und Base64-codiertes Foto (aber eher nicht in 6000*4000px) einer Person abholen, statt erst die Daten (und damit die URL des Fotos) und dann das Foto.
Der Nachteil ist nämlich, dass a) durch die notwendige Base64-Kodierung die zu übertragende Datenmenge stark steigt und b) (wegen der parallel übertragenen Daten, die aktuell sein sollen) ggf. Caches deaktiviert werden. Da muss also sehr genau abgewogen werden.
Ahja Base64 entfernt ja sowieso das Problem. Nehmen wir an, wir geben am Schluss data-urls aus (z.B in css). Werden solche Daten nicht wie übliche Bilder auch vom Browser gecacht? Das heisst, das Cache-Kriterium ist von der einbindenden CSS-Datei abhängig, weil der Inhalt schlicht als Teil der CSS-Datei angesehen wird?
Aber das ist ja ein anderes (nicht uninteressantes) Thema.
-
Nehmen wir an, wir geben am Schluss data-urls aus (z.B in css). Werden solche Daten nicht wie übliche Bilder auch vom Browser gecacht?
Wenn die gesamte CSS-Datei (es geht auch direkt im HTML) gecacht wird, dann ja. Allerdings bezweifle ich, dass auch nur einziger Browser Base64-Kodierung und binäre Repräsentanz cacht. HTML bzw. CSS cacht er entsprechend der Header und seiner Konfiguration. Hinzu kommt: Kommen die Base-64-codierten Daten (Grafiken) z.B. als Teil der JSON-codierten-Antwort in einem "XMLHttp"-Request will man (als Betreiber der Seite) oft nicht, dass diese zwischengespeichert werden.
In meiner vorherigen Antwort fehlt eine Zahl: base64 vergrößert die Datenmenge um ca. 40%. Das heißt statt 10KB müssten 14KB übertragen werden.
Noch ein Hinweis: Wenn ich sowas machen würde, dann würde ich (wenn es eine Grafik ist), diese auch auf dem Server base64-kodiert speichern. Das kann unter bestimmten Bedingungen sogar in einer Datenbank sinnvoll sein...
-
Hi fastix,
das Problem ist daß die derzeitigen JS Built-in-Funkionen mit base64 gar nicht richtig umgehen können. window.atob() und window.btoa() funktionieren nur mit Zeichenketten, nicht jedoch mit binaries.
MfG
-
Hi there,
das Problem ist daß die derzeitigen JS Built-in-Funkionen mit base64 gar nicht richtig umgehen können.
Wie geht man denn mit base64 richtig um?
window.atob() und window.btoa() funktionieren nur mit Zeichenketten, nicht jedoch mit binaries.
Naja, deswegen verwendet man ja eine Konvertierung in base64, weil man nicht überall mit Binaries umgehen kann. Alles was nach base64 konvertiert wird ist eine reine Zeichenwüste, deswegen versteh' ich Dein Posting nicht so ganz…
-
hi,
das Problem ist daß die derzeitigen JS Built-in-Funkionen mit base64 gar nicht richtig umgehen können.
Wie geht man denn mit base64 richtig um?
indem man base64 verwendet für was es gedacht ist: für Binaries. Sozusagen eine zweckmäßige Verwendung.
window.atob() und window.btoa() funktionieren nur mit Zeichenketten, nicht jedoch mit binaries.
Naja, deswegen verwendet man ja eine Konvertierung in base64, weil man nicht überall mit Binaries umgehen kann. Alles was nach base64 konvertiert wird ist eine reine Zeichenwüste, deswegen versteh' ich Dein Posting nicht so ganz…
Wie bitte? Was ist an btoa() und atob() funktionieren nur mit Zeichenketten nicht zu verstehen!?
MfG
-
Hi there,
Wie bitte? Was ist an btoa() und atob() funktionieren nur mit Zeichenketten nicht zu verstehen!?
Und was ist an 'base64-codiertes ist eine Zeichenkette' nicht zu verstehen?
-
Zum besseren Verständnis:
Fakt ist daß btoa und atob für Binaries ungeeignet sind. Also für das was Base64 machen soll, nämlich aus Binaries Zeichenketten und umgekehrt und genau das können diese beiden builitinfunktionen nicht.
Ergo beschränkt sich der Nutzen dieser Funktionen darauf aus Zeichenketten Zeichenketten zu machen.
http://rolfrost.de/Base64.js ist dagegen eine Library die nicht nur mit Zeichenketten sondern mit richtigen Binaries funktioniert. D.h., die Methode Base46.encode() bekommt eine Binary als ArrayBuffer übergeben. Neben ArrayBuffer kennt JS noch den Blob bzw. File als eine weitere Möglichkeit für die JS interne Verarbeitung von Binaries.
Fazit: Binaries in JS liegen entweder als Blob oder als ArrayBuffer vor und nicht etwa als Strings oder gar Zeichenketten. btoa und atob hingegen kennen weder ArrayBuffer noch Blob. Und demzufolge auch keine Binaries!
MfG
-
-
-
-
-
-
-
-
Tach!
In JSON gibt ja keine linebreaks und formfeeds mehr, sondern nur noch deren maskierte Varianten.
Sagen wir mal so, in jedem Dateiformat das Daten in einer Text-Struktur transportiert, müssen die Daten als Literal gemäß den Regeln des Formats geschrieben werden. Das betrifft alle Datentypen, nicht nur Strings mit Steuerzeichen drin.
Der Inhalt von JSON sollte also von den verschiedenen Konversionen zwischen Systemen nicht berührt sein.
Deswegen ist ja definiert, wie die Daten in diesem Format zu notieren sind.
Wird JSON auch schon mal als Übertragungsformat für binary Data benutzt, wenn solche Daten zusammen mit anderen Post-Daten gesendet werden?
Du kannst das tun, wenn du die entsprechenden Literale der Daten notierst. Das wird nur recht umständlich bis unmöglich werden, weil du dir eine Lösung für Bytes oberhalb von 7F ausdenken musst. Du wirst einfacher kommen, wenn du die Binärdaten in ein Textformat bringst. Base64 ist da sehr verbreitet.
dedlfix.
-
hi lieber Beat,
Wird JSON auch schon mal als Übertragungsformat für binary Data benutzt, wenn solche Daten zusammen mit anderen Post-Daten gesendet werden?
JSON ist dafür völlig ungeeignet. Ebenso werden mit multipart/form-data textliche Mittel zum Strukturieren von 8bit Daten verwendet was sehr viele Nachteile mit sich bringt.
8bit Daten sollten so strukturiert werden wie das Binaries erfordern, nämlich nicht mit textlichen Mitteln sondern mit Offsetangaben. Damit ist es auch CPU und RAM gefällig möglich multimediale Inhalte, also text+grafik+video+audio +Dateien beliebiger Inhalte zusammen in einem POST Request zu übertragen.
Aber bis die Browser da können kann das noch Jahrzehnte dauern. Obwohl das mit JavaScript auch schon seit Jahren möglich ist. Auf meiner Domäne gibt es hierzu ungezählte Beispiele.
MfG
-
Obwohl das mit JavaScript auch schon seit Jahren möglich ist. Auf meiner Domäne gibt es hierzu ungezählte Beispiele.
Leider zeigen diese "Beispiele" immer nur, dass etwas (angeblich) geht. Mangels Quelltextes kann man dort leider nicht sehen, was da wie "gemacht" wird. Deswegen zählt diese Beispiele auch niemand.
-
-
hallo
Und neuerdings kann man mit JS auch FormData Objekte nicht nur senden sondern auch empfangen und mit JS die Binaries bytegenau da wieder rausholen.
Freilich nützen meine Beispiele nur wenig wenn man nicht die richtigen Ideen dazu hat.
Hier ist halt die Frage: In welchem Context macht es überhaupt Sinn, mehrere Ressourcen in einen Response zusammenzupacken? Schliesslich versperrt man sich alle Vorteile die separate Ressourcen-URIs fürs Caching bieten.
mfg
-
hallo
Und neuerdings kann man mit JS auch FormData Objekte nicht nur senden sondern auch empfangen und mit JS die Binaries bytegenau da wieder rausholen.
Freilich nützen meine Beispiele nur wenig wenn man nicht die richtigen Ideen dazu hat.
Hier ist halt die Frage: In welchem Context macht es überhaupt Sinn, mehrere Ressourcen in einen Response zusammenzupacken? Schliesslich versperrt man sich alle Vorteile die separate Ressourcen-URIs fürs Caching bieten.
Cache ist ein Argument. Aber denke daran, Ein Request ist immer effizienter als Mehrere. Weil: Der meiste Overhead entsteht beim Herstellen der Verbindung. Wenn ein Socket einmal offen ist, ist das so transparent daß Anwendungen gar nichts davon mitbekommen daß sie auf unterschiedlichen Maschinen laufen. Und der User sowieso nicht.
Aus diesem Grunde kam ja auch Connection: Keep-Alive mit HTTP/1.1 was insbesondere fürs Management interessant ist, so kriege ich den Status von 500 verschiedenen Seiten in einer Response innerhalb von wenigen Sekunden was per HTT/1.0 Minuten dauern würde.
Ajax/fetch Responses kann man übrigens auch per Last-Modified cachen. Aber i.d.R. nutzt man ja solch API wenn man mal eben nicht cachen will 😉
MfG
-
Cache ist ein Argument. Aber denke daran, Ein Request ist immer effizienter als Mehrere. Weil: Der meiste Overhead entsteht beim Herstellen der Verbindung.
Das Thema hatten wir schon einmal, falls Du Dich erinnerst. Ich sag mal nur ein Stichwort: HTTP/2. Das wird wohl ausreichen, damit Du gleich erneut Deine, dem weit überlegene Lösung propagieren wirst ;-)
Davon ab: Wenn eine Ressource mit aggressiven Caching-Direktiven ausgeliefert wird (und der Client-Cache auch an ist): dann wird die jeweilige Ressource für lange Zeit nur ein einziges Mal angefordert. Danach erstmal nix Verbindung mehr.
-
-
hallo
PS: Fürs Upload überlege Dir einen eigenen Content-Type, etwa body+query
D.h., sämtliche Informationen die den serverseitigen Ablauf bestimmen werden als QUERY_STRING an den URL gehängt, ganz normal prozentkodiert, womit jeder Parser die Parameter wiederherstellen kann.
Die Datei/Binary selbst kommt bytegenau in den Message Body. Da hast Du zwar für jede Datei einen eigenen Request aber das ist i.d.R. erstens unerheblich, andererseits jedoch serverseitig recht einfach zu handlen ohne den Prozessor zu vergewaltigen: Die Datei wird ganz einfach aus STDIN gelesen.
Das ist übrigens auch die Idee die hinter der Request Methode PUT steckt 😉
.
-
hallo
PS: Fürs Upload überlege Dir einen eigenen Content-Type, etwa body+query
D.h., sämtliche Informationen die den serverseitigen Ablauf bestimmen werden als QUERY_STRING an den URL gehängt, ganz normal prozentkodiert, womit jeder Parser die Parameter wiederherstellen kann.
Die Datei/Binary selbst kommt bytegenau in den Message Body. Da hast Du zwar für jede Datei einen eigenen Request aber das ist i.d.R. erstens unerheblich, andererseits jedoch serverseitig recht einfach zu handlen ohne den Prozessor zu vergewaltigen: Die Datei wird ganz einfach aus STDIN gelesen.
Das ist übrigens auch die Idee die hinter der Request Methode PUT steckt 😉
Warum das?
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch Bietet doch die Möglichkeit, zusätzliche formData zu übertragen.
-
Warum das?
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch Bietet doch die Möglichkeit, zusätzliche formData zu übertragen.
-
hallo
PS: Fürs Upload überlege Dir einen eigenen Content-Type, etwa body+query
D.h., sämtliche Informationen die den serverseitigen Ablauf bestimmen werden als QUERY_STRING an den URL gehängt, ganz normal prozentkodiert, womit jeder Parser die Parameter wiederherstellen kann.
Die Datei/Binary selbst kommt bytegenau in den Message Body. Da hast Du zwar für jede Datei einen eigenen Request aber das ist i.d.R. erstens unerheblich, andererseits jedoch serverseitig recht einfach zu handlen ohne den Prozessor zu vergewaltigen: Die Datei wird ganz einfach aus STDIN gelesen.
Das ist übrigens auch die Idee die hinter der Request Methode PUT steckt 😉
Warum das?
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch Bietet doch die Möglichkeit, zusätzliche formData zu übertragen.
Warum fragst Du dann wie man binary Data mit JSON überträgt!?
MfG
-
-
-
-
-
-