# Gesplittete 7zip Archive mit SequenceInputStream zusammenführen, und dann entpacken.



## Janitom (2. August 2011)

Hallo,

ich habe folgendes Problem, ich lasse mehrere 7Zip Dateien (Datei.zip.001,...,Datei.zip.00x) mit den SequenceInputStream zusammenführen. Dies funktioniert soweit ganz gut, nur wenn ich die erhaltene Datei dann mit winrar oder Winzip öffnen will erscheint die Fehlermeldung unerwartetes Archivende.
Weis jemand von vlt eine Lösung?


```
....

Object[] streamArray = streamsTemp.toArray();
		for(int i = streamArray.length-1; i >= 0; i--) {
		   streams.addElement(streamArray[i]);
		}
		
		// Streams zusammenführen
		in = new SequenceInputStream(streams.elements());
	
		File zipTmp = new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang");
		try {
			if (zipTmp.exists() == false){									
				zipTmp.mkdir();
			}else if(zipTmp.exists()){
				
				out = new FileOutputStream(new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang\\Datei.zip"), true); 
				BufferedOutputStream bout = new BufferedOutputStream(out);

				int bytes;			
				while ((bytes = in.read()) != -1) { 
					bout.write(bytes); 
				} 
				streamTmp.close();
				in.close(); 
				out.close(); 
				bout.close();
				//}
			}
		}
		catch( Exception ex ) {
			ex.printStackTrace();
		}
...
```


----------



## SE (2. August 2011)

Verwende mal anstatt des BufferedOutputStream einfach OutputStream. Oder wenns schon der BufferedOutputStream sein muss ein flush() am Ende.
Außerdem kannst du nicht einfach so zwei eigenständige Zip-Files zusammenkopieren. Jedes Zip-File hat *unabhängig ob als Part oder regulär* File-Header und TOC. wenn du jetzt einfach alles zusamm kopierst *denn nichts anderes machst du* erhälts du einfach nur eine Aneinanderreihung. Das das ZIP nicht versteht liegt auf der Hand. Was du also machen müsstest wäre nun jedes Zip als ZipInputStream öffnen und einzeln alle Inhalte lesen , prüfen ob diese vollständig oder nur teilweise in jedem Part liegen , eventuell im RAM zusammenkopieren und dann in ein neues Zip mit einem ZipOutputStream völlig neu schreiben. Ein einfachs binäres zusammenkopieren funtkioniert bei Zip-Files nicht.


----------



## Janitom (2. August 2011)

Wie prüfe ich denn Ob die vollständig sind? Den BufferedOutputStream hatte ich letztendlich nur genommen, um Geschwindigkeit zu gewinnen. Kann ich diese dann auch mit dem SequenceInputStream dann auch zusammenführen?

Ich werd deinen Vorschlag mal versuchen.


----------



## SE (2. August 2011)

Erstmal : weg mit dem Buffered ... das bremst nur aus anstatt Geschindigkeit rauszuholen weil erst alles in den RAM geschrieben wird und dann vom RAM auf Platte. Das kannst du mit nem normalen OutputStream etwas abkürzen weil dieser dierekt auf das Ziel schreibt.

Um mit Zip-Daten zu arbeiten klick mal auf meine Signatur und geht dann aufs Paket java.util.zip
Da ist alles drin. Bei weiteren Fragen versuch ich dir zu helfen.


----------



## Janitom (2. August 2011)

So nun will er aber nicht die Datei schreiben.... er erkennt dass dort nix drin ist im zipoutputstream



