Wir übertragen ein Blob (Bild) auf einen Websocket und rendern es auf einer Leinwand am anderen Ende.
Wenn ich createObjectURL mit dem Blob verwende, erhalte ich folgende Warnung:
Wir erstellen die Objekt-URL mit dem folgenden Code. Der Blob wird über einen Standard-Websocket mit socket.binaryType = "blob"; auf der Client-Seite gesendet:
Der einzige Weg, wie ich diese Warnung angehen kann, besteht darin, eine Kopie des Blobs mit dem folgenden Code zu erstellen, aber ich möchte nicht den Aufwand für das Kopieren aller Daten einführen:
%Vor%Die Methode wird Dutzende Male pro Sekunde aufgerufen.
Irgendwelche Ideen, wie man den Blob-Inhaltstyp einstellt, ohne ein doppeltes Blob -Objekt mit new Blob zu erstellen?
Zuerst würde ich mich fragen, ob du mit "Fehler" eigentlich "Warnung" meinst. Sie sind wirklich zwei verschiedene Dinge und der Browser behandelt sie anders (es verfolgt / löst normalerweise nur Warnungen aus, wenn die Entwicklerwerkzeuge geöffnet sind usw.).
Zuerst würde ich die Prämisse in Frage stellen, dass dies sogar ein Problem ist (der Overhead des Browsers "automatisches Tippen" des Blobs gegen den Overhead des "Neustartens" eines Blobs usw.).
Aber die blob.type-Eigenschaft ist tatsächlich in JavaScript unveränderbar und muss daher gesetzt werden, wenn der Blob "newed" ist. In Ihrem Fall hört es sich so an, als ob Sie die Daten von einem Objective-C-Sockel bekommen und ihn einfach über:
verketten %Vor%Die Blob-Daten selbst aus dem Objective-C-Socket enthalten nicht die Daten des Typs "header" des Typs, wenn er sie sendet, und es hört sich so an, als würde Ihr Knoten den Blob überhaupt nicht berühren neue Blob in Ihrem Knoten und dann das sende den Socket, um zu sehen, ob es die Typisierung behält?).
Also, was passiert, ist, dass der Websocket nur die Blob-Daten sendet, wie sie es bekommen haben, und wenn das empfangende Javascript es bekommt, schreibt es implizit mit einem neuen Blob und dann, nur mit einem leeren Typ.
Also im Wesentlichen nein, es scheint keinen Weg in der neuen Blob-Konstruktion zu geben, wenn Sie diese Warnung wirklich loswerden wollen. Selbst wenn Sie Tricks wie das Hinzufügen des Typs in die Blobdaten und dann das Ausschneiden usw. ausprobiert haben, können Sie den WebSocket-Empfangscode immer noch nicht implizit als Blob mit einem leeren Typ eingeben.
"Blob-URLs funktionieren nur mit GET-Anforderungen, und wenn einer erfolgreich angefordert wurde, sendet der Browser einen HTTP 200 OK-Statuscode und sendet auch einen Content-Type-Header, der die type-Eigenschaft des Blobs verwendet."
%Vor%Bin ich komplett hier?
Ich habe all das von Ссылка
HTML5 Rocks scheint mit der Antwort auf die XHR-Anfrage einen neuen Blob zu erstellen. Vielleicht ist es ja gar nicht so schlimm. Ссылка
Einfach ein paar Ideen rauswerfen.
Sie können dieses Problem von dem Ende an lösen, an dem Sie das Bild bereitstellen. Dieses Problem tritt aufgrund des falschen Inhaltstyps auf. Daher sollten Sie den Server so konfigurieren, dass er ein Bild mit Bildkopfzeilen sendet.
Wenn dies in PHP war, sollten Sie etwas wie
haben %Vor%(Ich gebe Ihnen nur eine Idee)
Im Falle von Node.js, obwohl ich kein Experte bin, können Sie den Inhaltstyp für das Antwortobjekt wie folgt festlegen:
%Vor%Tags und Links javascript