2008-11-28 30 views
51

Tengo un archivo Jar, que contiene otros archivos JAR anidados. Cuando invoco la nueva JarFile() constructor en este archivo, me sale una excepción que dice:java.util.zip.ZipException: error al abrir el archivo zip

java.util.zip.ZipException: error en la apertura de archivos zip

cuando descomprimir manualmente el contenido de este archivo Jar y vuelva a cerrarlo, funciona bien.

Solo veo esta excepción en WebSphere 6.1.0.7 y versiones superiores. Lo mismo funciona bien en tomcat y WebLogic.

Cuando uso JarInputStream en vez de JarFile, puedo leer el contenido del archivo Jar sin ninguna excepción.

+2

Gracias por la pista sobre cómo volver a descomprimir el archivo, eso me solucionó. –

+0

Tuve este problema en Mac cuando Windows y Linux funcionaban bien. El uso de JarInputStream me solucionó el problema. –

+0

He enfrentado el mismo problema ** en Tomcat Start UP ** [catalina.properties]: 'org.apache.catalina.startup.TldConfig tldScanJar' ADVERTENCIA: Error al procesar JAR [jar: ../ opensaml.jar!/] para los archivos TLD 'ZipException' para resolver este problema, agregue [opensaml. ~ .jar] (http://mvnrepository.com/artifact/org.opensaml/opensaml) a la carpeta Application lib. – Yash

Respuesta

10

Podría estar relacionado con log4j.

¿Tiene el archivo log4j.jar en el classpath java de websphere (como se define en el archivo de inicio), así como el classpath de la aplicación?

Si se asegura de que el archivo log4j.jar esté en el classpath de java y que NO se encuentre en el directorio web-inf/lib de su aplicación web.


También puede estar relacionado con el ant version (puede ser no es su caso, pero yo no lo puso aquí por referencia):

tiene un archivo .class en su ruta de clase (es decir, no es un directorio o un archivo .jar). Comenzando con la hormiga 1.6, ant abrirá los archivos en la ruta de clases verificando entradas de manifiesto. Este intento de apertura fallará con el error "java.util.zip.ZipException"

El problema no existe con ant 1.5 porque no intenta abrir los archivos. - así que asegúrese de que su classpath no contenga archivos .class.


En una nota lateral, lo hicieron se tiene en cuenta que tiene separate jars?
Usted podría en el manifiesto de su frasco principal, consulte los otros frascos con este atributo:

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

A continuación, colocar todos los frascos en la misma carpeta.
Una vez más, puede no ser válido para su caso, pero todavía existe como referencia.

+0

Muchas gracias por su respuesta. Sin embargo, no tengo un log4j.jar en el classpath Java classpath. –

8

He visto esta excepción antes cuando cualquier cosa que la JVM considere como un directorio temp no se puede acceder debido a que no está allí o no tiene permiso para escribir.

19

Asegúrate de que el archivo jar no esté dañado. Si está dañado o no se puede descomprimir, se producirá este error.

3

Resolví este aclarando los directorios jboss-x.y.z/server [config]/tmp y jboss-x.y.z/server/[config]/work.

12

Me enfrenté al mismo problema. Tenía un archivo zip que java.util.zip.ZipFile no podía manejar pero WinRar lo desempaquetó muy bien.Encontré article on SDN sobre las opciones de compresión y descompresión en Java. Modifiqué ligeramente uno de los códigos de ejemplo para producir un método que finalmente fue capaz de manejar el archivo. El truco está en utilizar ZipInputStream en lugar de ZipFile y en la lectura secuencial del archivo zip. Este método también es capaz de manejar archivos comprimidos vacíos. Creo que puede ajustar el método para satisfacer sus necesidades, ya que todas las clases zip tienen subclases equivalentes para los archivos .jar.

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(); 
} 
+1

'zis.close(); fis.close(); 'debe estar en una cláusula finally - duh (o use try con recursos) –

2

También veo este error cuando estoy fuera del espacio de disco en el sistema de archivos que está escribiendo a. Entonces puede darle más espacio, limpiar archivos de registro, etc.

2

Vi esto con un archivo Zip específico con Java 6, pero desapareció cuando actualicé a Java 8 (no probé Java 7) , por lo que parece que las versiones más nuevas de ZipFile en Java admiten más algoritmos de compresión y, por lo tanto, pueden leer archivos que fallan con versiones anteriores.

0

Liquibase recibía este error por mí. Resolví esto después de depurar y observé que liquibase intentaba cargar las bibliotecas y descubrí que estaba cometiendo un error en los archivos de manifiesto de commons-codec-1.6.jar. Esencialmente, hay un archivo zip corrupto en algún lugar de su ruta o hay una versión incompatible que se utiliza. Cuando hice una exploración en el repositorio de Maven para esta biblioteca, encontré que había versiones más nuevas y agregué la versión más nueva al pom.xml. Pude proceder en este punto.

0

Quizás el archivo zip esté dañado, o se haya interrumpido durante la descarga.

1

que enfrentan estos temas debido a dañado postal Fils

comprobar si su archivo JAR se ha descargado completamente

0

que estaba recibiendo excepción

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) 
... 

cuando descomprimir un archivo en Java . El archivo en sí no parecía estar dañado ya que 7zip (y otros) lo abrieron sin ningún problema o queja sobre CRC inválido.

Cambié a Apache Commons Compress para leer las entradas zip y eso resolvió el problema.

0

simplemente para superar la ZipException, he utilizado un contenedor para commons-compress1.14 llamada jarchivelibescrito por thrau que hace que sea fácil de extraer o comprimir desde y hacia los objetos de archivo.

Ejemplo:

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 dependencia «Usted puede descargar los frascos de la Sonatype Maven repositorio en org/rauschig/jarchivelib/.

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

@see

0

En Windows7 he tenido este problema a través de una conexión de red Samba para un archivo Jar Java8> 80 MBytes grande . Copiar el archivo en una unidad local solucionó el problema.

Cuestiones relacionadas