Afficher le menu
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.zipcontenait 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).
- Vous pouvez le vérifier en visualisant votre arborescence en mode liste et en regardant la colonne
- 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
2nfichiers denbits et donc globalement moins de fichiers d'au plusn-1bits que de fichiers denbits ; 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).