Supposons que je possède 10 000 fichiers XML. Supposons maintenant que je veuille les envoyer à un ami. Avant de les envoyer, j'aimerais les compresser.
Méthode 1 : Ne pas les compresser
Résultats :
Resulting Size: 62 MB
Percent of initial size: 100%Méthode 2 : zippez chaque fichier et envoyez-lui 10 000 fichiers xml.
Commandement :
for x in $(ls -1) ; do echo $x ; zip "$x.zip" $x ; doneRésultats :
Resulting Size: 13 MB
Percent of initial size: 20%Méthode 3 : Créer un seul zip contenant 10 000 fichiers xml
Commandement :
zip all.zip $(ls -1)Résultats :
Resulting Size: 12 MB
Percent of initial size: 19%Méthode 4 : Concaténer les fichiers en un seul fichier et le zipper.
Commandement :
cat *.xml > oneFile.txt ; zip oneFile.zip oneFile.txtRésultats :
Resulting Size: 2 MB
Percent of initial size: 3%Questions :
- Pourquoi est-ce que j'obtiens de si bons résultats lorsque je ne fais que compresser un seul fichier ?
- Je m'attendais à obtenir de bien meilleurs résultats en utilisant la méthode 3 que la méthode 2, mais ce n'est pas le cas. Pourquoi ?
- Ce comportement est-il spécifique à
zip? Si j'ai essayé d'utilisergzipobtiendrais-je des résultats différents ?
Informations supplémentaires :
$ zip --version
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon. Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.
Compiled with gcc 4.4.4 20100525 (Red Hat 4.4.4-5) for Unix (Linux ELF) on Nov 11 2010.
Zip special compilation options:
USE_EF_UT_TIME (store Universal Time)
SYMLINK_SUPPORT (symbolic links supported)
LARGE_FILE_SUPPORT (can read and write large files on file system)
ZIP64_SUPPORT (use Zip64 to store large files in archives)
UNICODE_SUPPORT (store and read UTF-8 Unicode paths)
STORE_UNIX_UIDs_GIDs (store UID/GID sizes/values using new extra field)
UIDGID_NOT_16BIT (old Unix 16-bit UID/GID extra field not used)
[encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)Editer : Méta-données
Une réponse suggère que la différence réside dans les métadonnées du système qui sont stockées dans le zip. Je ne pense pas que cela puisse être le cas. Pour tester, j'ai fait ce qui suit :
for x in $(seq 10000) ; do touch $x ; done
zip allZip $(ls -1)Le zip résultant est de 1,4 Mo. Cela signifie qu'il y a encore ~10 Mo d'espace inexpliqué.
0 votes
Je ne suis pas familier avec le fonctionnement interne du programme zip, mais mon hypothèse initiale est que les méthodes 2 et 3 font essentiellement la même chose, sauf que zip combine les fichiers zippés individuels en une seule archive à la fin, ce qui expliquerait pourquoi les méthodes 3 et 4 sont aussi différentes.
36 votes
Si je ne me trompe pas, c'est ce phénomène qui fait que les gens font
.tar.gzplutôt que de simplement compresser le répertoire entier.0 votes
@corsiKlauseHoHoHo - Je parie que vous avez raison. Alors vous ne faites que zipper un seul fichier. Ce qui a probablement le même effet... Très intéressant
19 votes
A question similaire a déjà été demandé, tl;dr utilisez des archives 7zip solides.
4 votes
@sixtyfootersdude Comme test pour valider certaines des réponses, pouvez-vous essayer de zipper le zip produit par la méthode 3 ? Je pense que cela réduira la taille du fichier à quelque chose de comparable à la méthode 4.
7 votes
Au lieu de
$(ls -1)il suffit d'utiliser*:for x in *;zip all.zip *2 votes
@Travis : la représentation compressée de deux fichiers xml assez similaires peut ne pas être très similaire l'un à l'autre, surtout si la différence se situe au début. Si vous avez de la chance, vous pourriez arriver à une taille similaire à 4, mais cela pourrait facilement être bien pire.
0 votes
Un test supplémentaire intéressant consisterait à recréer un fichier .zip à partir de la méthode 3, c'est-à-dire en utilisant deux zips l'un dans l'autre.
0 votes
Vous utilisez Linux, pourquoi ne pas utiliser un format tar.[any] et profiter d'une archive "solide" ? tar.xz peut utiliser le même format que .7z - ou simplement utiliser .7z, si la raison est "mon ami n'utilise pas Linux ou n'a pas d'ordinateur". bon programmes d'archives installés" et vous ne voulez pas avoir à décompresser toute l'archive juste pour lister les fichiers. PS. Wikipedia mentionne pour zip " Chaque fichier est stocké séparément... il est possible de les extraire, ou d'en ajouter de nouveaux, sans appliquer de compression ou de décompression à l'ensemble de l'archive. Ceci contraste avec... les fichiers tar compressés [où] l'accès aléatoire n'est pas facilement possible. "
0 votes
La réponse est "Compression solide" .
4 votes
Si vous souhaitez effectuer une compression solide avec le ZIP, voici une solution de contournement : créez d'abord un fichier non compressé ZIP contenant tous vos fichiers. Ensuite, mettez ce ZIP à l'intérieur d'un autre ZIP compressé.
0 votes
Zip est très vieux et bien pire que rar ou 7z
1 votes
Par curiosité, en utilisant la méthode 4, comment avez-vous prévu que votre ami annule le
catet se retrouver à nouveau avec 10 000 fichiers ?0 votes
@kmort : Comme les fichiers sources sont des documents Xml, il est au moins encore possible d'extraire sans ambiguïté les documents Xml individuels, grâce au fait qu'aucun document Xml bien formé ne peut contenir plus d'un élément racine. Avec les bons outils, c'est-à-dire en particulier un lecteur Xml qui ne refuse pas de lire plusieurs documents Xml consécutifs du même flux.
0 votes
@O.R.Mapper Vous avez raison, c'est certainement possible, je me demandais juste s'il y avait une façon de faire. facile La manière canonique de "décatouer" quelque chose via une ou deux commandes Shell. Et comment obtenir les bons noms de fichiers, etc.)
2 votes
@corsiKlauseHoHoHo : Non, ce n'est pas à cause de l'intelligence, c'est à cause de la bêtise gzip ne peut pas réellement zipper un répertoire .
0 votes
En ce qui concerne votre question de savoir si
gzipdonnerait des résultats différents : gzip n'a aucune notion de la méthode 3.