```
...

if (archiveFiles.length == 1){
												//
												qZip = new FileInputStream(archiveFiles[k]);
												streamsTemp.addElement(new ZipInputStream(qZip));								        
											}							
										}									
									}
								}
							}
						}
						catch( Exception ex ) {
							ex.printStackTrace();
						}
...

Object[] streamArray = streamsTemp.toArray();
		for(int i = streamArray.length-1; i >= 0; i--) {
		   streams.addElement(streamArray[i]);
		}
		
		// Streams zusammenführen
		in = new ZipInputStream(new SequenceInputStream(streams.elements()));
	
		File zipTmp = new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang");
		try {
			if (zipTmp.exists() == false){									
				zipTmp.mkdir();
			}else if(zipTmp.exists()){
				out = new FileOutputStream(new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang\\Antrag.zip"), true);
				zOut = new ZipOutputStream(out); 
				
				//File zipTmpFile = new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang\\Antrag.zip");
				
				//if (zipTmpFile.exists() == false){
					int len = 0;			
					byte data[] = new byte[1024];
					while ((len = in.read(data)) > 0) { 
						zOut.write(data,0,len); 
					} 
					
					in.close(); 
					out.close(); 
					zOut.close();
```


----------



## SE (2. August 2011)

Gut ... du hast die DOC scheinbar nicht verstanden.
Von einem ZipInputStream liest man nicht via read(byte[]) und schreibt in einen ZipOutputStream auch nich via write(byte[], int, int).
Du musst mit den ZipEntry arbeiten.

Dessweiteren habe ich es mir noch mal durch den Kopf gehen lassen wie du überprüfst ob ein ZipEntry komplett in einem Zip-Part ist oder über mehrere verteilt :
du musst erst von allen ZipFiles das TOC lesen und überprüfen ob es in mehreren Parts ein Entry mit dem selben Namen gibt. Dieses musst du dann im RAM erst zusammensetzen bevor du es schreiben kannst.

Auch frage ich mal so :

Wie meinst du das mit den Parts ?

1) ein großes ZipFile wurd binär gesplittet ... also so das man erst aus allen Parts das originale File wieder zusammenkopieren muss
2) die Funktion von Zip : Parted ... also das Zip wirklich einzelne komplette Zip-Files schreibt in denen die Daten verteilt sind

Weil so wie du es versuchst wäre es 1) ... da du aber die Meldung : unerwartetes Archivende bekommst gehe ich davon aus das es in wirklichkeit 2) ist.


----------



## Janitom (2. August 2011)

Genau kann ich das eigentlich nicht sagen, die Daten Stammen aus einer Fachanwendung, die über mehrere Nachrichten a 30mb versendet wurden. Diese Anhänge müssen dann wieder zusammengefügt werden, um diese entpacken zu können. Also war wohl mein Ansatz falsch, und ich würde sagen ich sollte es nach 2.) probieren.

Edit: so ich versuche jetzt mal die tocs auszulesen ... hoffe es klappt

Edit2:
	
	
	



```
java.util.zip.ZipException: invalid END header (bad central directory offset)
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(Unknown Source)
	at java.util.zip.ZipFile.<init>(Unknown Source)
	at source.ActionAssign.widgetSelected(ActionAssign.java:95)
```

Edit3: So kleiner Fortschritt...er schreibt schonmal die Dateien aus der ersten gesplitteten Zip, blos am Ende dieser Zip meckert findet er keine Entries mehr folgender Code ist ein Test
	
	
	



```
for (int j = 0;j < splittedZips.length; j++){
			//zFile = new ZipFile(splittedZips[j]);
			//zipEntries = zFile.entries();
			//zIn = splittedZips[j].;
			try {
				   zipIn = new ZipInputStream(new FileInputStream(splittedZips[j]));
				   while ((entry = zipIn.getNextEntry()) != null) {
				      String targetFileName;
				      targetFileName = entry.getName().substring(entry.getName().lastIndexOf("/")+1);
				      int read = 0;
				      byte[] data = new byte[1024];
				      FileOutputStream entryout = new FileOutputStream(selectedDirectory  + System.getProperty("file.separator") + "Anhang\\" + targetFileName);
				      while ((read = zipIn.read(data,0,1024)) != -1) {
				          entryout.write(data, 0, read);
				      }
				      entryout.close();
				   }
				   zipIn.close();
				}
				catch (Exception e) {
				   e.printStackTrace();
				}
}
```


----------



