J'essaie d'utiliser des flux de déflate / gzip dans C #, mais il semble que les fichiers après la compression sont plus gros qu'auparavant.
Par exemple, je compresse un fichier DOCX de 900 ko, mais cela produise une 1,4 MO! P>
Et il le fait pour chaque fichier que j'ai essayé. P>
Peut-être que je me trompe dans la façon dont je le fais? Voici mon code: P>
FileStream input = File.OpenRead(Environment.CurrentDirectory + "/file.docx");
FileStream output = File.OpenWrite(Environment.CurrentDirectory + "/compressedfile.dat");
GZipStream comp = new GZipStream(output, CompressionMode.Compress);
while (input.Position != input.Length)
comp.WriteByte((byte)input.ReadByte());
input.Close();
comp.Close(); // automatically call flush at closing
output.Close();
5 Réponses :
DOCX est lui-même comprimé dans ZIP, il n'y a donc aucune raison de la compresser à nouveau, les résultats sont généralement plus gros. Oui merci, je ne le savais pas, et c'est pourquoi cela n'a pas fonctionné :) essayé avec .txt et autre format et il semble mieux. Mais cela ne fonctionne toujours pas sur un type de fichier sérialisé fabriqué à la maison ... mais peu importe à la fin, je voulais juste voir comment utiliser ces flux de compression :)
Je ne pense pas que Gzipstream et DeflateStream sont destinés à compresser des fichiers. Vous auriez probablement mieux la chance avec un compresseur de fichiers comme SharpziPlib .
Ils sont faits pour compresser et décompresser. Je lis actuellement le livre de certification MCTS 70-536 et ils sont utilisés comme ça là-bas ^^
et qu'est-ce qu'ils sont? msdn.microsoft.com/en-us/Library/ ... "La classe Gzipstream fournit des méthodes et des propriétés utilisées pour comprimer et décompresser les flux."
Ils sont parfaitement bons lors de la compression des fichiers et de nombreux cas que zip car ils fonctionnent directement sur le fichier plutôt que de créer une archive, et vous pouvez les produire directement à partir d'un serveur Web au lieu de compresser à chaque fois la volée. Ajout .GZ au nom (après l'extension d'origine plutôt que de le remplacer) est courant avec les fichiers GZIP. Pour ne pas dire que SharpziPlib n'est pas meilleur dans beaucoup de cas cependant.
@Kite: J'ai travaillé chez Microsoft PSS et j'ai aidé à développer certains des tests. Si cela est fait dans un livre de certification MS, il est également susceptible d'être un moyen horrible de faire des choses :) Cela dit, il n'y a pas de compresseur qui peut rendre un fichier déjà compressé plus petit.
@Dave Swersky: C'est une déclaration plutôt audacieuse. On pourrait utiliser le codage de Huffman pour compresser un fichier, puis la façonner pour le rendre encore plus petit. En fonction de la gravité de votre première technique de compression, une deuxième technique Compressen pourrait le rendre meilleur ou pire.
@Excel: Je suis corrigé. Je suppose que la combinaison de deux types de compression différents pourrait augmenter le ratio global, mais je dirai que l'utilisation de zip ne fonctionnera pas deux fois.
Premièrement, les flux de déflate / gzip sont remarquablement mauvais à la compression par rapport à Zip, 7z, etc.
Deuxièmement, DOCX (et tous les formats de document MS avec un «X» à la fin) sont des fichiers .zip de toute façon. Renommer un .docx à .zip pour révéler la fumée et les miroirs.
Ainsi, lorsque vous exécutez dégonfler / GZIP sur un DOCX, cela rendra le fichier plus grand. (C'est comme faire un zip avec un faible niveau de compression sur un fichier zippé avec un niveau de compression élevé.)
Toutefois, si vous exécutez déflate / gzip sur HTML ou un fichier texte ou quelque chose qui n'est pas compressé, il fera un bon bon travail.
Oui merci, comme indiqué dans d'autres commentaires, ne savait pas que Docx était déjà compressé. et bien sûr 7z et d'autres bibliothèques sont meilleures, mais je voulais juste essayer de voir ce qu'ils ont pu faire
Cela semble être un commentaire totalement invalide: Les flux de déflate / gzip sont remarquablement mauvais à la compression par rapport à Zip, 7z, etc. . Le fait est que 99% des fichiers zip utilisent de défler comme format de compression. Donc, zip peut être non mieux que de dégonfler, car il augmente le courant comprimé avec des métadonnées.
Le phénomène dans lequel un déflatetream réellement augmente la taille des données précédemment compressées est le sujet d'un bogue ouvert avec Microsoft en 2006: Connect.Microsoft.com/visualstudio/feedback/Détails/93930/...
Bien que cela soit vrai, comme d'autres personnes ont indiqué, que les exemples de fichiers que vous avez spécifiés sont déjà compressés - le problème le plus important consiste à comprendre que la plupart des utilitaires de compression, le déflatetream et gzipstream / EM> Les classes essaient simplement de goverser / compresser un flux de données sans l'intelligence que tous les jetons supplémentaires (surcharge) augmentent en réalité la quantité de données requise. Zip, 7z, etc. Sont assez intelligents pour savoir que si les données sont largement aléatoires (virtuellement non compressables), elles stockent simplement les données "as-" "(magasin, non comprimé), au lieu de tenter de la compresser plus loin. < / p>
Ceci n'est pas vrai: zip, 7z, etc. sont suffisamment intelligents pour savoir que si les données sont largement aléatoires (virtuellement non compressables), qu'ils stockent simplement les données "as-" "(magasin, non comprimé), à la place. de tenter de la compresser davantage. zip est simplement un format de fichier. Il ne "sait rien". Un programme qui produit un fichier zip peut faire ce que vous décrivez, mais le format ZIP ne le fait pas.
Le phénomène dans lequel déflatetream réellement gonfle la taille des données précédemment compressées est le sujet d'un bogue ouvert avec Microsoft: Connect.Microsoft.com/visualstudio/feedback/Détails/93930/...
Ne parlait pas du format (bon chagrin). Parlait des utilitaires de compression qui écrivaient des données dans leurs formats correspondants.
J'ai eu le même problème avec la compression des bases de données contenant des données JPG. J'ai essayé DotNetzip - une chute de remplacement et une compression décente (Prise en charge du cadre compact aussi!):
MS : 10MB -> 10.0MB DNZ: 10MB -> 7.6MB
Vous réalisez qu'une méthode de compression qui compressera toute entrée arbitraire par au moins un octet ne peut pas exister? Donc, surtout si vous essayez de comprimer des données proches de ALOM déjà, par exemple. Données précises, vous pouvez voir une augmentation de la taille.
.docx est déjà compressé à l'aide de la compression zip (essayez de renommer sur .zip et d'avoir une exploration). Je serais surpris si un deuxième niveau de compression produirait un avantage.
il devrait effectuer efficacement la compression que sur la chasse, de sorte que cela ne devrait pas changer une chose
@Spender> Je ne savais pas que je vais essayer avec un autre format de fichier
Avez-vous essayé de compresser un fichier .txt?
Eh bien, cela fonctionne avec un TXT. Je ne savais pas que les docs étaient déjà un format compressé
Il y avait un bug ouvert avec Microsoft couvrant ce phénomène, dans lequel DeflateStream augmente la taille d'un flux de données précédemment compressé: Connect.Microsoft.com/visualstudio/feedback/Détails/93930/... Il est actuellement marqué" fermé - externe ". Je ne sais pas ce que cela signifie.