Quel est le moyen le plus rapide pour extraire 1 fichier à partir d'un fichier zip qui contiennent beaucoup de fichier?

J'ai essayé le java.util.zip paquet, il est trop lent.

Puis j'ai trouvé LZMA SDK et 7z jbinding mais ils sont aussi en manque de quelque chose.
Le LZMA SDK ne permet pas de fournir une sorte de documentation/tutoriel-à-utilisation, il est très frustrant. Pas de javadoc.

Tandis que le 7z jbinding ne pas fournir un moyen simple d'extraire seulement 1 fichier, cependant, il seulement de fournir le moyen d'extraire tout le contenu du fichier zip. En outre, il ne fournit pas un moyen de spécifier un emplacement pour le fichier décompressé.

Une idée svp???

OriginalL'auteur lamwaiman1988 | 2011-03-30

  1. 15

    Que fait votre code avec java.util.zip ressembler et comment grand d'un fichier zip vous occupez-vous?

    Je suis en mesure d'extraire un 4MB entrée de 200 MO de fichier zip de 1 800 entrées dans environ une seconde avec cette:

    OutputStream out = new FileOutputStream("your.file");
FileInputStream fin = new FileInputStream("your.zip");
BufferedInputStream bin = new BufferedInputStream(fin);
ZipInputStream zin = new ZipInputStream(bin);
ZipEntry ze = null;
while ((ze = zin.getNextEntry()) != null) {
    if (ze.getName().equals("your.file")) {
        byte[] buffer = new byte[8192];
        int len;
        while ((len = zin.read(buffer)) != -1) {
            out.write(buffer, 0, len);
        }
        out.close();
        break;
    }
}
    Nous faisons une application web pour l'outsider de l'utilisation.....nous parlons de 20 requêtes par seconde. Nous avons à examiner que la vitesse de décompression d'un fichier à l'aide de java.util.zip serait entre 0,5 s à 2s. C'est lent.
    Je suppose que vous parlez de 20 requêtes par seconde qui ont besoin d'un seul fichier zip. Pourquoi ne pas juste complètement décompresser ceux à l'avance et de les servir directement à partir du système de fichiers?
    votre code devrait être encore plus rapide si vous avez eu une BufferedInputStream entre les FileInputStream et la ZipInputStream.
    vrai, de l'ajouter à la réponse, merci.
    Aussi, ne devriez-vous pas faire un zin.close() à la fin?

    OriginalL'auteur

  2. 10

    Je n'ai pas comparé la vitesse, mais avec java 7 ou plus, j'ai extrait un fichier comme suit.

    J'imagine que c'est plus rapide que la ZipFile API:

    Un court exemple de l'extraction de META-INF/MANIFEST.MF à partir d'un fichier zip test.zip:

    //file to extract from zip file
String file = "MANIFEST.MF";
//location to extract the file to
File outputLocation = new File("D:/temp/", file);
//path to the zip file
Path zipFile = Paths.get("D:/temp/test.zip");

//load zip file as filesystem
try (FileSystem fileSystem = FileSystems.newFileSystem(zipFile, null)) {
    //copy file from zip file to output location
    Path source = fileSystem.getPath("META-INF/" + file);
    Files.copy(source, outputLocation.toPath());
}
    merci. Cela fonctionne 🙂
    Les œuvres, et la vitesse de l'éclair ... ce doit être la accepté de répondre (en supposant que Java 7 ou supérieur).

    OriginalL'auteur

  3. 6

    Utiliser un ZipFile plutôt qu'un ZipInputStream.

    Bien que la documentation n'indique pas cela (il est dans les docs pour JarFile), il devrait utiliser l'accès aléatoire à des opérations de fichier pour lire le fichier. Depuis un ZIPfile contient un répertoire à un emplacement connu, ce qui signifie BEAUCOUP moins de IO a pour arriver à trouver un fichier en particulier.

    Quelques mises en garde: au meilleur de ma connaissance, le Soleil de la mise en œuvre utilise un fichier mappé en mémoire. Cela signifie que votre espace d'adressage virtuel doit être suffisamment grand pour contenir le fichier ainsi que toute autre chose dans votre JVM. Qui peut être un problème pour un serveur 32 bits. D'autre part, il peut être assez intelligent pour éviter de carte mémoire sur 32 bits, ou de la mémoire-carte juste au répertoire; je n'ai pas essayé.

    Aussi, si vous utilisez plusieurs fichiers, assurez-vous d'utiliser un try/finally pour s'assurer que le fichier est fermé après utilisation.

    OriginalL'auteur