## Janitom (3. August 2011)

So ich habe rausgefunden, dass ich die Dateien nicht in das (ist ein Beispiel)


```
ZipFile zipFile = new ZipFile("c:\datei.zip.001))
```

legen kann, dort kommt dann immer 

Exception in thread "main" java.util.zip.ZipException: error in opening zip file
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(Unknown Source)
	at java.util.zip.ZipFile.<init>(Unknown Source)
	at source.ZipArchiveExtractor.extractArchive(ZipArchiveExtractor.java:29)
	at source.ZipArchiveExtractor.main(ZipArchiveExtractor.java:19)


----------



## SE (3. August 2011)

Hmm ... darf ich raten : du hast noch nie was von sog. Escape-Sequenzen gehört , richtig ?
Mal davon abgesehen das du dich da oben vertippt hast und es anstatt

```
"001))
```
eigentlich

```
"001");
```
heißen müsste *String nicht geschlossen , letzte Klammer zu viel und vor allem fehlendes Semikolon* hast du nicht bedacht das ein Backslash "\" eine sog. Escape-Sequenz einleitet. Das Zeichen "\d" ist laut ASCII-Tabelle als "EOT" definiert *Hex 0x04*. Das du nun eine Exception bekommst liegt daran das es einfach kein File mit dem Namen

```
C:[EOT]atei.zip.001
```
gibt. Wenn du schon Backslashes in Pfadangaben verwenden willst weil du dich daran als Windows-User gewöhnt hast müsstest du es mindestens so schreiben :

```
ZipFile zipFile=new ZipFile("C:\\datei.zip.001");
```
Ich rate dir aber lieber es dir gleich anzugewöhnen in Pfadangaben IMMER einen (Foreward)Slash "/" zu verwenden da dieser
1) unter Unix sowieso verlangt wird *Linux , Mac* und "\\" kein gültiger Trenner ist
2) er unter Windows durch sämtliche File-Klassen richtig dargestellt wird
3) er auch das systemübergreifende Symbol in URLs und URIs ist die auch unter Windows so notiert werden und gültig sind
4) es einfacher ist und plattformunabhängig

Daher wundert es mich das eine so abstrakte Exception kommt und nicht eine viel niedrigere FileNotFoundException. Das der Compiler es überhaupt so übersetzt ist gleich das nächste was mich daran wundert.


----------



## Janitom (3. August 2011)

Wie bereits vor dem Code steht: Es ist ein Beispiel, wollte es eigentlich mit dieser Zeile verständlicher machen, da er generell bei diesen Dateien diesen Fehler auswirft (getestet mit Beispielcode aus diesem Forum, wobei normale *.zip als ZipFile auch bei Initialisierung geöffnet werden können) ^^


Zwecks Pfadangaben, das entstand aus schnellen Versuchen, da ich direkt aus dem Explorer den Pfad übernommen habe.  Diese habe ich natürlich bereits schon angepasst.

bin übrigens schon etwas weiter gekommen


----------



## SE (3. August 2011)

Naja wenn du hier ein falsches Beispiel postest dann muss ich davon ausgehen das es im richtigen Code genau so falsch steht.
Daher zwei Tipps :
1) befolge das was ich oben geschrieben habe
2) poste Beispiele genau so wie sie auch im richtigen Code stehen


----------



## Janitom (3. August 2011)

Ok! 
Beim nächsten Mal werde ich daran denken.
Danke dir erstmal. Für heut ist erstmal Schluss.


----------



## Janitom (4. August 2011)

So neue Erkenntnis.....Die Dateien wurden vor dem Packen gezippt und anschließend in zb. 5MB Dateien binär aufgeteilt. Also werde ich jetzt versuchen die Dateien wieder binär zusammenzuführen und dann die erhaltene Zip entpacken.


----------



## SE (4. August 2011)

