java.util.zip.ZipException: Fehler beim Öffnen der Zip-Datei

76

Ich habe eine Jar-Datei, die andere verschachtelte Jars enthält. Wenn ich den neuen JarFile()Konstruktor für diese Datei aufrufe, wird eine Ausnahme angezeigt, die besagt:

java.util.zip.ZipException: Fehler beim Öffnen der Zip-Datei

Wenn ich den Inhalt dieser Jar-Datei manuell entpacke und wieder komprimiere, funktioniert es einwandfrei.

Ich sehe diese Ausnahme nur in WebSphere 6.1.0.7 und höheren Versionen. Das gleiche funktioniert gut auf Tomcat und WebLogic.

Wenn ich JarInputStream anstelle von JarFile verwende, kann ich den Inhalt der Jar-Datei ohne Ausnahmen lesen.

Sandhya Agarwal
quelle
3
Vielen Dank für den Hinweis zum erneuten Kopieren der Datei - der für mich behoben wurde.
Bryan Larsen
Ich hatte dieses Problem auf dem Mac, als Windows und Linux einwandfrei funktionierten. Die Verwendung von JarInputStream hat das Problem für mich behoben.
Boris van Schooten
Ich habe das gleiche Problem beim Start von Tomcat [Catalina.properties] org.apache.catalina.startup.TldConfig tldScanJarfestgestellt: WARNUNG: Fehler beim Verarbeiten von JAR [jar: ../ opensaml.jar! /] Für TLD-Dateien ZipExceptionzur Behebung dieses Problems. Fügen Sie opensaml. ~ .Jar in Application lib hinzu Mappe.
Yash
Scheint vom Betriebssystem abhängig zu sein. Mit Java 8 ist eines meiner Jars unter MacOS und Linux lesbar, aber nicht unter Windows 7. Das JAR ist ungefähr 80 MByte groß. Ältere Jars sind unter demselben Windows 7 einwandfrei lesbar. Dafür gibt es bessere Debugging-Optionen.
Wolfgang Fahl

Antworten:

27

Stellen Sie sicher, dass Ihre JAR-Datei nicht beschädigt ist. Wenn es beschädigt ist oder nicht entpackt werden kann, tritt dieser Fehler auf.

arulraj.net
quelle
18

Ich hatte das gleiche Problem. Ich hatte ein Zip-Archiv, das java.util.zip.ZipFile nicht verarbeiten konnte, aber WinRar entpackte es einwandfrei. Ich habe einen Artikel über SDN über das Komprimieren und Dekomprimieren von Optionen in Java gefunden. Ich habe einen der Beispielcodes leicht modifiziert, um eine Methode zu erstellen, mit der das Archiv endlich verarbeitet werden konnte. Der Trick besteht darin, ZipInputStream anstelle von ZipFile zu verwenden und das Zip-Archiv nacheinander zu lesen. Diese Methode kann auch leere Zip-Archive verarbeiten. Ich glaube, Sie können die Methode an Ihre Bedürfnisse anpassen, da alle Zip-Klassen äquivalente Unterklassen für .jar-Archive haben.

public void unzipFileIntoDirectory(File archive, File destinationDir) 
    throws Exception {
    final int BUFFER_SIZE = 1024;
    BufferedOutputStream dest = null;
    FileInputStream fis = new FileInputStream(archive);
    ZipInputStream zis = new ZipInputStream(new BufferedInputStream(fis));
    ZipEntry entry;
    File destFile;
    while ((entry = zis.getNextEntry()) != null) {
        destFile = FilesystemUtils.combineFileNames(destinationDir, entry.getName());
        if (entry.isDirectory()) {
            destFile.mkdirs();
            continue;
        } else {
            int count;
            byte data[] = new byte[BUFFER_SIZE];
            destFile.getParentFile().mkdirs();
            FileOutputStream fos = new FileOutputStream(destFile);
            dest = new BufferedOutputStream(fos, BUFFER_SIZE);
            while ((count = zis.read(data, 0, BUFFER_SIZE)) != -1) {
                dest.write(data, 0, count);
            }
            dest.flush();
            dest.close();
            fos.close();
        }
    }
    zis.close();
    fis.close();
}
JohnyCash
quelle
3
zis.close(); fis.close();sollte in einer finally-Klausel sein - duh (oder versuchen Sie es mit Ressourcen)
Mr_and_Mrs_D
Dies löst mein genau das gleiche Problem! Problem war die Verwendung von ZipFile anstelle von ZipInputStream! Vielen Dank <3
CrazyProg
10

Es könnte mit log4j zusammenhängen.

Haben Sie die Datei log4j.jar im Java-Klassenpfad der Websphere (wie in der Startdatei definiert) sowie im Klassenpfad der Anwendung?

Wenn Sie sicherstellen, dass sich die Datei log4j.jar im Java-Klassenpfad und NICHT im Verzeichnis web-inf / lib Ihrer Webanwendung befindet.


Es kann auch mit der Ameisenversion zusammenhängen (möglicherweise nicht Ihr Fall, aber ich stelle es hier als Referenz):

Sie haben eine .class-Datei in Ihrem Klassenpfad (dh kein Verzeichnis oder eine .jar-Datei). Ab ant 1.6 öffnet ant die Dateien im Klassenpfad und sucht nach Manifesteinträgen. Dieser versuchte Öffnen schlägt mit dem Fehler "java.util.zip.ZipException" fehl.

Das Problem besteht bei ant 1.5 nicht, da nicht versucht wird, die Dateien zu öffnen. - Stellen Sie daher sicher, dass Ihre Klassenpfade keine .class-Dateien enthalten.


