java.util.zip.ZipException: помилка при відкритті файлу zip

У мене є файл Jar, який містить інші вкладені Jars. Коли я викликаю новий JarFile()конструктор для цього файлу, я отримую виняток, який говорить:

java.util.zip.ZipException: помилка при відкритті файлу zip

Коли я вручну розпаковую вміст цього файлу Jar і знову його застібаю, він працює нормально.

Цей виняток я бачу лише у WebSphere 6.1.0.7 та новіших версіях. Те саме добре працює на tomcat та WebLogic.

Коли я використовую JarInputStream замість JarFile, я можу читати вміст файлу Jar без будь-яких винятків.

Переконайтесь, що файл jar не пошкоджений. Якщо це пошкоджено або не вдається розпакувати, ця помилка трапиться.

Я зіткнувся з тією ж проблемою. У мене був zip-архів, який java.util.zip.ZipFile не зміг обробити, але WinRar його дуже добре розпакував. Я знайшов статтю про SDN про стиснення та розпакування опцій у Java. Я трохи модифікував один із прикладів кодів, щоб створити метод, який нарешті зміг обробляти архів. Фокус полягає у використанні ZipInputStream замість ZipFile та в послідовному читанні zip-архіву. Цей метод також здатний обробляти порожній zip-архів. Я вірю, що ви можете налаштувати метод відповідно до своїх потреб, оскільки всі zip-класи мають еквівалентні підкласи для архівів .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();
}

Це може бути пов’язано з log4j.

Чи є у вас файл log4j.jar у шляху до класу websphere Java (як визначено у файлі запуску), а також шлях до класу програми?

Якщо ви переконаєтесь, що файл log4j.jar знаходиться у шляху до класу Java і що НЕ знаходиться в каталозі web-inf / lib вашого веб-додатка.

Це також може бути пов’язано з мурашиною версією (можливо, це не ваш випадок, але я поміщаю її тут для довідки):

У шляху до вашого класу є файл .class (тобто не каталог або файл .jar). Починаючи з ant 1.6, ant відкриває файли в шляху до класу, перевіряючи записи маніфесту. Ця спроба відкриття не вдасться з помилкою "java.util.zip.ZipException"

Проблема не існує з ant 1.5, оскільки він не намагається відкрити файли. - переконайтесь, що шлях до вашого класу не містить файлів .class.

У додатковій записці ви розглядали можливість мати окремі банки ?
Ви можете у маніфесті своєї основної банки звернутися до інших банок із цим атрибутом:

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

Потім помістіть усі банки в одну папку.
Знову ж таки, можливо, це не відповідає вашому випадку, але все ж є для довідки.

Я вже бачив цей виняток, коли все, що JVM вважає тимчасовим каталогом, недоступне через відсутність там або відсутність дозволу на запис.

Я вирішив це, очистивши каталоги jboss-xyz / server [config] / tmp та jboss-xyz / server / [config] / work.

Я бачив це з певним Zip-файлом з Java 6, але він зник, коли я перейшов на Java 8 (не тестував Java 7), тому, схоже, новіші версії ZipFile в Java підтримують більше алгоритмів стиснення і, отже, можуть читати файли, які не вдається з попередніми версіями.

Liquibase отримував цю помилку для мене. Я вирішив це після того, як налагодив і спостерігав, як liquibase намагався завантажити бібліотеки, і виявив, що він помилявся у файлах маніфесту для commons-codec-1.6.jar. По суті, десь на вашому шляху є або пошкоджений zip-файл, або використовується несумісна версія. Коли я дослідив сховище Maven для цієї бібліотеки, я виявив, що є новіші версії, і додав нову версію до pom.xml. На цьому етапі я зміг продовжити.

Я отримував виняток

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

під час розпакування архіву на Java. Сам архів не здавався пошкодженим, оскільки 7zip (та інші) відкрили його без будь-яких проблем чи скарг на недійсні CRC.

Я перейшов на Apache Commons Compress для читання zip-записів, і це вирішило проблему.

У Windows7 у мене виникла проблема через мережеве підключення Samba для файлу Jar Java8> 80 МБ. Копіювання файлу на локальний диск вирішило проблему.

У моєму випадку мій -Dloader.path="lib"містить інші банки, які не потрібні. наприклад, mvn dependency:copy-dependenciesперераховує 100 файлів jar. але мій libкаталог містить 101 файл jar.

У моєму випадку SL4j-api.jar із декількома версіями суперечить репозиторію maven. Потім я видалив всю папку SL4j-api у repo m2 maven і оновив проект maven, будуючи проект maven, ніж запускав проект на сервері JBOSS. питання вирішено.

Просто для подолання ZipException, я використав обгортку для ^{1.14, яку} називає ^{написаний thrau,} що дозволяє легко витягувати або стискати з та у файлові об'єкти.commons-compressjarchivelib

Приклад:

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 «Ви можете завантажити банки зі сховища Sonatype Maven за адресою org / rauschig / jarchivelib / .

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

@подивитися

• Архіватори та компресори
• Стиснення та декомпресія даних за допомогою API Java