die zlib-Komprimierung von ByteArray?
Habe ich diese unkomprimiert byte-array:
0E 7C BD 03 6E 65 67 6C 65 63 74 00 00 00 00 00 00 00 00 00 42 52 00 00 01 02 01
00 BB 14 8D 37 0A 00 00 01 00 00 00 00 05 E9 05 E9 00 00 00 00 00 00 00 00 00 00
00 00 00 00 01 00 00 00 00 00 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 05 00 00 01 00 00 00Und ich muss es komprimieren mit dem deflate-Algorithmus (implementiert in zlib), von dem, was ich gesucht das äquivalent in C# wäre mit GZipStream aber ich kann nicht mit den komprimierten führte bei allen.
Hier ist das komprimieren code:
public byte[] compress(byte[] input)
{
using (MemoryStream ms = new MemoryStream())
{
using (GZipStream deflateStream = new GZipStream(ms, CompressionMode.Compress))
{
deflateStream.Write(input, 0, input.Length);
}
return ms.ToArray();
}
}Hier ist das Ergebnis der oben komprimieren code:
1F 8B 08 00 00 00 00 00 04 00 ED BD 07 60 1C 49 96 25 26 2F 6D CA 7B 7F 4A F5 4A
D7 E0 74 A1 08 80 60 13 24 D8 90 40 10 EC C1 88 CD E6 92 EC 1D 69 47 23 29 AB 2A
81 CA 65 56 65 5D 66 16 40 CC ED 9D BC F7 DE 7B EF BD F7 DE 7B EF BD F7 BA 3B 9D
4E 27 F7 DF FF 3F 5C 66 64 01 6C F6 CE 4A DA C9 9E 21 80 AA C8 1F 3F 7E 7C 1F 3F
22 7E 93 9F F9 FB 7F ED 65 7E 51 E6 D3 F6 D7 30 CF 93 57 BF C6 AF F1 6B FE 5A BF
E6 AF F1 F7 FE 56 7F FC 03 F3 D9 AF FB 5F DB AF 83 E7 0F FE 35 23 1F FE BA F4 FE
AF F1 6B FC 1A FF 0F 26 EC 38 82 5C 00 00 00Hier ist das Ergebnis ich erwarte:
78 9C E3 AB D9 CB 9C 97 9A 9E 93 9A 5C C2 00 03 4E 41 0C 0C 8C 4C 8C 0C BB 45 7A
CD B9 80 4C 90 18 EB 4B D6 97 0C 28 00 2C CC D0 C8 C8 80 09 58 21 B2 00 65 6B 08
C8Was ich falsch mache, könnte jemand mir helfen ?
Warum erwarten Sie, dass die gleiche Ausgabe von verschiedenen Implementierungen? Es gibt viele Möglichkeiten zum komprimieren Sie einige Inhalte, die dekomprimiert werden kann, die mit der gleichen decompressor. Aber in deinem Fall den zip-stream scheint zu der Ausgabe eine Art header.
Nicht nur ist die GZipStream das Ergebnis anders, aber es ist größer als die unkomprimierte Eingabe!
viel habe ich schon verstanden, das ist, warum ich bin auf der Suche nach, wie man Sie iqual, indem Sie versuchen, um herauszufinden, was ich falsch mache, wie ich erwähnt habe, die ich brauche, um die Verwendung des deflate-implementation von zlib, die in C#. @CodeInChaos ich wusste nicht, es war eine andere Implementierung, die ich war auf der Suche um und ich fand einige Antworten, die besagt, dass die GZip-war das äquivalent für die es ich es herauszufinden, dass es war nicht, als ich anfing, es zu testen.
Abgesehen von der Zunahme der Größe, ich nehme an, es ist ein anderes Programm decompresing. Wie geht das zusammen?
Nicht nur ist die GZipStream das Ergebnis anders, aber es ist größer als die unkomprimierte Eingabe!
viel habe ich schon verstanden, das ist, warum ich bin auf der Suche nach, wie man Sie iqual, indem Sie versuchen, um herauszufinden, was ich falsch mache, wie ich erwähnt habe, die ich brauche, um die Verwendung des deflate-implementation von zlib, die in C#. @CodeInChaos ich wusste nicht, es war eine andere Implementierung, die ich war auf der Suche um und ich fand einige Antworten, die besagt, dass die GZip-war das äquivalent für die es ich es herauszufinden, dass es war nicht, als ich anfing, es zu testen.
Abgesehen von der Zunahme der Größe, ich nehme an, es ist ein anderes Programm decompresing. Wie geht das zusammen?
InformationsquelleAutor Guapo | 2011-06-08
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Zunächst einige Informationen: DEFLATE ist der Kompressions-Algorithmus definiert wird, der in RFC 1951. DEFLATE wird in der ZLIB und GZIP-Formate, definiert in RFC 1950 und Ein tausend neun hundert zwei und fünfzig beziehungsweise, die im wesentlichen dünne Wrapper um DEFLATE-bytestreams. Die Wrapper Metadaten wie den Namen der Datei, Zeitstempel, Prüfsummen oder Adlers, und so weiter.
.NET base class library implementiert ein DeflateStream, produziert eine raw DEFLATE-bytestream, wenn für die Komprimierung benutzt wird. Beim Einsatz in der Dekompression benötigt er einen rohen DEFLATE bytestream. .NET bietet auch einen GZipStream, das ist einfach ein GZIP-wrapper, base. Es gibt keine ZlibStream in der .NET base class library - nichts, die produziert oder verbraucht ZLIB. Es gibt einige tricks, um es zu tun, können Sie suchen, um.
Deflate-Logik .NETTO weist eine Verhaltens-Anomalie, wo zuvor komprimierten Daten tatsächlich aufgeblasen werden, wird deutlich, wenn man "komprimiert". Dies war die Quelle der ein Connect Fehler angesprochen mit Microsoft, und diskutiert wurde hier auf SO. Dies kann sein, was Sie sehen, so weit als unwirksam Kompression. Microsoft abgelehnt haben, der Fehler, weil, während es unwirksam ist Platz zu sparen, wird der komprimierte Datenstrom wird nicht ungültig, in anderen Worten, es kann sein, "dekomprimiert" von jedem konformen Motor ENTLÜFTEN.
In jedem Fall, als jemand anderes gepostet, die komprimierte bytestream erzeugt, die von verschiedenen Verdichtern sind nicht unbedingt die gleichen. Es hängt davon ab, auf Ihre Standardeinstellungen zurückgesetzt, und die anwendungsspezifischen Einstellungen für den Kompressor. Obwohl die komprimierte bytestreams sind unterschiedlich, Sie können immer noch entpacken, um die gleichen original-bytestream. Auf der anderen Seite die Sache, die Sie für die Komprimierung wurde GZIP, während es scheint, was Sie wollen wird die ZLIB. Während Sie verwandt sind, Sie sind nicht das gleiche; man kann Sie nicht verwenden GZipStream zu produzieren, ZLIB bytestream. Dies ist die primäre Quelle für den Unterschied, den Sie sehen.
Ich denke, Sie wollen eine ZLIB-stream.
Die frei verwalteten Zlib in der DotNetZip-Projekt implementiert das komprimieren von streams, die für alle drei Formate (DEFLATE, ZLIB, GZIP). Der DeflateStream und GZipStream funktionieren auf die gleiche Weise wie die .NETTO-builtin-Klassen, und es gibt eine ZlibStream Klasse dort, das tut, was Sie denken, es tut. Keine dieser Klassen das Verhalten der Anomalie die ich oben beschrieben habe.
In code sieht es wie folgt aus:
Die Ausgabe wie diese:
Zu entpacken,
Können Sie sehen,die Dokumentation über die statische Methode CompressBuffer.
BEARBEITEN
Die Frage, warum ist die DotNetZip Herstellung
78 DAfür die ersten zwei bytes statt78 9C? Der Unterschied ist unerheblich.78 DAkodiert "maximale Komprimierung", während78 9Ckodiert "Standard-Komprimierung". Wie Sie sehen können, in den Daten, für dieses kleine Beispiel, die tatsächliche komprimierte bytes sind genau die gleichen, ob die Verwendung der BESTEN oder STANDARD. Auch der Grad der Komprimierung Informationen werden nicht verwendet, während der Dekompression. Es hat keinen Effekt in Ihrer Anwendung.Wenn Sie nicht möchten, dass "max" - Kompression, in anderen Worten, wenn Sie sehr festgelegt auf immer
78 9Cals die ersten zwei bytes, auch wenn es nicht wichtig ist, dann können Sie dieCompressBufferconvenience-Funktion, welche mit der besten Kompressionsstufe unter der Decke. Stattdessen können Sie diese:Ist das Ergebnis:
Ich weiß nicht, ZLib.Net. Ich gab den code für die DotNetZip oben.
danke, Es scheinen eher einfach zu entpacken, ich werde es mal ausprobieren, da ich einige Probleme entpacken es aus der anderen lib.
DotNetZip immer komprimieren Sie es mit 1 unterschiedliche byte "78 DA" statt "78 9C" in der sehr beginnen, während, wenn ich ZLib.Net es funktioniert gut, mir das zu geben 9C, statt DA, entfernt, läuft es einwandfrei entpacken, nicht sicher, warum es änderungen 9C DA noch...
Es spielt keine Rolle, ob das 2. byte ist 9C oder DA. ZLIB hat eine 2-byte-header, das erste byte gibt die Komprimierungsmethode und die Größe der Fenster, wenn DEFLATE verwendet wird. Es ist immer 78. Das nächste byte variiert, und deutet auf 3 Dinge: ob eine voreingestellte Wörterbuch verwendet wurde, der Grad der Komprimierung und eine Prüfsumme der Sorten auf dem 1. zwei bytes. Im Effekt, 9C zeigt comp-Ebene "Standard" während DA zeigt die Komprimierung der Stufe "max". Diese information wird nicht gebraucht für die Dekompression; es ist nur interessant, wenn die app prüft, ob die zusätzliche Komprimierung nützlich sein könnten. Man kann es ignorieren.
InformationsquelleAutor Cheeso
Ganz einfach, was Sie bekam hatte Sie eine GZip-header. Was Sie wollen, ist die einfachere die Zlib-header. ZLib-Optionen für GZip-header, Zlib-header oder keinem header. In der Regel werden die Zlib-header wird verwendet, wenn die Daten im Zusammenhang mit einem Datenträger-Datei (in dem Fall GZip-header verwendet wird.) Anscheinend gibt es keinen Weg mit .Net-Bibliothek zum schreiben einer zlib-header (obwohl dies ist bei weitem die häufigste header verwendet im Datei-Formate). Versuchen http://dotnetzip.codeplex.com/.
Können Sie schnell testen, all die verschiedenen zlib-Optionen mit HexEdit (Operations->Compression->Einstellungen). Sehen http://www.hexedit.com . Es dauerte 10 Minuten, um zu überprüfen, dass Ihre Daten durch einfaches einfügen der komprimierten bytes in HexEdit und zu Dekomprimieren. Habe auch versucht die Komprimierung der ursprünglichen bytes mit GZip and ZLib-Header als ein double-check. Beachten Sie, dass Sie tüfteln mit den Einstellungen exakt die bytes, die Sie erwartet hatten.
InformationsquelleAutor Andrew W. Phillips