Na das ist doch mal eine Information mit der sich was anfangen lässt.
Ich würde jetzt allerdings nicht diesen Sequenced Stream nehmen sondern einfach über File.listFiles() mit n File-Array holen und die dann hinter ein andere öffnen , lesen , schließen. Und dabei bleibt der OutputStream auf das ZipFile immer offen und du schreibst da munter hinter ein ander rein.
Danach solltest du es dann ohne Fehlermeldungen öffnen können.


----------



## Janitom (4. August 2011)

Alles klar. Mit diesen Gedanken hatte ich auch gerade gespielt 
Ich meld mich wieder wenn es geklappt hat.
Danke Dir.


----------



## Janitom (4. August 2011)

So jetzt geht es, folgender Code führt die Dateien zusammen.


```
splittedZips = new File[checkedCount];

		checkedCount=0;
		qZipTmp = new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang/", "tempAntrag.zip");
		try{
			out = new FileOutputStream(qZipTmp);
			for(int i = splittedZipsTmp.length-1; i >= 0; i--) {
				if(splittedZipsTmp[i] != null){
					splittedZips[checkedCount]=splittedZipsTmp[i];
					checkedCount++;
				}
				
			}
			for(int j=0; j < splittedZips.length; j++){
				qZip = new FileInputStream(splittedZips[j]);
				byte[] buffer = new byte[1024];
				int len;
				while ((len = qZip.read(buffer)) > 0) {
					out.write(buffer);
				}
				qZip.close();
			}
			out.flush();
			out.close();
		} catch (IOException e1) {
			// TODO Auto-generated catch block
			e1.printStackTrace();
		}
```


----------



## Janitom (4. August 2011)

So die Zip kann ich zwar mit einem herkömmlichen Programm entpacken, aber nicht beim Javacode, da kann er ab einer bestimmten Stelle keinen Entry mehr finden ... ich werd noch zum Elch.


```
zipIn = new ZipInputStream(new FileInputStream(qZipTmp));

			byte[] buffer = new byte[16384];
			int len;
			while ((entry = zipIn.getNextEntry()) != null) {

				File dir = dir = buildDirectoryHierarchyFor(entry.getName(), new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang/"));
				if (!dir.exists()) {
					dir.mkdirs();
				}

				if (!entry.isDirectory()) {
					bos = new BufferedOutputStream(new FileOutputStream(new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang/", entry.getName())));

					while ((len = zipIn.read(buffer)) > 0) {
						bos.write(buffer, 0, len);
					}
				}
			}
			zipIn.close();
			bos.flush();
			bos.close();
		} catch (IOException e1) {
			// TODO Auto-generated catch block
			e1.printStackTrace();
		}
```


----------



## SE (4. August 2011)

Hmm .. also bei deinem Code da oben wundert es mich erlich gesagt das du das Zip überhaupt zusammengesetzt bekommst.
Ich erklär dir erstmal die "Fehler" und dann poste ich dir ein kleines Beispiel wie man sowas eleganter löst.

1) Zeile 1

```
splittedZips = new File[checkedCount];
```
Gut ... damit legst du ein neues File[]-Objekt an und speicherst dies in splittedZips *sollte demnach auch vom Typ File[] sein*.
Damit hast du zwar ein File-Array das die Größe von checkedCount hat, aber die einzelnen Felder sind immernoch NULL.

2) Zeile 3

```
checkedCount=0;
```
Ist ja gut das du eine Variable für mehrere Aufgabe nutzt ... aber damit verliert man schnell den überblick und muss sich immer durch den gesamten Code wühlen. Da ein Rechner deutlich mehr Resourcen hat hättest du hier auch einen neuen int deklarieren können. Die 4 Byte mehr oder weniger im Speicher sind auf einem PC kein Problem, aber es ist schon mal ein guter Ansatz wenn du mal auf nem embedded System arbeiten musst wo jedes Byte extra Gold wert ist.

3) Zeile 4

```
qZipTmp = new File(selectedDirectory  + System.getProperty("file.separator") + "Anhang/", "tempAntrag.zip");
```
Vorne machst du dir die Mühe mit System.getProperty und hinten schreibst du dann einfach ein "/". Ist zwar beides richtig und funktioniert auch beides ... aber wenn du schon einmal die einfach Variante drin hast kannst du das auch anstelle des System.getProperty machen

4) Zeilen 7 bis 13
Ähäm ... also was diese for() soll versteh ich gerade überhaupt nicht.
Gut ... soweit wie ich das sehe speichert sie das Array splittedZipsTmp in umgekehrter Reihenfolge in splittedZips. Bevor ich sowas schreiben würde würde ich mir erstmal Gedanken machen WARUM ich das schreiben sollte : suche hier also weiter oben einen Ansatz bei dem das Array splittedZipsTmp gleich in der richtigen Reihenfolge angelegt wird. Sowas ist eine unnötige Performancebremse und ist ein Zeichen für schlechtes Konzept und schlechten Code.

5) Zeile 14

```
for(int j=0; j < splittedZips.length; j++)
```
Da splittedZips vom Typ File[] ist und du im Schleiferumpf eh ein File-Objekt brauchst kannst du hier ein *foreach* draus machen. Das sieht in Java dann so aus:

```
for(File file : splittedZips)
```
und beim erstellen des FIS nutzt du dann anstelle von splittedZips[j] einfach file.

6) Zeile 18
Achtung : prüfen auf read(byte[]) > 0 sollte man laut Doc *NICHT* machen. Das wirst du später sehen wenn du mal mit Sockets und Verbindungen darüber arbeitest. Du solltest hier lieber auf read(byte[]) != -1 prüfen da read(byte[]) im Fehlerfall -1 zurückgibt, aber 0 wenn einfach nichts gelesen wurde. Das 0 zurückgegeben wird kann z.B. vorkommen wenn du von einem gepuffertem Stream liest und dieser aber noch nicht genug Daten im Puffer hat das er dir diese über read(byte[]) zur verfügung stellt.

Da man aber nicht nur Meckern sondern auch bei Fehlern helfen soll hier mal ein sehr kompaktes Beispiel

```
private void binaryJoin() throws Exception
{
	String PATH=this.getClass().getResource(this.getClass().getSimpleName()+".class").toString();
	if(PATH.contains("!"))
		PATH=PATH.substring(0, PATH.indexOf("!"));
	PATH=(new File(PATH.substring(PATH.indexOf("/"), PATH.lastIndexOf("/")))).getAbsolutePath();
	FileOutputStream fos=new FileOutputStream(new File(PATH, "output.zip"));
	File[] inputFiles=(new File(PATH)).listFiles(new FilenameFilter()
	{
		public boolean accept(File path, String name)
		{
			Pattern pattern=Pattern.compile("input\\.[\\d]{3}\\.zip");
			Matcher matcher=pattern.matcher(name);
			return matcher.matches();
		}
	});
	for(File file : inputFiles)
	{
		FileInputStream fis=new FileInputStream(file);
		int br=0;
		byte[] buf=new byte[8129];
		while((br=fis.read(buf))!=-1)
		{
			fos.write(buf, 0, br);
		}
		fis.close();
	}
	fos.close();
}
```
Zur kurzen Erklärung einiger Zeilen

1) Zeilen 3 bis 6
String PATH enthält den absolute Pfad zur aktuellen Klasse. Daher müssen die Input-Files auch im selben Ordner liegen und das Output-File wird ebenfalls im selben Ordner erstellt. Bei Unterordnern ggf an entsprechender Stelle anpassen.

2) Zeilen 8 bis 16
Erzeugen eines File-Arrays des aktuellen Ordners. Dabei werden nur Dateien in das Array aufgenommen auf das die RegEx zutrifft.
Beispiel : "input.XXX.zip" wobei XXX eine *dreistellige Zahl* ist.
benötigtes Paket : java.util.regex.*

3) Zeilen 17 bis 27
foreach über das eben erzeugte File-Array.
Dabei wird für jedes File ein neuer FileInputStream geöffnet , aus diesem bis EOF gelesen , dabei mit einem Buffer von 8kByte *kannst du auch anpassen* in den FileOutputStream des Output-Files geschreiben und das InputFile wieder geschlossen.
Eine Prüfung ob das Array-Feld NULL ist brauchst du nicht da dieses Array aus den Verzeichnisinformationen erstellt wurde und daher nur gültige File-Objekte enthält.

Eine OutputStream.flush() ist hier nicht nötig da du keinen BufferedStream verwendest.

Ob die RegEx jetzt wirklich so hinhaut weis ich nicht da das jetzt nur schnell aus dem Kopf mit Hilfe der APi-Doc geschrieben ist , müsste aber so hinhauen.
Wichtig sind die *doppelten* Backslashes vor den Punkten da ein Punkt in einer RegEx als Symbol für "jedes Zeichen" steht.

So habe ich in der selben Anzahl an Zeilen eine komplett funktionierende Methode an stelle deines Codes wobei bei dir da noch einiges fehlt. Auch habe ich einfach "throws Exception" drangeschrieben weil es wohl am einfachsten ist anstatt jede mögliche Exception *namentlich : IOException , FileNotFoundException und andere die damit in zusammenhang stehen* einzelen und in richtiger Reihenfolge anzugeben.

Was jetzt deinen Code im zweiten Post angeht würde ich erstmal das ganze Lesen der einzelnen Files zum Testen rausnehmen und erstmal nur mit einem anderen Tool wie WinRar o.ä. prüfen ob überhaupt der *gesamte* Inhalt gefunden wird oder ob vorher eine Exception fliegt. Denn einfach "findet am einem bestimmten Punkt nichts mehr" *ohne* Exception ist in Java nicht möglich. Ansonsten ist das File beschädigt / falsch zusammen kopiert.


----------



## Janitom (5. August 2011)

Hallo erstmal Vielen Dank.

Zu Punkt 1.)

Dies habe ich so gewählt, da splittedZipsTmp ein variables Array ist und ich das eigentliche FileArray splittedZips nur für die Files nehmen wollte, die vom Nutzer vorher in einer Tabelle, welche die empfangenen Nachrichten enthält, anhand von Checkboxen ausgewählt wurden. Dann mache ich mehrere Abfragen, so dass ich dann zu den Nachrichtenanhängen (da diese in unterschiedlichen Nachrichtenverzeichnissen liegen) komme. Hierbei wird auch nach dem jeweiligen Anhang die Variable checkCount hochgesetzt. Sie zeigt auch an wieviele Nachrichten ausgewählt wurden. Da auch beispielsweise die neueste Nachricht immer oben steht und diese den letzten Zipteil enthält, drehe ich diese dann auch mit der For-Schleife (Punkt5) um.

zu Punkt 3.)

Hier ist das so gewollt da der Nutzer hier den Bezug zu den Nachrichten anhand einer Ordnerauswahl festlegt. Das heist fals der Ordner existiert wählt er ihn aus, ansonsten erzeugt er einen neuen. Der Anhangsordner ist nur ein Unterordner, wobei dann später noch ein weiterer hinzukommt (mit Entpackatumsbenennung, da zu einem Bezug mehrere Nachrichtenvarianten hinzukommen können) .


Desweiteren habe ich auch im vorigen Post geschrieben, dass ich meine erzeugte Zip, sowie die Quelldateien mit mehreren Zip-Programmen getestet und überprüft habe. Leider ohne Probleme. Daher hatte es mich verwundert, dass es trotzdem nicht mit Java entpacken konnte. Wenn ich mir selber eine Zip erstelle und die versuche mit meinem Tool zu entpacken funktioniert auch der code.

Ich versuche jetzt erstmal deine Tips umzusetzen. Vielen Dank. Ich meld mich dann wieder.


----------



## SE (5. August 2011)

Also deine Erklärung zu Punkt 3) reicht mir nicht und ist auch keine Antwort auf die Frage : Warum erst System.getProperty() und dann ein simples "/" ?
Wie ich bereits sagte : du kannst hier an beiden Stellen "/" setzen.

