2008-11-28 12 views
51

मेरे पास एक जार फ़ाइल है, जिसमें अन्य नेस्टेड जार शामिल हैं।java.util.zip.ZipException: ज़िप फ़ाइल खोलने में त्रुटि

java.util.zip.ZipException: उद्घाटन ज़िप फ़ाइल

में त्रुटि जब मैं मैन्युअल की सामग्री को अनज़िप जब मैं इस फाइल पर नए JarFile() निर्माता आह्वान, मैं एक अपवाद है जो कहता मिल यह जार फ़ाइल और इसे फिर से ज़िप, यह ठीक काम करता है।

मुझे केवल वेबस्पेयर 6.1.0.7 और उच्च संस्करणों पर यह अपवाद दिखाई देता है। वही बात टॉमकैट और वेबलॉगिक पर ठीक काम करती है।

जब मैं जारफाइल की बजाय जार इनपुटपुट का उपयोग करता हूं, तो मैं बिना किसी अपवाद के जार फ़ाइल की सामग्री को पढ़ने में सक्षम हूं।

+2

फ़ाइल को फिर से भरने के संकेत के लिए धन्यवाद - जो मेरे लिए तय है। –

+0

मैक पर यह समस्या आई है जब विंडोज और लिनक्स ने ठीक काम किया था। JarInputStream का उपयोग करने से मेरे लिए समस्या ठीक हो गई। –

+0

