Journal Le 7z, un format qu'il est bien !

Posté par  .
Étiquettes : aucune
0
26
sept.
2006
Cher journal,

Voici quelques temps, j'étais encore un fervant utilisateur des tar.bz2 pour mes archives et sauvegardes... Mais voici qu'il y a peu, j'ai commencé à recevoir des fichiers compressé en .7z [1] !!
Je me suis alors tout naturellement interessé à ce format, pour découvrir, Ô combien il est merveilleux !

Voici un bref résumé de ce qui m'interesse dans ce format :

1. Déja, très important à mes yeux, c'est un format totalement libre et ouvert ! De plus, déja disponible sur la majorité des plates-formes existantes.

2. Il dispose d'un taux de compression extrêmement bon [2] ! Bien meilleur que la plupart des autres formats dans la majorité des cas. Pour dire, j'avais tester avec un fichier texte texte de 360Mo (extremement répétitif, car c'est des coordonnées, donc qui se compresse très bien). En zip, j'obtenais un fichier de 65Mo. En zip avec 7z, j'obtient un fichier de 50Mo... Et en format 7z, j'obtient un fichier de 3,5 Mo !!! (Non, y'a pas d'erreur... J'ai dis que c'est un fichier qui devait bien ce compresser ^^). Ensuite, pour des fichiers normaux, j'obtient quand même de bien meilleur résultat d'environ 2/3 des zips.

3. L'executable est capable de décompresser pratiquement n'importe quel format courant. Ce qui est très pratique pour pas se casser la tete avec 36 commande pour chaque format... Mais aussi de compresser dans certain format libre (bz2... zip.. ect...) [3]

4. Le format 7z contient toutes les caratéristiques des zip en mieux (cryptage pas mot de passe... ect) plus des petits truc interessant comme la synchronisation avec des dossiers (pratique pour faire des sauvegardes).

5. Point non négligeable pour participer à son succes, la version Windows contient une interface semblable à celle de Winzip, qui permet même a vos amis windowsiens de pas passez par la ligne de commande et de s'y retrouver facilement. Et donc de faire une total alternative au winzip.

6. La ligne de commande est également facile à utilisé... Un simple "7z a fichier.7z [fichiers_à_compresser]" est c'est bon ^^

Seul point noir que j'ai a noté dire, c'est sa vitesse... Il est très lent à la compression. La décompression est, elle, correct.
Donc, amis Linuxien et Windowsien, abandonnés vos tar.bz2 tar.gz et zip, et utilisé maintenant le format alternatif 7z qui est bien plus pratique, et plus facilement abordable sur toutes les plate-formes.

Liens :
[1] Site officiel : http://www.7-zip.org/fr/
[2] Un comparatif : http://rlwpx.free.fr/WPFF/comploc.htm
[3] Les formats supporté (sur Wikipédia) : http://fr.wikipedia.org/wiki/7-Zip
  • # C'est plutôt logique

    Posté par  . Évalué à 9.

    Une meilleure compression se paye par un temps de compression plus long et à la decompression par une utilisation memoire plus importante.

    Teste avec bzip2 à differents niveaux de compression (option: -1, -2, ... , -9 de mémoire). Si tu demandes à un 7z une compression moins forte s'approchant d'un resultat d'un zip, le temps de compression sera lui aussi similaire au temps de compression d'un zip ;)
    • [^] # Re: C'est plutôt logique

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Sur le petit test que je viens de faire (fichier texte de 235Mo), un bzip2 -9 compresse à 7.1Mo, vs 3.5Mo pour 7z. Lent mais très impressionnant.

      Seul bémols, d'après la page man :
      - il ne garde pas les droits
      - il permet pas de faire une archive récursive d'un répertoire sans passer par tar (on a donc du tar.7z)
      • [^] # Re: C'est plutôt logique

        Posté par  . Évalué à 6.

        remarque si je ne me trompe pas, il en est de même pour le format gzip ? il faut bien passer par tar, qui lui va gérer les permissions.
        Donc pas vraiment d'inconvénient pour le format 7z à ce niveau-là, et même limite, ça reste plus dans l'esprit unix, chaque chose fait une chose mais bien.
  • # Oui au 7z!

    Posté par  (site web personnel) . Évalué à 1.

    Ca me fait toujours bizarre quand je passe sous Linux de me taper un .tar.bz2, qui si je ne mets pas les bonnes options à apprendre par coeur, decompresse le bz2 en un .tar, donc hop deuxième commande.

    7z, c'est tout en 1.
    Et avec les CPU et la RAM actuelle, ca va, c'est très correct comme consommation (et surtout, on s'en fout de la machine cliente, la décompression est très très rapide)
    7z, c'est bon, mangez-en!
    • [^] # Re: Oui au 7z!

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Franchement avec les dernières version de tar plus la peine de connaitre tar xvfz ou tar xfvj selon le format, un simple tar xvf suffit, et tar reconnait tout seul le format de l'archive.
      • [^] # Re: Oui au 7z!

        Posté par  . Évalué à 3.

        Y a aussi des êtres humains qui font "clic droit, extraire ici" et qui se retrouve avec un fichier .tar tout court à re-"clic droit, extraire ici". :-) Avec un .7z pas de soucis (même si je me demande pourquoi le support des .7z n'est pas intégré de base dans les distros que j'ai pu voir).
        • [^] # Re: Oui au 7z!

          Posté par  (site web personnel) . Évalué à 5.

          Je sais pas pour toi, mais dans mon environnement de bureau, pour décompresser n'importe quelle archive, je fais clic-droit->extraire et ça m'extrait le contenu de l'archive.
          Bref ça marche très bien et pas besoin non plus de se souvenir des options de la ligne de commande, et donc mauvais argument !
          • [^] # Re: Oui au 7z!

            Posté par  . Évalué à -1.

            Soit tu répondais au commentaire au dessus du mien et tu t'es gourré de lien, soit tu répondais à mon commentaire en disant la même chose. :D
        • [^] # Re: Oui au 7z!

          Posté par  (site web personnel) . Évalué à 10.

          si ton logiciel est suffisamment con pour ne pas voir le ".tar" (ou mieux, utiliser le magic de "file" pour savoir que c'est un tar) et proposer de sortir les fichiers de l'archive par la meme occasion, c'est que c'est lui le problème - pas le format...
      • [^] # Re: Oui au 7z!

        Posté par  . Évalué à 4.

        Et si tu trouves que c'est pas assez rapide, tu enlèves le ‛v’ (c'est fou le temps que ça prend l'affichage).
        • [^] # Re: Oui au 7z!

          Posté par  (site web personnel) . Évalué à 0.

          l'homme a inventé le frame buffer pour que justement on laisse le l'option verbose afin de faire un joli économiseur d'écran lorsqu'on extrait les sources du kernel sans tout ralentir :)
          • [^] # Re: Oui au 7z!

            Posté par  (site web personnel) . Évalué à 2.

            Ben mes commandes sont en framebuffer, et mon écran lcd, si je fait un zoli Ctrl+Alt+Fx (allez retour, ho mirracle ça va plus vite que si je reste a regarder les lignes défiler, donc y a bien une différence...)

            Sans parle du fait que ton gentil programme il fait un printf a chaque ligne, je te dis pas comme c'est peu gourmand un printf pour chaque fichier comparé a RIEN...
            • [^] # Re: Oui au 7z!

              Posté par  . Évalué à 2.

              normal, le problème c'est pas le fb, c'est que tu fais
              1°) des appels systèmes -rajout de fonction, c'est pas nul, encore moins quand elles sont systèmes -
              2°) que le framebuffer il doit aussi faire des traitements pour afficher.

              D'ailleurs c'est pas pour rien qu'on ne met pas tout le temps les affichages de debug sur un programme (mis à part pour ne pas pourrir le terminal)
  • # gzip *

    Posté par  . Évalué à 0.

    Comment fait-on la même chose qu'un : gzip -9 *
    C'est à dire un truc qui prend tous les fichiers d'un répertoire et les remplace par leur homologue compressé.
    toto -> toto.gz
    Parce que si je fais : 7z * j'ai des erreurs.
    Finalement on perd en facilité d'utilisation si l'on doit entrer pour chaque fichier le nom de l'archive à créer.
    • [^] # Re: gzip *

      Posté par  . Évalué à 3.

      Bah, j'ai a étudié assez pour savoir si ça existe directement dedans, mais ça c'est vite fait : ^^
      $ for FILE in *; do 7z a $FILE.7z $FILE; done
    • [^] # Re: gzip *

      Posté par  (site web personnel) . Évalué à 1.

      le package debian fournit un scrip shell dénommé p7zip qui appelle les commandes 7z pour fonctionner comme gzip.
      Script surement présent dans d'autres distribs (?)
  • # wrappers

    Posté par  (site web personnel) . Évalué à 5.

    Ce qui serait intéressant, ce serait de faire des wrapper :
    unzip, zip, unrar qui appelerait 7z ainsi tout les progs GUI ou autres qui utisent unzip, zip, ou unrar n'aurait plus qu'une seule dépendance, 7z (libre qui plus est.)
    • [^] # Re: wrappers

      Posté par  . Évalué à 5.

      Le wrapper ultime qui gère tout même 7z: http://www.nongnu.org/atool/
  • # comparatif

    Posté par  (site web personnel) . Évalué à 8.

    C'est moi où il n'y a pas bzip2 dans le comparatif ?

    Ensuite marquer «tar.gz» est incorrect, «gzip» seul permet de compresser. Mais bon je pinaille là ... mais c'est important de pinnailler, après on se retrouve à appeler les balladeurs numériques des «MP3» et à croire que flash est libre (ben oui ! il est gratuit !).
    • [^] # Re: comparatif

      Posté par  . Évalué à 3.

      Non, je reste sur le tar.gz, car gzip permet de compresser uniquement, mais 7z archive+compresse, c'est à dire l'équivalent du tar+gz ! :-)
      • [^] # Re: comparatif

        Posté par  (site web personnel) . Évalué à 4.

        Ok, mais dans le comparatif, à chaque test un seul fichier est compressé !
        • [^] # Re: comparatif

          Posté par  (site web personnel) . Évalué à 3.

          Et ce point est d'autant plus important qu'il constitue l'énorme avantage des fichier de type "tar.bz2" (groupage puis compression) par rapport aux "bz2.tar" (compression puis groupage).

          En effet, les "tar.bz2" réduisent la redondance entre différents fichiers d'un même groupe, laquelle peut être très importante.

          À priori, l'archivage de 7zip est de type "bz2.tar", alors que les outils bzip2 et tar utilisés conjointement permettent de produire les deux sortes.
          • [^] # Re: comparatif

            Posté par  (site web personnel) . Évalué à 4.

            À priori, l'archivage de 7zip est de type "bz2.tar", alors que les outils bzip2 et tar utilisés conjointement permettent de produire les deux sortes.

            Hum... Faut se renseigner avant d'écrire.
            Je ne connais pas l'option en ligne de commande mais en GUI c'est "archive solide" qui permet de faire l'équivalent de tar.bz2 (sans cocher, ca fait l'equivalent de bz2.tar)

            C'est vraiment vouloir le descendre que de chercher en 7z des défauts qu'il n'a pas...
            (ceci dit, c'est aussi vraiment vouloir faire un comparatif moyen que de ne pas mettre tar.bz2 en compétition dans le comparatif, car c'est le compresseur le plus "moderne"et doué actuellement! Un point partout :) )
          • [^] # Re: comparatif

            Posté par  (site web personnel) . Évalué à 3.

            > Et ce point est d'autant plus important qu'il constitue l'énorme avantage des fichier de type "tar.bz2"

            C'est aussi un énorme inconvénient : ça enlève la possibilité d'extraire un seul fichier sans décompresser la totalité de l'archive, la possibilité d'ajouter un fichier simplement, ...

            Par ailleurs, je ne sais pas pour bzip2, mais gzip travaille avec une fenêtre, qui n'est pas si grande que ça, donc si tu met deux fichiers identiques dans l'archive, mais que les fichiers sont plus gros que la taille de la fenêtre, ça ne compresse pas vraiment mieux.

            Sauf erreur de ma part, le format d'archive de 7z permet de compresser plusieurs fichiers à la fois (des sortes de sous-archives) sans compresser tous les fichiers à la fois. C'est plutôt un bon compromis.
  • # FAITES DES DEPECHES MERDE ALORS

    Posté par  (site web personnel) . Évalué à 3.

    Ben ouais quoi, le texte est très bon mais juste un peu mal formulé et bourré de fautes d'orthographe. Contacte-moi Snarky si tu veux que je t'aide à la reformuler :
    http://www.haypocalc.com/wiki/Victor_Stinner#Me_contacter

    Haypo
  • # la page man

    Posté par  (site web personnel) . Évalué à 2.

    Comme les discutions s'enflamme un peu :) la page man :
    http://www.www.netzagentur.at/cgi-bin/man/man2html?7za+1

    On peu très bien compresser un répertoire complet mais on perd la gestion des droits, la seule solution passe par tar !

    7za a directory.7z directory

    tar cf - directory | 7za a -si directory.tar.7z

    Et sous Linux, 7z se nomme p7zip !
    http://p7zip.sourceforge.net/
    • [^] # Re: la page man

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Sous linux p7zip, qui ne comprend pas quand le nom du fichier a un espace, est compilé n'importe comment sur les amd64 (problèmes signalés, on verra bien un jour...), ... Programme LGPL sûrement, programme (vraiment) Linux c'est pas pour tout de suite

      En attendant <mode rabat-joie sous linux>comme déjà dit le bzip2 est manquant dans la liste de comparatifs, et si il fait 3% pire que 7zip... vu le coût du Mo de stockage, je préfère un truc qui prend un peu plus de place mais ne noie pas mon processeur! Et facile à utiliser... Franchement entre "p7zip -d" et "tar xvf[jz]" je vois pas la différence en facilité d'utilisation!

      Donc merci j'en reste aux tarballs+gzip ou bzip
      </mode rabat-joie>

      Après pour les windosiens, c'est effectivement mieux
  • # where is my trollometer?

    Posté par  . Évalué à 5.

    C'est donc ça un troll?
    7z, c'est mieux que bzip!

    http://linuxfr.org/~Uld/22745.html
  • # Fourchettes à ressorts

    Posté par  . Évalué à 2.

    Il lui manque à mon avis un truc, pas universellement utilisé certes, pour s'imposer vraiment : les "ressources forks" d'OSX.

    Pour ceux qui ne suivent pas tellement le monde non-libre (peu-libre?), il s'agit des métadonnées des systèmes de fichiers d'Apple. Une des particularités de ces systèmes est en effet d'avoir chaque entrée du FS "en double", une partie contenant les données (le fichier, quoi), l'autre les métadonnées. Cette spécificité est mal (voire pas) gérée par un certain nombre de formats de compressions, ce qui fait que les utilisateurs Mac sont encore largement coincée avec ce "cher" Stuffit Expander : application proprio, format fermé, etc. Le fait que Tiger supporte nativement le zip commence à faire bouger les choses, mais beaucoup commençent à voir en 7-Zip une alternative OpenSource. Si seulement il gérait correctement ces satanés forks, il ne serait plus bien compliqué de faire une petite interface à la Stuffit (i.e. minimaliste) par dessus et de la diffuser très largement.

    Alors certes, ça n'empèchera pas les linuxiens que nous sommes de dormir. Ni les adeptes de la Grande Fenêtre Cosmique. Mais ça serait une opportunité de plus pour le libre de se faire connaître.
    • [^] # Re: Fourchettes à ressorts

      Posté par  . Évalué à 3.

      ah non alors. ne contaminez pas le reste du monde avec vos "spécificités".
      • [^] # Re: Fourchettes à ressorts

        Posté par  . Évalué à 1.

        Bof,c'est pas forcément modifier le comportement de 7-zip sur les plateformes "normales". C'est juste rajouter une procédure de stockage/restauration des-dites infos dès lors qu'on se trouve sur Mac.

        Parce que bon, quand je vois des macqueux (pas spécialement OSS-friendly, donc) faire de longues tirades sur les forums macs en regrettant que 7z ne gère pas la-dite fonctionnalité, je me dis qu'on passe à-côté de quelque-chose. Merde quoi, pour une fois que c'est eux qui font l'apologie d'un truc libre... ;)
  • # Portage ...

    Posté par  (site web personnel) . Évalué à 4.

    Ça serait bien d'avoir une version native UNIX/Linux plutôt qu'un portage à l'arrache de code windows assez dégueux...
    • [^] # Re: Portage ...

      Posté par  (site web personnel) . Évalué à 3.

      L'algorythme est libre et tu as une implémentation de référence sous license libre, de plus, tu as mets un port unix libre. Donc si tu veux réimplémenter 7zip rien ne t'en empêche, si il est bien tu feras sans doute des heureux.

      Moi la version p7zip me va très bien, car elle est synchronisée avec la version de base (sous windows) et donc suit de très près les fonctionnalités ajoutées à ce dernier. Je n'ai pas regarder le code, je ne sais pas si il est dégueux comme tu le dit, mais il me satisfait très bien et sans doute les développeurs de p7zip.
    • [^] # Re: Portage ...

      Posté par  . Évalué à 2.

      Pourquoi tu dis que le code est degueux...?
      • [^] # Re: Portage ...

        Posté par  (site web personnel) . Évalué à 1.

        Peut-être parce que c'est du C++
        • [^] # Re: Portage ...

          Posté par  . Évalué à 4.

          En effet Nicolas, j'y avais déjà un coup d'oeil, c'est pas du code qui donne envie de l'inclure dans son projet! Le coding style C++, les noms de variables truffés de majuscules, etc ...

          D'ailleurs, http://www.7-zip.org/sdk.html :

          "ANSI-C LZMA decompression code was ported from original C++ sources to C. Also it was simplified and optimized for code size. But it is fully compatible with LZMA from 7-Zip"


          Il y a de la marge pour améliorer et nettoyer le code. En particulier, ca serait bien de decouper l'utilitaire en un frontend et une librairie dynamique. Ca permettrait alors d'inclure le support 7z dans des projets tiers.
  • # rzip

    Posté par  . Évalué à 4.

    Le format d'rzip est lui aussi adapté aux très gros fichiers car il va chercher les redondances très très loin. Son défaut en revanche est de ne pas gérer l'entrée standard et donc de ne pas être intégrable dans une chaîne de commandes. Quoi qu'il en soit il est meilleur que bzip2 pour les gros fichiers. Je vais tout de même faire un petit comparatif avec 7zip. Sait-on jamais... :)
    • [^] # Re: rzip

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Si tu pouvais nous faire partager ce petit comparatif, ce serait super :)
      • [^] # Re: rzip

        Posté par  . Évalué à 1.

        Les tests que j'ai pu faire jusqu'à présent montrent que le format 7zip est meilleur que rzip (lui même meilleur que bzip2 (lui même bien meilleur que gzip))... mais nom de nom : c'est looooong. Ah ça on sent que l'algo fignole sa compression. :)

        Celui qui veut recompresser ses fichiers .gz, .bz2 ou .rz devrait se faire un petit script et le lancer avant d'aller au lit... C'est pas pour les pressés, p7zip. :)
        • [^] # Re: rzip

          Posté par  . Évalué à 4.

          Par contre le temps de decompression du 7z est bien meilleur que dans le cas du bzip2 (complexite asymetrique : compression longeue, decompression facile). Ainsi le 7z est un format ideal pour la compression d'archive qui devront etre utilisée sur des systemes aux ressources CPU / mémoire limitées (par ex. un systeme embarqué).
  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: 7zip contre tous

      Posté par  . Évalué à 2.

      Un autre site qui n'est pas mal du tout pour ceux qui aiment les comparaisons tres detaillees : http://www.maximumcompression.com/

      Sur ce site, on trouve une comparaison de plus de 150 logiciels de compressions et sur une quantite tres variee de fichiers.

      Pour ceux qui n'ont pas envie de cliquer, 7-zip arrive dans les 20 premiers en general. Il arrive tres souvent devant les grands classiques (gzip, bzip, winzip...) : http://www.maximumcompression.com/data/summary_sf.php
      En plus, le site donne toutes les meilleures options a utiliser pour arrive a exploiter au mieux son logiciel prefere.

      Ce qui est interessant c'est le haut du tableau, il semble qu'il y ait des logiciels libres de compression (et aussi des propios) encore plus performant! c'est apparemment le cas de PAQ8i (que je n'ai pas pu essayer encore): http://www.cs.fit.edu/~mmahoney/compression/

      C'est surprenant de voir que 30 ans apres, on fait toujours des progres par rapport aux fameux LZ77 : http://en.wikipedia.org/wiki/LZ77
      • [^] # Re: 7zip contre tous

        Posté par  (site web personnel) . Évalué à 5.

        C'est surprenant de voir que 30 ans apres, on fait toujours des progres par rapport aux fameux LZ77

        Non, pas surprenant : les perfs CPU et la RAM de l'époque n'était pas compatibles avec des algorithmes plus complexes comme 7z (qui cosomme *beaucoup* de RAM et CPU)
        Il n'y avait pas que la capacité humaine à faire des algo, mais aussi la technologie qui a limité les premiers outils de compression...
        (Va mettre un dictionnaire de 128 Mo dans 128 Ko de RAM...)
    • [^] # Re: 7zip contre tous

      Posté par  . Évalué à 3.

      In the computer industry, we have lies, damn lies, statistics, benchmarks, and delivery dates.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.