Zip archive

Hallo,
in a Order I have many files and I want some file to put in a zip archive who it is to do. can sombody post a samplecod ???
thanks

Compressing Files is extremely easy in Java.
import java.util.zip.ZipOutputStream;
import java.util.zip.ZipEntry;
import java.io.File;
import java.io.FileOutputStream;
import java.io.FileInputStream;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.IOException;
* Compresses Files Together
* @author Jegadisan
* @version $Revision$ $Date$
public final class Compressor {
   * The Zip Output Stream to which the Compressed Files will be
   * written to
   * @since 1.1
  private ZipOutputStream _zOS;
   * Creates a Compressor for the Output File Specified
   * @param outputFile The Output File to which the files to be compressed are to be added
   * @throws IOException If any IO Errors are encountered
   * @since 1.1
  public Compressor(File outputFile) throws IOException {
    _zOS = new ZipOutputStream(new FileOutputStream(outputFile));
   * Adds a File to the Compressed File
   * @param f The File to be added
   * @since 1.1
  public void addFile(String entryName, File f) throws IOException {
    _zOS.putNewEntry(new ZipEntry(entryName));
    BufferedInputStream bIS = new BufferedInputStream(new FileInputStream(f));
    bOS = new BufferedOutputStream(_zOS);
    byte[] buffer = new byte[2048];
    int bytesRead = 0;
    while ((bytesRead = bIS.read(buffer,0,buffer.length) != -1) {
      bOS.write(buffer, 0, bytesRead);
    bOS.flush();
    bIS.close();
    _zOS.closeEntry();
   * Closes the Compressed File.
   * @throws IOException If any IO errors are encountered
   * @since 1.1
  public void close() throws IOException {
    _zOS.close();
}Of course ,the code is not complete. This compressor is only capable of adding Files to the compressed File. Directories can't be added. Test the code before you use it. It should work, but I dun have a compiler on this Machine, and I am too lazy to download one

Similar Messages

  • Need help in creating a Zip archive through Java

    I need some files existing a folder.
    When I use ZipOutputStream to zip the files, do I need to give the entire path to each of the files to add the file to the zip archive?
    For example here is the folder structure.
    C:
    ->Folder1
    ---->Folder2
    ------>File1
    ------>File2
    ---->File3
    ---->File4
    Here should I pass the entire path of Each file to the ZipOutputStream?
    Can any one please give me an example of creating a zip archive of the above file structure.
    Thanks,
    Ramesh

    Hi,
    I atleast need the following:
    I want to add a file "pres.txt" to an existing zip archive "test..zip". This file "pres.txt" already exists in the zip archive, but is a modified one.
    Can any one please help.
    Thanks,
    Ramesh

  • Create a new directory in existing Zip archive

    Hello Every One
    I want create a new folder in existing Zip archive. Can any one help in this regard.
    Thanks
    Edited by: SatishBejgum on Dec 18, 2007 12:42 AM

    Delete the ZIP, write a new one. You can't modify an existing archive.

  • Windows Explorer misreads large-file .zip archives

       I just spent about 90 minutes trying to report this problem through
    the normal support channels with no useful result, so, in desperation,
    I'm trying here, in the hope that someone can direct this report to some
    useful place.
       There appears to be a bug in the .zip archive reader used by Windows
    Explorer in Windows 7 (and up, most likely).
       An Info-ZIP Zip user recently reported a problem with an archive
    created using our Zip program.  The archive was valid, but it contained
    a file which was larger than 4GiB.  The complaint was that Windows
    Explorer displayed (and, apparently believed) an absurdly large size
    value for this large-file archive member.  We have since reproduced the
    problem.
       The original .zip archive format includes uncompressed and compressed
    sizes for archive members (files), and these sizes were stored in 32-bit
    fields.  This caused problems for files which are larger than 4GiB (or,
    on some system types, where signed size values were used, 2GiB).  The
    solution to this fundamental limitation was to extend the .zip archive
    format to allow storage of 64-bit member sizes, when necessary.  (PKWARE
    identifies this format extension as "Zip64".)
       The .zip archive format includes a mechanism, the "Extra Field", for
    storing various kinds of metadata which had no place in the normal
    archive file headers.  Examples include OS-specific file-attribute data,
    such as Finder info and extended attributes for Apple Macintosh; record
    format, record size, and record type data for VMS/OpenVMS; universal
    file times and/or UID/GID for UNIX(-like) systems; and so on.  The Extra
    Field is where the 64-bit member sizes are stored, when the fixed 32-bit
    size fields are too small.
       An Extra Field has a structure which allows multiple types of extra
    data to be included.  It comprises one or more "Extra Blocks", each of
    which has the following structure:
           Size (bytes) | Description
          --------------+------------
                2       | Type code
                2       | Number of data bytes to follow
            (variable)  | Extra block data
       The problem with the .zip archive reader used by Windows Explorer is
    that it appears to expect the Extra Block which includes the 64-bit
    member sizes (type code = 0x0001) to be the first (or only) Extra Block
    in the Extra Field.  If some other Extra Block appears at the start of
    the Extra Field, then its (non-size) data are being incorrectly
    interpreted as the 64-bit sizes, while the actual 64-bit size data,
    further along in the Extra Field, are ignored.
       Perhaps the .zip archive _writer_ used by Windows Explorer always
    places the Extra Block with the 64-bit sizes in this special location,
    but the .zip specification does not demand any particular order or
    placement of Extra Blocks in the Extra Field, and other programs
    (Info-ZIP Zip, for example) should not be expected to abide by this
    artificial restriction.  For details, see section "4.5 Extensible data
    fields" in the PKWARE APPNOTE:
          http://www.pkware.com/documents/casestudies/APPNOTE.TXT
       A .zip archive reader is expected to consider the Extra Block type
    codes, and interpret accordingly the data which follow.  In particular,
    it's not sufficient to trust that any particular Extra Block will be the
    first one in the Extra Field.  It's generally safe to ignore any Extra
    Block whose type code is not recognized, but it's crucial to scan the
    Extra Field, identify each Extra Block, and handle it according to its
    type.
       Here are some relatively small (about 14MiB each) test archives which
    illustrate the problem:
          http://antinode.info/ftp/info-zip/ms_zip64/test_4g.zip
          http://antinode.info/ftp/info-zip/ms_zip64/test_4g_V.zip
          http://antinode.info/ftp/info-zip/ms_zip64/test_4g_W.zip
       Correct info, from UnZip 6.00 ("unzip -lv"):
    Archive:  test_4g.zip
     Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
    4362076160  Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece  test_4g.txt
    Archive:  test_4g_V.zip
     Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
    4362076160  Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece  test_4g.txt
    Archive:  test_4g_W.zip
     Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
    4362076160  Defl:X 14800839 100% 05-01-2014 15:33 6d8d2ece  test_4g.txt
    (In these reports, "Length" is the uncompressed size; "Size" is the
    compressed size.)
       Incorrect info, from (Windows 7) Windows Explorer:
    Archive        Name          Compressed size   Size
    test_4g.zip    test_4g.txt         14,454 KB   562,951,376,907,238 KB
    test_4g_V.zip  test_4g.txt         14,454 KB   8,796,110,221,518 KB
    test_4g_W.zip  test_4g.txt         14,454 KB   1,464,940,363,777 KB
       Faced with these unrealistic sizes, Windows Explorer refuses to
    extract the member file, for lack of (petabytes of) free disk space.
       The archive test_4g.zip has the following Extra Blocks: universal
    time (type = 0x5455) and 64-bit sizes (type = 0x0001).  test_4g_V.zip
    has: PWWARE VMS (type = 0x000c) and 64-bit sizes (type = 0x0001).
    test_4g_W.zip has: NT security descriptor (type = 0x4453), universal
    time (type = 0x5455), and 64-bit sizes (type = 0x0001).  Obviously,
    Info-ZIP UnZip has no trouble correctly finding the 64-bit size info in
    these archives, but Windows Explorer is clearly confused.  (Note that
    "1,464,940,363,777 KB" translates to 0x0005545500000400 (bytes), and
    "0x00055455" looks exactly like the size, "0x0005" and the type code
    "0x5455" for a "UT" universal time Extra Block, which was present in
    that archive.  This is consistent with the hypothesis that the wrong
    data in the Extra Field are being interpreted as the 64-bit size data.)
       Without being able to see the source code involved here, it's hard to
    know exactly what it's doing wrong, but it does appear that the .zip
    reader used by Windows Explorer is using a very (too) simple-minded
    method to extract 64-bit size data from the Extra Field, causing it to
    get bad data from a properly formed archive.
       I suspect that the engineer involved will have little trouble finding
    and fixing the code which parses an Extra Field to extract the 64-bit
    sizes correctly, but if anyone has any questions, we'd be happy to help.
       For the Info-ZIP (http://info-zip.org/) team,
       Steven Schweda

    > We can't get the source (info-zip) program for test.
       I don't know why you would need to, but yes, you can:
          http://www.info-zip.org/
          ftp://ftp.info-zip.org/pub/infozip/src/
    You can also get pre-built executables for Windows:
          ftp://ftp.info-zip.org/pub/infozip/win32/unz600xn.exe
          ftp://ftp.info-zip.org/pub/infozip/win32/zip300xn.zip
    > In addition, since other zip application runs correctly. Since it should
    > be your software itself issue.
       You seem to misunderstand the situation.  The facts are these:
       1.  For your convenience, I've provided three test archives, each of
    which includes a file larger than 4GiB.  These archives are valid.
       2.  Info-ZIP UnZip (version 6.00 or newer) can process these archives
    correctly.  This is consistent with the fact that these archives are
    valid.
       3.  Programs from other vendors can process these archives correctly.
    I've supplied a screenshot showing one of them (7-Zip) doing so, as you
    requested.  This is consistent with the fact that these archives are
    valid.
       4.  Windows Explorer (on Windows 7) cannot process these archives
    correctly, apparently because it misreads the (Zip64) file size data.
    I've supplied a screenshot of Windows Explorer showing the bad file size
    it gets, and the failure that occurs when one tries to use it to extract
    the file from one of these archives, as you requested.  This is
    consistent with the fact that there's a bug in the .zip reader used by
    Windows Explorer.
       Yes, "other zip application runs correctly."  Info-ZIP UnZip runs
    correctly.  Only Windows Explorer does _not_ run correctly.

  • Loading a text file in a gzip or zip archive using an applet to a String

    How do I load a text file in a gzip or zip archive using an applet to a String, not a byte array? Give me both gzip and zip examples.

    This doesn't work:
              try
                   java.net.URL url = new java.net.URL(getCodeBase() + filename);
                   inputStream = new java.io.BufferedInputStream(url.openStream());
                   if (filename.toLowerCase().endsWith(".txt.gz"))
                        inputStream = (java.io.InputStream)(new java.util.zip.GZIPInputStream(inputStream));
                   else if (filename.toLowerCase().endsWith(".zip"))
                        java.util.zip.ZipInputStream zipInputStream = new java.util.zip.ZipInputStream(inputStream);
                        java.util.zip.ZipEntry zipEntry = zipInputStream.getNextEntry();
                        while (zipEntry != null && (zipEntry.isDirectory() || !zipEntry.getName().toLowerCase().endsWith(".txt")))
                             zipEntry = zipInputStream.getNextEntry();
                        if (zipEntry == null)
                             zipInputStream.close();
                             inputStream.close();
                             return "";
                        inputStream = zipInputStream;
                   else
                   byte bytes[] = new byte[10000000];
                   byte s;
                   int i = 0;
                   while (((s = inputStream.read())) != null)
                        bytes[i++] = s;
                   inputStream.close();
            catch (Exception e)
              }

  • Adobe Bridge CS5.1 crashes if directory contains .zip archive

    Every time I try to open a directory that contains .zip archive in Adobe Bridge CS5.1 it crashes. This started to happen after Mountain Lion upgrade.
    It crashes even when I generate .zip archive in a directory that is already opened in Bridge.
    Is it related to some new Mountain Lion "security feature" that can be turned off? My computers only purpose is running Adobe Creative Suite so this is pretty big issue. Browsing directories in Bridge is like walking through the mine field, you newer know where .zip archive is waiting.

    Yep, same here. Running Adobe bridge CS5.1, upgraded to Mountain Lion yesterday. Navigated to folder that contained a zip file and Bridge crashed. I removed the zip file, launched Bridge again,and went to that same folder. Worked perfectly. On a hunch, I dragged a zip file back into that folder in Bridge, and *WHAP* down she goes again.
    Looks like we wait for a fix. *sigh*
    Unless...File type association somehow comes into it? Interesting, I just checked (it's under Preferences) and neither a zip file or a doc file is in the list.
    Furthermore, there doesn't seem to be any way to add a new file type. Hm. Don't know if it has anything to do with the crashing, but man, what a pain this is!

  • Files in ZIP Archive not visible in XP explorer

    I have a strange problem. I'm sure the solution is something simple, but I seem to be overlooking it. I am creating a .zip archive from within my Java app, zipping up 5-10 straight text files. From what I can tell the file gets created successfully. After the .zip file is created, I can do a jar -tf on the file and it will show them all to me. I can also programatically get a list of the files in the archive and it all looks correct. However, when I try opening the archive file from the Windows XP file explorer (or extracting it to a location) it says that there are no objects in the archive.
    Here is the code I am using to create the zip file:
       byte[] buf = new byte[1024];
       try {
          String outputFilename = "somefile.zip";  // The output archive
          ZipOutputStream outStream = new ZipOutputStream(new FileOutputStream(outputFilename));
          System.out.println("createZip: zipping "+_files.length+" files.");
          // _files is an array of c:\somedir\somefile.txt file listings
          for (int i=0; i<_files.length; i++) {
            System.out.println("Adding entry: "+_files);
    FileInputStream in = new FileInputStream(_files[i]);
    outStream.putNextEntry(new ZipEntry(_files[i]));
    int len;
    while ((len = in.read(buf)) > 0) {
    outStream.write(buf,0,len);
    outStream.closeEntry();
    in.close();
    outStream.finish();
    outStream.close();
    rv = true;
    // ... catch, return value, etc.
    Any suggestions or hints would be greatly appreciated..

    We had a similar problem
    It turned out to be a feature and not a bug
    Actually 'vanilla' XP handles those files and is able to open them and it seems that the problem appears only after updating the XP to fix the vulnerability described in:
    http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-054.asp
    What we have determined is that if the zip file contains '/' at the begining of the path - the compressed folder utility will refuse to open it and will show only a blank pane in explorer. Removing the '/' from path in zip file solves the problem on updated Windows XP.

  • How to recover a zip archive?

    Dear all,
    I'm trying to open a zip archive I created but I've got the message "Error 1-Operation not permitted".
    I don't know if it is corrupted or something else. It's an archive with 3 or 4 mov and wmv files on it.
    Could you suggest me any name of software that can recover it? Or some trick to force the opening of it? I've tried system's Archive Utility, Stuffit...
    Thanks in advance.
    Ken

    Ken Ponzio wrote:
    Arigato Kenichi.
    But unfortunately I have only mac os sys in my studio! No windows...
    I'already saw there are some windoze zip recover sw but I've not found a mac soft...
    thanks anyway
    ken
    Can you email or FTP it to a Windows user you know? You could also use iDisk or MobilMe to do the same. The Windows user could extract/repair the archive and return it to you.

  • I have an iPhone 5S and I can't open photos that are emailed to me. It just says zip archive when I click on the jpg. Help?

    I Have an iPhone 5S and I can't open photos that emailed to me. It just says Zip archive when I click on the JPG file to download it.  Help?

    whoever is emailing you the photos is sending them as a .zip file not a .jpg most likely because there is more than one photo. unfortunately iPhone does not have a .zip file reader so whoever is emailing the photos has to make sure they are not zip ing them and resend them as .jpg files. (usually gmail tries to convert several images into .zip files)

  • After Migration to Server 2012 R2 One Zip Archive (7.08 mb) Downloads Empty

    I recently migrated from Server 2008 R2 to 2012 R2. I offer a number of web application as zip archives and Dreamweaver Extension installer packages .mxp. I have one zip archive that's empty when downloaded with size 0. Out of all the files served
    the issue only exists with this one file. All the other files regardless of .zip or .mxp work correctly. I think it may be a size related issue. The .zip file that is empty is 7.08 mb and the others are much smaller. I've tried deleting the existing file
    and uploading a new one with and without a file name change and still get same results. Here's the code.
    I'm thinking I may need to allow the larger file download. Does anyone know how to fix this?
    Response.Buffer=true
    On Error Resume Next
    'Create a stream object
    Dim mxp_downloadStream
    Set mxp_downloadStream = Server.CreateObject("ADODB.Stream")
    mxp_downloadStream.Type = 1
    mxp_downloadStream.Open
    mxp_downloadStream.LoadFromFile Server.Mappath("../downloads/dwmx_extensions/" & (rs_mxp.Fields.Item("MXP_DL_Path").Value) & "")
    If Err.number = 0 Then
    Response.Clear
    Response.ContentType = "application/octet-stream"
    Response.AddHeader "Content-Disposition", "attachment; filename=" & (rs_mxp.Fields.Item("MXP_DL_Path").Value) & ""
    Response.AddHeader "Content-Transfer-Encoding","binary"
    Response.BinaryWrite mxp_downloadStream.Read
    mxp_downloadStream.Close
    Set mxp_downloadStream = Nothing
    Response.End()
    End If

    YOu are asking a quesiton about ASP on a web server.  YOu need to post in the web server forum for this.  Thisis not a web scripting forum.
    Try here: http://forums.iis.net/
    ¯\_(ツ)_/¯

  • [ZIP Archive] Append files to an existing archive

    Hi to all,
    I have an existing file that contains a ZIP archive. I want to add some files to this archive. I have seen in another thread that it's mandatory to read all the structures and construct a new zip file in order to add other files?
    Is it true?
    In this thread, someone proposes a method that performs this job
    <quote>
          * Loads a zip file for appending files
          * @param file The old zip archive     
          * @param newFile The new zip archive
          * NOTE: This method will write a new file and data to an archive, to
                 * write an existing file, we must first read the data frm the file,
          * then you could call this method.
         public ZipOutputStream loadZipFile(File file, File newFile)
           ZipOutputStream zipOutput = null;
           ZipFile zipFile = null;
           Enumeration zippedFiles = null;
           ZipEntry currEntry = null;
           ZipEntry entry = null;
           try {     
              zipFile = new ZipFile( file.getAbsolutePath() );
              //get an enumeration of all existing entries
              zippedFiles = zipFile.entries();
              //create your output zip file
              zipOutput = new ZipOutputStream(new FileOutputStream (newFile));
              //Get all the data out of the previously zipped files and write it to a new ZipEntry to go into a new file archive
              while (zippedFiles.hasMoreElements())
                   //Retrieve entry of existing files
                   currEntry = (ZipEntry)zippedFiles.nextElement();
                   //Read data from existing file
                   BufferedReader reader = new BufferedReader( new InputStreamReader( zipFile.getInputStream( currEntry ) ) );
                   String currentLine = null;
                   StringBuffer buffer = new StringBuffer();
                   while( (currentLine = reader.readLine() ) != null )
                        buffer.append( currentLine);
                   //Commit the data
                   zipOutput.putNextEntry(new ZipEntry(currEntry.getName()) ) ;
                   zipOutput.write (buffer.toString().getBytes() );
                   zipOutput.flush();
                   zipOutput.closeEntry();
              //Close the old zip file
              zipFile.close();
              return zipOutput;
            catch (Exception e)
                 Logger.error("LoadZipFile", e);
                 System.out.println("Fatal error: "+e);     
            return null;
    }</quote>
    It runs fine but all the file contained in the archive are on a singlie line.
    E.g. I have a text file in the original archive. When adding another stuff in the archive and by using this method, my orignal text file has its content on only one line.
    Could someone help with this bug?
    Kind regards,
    St�phane

    yes it is true. You can only create a new archive with the added file(s) inside, there is nothing to happen an existing file to an existing zip file.
    Good luck

  • Drop files out of zip archiv and deliver?

    Is it possible to drop a special filetype (exe) or filenames out of an zip archiv? After deleting the unwanted "archiv-members", the archiv should be delivered.
    I need this requirement for specific recipients, not as a "global setting".

    While it is possible to drop an archive file if the contents contain a certain attribute ( .exe file, filename, etc... ), at this time I am not aware of any way to remove a *single* portion of that archive and deliver the rest of the contents.
    I would envision the difficulty would lie in re-assembling the archive correctly, so the recipient did not receive a "broken" file.
    -whardison

  • Zip archive problem

    Hi everyone,
    Is there a way to repair a corrupt zip archive? I have a rather large file, a 2GB movie I want to unzip, but I get an error message with every program I've tried (stuffit, archive, jimzip, zipeg, the unarchiver). When I tried to unzip directly from the terminal, I got the following message:
    bad CRC f23db85c (should be 77b37ff6)
    It only expands the first 75MB of the file. Any ideas or suggestions?
    Thanks!

    Hi Davidludwig;
    To the best of my knowledge no. I do not believe there is sufficient redundancy in the data after it has been compressed to effect a recovery of data. The CRC is created as the data is compressed into the zip file and then later used to check for corruption. If corruption has occurred as in your case, there is no way to recover it.
    I think this is one of the reasons zip files are used for communications and not archives. With communications, if the CRC fails you sent it again. With archive on the other hand, the original is gone by the time the CRC fails hence you lost the archive.
    Allan

  • Automate renaming files within zip archive

    I have a large number of files where I need to do the following:
    Change the file extension to .zip. (The files are zip archives but with a special extension, and all of the files have their own extension, ie .xx01, .xx02, etc...)
    Extract the zip file.
    Rename a file within. (Alternatively, it'd be great to be able to rename the file without extracting the zip file.)
    Recompress the file.
    Set the file extension back to what it was.
    I've been playing around in Automator to see if I could create a workflow that would do some or all of this. I've figured out changing the file extension, and Automator has an action to compress a zip file, but the other parts are eluding me.
    Does anyone know a way to make this process a little less labor intensive? I'd prefer to automate the whole thing, but even just some way to rename a file in a .zip archive without extracting it first would be hugely helpful. (I know this is possible under Windows.)
    I'm comfortable with delving into new territory in Automator, AppleScript, or shell scripts to make this easier.
    Thanks!

    We had a similar problem
    It turned out to be a feature and not a bug
    Actually 'vanilla' XP handles those files and is able to open them and it seems that the problem appears only after updating the XP to fix the vulnerability described in:
    http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-054.asp
    What we have determined is that if the zip file contains '/' at the begining of the path - the compressed folder utility will refuse to open it and will show only a blank pane in explorer. Removing the '/' from path in zip file solves the problem on updated Windows XP.

  • Change file in Zip archive without repacking

    Hi All,
    I have Zip archive. It contains ~100000 files. I needed to change only one file, without repacking all Zip archive.
    How can I do this? Do smb have such situations?

    You can't, using Java. I think that there are 3rd-party products that can. Try searching for one.

  • SmartView 11.1.2.5.400 - corrupt zip archive?

    Hi,
    I have recently downloaded SmartView 11.1.2.5.400 zip and couldn't uncompress it - corrupt zip archive.
    I have tried different browsers(IE, Firefox, Chrome etc ) and download sources (eDelivery and OTN).
    Has anyone else experienced the same? If so, with whom should we get it touch to have this issue fixed?
    Thanks,
    Gabriel

    For me this still doesn't  work - I believe that we are downloading from different "mirrored" sites.
    So, while giving up on this approach, I've found an alternate one on the Oracle Support Portal:
    Patch 20327649: Patch Set Update: 11.1.2.5.400 for Oracle Smart View for Office
    Finally, I have something that works and that it has indeed the indicated size: 124MB
    Cheers and thanks for trying to help anyway!
    -Gabriel

Maybe you are looking for