Was den Rest deiner Erklärung angeht : leider völlig aus dem Kontext gerissen da man das so ohne den restlichen Code nicht nachvollziehen kann.

Auch hast du es nicht geschafft dein Problem weiter zu beschrieben : ein einfaches : "bricht irgendwo ab" OHNE jegliche Exception ist in Java nicht möglich *es sei denn du schluckst diese einfach*. Post also bitte mal die Exception welche auftritt wenn der Iterator irgendwo mitten im Zip false returned. Eventuell wird alles auch in einer etwas anderen Reihenfolge ausgelesen als du es in WinZip sehen kannst.


----------



## Janitom (5. August 2011)

Also die Exception die er wirft sieht dabei so aus: 
	
	
	



```
java.lang.IllegalArgumentException
	at java.util.zip.ZipInputStream.getUTF8String(Unknown Source)
	at java.util.zip.ZipInputStream.getFileName(Unknown Source)
	at java.util.zip.ZipInputStream.readLOC(Unknown Source)
	at java.util.zip.ZipInputStream.getNextEntry(Unknown Source)
	at source.ActionAssign.widgetSelected(ActionAssign.java:158)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657)
	at source.GUI.main(GUI.java:46)
```


----------



## SE (5. August 2011)

Tja ... ohne den entsprechenden Source wird das ein Rätzelraten.
Wie gesagt : versuche doch mal den ganzen mist den du da in deinem zweiten Post hast zu kommentieren und einfach nur über den Iterator die Struktur des Zip's mit einem simplen System.out.println() auf der Console auszugeben.


----------



## Janitom (5. August 2011)

der Code steht schon da 

und bei while ((entry = zipIn.getNextEntry()) != null) { passiert der Fehler, aber erst nach mehreren Entries


----------



## SE (5. August 2011)

1) Doppel-Posts sind hier unerwünscht.
Du kannst also den Code löschen ... wichtig war die Info WO die Exception auftritt.

2) Du hast die Zip-API scheinbar immer noch nicht verstanden und verstehst auch nicht was ich von dir will.
Es ist zwar richtig das ZipInputStream die Methode getNextEntry() bereitstellt, jedoch würde ich mich darauf nicht verlassen.
Versuche doch erstmal , bevor du das Zip liest , folgendes *ist in Bezug auf meinen vorheringen Code*:

```
ZipFile zipFile=new ZipFile(new File(PATH, "output.zip"));
Enumeration<? extends ZipEntry> entries=zipFile.entries();
while(entries.hasMoreElements())
{
	ZipEntry entry=(ZipEntry)entries.nextElement();
	System.out.println(entry.getName());
}
```

Sollte dieser Code eine Exception werfen ist das von dir zusammenkopierte ZipFile immernoch fehlerhaft.


----------



## Janitom (5. August 2011)

Deinen Code habe ich schon verstanden, ich  hab rausgefunden das wiedermal die quellzips kaputt waren. Jetzt geht es soweit, aber nun habe ich ein neues Problem sobald eine Datei im Zip ist, die Umlaute drinnen hat schmeist der mich mit einer IO-Exception beim Schreiben der Datei raus. Die Meldung ist dabei Stream Closed.


----------



## SE (5. August 2011)

Das ist auch der Grund warum man Sonderzeichen in Datei- und Ordnernamen vermeiden sollte. Aber da ja heutzutage die meisten OS UTF können fällt es erst auf wenn du mal sowas wie Zip hast das kein UTF kann.
Beschwere dich diesbezüglich also mal bei dem der die Zip-Files erstellt das er sich aus komatibilitäts-Gründen mal dazu entschließen sollte KEINE UTF-Chars zu verwenden. Auch gibt es Probleme weil Win und Linux unterschiedliche Charsets benutzen ... also die Sonderzeichen noch nicht mal zwischen verschiedenen OS gleichbleiben geschweigedenn in irgendwelchen Algorythmen.


----------

