la compression zlib tableau d'octets?

D'abord, quelques informations: DEFLATE est l'algorithme de compression, il est défini en RFC 1951. DÉGONFLER est utilisé dans la ZLIB et GZIP formats définis dans RFC 1950 et Mille neuf cent cinquante deux respectivement, qui sont essentiellement des wrappers minces autour de DÉGONFLER bytestreams. Les wrappers de fournir des métadonnées telles que le nom du fichier, horodateurs, Crc ou Adlers, et ainsi de suite.

.NET de base de la bibliothèque de la classe implémente une DeflateStream qui produit un cru DÉGONFLER bytestream, lorsqu'il est utilisé pour la compression. Lorsque utilisé dans de décompression, il consomme cru DÉGONFLER bytestream. .NET fournit également un GZipStream, qui est juste un GZIP wrapper autour de la base. Il n'y a pas de ZlibStream dans le .NET de la bibliothèque de classes de base - rien de ce que produit ou consomme de la ZLIB. Il y a quelques astuces pour le faire, vous pouvez rechercher autour de.

Le dégonfler logique .NET présente une anomalie comportementale, où, auparavant, les données compressées peuvent vraiment être gonflé, de manière significative, lorsque "compressé". Ce fut la source de un Connecter bug soulevé avec Microsoft, et a été discuté ici sur DONC. C'est peut être ce que vous voyez, dans la mesure inefficace de compression. Microsoft ont rejeté le bug, parce qu'elle est inefficace pour économiser de l'espace, le flux compressé n'est pas valide, en d'autres termes, il peut être "décompressé" par tout conforme à DÉGONFLER moteur.

En tout cas, que quelqu'un d'autre a posté, le comprimé bytestream produite par les compresseurs différents ne peuvent pas nécessairement être la même. Cela dépend de leurs paramètres par défaut, et l'application paramètres spécifiés pour le compresseur. Même si le comprimé bytestreams sont différents, ils peuvent encore décompresser à la même origine bytestream. D'autre part, la chose que vous avez utilisé pour compresser était GZIP, bien qu'il semble que ce que vous voulez est ZLIB. Alors qu'ils sont liés, ils ne sont pas les mêmes; vous ne pouvez pas utiliser GZipStream pour produire un ZLIB bytestream. C'est la principale source de la différence que vous voyez.

---

Je pense que vous voulez un ZLIB flux.

La libre géré Zlib dans le DotNetZip projet met en œuvre la compression de flux pour tous les trois formats (DEFLATE, ZLIB, GZIP). Le DeflateStream et GZipStream fonctionnent de la même manière que l' .NET builtin classes, et il y a un ZlibStream classe là, qu'est-ce que vous pensez que cela fonctionne. Aucune de ces classes présentent le comportement de l'anomalie que j'ai décrit ci-dessus.

---

Dans le code ressemble à ceci:

    byte[] original = new byte[] {
0x0E, 0x7C, 0xBD, 0x03, 0x6E, 0x65, 0x67, 0x6C,
0x65, 0x63, 0x74, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x42, 0x52, 0x00, 0x00,
0x01, 0x02, 0x01, 0x00, 0xBB, 0x14, 0x8D, 0x37,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x05, 0xE9, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x81, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00,
0x01, 0x00, 0x00, 0x00
};
var compressed = Ionic.Zlib.ZlibStream.CompressBuffer(original);

La sortie ressemble à ceci:

0000    78 DA E3 AB D9 CB 9C 97 9A 9E 93 9A 5C C2 00 03     x...........\...
0010    4E 41 0C 0C 8C 4C 8C 0C BB 45 7A CD 61 62 AC 2F     NA...L...Ez.ab./
0020    19 B0 82 46 46 2C 82 AC 40 FD 40 0A 00 35 25 07     ...FF,..@.@..5%.
0030    CE                                                  .

Pour décompresser,

    var uncompressed = Ionic.Zlib.ZlibStream.UncompressBuffer(compressed);

---

Vous pouvez voir la documentation sur la statique CompressBuffer méthode.

---

MODIFIER

La question est, pourquoi est-DotNetZip la production de 78 DA pour les deux premiers octets au lieu de 78 9C? La différence est négligeable. 78 DA code "max" compression, tandis que 78 9C code "de compression par défaut". Comme vous pouvez le voir dans les données, pour ce petit échantillon, le réel d'octets compressés sont exactement les mêmes que ce soit en utilisant les MEILLEURES ou par DÉFAUT. Aussi, le niveau de compression de l'information n'est pas utilisée lors de la décompression. Il n'a pas d'effet dans votre application.

Si vous ne voulez pas "max" de la compression, en d'autres termes, si vous êtes très mis sur l'obtention de 78 9C comme les deux premiers octets, même si elle n'a pas d'importance, alors vous ne pouvez pas utiliser le CompressBuffer fonction de commodité, qui utilise le meilleur niveau de compression sous les couvertures. Au lieu de cela, vous pouvez faire ceci:

  var compress = new Func<byte[], byte[]>( a => {
using (var ms = new System.IO.MemoryStream())
{
using (var compressor =
new Ionic.Zlib.ZlibStream( ms, 
CompressionMode.Compress,
CompressionLevel.Default )) 
{
compressor.Write(a,0,a.Length);
}
return ms.ToArray();
}
});
var original = new byte[] { .... };
var compressed = compress(original);

Le résultat est:

0000    78 9C E3 AB D9 CB 9C 97 9A 9E 93 9A 5C C2 00 03     x...........\...
0010    4E 41 0C 0C 8C 4C 8C 0C BB 45 7A CD 61 62 AC 2F     NA...L...Ez.ab./
0020    19 B0 82 46 46 2C 82 AC 40 FD 40 0A 00 35 25 07     ...FF,..@.@..5%.
0030    CE                                                  .

OriginalL'auteur Cheeso