Discussion :

[TomZ]

Bonjour à tous ,

Voilà j'ai un soucis relativement étrange concernant la génération de fichiers ZIP avec java.util. En effet, dans tous les cas ma génération se passe sans aucun problème. Voici le code ci-dessous:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
 
		//These are the files to include in the ZIP file 
		String[] filenames = new String[]{"C:\\sysiclog.txt", "C:\\Montreal_Twilight_Panorama_2006.jpg"}; 
 
		// Create a buffer for reading the files 
		byte[] buf = new byte[1024]; 
 
		try { 
 
			// Create the ZIP file 
			String outFilename = "outfile.zip"; 
			ZipOutputStream out = new ZipOutputStream(new FileOutputStream(outFilename)); 
 
			// Compress the files 
			for (int i=0; i<filenames.length; i++) 
			{ 
				FileInputStream in = new FileInputStream(filenames[i]); 
 
				// Add ZIP entry to output stream. 
				out.putNextEntry(new ZipEntry(filenames[i])); 
 
				// Transfer bytes from the file to the ZIP file 
				int len; 
 
				while ((len = in.read(buf)) > 0) 
				{ 
					out.write(buf, 0, len); 
				}
				// Complete the entry 
				out.closeEntry(); 
				in.close(); 
			} // Complete the ZIP file 
 
			out.close(); 
		} 
		catch (IOException e) {
			System.out.println( e.toString());
		}
		catch (Exception e) {
			System.out.println( e.toString());
		}
	}

Le soucis survient à la décompression. Cette dernière marche très bien avec des outils de type Winzip, Winrar, 7zip etc... mais avec l'outil natif de Windows XP, j'ai l'erreur suivante:



L'API org.apache.commons.compress marche très bien dans tous les cas mais je suis limité à Java 1.3 pour le moment ce qui ne me permet pas de l'utiliser (1.4 minimum).

Avez-vous des solutions à cet étrange problème ?

Merci à vous.

[adiGuba]

Salut,

En effet, dans tous les cas ma génération se passe sans aucun problème. Voici le code ci-dessous:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	// ...
	catch (IOException e) { }

En effet il ne peut jamais y avoir de soucis comme cela !!!
Il manque également le try/finally pour la fermeture des ressources...


a++

[TomZ]

Bonjour,

J'ai rapidement reproduit une portion du code hors de son contexte. Néanmoins, j'ai bien peur de ne pas avoir saisi la réponse apportée (or syntaxe try / catch /finally).

En effet il ne peut jamais y avoir de soucis comme cela !!!

Cela veut dire que le problème n'existe pas ? Typiquement le code ci-dessus génère ce problème. Le zip est bien généré, décompression ok avec : Winzip, Winrar, 7Zip mais pas avec l'outil natif d'XP.

Merci par avance.

[adiGuba]

Tu as un bloc catch vide, donc quoi qu'il arrive tu n'auras aucun message d'erreur. Il ne faut jamais ignorer une exception !!!


Enfin, chaque ouverture d'une ressource DOIT être immédiatement suivi d'un bloc try/finally afin de s'assurer qu'elle sera correctement fermé ( Comment libérer proprement les ressources ?)



a++

[TomZ]

J'ai clairement compris la syntaxe des bloc try / catch / finally ce n'est pas le problème.

J'ai précisé que ce programme a été écrit rapidement dans une classe de test sans intégration aucune. Il n'a donc qu'une vocation particulière de tester un module plus important qui s'inscrit dans le cadre d'un programme "complet". Ci-dessous le code à jour (aucune exception dans tous les cas et zip généré correctement, ressources libérées)

Néanmoins, dans mon cas précis et après investigations il semblerait que la notion d'arborescence dans l'ajout du ZipEntry pose des problèmes (ex: C:\\rep1\\rep2...) pour la décompression par l'outil natif XP. Avez-vous déjà fait face à ce problème ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
		//These are the files to include in the ZIP file 
		String[] filenames = new String[]{"C:\\sysiclog.txt", "C:\\Montreal_Twilight_Panorama_2006.jpg"}; 
 
		// Create a buffer for reading the files 
		byte[] buf = new byte[1024]; 
 
		ZipOutputStream out = null ;
		FileInputStream in = null;
 
		try { 
 
			// Create the ZIP file 
			String outFilename = "outfile.zip"; 
			out = new ZipOutputStream(new FileOutputStream(outFilename)); 
 
			// Compress the files 
			for (int i=0; i<filenames.length; i++) 
			{ 
				in = new FileInputStream(filenames[i]); 
 
				// Add ZIP entry to output stream. 
				out.putNextEntry(new ZipEntry(filenames[i])); 
 
				// Transfer bytes from the file to the ZIP file 
				int len; 
 
				while ((len = in.read(buf)) > 0) 
				{ 
					out.write(buf, 0, len); 
				}
 
				// Complete the entry 
				out.closeEntry(); 
				in.close(); 
 
			} // Complete the ZIP file 
 
			out.close(); 
		} 
		catch (IOException e) {
			System.out.println( e.toString());
		}
		catch (Exception e) {
			System.out.println( e.toString());
		}
		finally{
			out.close();
			in.close();
		}
	}

[adiGuba]

J'ai clairement compris la syntaxe des bloc try / catch / finally ce n'est pas le problème.

Il est préférable d'utiliser un try/finally par ressource
Le tout dans un seul try/catch pour éviter la multiplication de la gestion des erreurs...


Je dis simplement qu'avoir un code incorrect n'aide pas à trouver les éventuels problèmes. En particulier le catch vide qui aurait pu te cacher beaucoup de chose...




Pour le reste d'après toi ce serait une limitation de l'outil de décompression de Windows ? As-tu réellement besoin d'utiliser le chemin complet pour le nom de l'entré du fichier zip ?

a++

[TomZ]

Salut,

Effectivement il se peut que ça soit une limitation de l'outil Windows néanmoins devant l'urgence, une solution de contournement a été mise en œuvre.

Les ZIP sont générés à la racine du serveur applicatif (donc sans chemin) puis copiés dans le répertoires de sortie pour affichage. Nous évitons le problème de chemins donc.

Dommage cependant. Je suis toujours preneur d'une solution

[adiGuba]

Ben utilises simplement le nom du fichier à la place du chemin complet dans putNextEntry().
Je pensais que tu avais besoin d'un chemin complet...

a++

[TomZ]

Techniquement effectivement nous en avions besoin mais par le biais de copier / coller nous avons contourné le problème.

Merci.