Des archives zip plus petites que ce que la classe Php ZipArchive permet d'obtenir!

Les algorithmes d'archivages que nous avons testés (Php 5.3.3 et une distribution Linux 2.6.31.14-0.8-desktop x86_64) ne compressent pas les noms de fichiers! A noter que les software mentionnés ne sont pas les plus récents, mais il y a peu de chances que ces paramètres aient été changés. Il s'ensuit que dans de nombreux cas une compression supplémentaire diminue considérablement la taille du fichier obtenu, car les noms de fichiers en toutes lettres se font cette fois compresser vu qu'ils font maintenant partie du contenu du premier fichier d'archive. A noter qu'une troisième compression augmente la taille de l'archive car il n'y a plus rien a compresser et l'archive finale doit englober les informations supplémentaires générées par la dernière compression! Nous avons donc dans l'environnement Ataox deux manières de générer des fichiers ultra-compressés :

1. Zip-->zip : c'est à dire deux compressions en série utilisant la classe Php ZipArchive.
2. Agré-->zip : c'est à dire une mise bout à bout de tous les fichiers avec l'algorithme disponible dans le menu du navigateur de fichiers Ataox : "Agrégation / Construire", suivie d'une compression standard utilisant la classe Php ZipArchive. A noter que l'agrégateur génère par défaut des fichiers suffixés en .tar (tape archive) alors que ce n'est qu'un simple format texte! Ceci a été fait pour faciliter le téléchargement par simple pointage du fichier dans les navigateurs.

Suprise : la méthode de compression "agré-->zip", compresse souvent et peut-être même toujours mieux (*x) que la compression "zip-->zip"!. (*x) A noter qu'il y a de nombreuses méthodes de compression et d'agrégation, et nous n'en avons testé que deux.

Deux tests pour mettre ces différences en évidence :

Cas des fichiers et répertoires de la distribution Ataox 1.2.0 beta (les archives incluses dans la distribution ont été décompressées et les archives enlevées, la vraie distribution à une forme hybride car le fichier d'archive contient une archive zip et d'autres fichiers n'ayant pas été compressés) : nous obtenons respectivement pour les cas "agré-->zip" et "zip-->zip" les résultats suivants : (testConcat.zip : 1 Mb + 773 Kb + 495 bytes || testZip.zip : 1 Mb + 931 Kb + 714 bytes) ----> (1024*1024+931*1024+714) / (1024*1024+773*1024+495) = 1.08802 de facteur d'économie, ce qui représente une économie de place d'environ 8.8% de la taille de la plus petite archive obtenue.

Cas d'un ensemble de fichiers et répertoires nommé de la manière la plus longue possible (255 caractères de 1 byte chacun, pas testé les caractères multibytes) : on obtient 965 bytes pour une archive "zip-->zip" et 402 bytes pour une archive "aglo-->zip", ce qui donne le rapport : 965 / 402 = 2.400498 donc un gain d'environ 240%, l'exemple de test utilisé est disponible en téléchargement sous sa forme "zip-->zip".

L'agrégateur n'a pas été créé dans le but premier de gagner quelques pourcents en compression sérialisées, mais bien par nécessité car :

• A l'époque de sa création la classe php ZipArchive n'existait pas et créer un système d'archivage et de compression aurait été beaucoup trop long, ce qui fait qu'une simple agrégation ds fichiers s'est imposée.
• L'alternative de décompresser localement et de monter tous les fichiers avec FTP est dans de nombreux cas beaucoup trop lente pour être pratique.
• Certains environnements php ont des difficultés avec la classe ZipArchive, un environnement php 5.6 testé par nos soins parvient à faire une décompression correcte mais n'est pas capable de compresser le moindre répertoire et évidemment dans ce genre de cas l'agrégation de fichiers est salutaire.

Remarques :

• La comparaison entre une simple agrégation de fichiers et un processus de compression classique permet des tests intéressants et permet de présenter le sujet de la compression php / Linux sous un angle différent.
• Il est possible que d'autres avantages apparaissent à plus long terme.

Conclusion : une agrégation préalable de fichiers et répertoires peut dans certains cas présenter un gain de place intéressant, mais dans la majorité des cas la différence obtenue ne justifie pas l'effort supplémentaire. Son utilisation se cantonne donc principalement aux situations de dépannages comme alternatives aux archives zip standards.