Ich habe einen einfachen Code, um Zip-Dateien zu extrahieren, es funktionierte wie erwartet, aber während meines Tests habe ich meinen Code mit einigen Zip-Dateien ausprobiert (Schriften, Icons und Vorlagen, die ich aus dem Internet heruntergeladen habe) alle Zip-Dateien zur Verfügung gestellt, aber es funktioniert nicht mit einigen Zip-Dateien, hier ist der minimierte Code, um dieses Problem zu regenerieren:
%Vor%eigentlich In meiner realen Anwendung muss ich Zip-Dateien durch Inputstreams extrahieren. Im obigen Code versuche ich "janne.zip" zu extrahieren. Ich habe diese Datei von Ссылка heruntergeladen extrahiere es mit einem beliebigen Zip-Tool und überraschenderweise auch mit der Methode "unzipFile (String zipName)", aber mit der Methode unzipStream (String zipName)
%Vor%gibt null zurück
jede Hilfe wäre willkommen
Keine Antwort darauf, warum diese bestimmte Datei nicht mit java.util.zip funktioniert, aber wenn Sie die Option haben, Ihre Verwendung von java.util.zip.ZipInputStream durch die Apache commons-compress org.apache.commons.compress.archivers.zip.ZipArchiveInputStream (was API-kompatibel sein sollte), dann habe ich das gerade in der Beispieldatei getestet und es scheint erfolgreich zu funktionieren.
Allgemein finde ich commons-compress, um viel zuverlässiger als java.util.zip beim Entpacken von Dateien zu sein, die von anderen Tools als den java.util.zip -Klassen selbst erstellt wurden.
Bearbeiten: Ich habe ein bisschen Debugging in Eclipse gemacht und es sieht so aus, als hätte diese spezielle Zip-Datei eine Einzelsegment überspannende Marker von 0x30304b50 vor dem LOC Signatur ( 0x04034b50 ) des lokalen Headers des ersten Eintrags. Dies ist etwas, das commons-compress weiß, wie man mit umgeht, aber java.util.zip nicht - wenn j.u.z.ZipInputStream etwas anderes als eine LOC-Signatur sieht, gibt getNextEntry() % co_de zurück %.
Lustig!
Ich habe Ihren Code ausgepackt und den gleichen Fehler erhalten. Ich habe eine Header-Überprüfung in der ZipInputStream-Implementierung gefunden, aber nicht in der ZipFile-Implementierung.
Frag mich nicht warum, aber der Header in deiner Zip-Datei ist nicht gültig !
%Vor% Wenn Sie die ersten Bytes ( 50 4B 30 30 ) aus Ihrer Datei löschen, haben Sie eine gültige Kopfzeile und Sie können Ihre Datei lesen!
Ich hatte das gleiche Problem! Glücklicherweise konnte ich es lösen.
Zuerst setze ich die Blob-Daten in der Datenbank zurück und benutze dann Java-Code, um sie mit ZipInputStream zu komprimieren. Obwohl ich nicht sicher bin, könnte das Null ZipEntry-Problem wegen 2 Dinge sein:
1. Die Blobdaten in der Datenbank werden nicht korrekt gespeichert (oder sie sind bereits komprimiert, einige Datenbanken komprimieren Blobdaten zum Zeitpunkt der Speicherung. Sie können dies auch googeln).
2. Die Eingabe / Ausgabe-Streams können ebenfalls Probleme verursachen, siehe
Hier ist eine detaillierte Beschreibung von dem, was ich getan habe:
1. Setzen Sie das BLOB-Feld in der Datenbank mit EMPTY_BLOB zurück und übernehmen Sie die Änderungen
2. das folgende Java-Programm verwendet, um das Blob-Feld mit einer .xls-Datei zu aktualisieren
Bitte beachten Sie, dass der obige Code funktioniert, aber absolut keine Kodierungsstandards und -praktiken demonstriert.
3. Benutzte die folgende zip-Methode, um Daten zu komprimieren
Die obige Methode nimmt ein Byte-Array, reißt es, steckt es in einen ByteArrayOutputStream. Sie können wählen, ByteArrayOutputStream selbst zu verwenden, aufgrund einiger Anforderungen, die ich in Bytearray umwandeln.
4. Dann füge ich das obige Byte-Array in das Blob-Feld unter Verwendung der vorbereiteten Anweisung | ein
5. Wenn ich den unten angegebenen Entpackungscode verwende, funktioniert es gut!
Die Ausgabe der obigen Methode sind die entpackten Daten.
Tags und Links java unzip zipfile decompression