11/01/2021
Quelques éléments de réflexion
Effectuons quelques remarques suite à notre exercice sur les notions d'archive et d'arborescence. Nous reviendrons sur certains points ultérieurement mais rien ne vous empêche de chercher à mieux comprendre les notions esquissées par des recherches personnelles sur internet.
Un constat
- L'archive
Archive_fleurs_arbres_transports.zip
contenait 24 fichiers dont chacun faisait 11 octets.
- Vous pouvez le vérifier en visualisant votre arborescence en mode liste et en regardant la colonne
Taille
(si cette colonne n'apparaît pas, modifiez les paramètres d'affichage de votre gestionnaire de fichiers).
- Vous pouvez aussi sélectionner un fichier et dans son menu contextuel, lire les informations. Sur la machine où a été conçue ce TD, il est indiqué que le fichier fait bien 11 octets mais qu'il utilise 4Ko sur disque : cela est dû au gestionnaire de fichiers qui réserve de la place par blocs (ici de 4Ko).
- À noter que les fichiers sont au format texte seulement (aussi appelé texte brut) ce qui signifie qu'il contiennent juste une suite de caractères. Il y a 11 caractères dans chaque fichier. Cela est cohérent avec la définition d'un octet, 8 bits, taille nécessaire pour l'encodage des caractères de base (ici l'encodage du fichier est en UTF-8, si on avait eu d'autres caractères, nous aurions pu avoir une taille supérieure, certains caractères étant codés sur 2 ou 4 octets).
- La taille totale utile des fichiers fait donc 264 octets.
- Or la taille de l'archive compressée est 10 108 octets (12 Ko sur disque).
- Question : est-ce normal que l'archive soit plus grosse que les données de départ ?
Exercice
- Choisissez un des fichiers de l'archive (il fait donc 11 octets).
- Faites-en une archive compressée et comparez sa taille. N'est-elle pas, là encore, plus grosse que le fichier de départ ?
Explications et conséquences
- La situation précédente n'est pas anormale pour des raisons combinatoires (grosso modo : un fichier est une suite de bits ; il y a
2n
fichiers de n
bits et donc globalement moins de fichiers d'au plus n-1
bits que de fichiers de n
bits ; comme on veut une compression sans perte, il n'existe pas d'algorithme général capable de compresser n'importe quel fichier en un fichier strictement plus petit).
- En pratique, on travaille avec des fichiers beaucoup plus gros que nos fichiers d'exemple et la compression est effective.
- Outre le phénomène, on pourra retenir aussi que :
- quand on veut compresser un ensemble de fichiers, ce n'est pas une bonne idée de compresser un à un tous les fichiers puis faire une archive compressée. Outre que c'est chronophage, le résultat risque fort d'être plus gros (vous pouvez essayer avec nos fichiers (ou d'autres)).
- il est inutile de compresser un fichier déjà compressé (le gain sera faible voire négatif).