मुझे टॉमकैट स्टार्ट यूपी ** [catalina.properties] पर एक ही समस्या का सामना करना पड़ा है: 'org.apache.catalina.startup.TldConfig tldScanJar' चेतावनी: JAR को संसाधित करने में विफल [jar: ../ opensaml.jar!/] इस समस्या को हल करने के लिए टीएलडी फाइलों के लिए 'ZipException' फाइलों के लिए [opensaml। ~ .jar] (http://mvnrepository.com/artifact/org.opensaml/opensaml) अनुप्रयोग lib फ़ोल्डर में जोड़ें। – Yash

उत्तर

10

यह log4j से संबंधित हो सकता है।

क्या आपके पास websphere जावा क्लासपाथ (स्टार्टअप फ़ाइल में परिभाषित) के साथ-साथ एप्लिकेशन क्लासपाथ में log4j.jar फ़ाइल है?

यदि आप सुनिश्चित करते हैं कि log4j.jar फ़ाइल जावा क्लासपाथ में है और यह आपके वेबैप की वेब-इंफ/lib निर्देशिका में नहीं है।


यह भी ant version के साथ संबंधित जा सकता है (अपने मामले नहीं हो सकता है, लेकिन मैं इसे यहाँ संदर्भ के लिए डाल दिया है):

आप अपने वर्ग रास्ते में एक .class फ़ाइल है (यानी निर्देशिका या एक .jar फ़ाइल नहीं)। चींटी 1.6 से शुरू होने पर, चींटी प्रकट प्रविष्टियों के लिए क्लासपाथ जांच में फ़ाइलों को खोल देगा। यह खोलने का प्रयास त्रुटि "java.util.zip.ZipException"

समस्या एंट 1.5 के साथ मौजूद नहीं है क्योंकि यह फ़ाइलों को खोलने की कोशिश नहीं करता है। - इसलिए सुनिश्चित करें कि आपके क्लासपाथ में .class फ़ाइलें नहीं हैं।


एक तरफ ध्यान दें पर, आप separate jars रखने पर विचार किया?
आप अपने मुख्य जार के प्रकट में, इस विशेषता के साथ अन्य जार की जानकारी दे सकती:

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

फिर, जगह एक ही फ़ोल्डर में अपने जार के सभी।
फिर से, आपके मामले के लिए मान्य नहीं हो सकता है, लेकिन अभी भी संदर्भ के लिए।

+0

आपकी प्रतिक्रिया के लिए बहुत बहुत धन्यवाद। हालांकि, मेरे पास websphere Java classpath में log4j.jar नहीं है। –

8

मैंने यह अपवाद पहले देखा है जब जेएमएम temp निर्देशिका होने पर विचार करने योग्य नहीं है या लिखने की अनुमति नहीं है।

19

सुनिश्चित करें कि आपकी जार फ़ाइल दूषित नहीं है। यदि यह दूषित है या अनजिप करने में सक्षम नहीं है, तो यह त्रुटि होगी।

3

मैंने jboss-x.y.z/server [config]/tmp और jboss-x.y.z/server/[config]/कार्य निर्देशिकाओं को साफ़ करके इसे हल किया।

12

मुझे एक ही समस्या का सामना करना पड़ा। मेरे पास एक ज़िप संग्रह था जो java.util.zip.ZipFile को संभालने में सक्षम नहीं था लेकिन WinRar ने इसे ठीक से अनपॅक किया।मुझे जावा में संपीड़न और डिकंप्रेसर विकल्पों के बारे में article on SDN मिला। मैंने थोड़ा सा उदाहरण तैयार करने के लिए उदाहरण कोडों में से एक को संशोधित किया जो आखिरकार संग्रह को संभालने में सक्षम था। ट्रिक ZipFile के बजाय ZipInputStream का उपयोग करने और ज़िप संग्रह के अनुक्रमिक पढ़ने में है। यह विधि खाली ज़िप संग्रह को संभालने में भी सक्षम है। मेरा मानना ​​है कि आप अपनी जरूरतों के अनुसार विधि को समायोजित कर सकते हैं क्योंकि सभी ज़िप वर्गों में .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(); 'अंत में खंड में होना चाहिए - duh (या संसाधनों के साथ प्रयास करें) –

2

मुझे यह त्रुटि भी दिखाई देती है जब मैं उस फाइल सिस्टम पर डिस्क स्पेस से बाहर हूं जब यह लिख रहा है। तो आप या तो इसे और अधिक स्थान दे सकते हैं, लॉग फाइलों को साफ कर सकते हैं, आदि

2

मैंने इसे जावा 6 के साथ एक विशिष्ट ज़िप फ़ाइल के साथ देखा, लेकिन जब मैं जावा 8 में अपग्रेड करता हूं (जावा 7 का परीक्षण नहीं करता) , ऐसा लगता है कि जावा में ज़िपफाइल के नए संस्करण अधिक संपीड़न एल्गोरिदम का समर्थन करते हैं और इस प्रकार उन फ़ाइलों को पढ़ सकते हैं जो पिछले संस्करणों में विफल हो जाते हैं।

0

लिक्विबेस को मेरे लिए यह त्रुटि मिल रही थी। मैंने डीबग किया और लाइब्रेरीज़ को लोड करने का प्रयास करने के बाद इसे हल किया और पाया कि यह कॉमन्स-कोडेक-1.6.jar के लिए मैनिफेस्ट फ़ाइलों पर त्रुटि कर रहा था। अनिवार्य रूप से, आपके पथ में कहीं भी भ्रष्ट ज़िप फ़ाइल है या एक असंगत संस्करण उपयोग किया जा रहा है। जब मैंने इस पुस्तकालय के लिए मेवेन रिपोजिटरी पर एक एक्सप्लोर किया, तो मैंने पाया कि नए संस्करण थे और नए संस्करण को pom.xml में जोड़ा गया। मैं इस बिंदु पर आगे बढ़ने में सक्षम था।

0

शायद ज़िप फ़ाइल क्षतिग्रस्त हो गई है, या डाउनलोड करते समय ब्रोक किया गया है।

1

मैं भ्रष्ट की वजह से इस मुद्दों का सामना करना पड़ा ज़िप फिल्स

देखें कि आपका JAR फ़ाइल पूरी तरह से डाउनलोड किया गया था

0

मैं जब जावा में एक संग्रह अनज़िप अपवाद

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

हो रही थी । संग्रह स्वयं ही दूषित नहीं हुआ क्योंकि 7zip (और अन्य) ने इसे अवैध सीआरसी के बारे में किसी भी समस्या या शिकायत के बिना खोला।

मैंने ज़िप-प्रविष्टियों को पढ़ने के लिए Apache Commons Compress पर स्विच किया और समस्या को हल किया।

0

आप पर काबू पाने के ZipException की, मैं commons-compress1.14 कहा जाता है के लिए एक आवरण का इस्तेमाल किया है jarchivelibthrau आसान निकालने या से और फ़ाइल वस्तुओं में संपीड़ित करने के लिए करता है कि ने लिखा है।

उदाहरण:

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 निर्भरता «आप org/rauschig/jarchivelib/ पर Sonatype Maven भंडार से जार डाउनलोड कर सकते हैं।

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

@see

0

Windows7 पर मैं एक Java8 जार फ़ाइल> 80 मेगाबाइट बड़ा के लिए एक सांबा नेटवर्क कनेक्शन पर इस समस्या थी । फ़ाइल को स्थानीय ड्राइव में कॉपी करने से समस्या ठीक हो गई।

संबंधित मुद्दे