FULL PRODUCT VERSION :
JDK1.1.8_008
JDK1.2.2_008

FULL OPERATING SYSTEM VERSION :Windows NT 4.0 SP5


A DESCRIPTION OF THE PROBLEM :
There is no compatibility in the Zip file created between
JDK1.1.8 and JDK 1.2.X, JDK 1.3.X.

Reappearance procedure
1: Compress the file which used Japanese for the file name
by java.util.zip.ZipFile of JDK1.1.8.
2:The Zip file created by 1.1.8 cannot be thawed by JDK 1.2.X.
("ZipFile.getInputStream (ZipEntry)" in the following source
code will return null.)

I know that the file name encoding method in a Zip file was
changed by JDK 1.2.X.
However, it is amusing that InputStream cannot be obtained
in spite of passing ZipEntry acquired from ZipFile to
ZipFile as it is.

It deals with the problem of the file name using umlaut as a bug.
(Bug Id :4244499,4415733)
Reference is made only till these problems not having the file name
of "ZipEntry" correctly.
Since my problem cannot even perform opening a file,
it is still more serious.


Source code (extract)

	ZipFile zf = null;
	try {
	  zf = new ZipFile(src);

	  Enumeration enum = zf.entries();
	  if (enum == null) return;
	  while(enum.hasMoreElements()) {
		ze = (ZipEntry)enum.nextElement();
		int off = 0;
		int len = 0;
		long size = ze.getSize();

		if(ze.isDirectory()) {
		  // Directory
		} else {
		  // file
		  InputStream is = zf.getInputStream(ze);
//This result is null on Java2
		  bis = new BufferedInputStream(is, RLEN);
		  fos = new FileOutputStream(file);
		  while((size-=len) > 0) {
			len = bis.read(b, off, RLEN);
			//My Processing
		  }
		  bis.close();
		  fos.close();
		}

	    } // end while

	    zf.close();

	} catch (ZipException e) {
	    // ZIP Formal error:ZipFile()
	} catch (IOException e) {
	    // I/O
error:ZipFile(),FileOutputStream(),read(),write().close()
	}



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Compress the file which used Japanese for the file name by
java.util.zip.ZipFile of JDK1.1.8.
2.UnCompress The Zip file(created by 1) on JDK 1.2.X.
Then "ZipFile.getInputStream (ZipEntry)" returns null.
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
"ZipFile.getInputStream (ZipEntry)" returns some
InputStream.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages or Exception is occur.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
	ZipFile zf = null;
	try {
	  zf = new ZipFile(src);

	  Enumeration enum = zf.entries();
	  if (enum == null) return;
	  while(enum.hasMoreElements()) {
		ze = (ZipEntry)enum.nextElement();
		int off = 0;
		int len = 0;
		long size = ze.getSize();

		if(ze.isDirectory()) {
		  // Directory
		} else {
		  // file
		  InputStream is = zf.getInputStream(ze);  //This result is null
on Java2
		  bis = new BufferedInputStream(is, RLEN);
		  fos = new FileOutputStream(file);
		  while((size-=len) > 0) {
			len = bis.read(b, off, RLEN);
			//My Processing
		  }
		  bis.close();
		  fos.close();
		}

	    } // end while

	    zf.close();

	} catch (ZipException e) {
	    // ZIP Formal error:ZipFile()
	} catch (IOException e) {
	    // I/O error:ZipFile(),FileOutputStream(),read(),write().close()
	}


---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Do not use Java.
(Review ID: 143349) 
======================================================================

N/A

Won't fix, use later version of JDK.


 xxxxx@xxxxx  2002-05-16

java.util.zip and winzip32.exe can NOT operate zip-files including Japanese Path well. so-called garbled characters!! (UTF-8 vs MS932)
Please resolve this too!!

This is a kind of internationalization bug, too.

Because most ZIP application encode/decode file entries in
platform's native encoding, Java ZIP application isn't
compatible with them.

I recommend to add a charset parameter to ZIP-related
methods.

Comments?

I am agree with kazama. And the bug is still in the newest 
JDK1.4. We hope this problem can be resolved sooner.

I am also facing the same problem. I have a .cab file created 
from JDK 1.2 and when trying to run the application with JDK 
1.3 or JDK 1.4 I am facing the problem of Applet couldn't be 
recognized. Have anyone found any workaround till now? 
Please let me know. 

Still a bug in 1.5.0_05 this is so important!!!

I'm appalled. Version 1.6 now and still no possibility to override some relevant methods - why?

Just give the people the possibility to use them their own encoding-Set.

The consecence for me is to use foreign libraries with all the overhead (See the FIXME-Comment in Apache's org.apache.tools.zip.ZipFile). 

It is not possible for me to go to my customers an say: "Hey, you use the wrong character-set for your files. Take the right one!"