Frage

Ich habe eine Web-Anwendung entwickelt in Adobe Flex 3 und Python 2.5 (Einsatz auf Google App Engine). Ein RESTful Web-Service hat in Python und seine Ergebnisse sind zur Zeit in einem XML-Format erstellt wurde, die von Flex mit dem Httpservice-Objekt gelesen wird.

Jetzt ist das Hauptziel ist es, die XML so zu komprimieren, dass es so weniger eine Zeit zwischen dem Httpservice send () Methode und Ergebnis Ereignissen ist. Ich sah Python docs und verwalten zlib.compress () verwenden, um das XML-Ergebnis zu komprimieren.

Dann stelle ich den Httpservice Ergebnistyp aus „xml“ auf „Text“ und versuchte ByteArrays mit dem String zurück in XML zu dekomprimieren. Hier ist, wo ich versagt. Ich tue so etwas wie folgt aus:

var byteArray:ByteArray = new ByteArray();
byteArray.writeUTF( event.result.toString() );
byteArray.uncompress();
var xmlResult:XML = byteArray.readUTF();

Die eine Ausnahme bei ByteArray.uncompress () wirft und sagt nicht in der Lage, die byteArray zu dekomprimieren. Auch wenn ich verfolgen die Länge des byteArray es 0 wird.

konnte nicht herausfinden, was mache ich falsch. Alle Hilfe ist willkommen.

- Bearbeiten -

Der Code:

# compressing the xml result in Python
print zlib.compress(xmlResult)

# decompresisng it in AS3
var byteArray:ByteArray = new ByteArray();
byteArray.writeUTF( event.result.toString() );
byteArray.uncompress()

Veranstaltung ist vom Typ Result.

Der Fehler:

Fehler: Error # 2058:. Es gab einen Fehler, die Daten zu dekomprimieren

Der Fehler sein könnte, weil der Wert von byteArray.bytesAvailable = 0, die den rohen Bytes Python bedeutet generierte nicht in byteArray geschrieben richtig ..

- Sri

War es hilfreich?

Lösung

Was soll byteArray.writeUTF( event.result.toString() ); tun? Das Ergebnis der zlib.compress () weder noch Unicode „UTF“ (bedeutungslos ohne Nummer, nachdem es !?); es ist binär aka rohes Bytes; Sie sollten weder sie noch dekodieren sie kodieren, noch irgendeine andere Transformation für sie gelten. Der Empfänger sollte sofort das rohe Bytes dekomprimieren, die er empfängt, um die Daten wiederherzustellen, die zlib.compress übergeben wurde ().

Aktualisieren Welche Unterlagen müssen Sie unterstützen die Vorstellung, dass byteArray.uncompress() einen echten erwartet zlib Strom und kein deflate Strom (dh ein zlib Strom, nachdem Sie das erste 2 Bytes und das letzten 4) snipped haben?

Die Flex 3-Dokumentation von ByteArray gibt folgendes Beispiel:

bytes.uncompress(CompressionAlgorithm.DEFLATE);

aber wenig hilfreich nicht sagen, was der Standard (falls vorhanden) ist. Wenn es einen Standard ist, ist es nicht überall klar dokumentiert, so wäre es eine sehr gute Idee für Sie verwenden

bytes.uncompress(CompressionAlgorithm.ZLIB);

, um es klar, was Sie beabsichtigen.

und die Dokumentation zu einem writeUTFBytes Methode sprechen, keine writeUTF Methode. Sind Sie sicher, dass Sie die genaue Empfängercode in Ihrer Frage Kopieren / Einfügen?

Update 2

Danke für die URL. Sieht aus wie ich halten, die „Hilfe“ bekam, nicht die wirklichen docs: = (Ein paar Punkte.

(1) Ja, es ist eine explizite inflate() Methode. Jedoch Dekomprimieren DOES einen Algorithmus arg haben; es kann entweder CompressionAlgorithm.ZLIB (Standard) oder CompressionAlgorithm.DEFLATE sein ... Interessanter letztere jedoch nur in Adobe Air, nicht in Flash Player verfügbar ist. Wenigstens wissen wir das Dekomprimieren () Aufruf OK erscheint, und wir können immer das rohe Bytes auf den Draht, um das Problem wieder und wieder aus in eine ByteArray-Instanz.

(2) Noch wichtiger ist, es gibt sowohl writeUTF (Schreibt einen UTF-8-String in das Bytestrom. Die Länge des UTF-8-String in Bytes zuerst geschrieben wird, als ein 16- Bit-Ganzzahl, gefolgt von den Bytes, die die Zeichen der Zeichenfolge darstellt) und writeUTFBytes (schreibt ein UTF-8-String in dem Bytestrom. Ähnlich dem writeUTF () Methode, aber writeUTFBytes () nicht prefix die Saite mit einem 16-Bit-Längenwort).

Was sind die Vorzüge der Versorgung UTF8-codierten Bytes (nil, IMHO), müssen Sie eine 2-Byte-Längenpräfix es nicht wollen; mit writeUTF () garantiert dekomprimieren verursachen () zu bork .

Ankommen es auf den Draht auf. Mit Python-Druck auf binäre Daten scheint nicht wie eine gute Idee (es sei denn sys.stdout nobbled wurde im Raw-Modus laufen zu lassen, die Sie nicht in Ihrem Code aufwiesen)

Ebenso event.result.toString tun () immer einen String (ähnlich ein Python Unicode-Objekt, ja / nein?) - mit dem, was und kodiert sie dann in UTF-8 scheint eher unwahrscheinlich arbeiten

.

Da ich nicht wusste, dass flex bis heute existiert, ich Sie wirklich nicht effektiv helfen kann. Hier sind einige weitere Vorschläge zur Selbstversorgung im Falle niemand, der mehr flex weiß kommt bald:

(1) Sie einige der Fehlersuche. Beginnen Sie mit einem minimalen XML-Dokument ab. Zeigen repr(xml_doc). Zeigen repr(zlib_compress_output). In (eine abgespeckte Version) Ihr Flex-Skript, verwenden Sie die nächste Funktion / Methode repr(), dass Sie zu zeigen, finden Sie unter: event.result, event.result.toString() und das Ergebnis writeUTF*(). Achten Sie darauf, die Auswirkungen der alles verstehen, die nach zlib.compress passieren kann (). die Dokumentation lesen kann sorgfältig helfen.

(2) Schauen Sie, wie Sie rohes Bytes aus event.result erhalten können.

HTH, John

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top