Haben Sie nebenbei in Betracht gezogen, separate Gläser zu haben ?
Sie können sich im Manifest Ihres Hauptglases auf die anderen Gläser mit diesem Attribut beziehen:

Class-Path: one.jar two.jar three.jar

Stellen Sie dann alle Ihre Gläser in denselben Ordner.
Auch hier gilt möglicherweise nicht für Ihren Fall, aber immer noch als Referenz.

VonC
quelle
Vielen Dank für Ihre Antwort. Ich habe jedoch keine log4j.jar im Java-Klassenpfad der Websphere.
Sandhya Agarwal
9

Ich habe diese Ausnahme schon einmal gesehen, wenn auf das, was die JVM als temporäres Verzeichnis betrachtet, nicht zugegriffen werden kann, weil es nicht vorhanden ist oder keine Schreibberechtigung hat.

Artur ...
quelle
3

Ich habe dieses Problem gelöst, indem ich die Verzeichnisse jboss-xyz / server [config] / tmp und jboss-xyz / server / [config] / work gelöscht habe.

Marius K.
quelle
2

Ich habe dies mit einer bestimmten Zip-Datei mit Java 6 gesehen, aber es ging weg, als ich auf Java 8 aktualisierte (habe Java 7 nicht getestet), so dass es scheint, dass neuere Versionen von ZipFile in Java mehr Komprimierungsalgorithmen unterstützen und somit Dateien lesen können, die scheitern mit früheren Versionen.

Centic
quelle
0

Liquibase hat diesen Fehler für mich erhalten. Ich habe dieses Problem behoben, nachdem ich debuggt und beobachtet habe, wie liquibase versucht, die Bibliotheken zu laden, und festgestellt habe, dass in den Manifestdateien für commons-codec-1.6.jar ein Fehler aufgetreten ist. Im Wesentlichen befindet sich entweder irgendwo in Ihrem Pfad eine beschädigte Zip-Datei oder es wird eine inkompatible Version verwendet. Als ich das Maven-Repository für diese Bibliothek erkundete, stellte ich fest, dass es neuere Versionen gab, und fügte die neuere Version der Datei pom.xml hinzu. An diesem Punkt konnte ich fortfahren.

iowatiger08
quelle
0

Ich bekam eine Ausnahme

java.util.zip.ZipException: invalid entry CRC (expected 0x0 but got 0xdeadface)
    at java.util.zip.ZipInputStream.read(ZipInputStream.java:221)
    at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:140)
    at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:118)
...

beim Entpacken eines Archivs in Java. Das Archiv selbst schien nicht beschädigt zu sein, da 7zip (und andere) es ohne Probleme oder Beschwerden über ungültige CRC geöffnet haben.

Ich habe zu Apache Commons Compress gewechselt, um die Zip-Einträge zu lesen, und das hat das Problem behoben.

Radoh
quelle
0

Unter Windows 7 hatte ich dieses Problem über eine Samba-Netzwerkverbindung für eine Java8-Jar-Datei mit einer Größe von> 80 MByte. Durch Kopieren der Datei auf ein lokales Laufwerk wurde das Problem behoben.

Wolfgang Fahl
quelle
0

In meinem Fall -Dloader.path="lib"enthält meine andere Gläser, die nicht benötigt werden. mvn dependency:copy-dependencieslistet zum Beispiel 100 libJAR-Dateien auf. Mein Verzeichnis enthält jedoch 101 JAR-Dateien.

hatanooh
quelle
0

In meinem Fall stehen SL4j-api.jar mit mehreren Versionen im Maven-Repo in Konflikt. Als ich den gesamten SL4j-api-Ordner in m2 maven repo gelöscht und das maven-Projekt aktualisiert habe, habe ich ein maven-Projekt erstellt und dann das Projekt auf dem JBOSS-Server ausgeführt. Problem wurde behoben.

Shaik Elias
quelle
-1

Einfach auf die ZipException der zu überwinden, ich einen Wrapper für verwendet haben 1,14 genannt durch schriftliche thrau dass es leicht zu extrahieren oder Kompresse aus und in die File - Objekte macht.commons-compressjarchivelib

Beispiel:

public static void main(String[] args) {
        String zipfilePath = 
                "E:/Selenium_Server/geckodriver-v0.19.0-linux64.tar.gz";
                //"E:/Selenium_Server/geckodriver-v0.19.0-win32.zip";
        String outdir = "E:/Selenium_Server/";
        exratctFileList(zipfilePath, outdir );
}
public void exratctFileList( String zipfilePath, String outdir ) throws IOException {
    File archive = new File( zipfilePath );
    File destinationDir = new File( outdir );

    Archiver archiver = null;
    if( zipfilePath.endsWith(".zip") ) {
        archiver = ArchiverFactory.createArchiver( ArchiveFormat.ZIP );
    } else if ( zipfilePath.endsWith(".tar.gz") ) {
        archiver = ArchiverFactory.createArchiver( ArchiveFormat.TAR, CompressionType.GZIP );
    }
    archiver.extract(archive, destinationDir);

    ArchiveStream stream = archiver.stream( archive );
    ArchiveEntry entry;

    while( (entry = stream.getNextEntry()) != null ) {
        String entryName = entry.getName();
        System.out.println("Entery Name : "+ entryName );
    }
    stream.close();
}

Maven-Abhängigkeit «Sie können die Gläser aus dem Sonatype Maven Repository unter org / rauschig / jarchivelib / herunterladen .

<dependency>
  <groupId>org.rauschig</groupId>
  <artifactId>jarchivelib</artifactId>
  <version>0.7.1</version>
</dependency>

@sehen

Yash
quelle