Thanks for replying. I'm compressing a small text file I saved from an excel worksheet to send to a government agency (they archive it as a zip file for their records- they don't deal with MAC computers of course). I have had no problems doing this on a PC (where previously I save the text file as a \"text delimited\", but now I have an IMAC. (I have to load lots and lots of files to them for my work.) I tried first saving the data as a Windowstext file. Then I \"compress it\" as a zip file. Thanks so much for looking at this.
I am saving my data set as a windows text file in excel, which gives me many text options. I compress the by right clicking on the text file in FINDER. When I \"open\" or uncompress the zipped file it looks normal. The government agency tech guy says that MAC compressed files save an additional line or two of stuff, and this causes the problem. But he's not an APPLE type and doesn't know more than that. One can't view the zipped file, right without un-zipping it
In addition to what others suggested, it's important pay Attention to your file and directory names as Windows does not necessarily like Linux file path and names. It sometimes also escapes them differently when zipping. Examples are numerous, but most importantly dot files (. and ..), files with only case differences (name.txt and NAME.txt), absolute file paths (/tmp/file.txt). Some other characters which are allowed in file names on Windows could cause issues when Windows Explorer is used to open files. In my case ':' character was the deal breaker but took a lot of work to find this out.
Also -k option may render your file names unreadable. In my case my files were named based on creation time (e.g. 10:55:39.pdf) to facilitate easily locating the required record from archives, but -k option turned it to 105539.pdf which is not easily readable by users. I hence changed the names to 10_55_39.pdf which opens on Windows without using -k option but is still readable.
Had a similar issue recently with files produced from a perl script. Found that native windows zip (tested Windows 7 only) incorrectly handles paths with a leading slash and displays an empty zipfile. Solution was to strip the leading slash before adding files. Perhaps some versions of the linux zip command store file paths with leading slashes.
The graphical user interface (GUI) on Mac OS X and Linux-based operating systems does not display files and folders with names that begin with a period (.). Use the command line instead of the GUI to compress your application if the ZIP file must include a hidden folder, such as .ebextensions. For command line procedures to create a ZIP file on Mac OS X or a Linux-based operating system, see Creating a source bundle from the command line.
As noted in the list of requirements above, your source bundle must be compressed without a parent folder, so that its decompressed structure does not include an extra top-level directory. In this example, no myapp folder should be created when the files are decompressed (or, at the command line, no myapp segment should be added to the file paths).
You may want to test your source bundle locally before you upload it to Elastic Beanstalk. Because Elastic Beanstalk essentially uses the command line to extract the files, it's best to do your tests from the command line rather than with a GUI tool.
Therefore, if you plan to share Microsoft Office Word, PowerPoint, or Excel files with other people, you'll want to know which fonts are native to the version of Office that the recipient is using. If it isn't native, you may have to embed or distribute the font along with the Word file, PowerPoint presentation, or Excel spreadsheet. For more information about this see Fonts that are installed with Microsoft Office.
Keep in mind that password protected zip files are not encrypted with some super strong deep encryption method, so if you want a more secure file encryption, you may want to pass a regular zip file through openSSL encryption with des3 or something similar to really make the file secure.
WinZip, starting with version 12.1, uses the extension .zipx for ZIP files that use compression methods newer than DEFLATE; specifically, methods BZip, LZMA, PPMd, Jpeg and Wavpack. The last 2 are applied to appropriate file types when \"Best method\" compression is selected.
In April 2010, ISO/IEC JTC 1 initiated a ballot to determine whether a project should be initiated to create an ISO/IEC International Standard format compatible with ZIP. The proposed project, entitled Document Packaging, envisaged a ZIP-compatible 'minimal compressed archive format' suitable for use with a number of existing standards including OpenDocument, Office Open XML and EPUB.
.ZIP files are archives that store multiple files. ZIP allows contained files to be compressed using many different methods, as well as simply storing a file without compressing it. Each file is stored separately, allowing different files in the same archive to be compressed using different methods. Because the files in a ZIP archive are compressed individually, it is possible to extract them, or add new ones, without applying compression or decompression to the entire archive. This contrasts with the format of compressed tar files, for which such random-access processing is not easily possible.
A directory is placed at the end of a ZIP file. This identifies what files are in the ZIP and identifies where in the ZIP that file is located. This allows ZIP readers to load the list of files without reading the entire ZIP archive. ZIP archives can also include extra data that is not related to the ZIP archive. This allows for a ZIP archive to be made into a self-extracting archive (application that decompresses its contained data), by prepending the program code to a ZIP archive and marking the file as executable. Storing the catalog at the end also makes possible hiding a zipped file by appending it to an innocuous file, such as a GIF image file.
A ZIP file is correctly identified by the presence of an end of central directory record which is located at the end of the archive structure in order to allow the easy appending of new files. If the end of central directory record indicates a non-empty archive, the name of each file or directory within the archive should be specified in a central directory entry, along with other metadata about the entry, and an offset into the ZIP file, pointing to the actual entry data. This allows a file listing of the archive to be performed relatively quickly, as the entire archive does not have to be read to see the list of files. The entries within the ZIP file also include this information, for redundancy, in a local file header. Because ZIP files may be appended to, only files specified in the central directory at the end of the file are valid. Scanning a ZIP file for local file headers is invalid (except in the case of corrupted archives), as the central directory may declare that some files have been deleted and other files have been updated.
For example, we may start with a ZIP file that contains files A, B and C. File B is then deleted and C updated. This may be achieved by just appending a new file C to the end of the original ZIP file and adding a new central directory that only lists file A and the new file C. When ZIP was first designed, transferring files by floppy disk was common, yet writing to disks was very time-consuming. If you had a large zip file, possibly spanning multiple disks, and only needed to update a few files, rather than reading and re-writing all the files, it would be substantially faster to just read the old central directory, append the new files then append an updated central directory.
Each entry stored in a ZIP archive is introduced by a local file header with information about the file such as the comment, file size and file name, followed by optional \"extra\" data fields, and then the possibly compressed, possibly encrypted file data. The \"Extra\" data fields are the key to the extensibility of the ZIP format. \"Extra\" fields are exploited to support the ZIP64 format, WinZip-compatible AES encryption, file attributes, and higher-resolution NTFS or Unix file timestamps. Other extensions are possible via the \"Extra\" field. ZIP tools are required by the specification to ignore Extra fields they do not recognize.
ZIP supports a simple password-based symmetric encryption system generally known as ZipCrypto. It is documented in the ZIP specification, and known to be seriously flawed. In particular, it is vulnerable to known-plaintext attacks, which are in some cases made worse by poor implementations of random-number generators. Computers running under native Microsoft Windows without third-party archivers can open, but not create, ZIP files encrypted with ZipCrypto, but cannot extract the contents of files using different encryption.
The File Explorer in Windows XP does not support ZIP64, but the Explorer in Windows Vista and later do. Likewise, some extension libraries support ZIP64, such as DotNetZip, QuaZIP and IO::Compress::Zip in Perl. Python's built-in zipfile supports it since 2.5 and defaults to it since 3.4. OpenJDK's built-in java.util.zip supports ZIP64 from version Java 7. Android Java API support ZIP64 since Android 6.0. Mac OS Sierra's Archive Utility notably does not support ZIP64, and can create corrupt archives when ZIP64 would be required. However, the ditto command shipped with Mac OS will unzip ZIP64 files. More recent[when] versions of Mac OS ship with info-zip's zip and unzip command line tools which do support Zip64: to verify run zip -v and look for \"ZIP64_SUPPORT\".
A Seek-Optimized ZIP file (SOZip) profile  has been proposed for the ZIP format. Such file contains one or several Deflate-compressed files that are organized and annotated such that a SOZip-aware reader can perform very fast random access (seek) wit