GZipStream e DeflateStream producono file più grandi

Sto provando a usare i flussi deflate/gzip in C# ma sembra che i file dopo la compressione siano più grandi di prima.GZipStream e DeflateStream producono file più grandi

Ad esempio, comprimo un file docx di 900ko, ma ne produce uno 1.4Mo!

E lo fa per ogni file che ho provato.

Forse ho sbagliato nel modo in cui lo sto facendo? Qui è il mio codice:

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();

fonte

2010-10-05 kite

Ti rendi conto che un metodo di compressione che comprime * qualsiasi arbitraria * ingresso di almeno un byte non può esistere? Quindi, soprattutto se stai provando a comprimere i dati che sono già quasi casuali, ad es. dati precompressi, potresti vedere un aumento delle dimensioni. – Joey

.docx è già compresso utilizzando la compressione ZIP (prova a rinominare in .zip e avere un esplora). Sarei sorpreso se un secondo livello di compressione portasse qualche beneficio. – spender

dovrebbe effettivamente fare solo la compressione sul flush, quindi non dovrebbe cambiare una cosa – kite

Tale una grande differenza sembra strano per me, ma si dovrebbe tenere a mente che docx è a sua volta compressi in ZIP, quindi non c'è alcuna ragione per comprimere ancora una volta, i risultati di solito sono più grandi.

fonte

2010-10-05 13:32:45 Andrey

Confermato: http://www.myformatfactory.com/DOCX –

sì grazie, non lo sapevo, ed è per questo che non ha funzionato :) provato con .txt e altri formati e mi sembra migliore. ma ancora non funziona su un tipo di file serializzato fatto in casa ... ma alla fine non importa, volevo solo vedere come usare quei flussi di compressione :) – kite

-2

Non credo che GzipStream e DeflateStream siano pensati per comprimere i file. Probabilmente avresti miglior fortuna con un compressore di file come SharpZipLib.

fonte

2010-10-05 13:32:55

sono fatti per comprimere e decomprimere. Attualmente sto leggendo il libro di certificazione MCTS 70-536 e sono usati così lì ^^ – kite

e a cosa servono? http://msdn.microsoft.com/en-us/library/system.io.compression.gzipstream.aspx "Classe GZipStream Fornisce metodi e proprietà utilizzati per comprimere e decomprimere i flussi." – Andrey

Sono perfettamente in grado di comprimere file e per molti casi più maneggevoli che zip, poiché lavorano direttamente sul file anziché creare un archivio e possono essere visualizzati direttamente da un server web invece di comprimere al volo ogni volta. L'aggiunta di .gz al nome (dopo l'estensione originale invece di sostituirla) è comune con i file gzip. Per non dire che SharpZipLib non è migliore in molti casi però. –

Innanzitutto, sgonfiare/flussi gzip sono notevolmente male compressione rispetto a zip, 7z, ecc

secondo luogo, docx (e tutti i formati di documenti MS con un 'x' alla fine) appena sono file .zip comunque. Rinominare un .docx in .zip per rivelare il fumo e gli specchi.

Così quando si esegue deflate/gzip su un docx, in realtà renderà il file più grande. (È come fare una zip con un basso livello di compressione su un file zippato con un alto livello di compressione.)

Tuttavia se si esegue deflate/gzip su HTML o un file di testo o qualcosa che non è compresso, sarà effettivamente fare un buon lavoro

fonte

2010-10-05 13:39:25 DJA

grazie, come detto in altri commenti non sapevo che docx era già compresso. e sicuramente 7z e altre librerie sono migliori, ma volevo solo provare a vedere cosa erano in grado di fare – kite

Questo sembra un commento totalmente non valido: * i flussi di deflate/gzip sono notevolmente cattivi a compressione rispetto a zip, 7z, eccetera*. Il fatto è che il 99% dei file zip utilizza DEFLATE come formato di compressione. Quindi zip può essere * non migliore * di DEFLATE, perché aumenta il flusso compresso con i metadati. – Cheeso

Il fenomeno in cui un DeflateStream effettivamente * aumenta * la dimensione dei dati precedentemente compressi è l'argomento di un bug che è stato aperto con Microsoft nel 2006: https://connect.microsoft.com/VisualStudio/feedback/details/93930/ gzipstream-deflatestream-fail-to-check-per-incompressible-data – Cheeso

Se è vero, come altri hanno indicato, che l'esempio si specificato sono già file compressi - il più grande problema è capire che a differenza della maggior utilità di compressione, il DeflateStream e GZipStream classi cercano semplicemente di tokenize/comprimere un flusso di dati senza l'intelligenza che tutti i token aggiuntivi (overhead) stanno effettivamente aumentando la quantità di dati richiesti. Zip, 7z, ecc. Sono abbastanza intelligenti da sapere che se i dati sono in gran parte un'entropia casuale (praticamente non comprimibile), che memorizzano semplicemente i dati "così come sono" (archivia, non compressi), invece di tentare di comprimerlo ulteriormente.

fonte

2010-10-05 14:21:30 Michael

Questo non è vero: * Zip, 7z, ecc. sono abbastanza intelligenti da sapere che se i dati sono in gran parte un'entropia casuale (praticamente non comprimibile), che semplicemente memorizzano il dati "così com'è" (store, non compresso), invece di tentare di comprimerlo ulteriormente. * ZIP è semplicemente un formato di file. Non "sa" nulla. un programma che produce un file ZIP può fare ciò che descrivi, ma il formato ZIP no. – Cheeso

Il fenomeno in cui DeflateStream effettivamente * gonfia * la dimensione dei dati precedentemente compressi è l'argomento di un bug che è stato aperto con Microsoft: https://connect.microsoft.com/VisualStudio/feedback/details/93930/gzipstream-deflatestream -fail-to-check-for-incompressible-data – Cheeso

Non parlava del formato (buon dolore). Stavo parlando delle utility di compressione che scrivono i dati nei loro formati corrispondenti. – Michael

Ho avuto lo stesso problema con la compressione di database contenenti dati jpg. Ho provato dotnetzip - un calo di sostituzione e ottenuto compressione decente (Supporta Compact Framework troppo!):

MS : 10MB -> 10.0MB 
DNZ: 10MB -> 7.6MB

fonte

2011-10-11 14:53:39

GZipStream e DeflateStream producono file più grandi

risposta

Problemi correlati