Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4244499

ZipEntry() does not convert filenames from Unicode to platform

    Details

    • Subcomponent:
    • Resolved In Build:
      b57
    • CPU:
      generic, x86, sparc
    • OS:
      generic, solaris_8, windows_98, windows_nt, windows_2000, windows_2003, windows_xp

      Description

      Name: rlT66838 Date: 06/07/99


      I try to create a ZIP archive containing files, provided that the filenames are french words (ie with accentuated characters). The filenames are contained in String, this means they are encoded in Unicode. If I try to create a File from the String filename, this filename is converted OK to platform specifics; but if I create a ZipEntry from the String filename, it is NOT converted to platform specifics, leading to a filename in ZIP archive which is the Unicode image (unreadable from various ZIP tools !).

      For instance:

      String filename = "?l?ve.txt";

      // This will create a right filename on disk
      File myFile = new File(filename);
      ...
      // A file ?l?ve.txt is created on disk

      // This will create a bad (unconverted) filename in ZIP archive
      ZipEntry myEntry = new Entry(filename);
      ...
      // An entry ??l??ve.txt is created in ZIP archive

      The result is that the generated ZIP entry is not usable for extraction...
      (Review ID: 83688)
      ======================================================================

      Name: tb29552 Date: 03/24/2000


      Solaris VM (build Solaris_JDK_1.2.1_04, native threads, sunwjit)
      Classic VM (build JDK-1.2.2-W, green threads, sunwjit)
      java version "1.1.6"

      Within a ZIP file, pathnames use the forward slash / as separator, as required
      by the ZIP
      <A HREF="ftp://ftp.uu.net/pub/archiving/zip/doc/appnote-970311-iz.zip">spec</A>.
      This requires a conversion from or to the local file.separator on systems like
      Windows. The API (ZipEntry) does not take care of the transformation, and the
      need for the programmer to deal with it is not documented. As a result, code
      like
        ZipEntry ze;
        File f;
        f = new File( ze.getName());
      will be written and fail on the Windows platform, or the reverse
        ze = new ZipEntry( f.getName());
      will fail or produce invalid jars on Windows platforms.

      Either the docs or the API needs to be fixed. Preferably a new method and
      constructor could be added
        File f = ze.toFile(); ze = new ZipEntry( f);
      that would perform the translation between '/' and File.separatorChar, leaving
      the existing methods/constructors (perhaps deprecated) for use by existing code.
      But if the API is not fixed, then the docs must be fixed to make sure the
      programmer deals with the translation explicitly.

      Note new methods in java.util.zip.ZipEntry would also need to be reflected
      in java.util.jar.JarEntry.
      (Review ID: 100505)
      ======================================================================

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                sherman Xueming Shen
                Reporter:
                rlewis Roger Lewis (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: