Ich arbeite an meinem Open-Source-Projekt Downloadify , und bis jetzt behandelt es einfach die Rückgabe von Strings als Antwort auf ExternalInterface.call -Befehle.
Ich versuche, einen Testfall zusammenzustellen, indem ich JSZip und Downloadify zusammen benutze. Das Ergebnis ist, dass es sich um eine Zip-Datei handelt wird dynamisch im Browser erstellt und dann mit FileReference.save auf dem Datenträger gespeichert. Dies ist jedoch mein Problem:
Die JSZip-Bibliothek kann entweder eine base64 -kodierte Zeichenfolge der Zip-Datei oder die rohe Byte-Zeichenfolge zurückgeben. Das Problem ist, wenn ich diese Byte-Zeichenfolge als Antwort auf den ExternalInterface.call -Befehl zurückgebe, bekomme ich diesen Fehler:
ActionScript 3:
%Vor% Dabei ist queue_name nur eine Zeichenfolge, die zur Identifizierung der korrekten Instanz in JS verwendet wird.
JavaScript:
%Vor% Wenn ich stattdessen eine normale Zeichenfolge anstelle der Byte-Zeichenfolge zurückgebe, funktioniert der Aufruf korrekt. Ich möchte vermeiden, base64 zu verwenden, da ich einen base64 -Decoder in meine swf einbeziehen müsste, der seine erhöht Größe.
Endlich: Ich bin nicht suche nach einem AS3 Zip-Generator. Es ist zwingend erforderlich, dass mein Teil in JavaScript ausgeführt wird
Ich bin zwar nicht ein AS3 Programmierer von Beruf, also wenn Sie weitere Details benötigen, lassen Sie es mich bitte wissen.
Wenn Daten von JavaScript-Aufrufen zurückgegeben werden, werden sie in eine XML-Zeichenfolge serialisiert. Wenn also die von JSZip zurückgegebene "rohe Zeichenkette" Zeichen enthält, die den XML-Code ungültig machen, was meiner Meinung nach hier passiert, werden Sie solche Fehler bekommen.
Was Sie als Rückgabe bekommen, ist eigentlich:
%Vor%Stellen Sie sich vor, Ihre Return-Zeichenfolge enthält ein "& lt;" char - dies wird das XML ungültig machen, und es ist schwer zu sagen, welche Zeichencodes ein roher Bytestrom auch übersetzen wird.
Sie können mehr über das XML-Format der externen API auf LiveDocs
Ich denke, dass das Problem durch die Tatsache verursacht wird, dass flash einen utf8-String erwartet und du ein paar Binärkram draufwirfst. Ich denke, zum Beispiel 0x00FF wird sich nicht als gültig erweisen utf8 ...
Sie können versuchen, mit flash.system::System.setCodePage herumzuspielen, aber ich wäre nicht zu optimistisch ...
Ich denke, ein Base64-Decoder ist wahrscheinlich wirklich der einfachste ... ich mache mir eher Sorgen über die Geschwindigkeit als über die Dateigröße. Diese rudimentäre Decodermethode benötigt weniger als ein halbes K:
%Vor% Du könntest einfach Funktionsnamen verkürzen und ein kleineres Bild machen ... oder ColorTransform oder ConvolutionFilter für ein Bild anstatt für vier verwenden ... oder das Bild für kleinere Gesamtgröße in die SWF kompilieren ... oder Reduziere die Länge des Funktionsnamens ...
Wenn Sie also nicht mit MB-Daten arbeiten möchten, ist dies der richtige Weg ...
Tags und Links javascript flash actionscript-3 externalinterface bytearray