Best way to detect if a stream is zipped in Java

Question

What is the best way to find out i java.io.InputStream contains zipped data?

Answer 1

Introduction

Since all the answers are 5 years old I feel a duty to write down, what's going on today. I seriously doubt one should read magic bytes of the stream! That's a low level code, it should be avoided in general.

Simple answer

miku writes:

If the Stream can be read via ZipInputStream, it should be zipped.

Yes, but in case of ZipInputStream "can be read" means that first call to .getNextEntry() returns a non-null value. No exception catching et cetera. So instead of magic bytes parsing you can just do:

boolean isZipped = new ZipInputStream(yourInputStream).getNextEntry() != null; 

And that's it!

General unzipping thoughts

In general, it appeared that it's much more convenient to work with files while [un]zipping, than with streams. There are several useful libraries, plus ZipFile has got more functionality than ZipInputStream. Handling of zip files is discussed here: What is a good Java library to zip/unzip files? So if you can work with files you better do!

Code sample

I needed in my application to work with streams only. So that's the method I wrote for unzipping:

import org.apache.commons.io.IOUtils; import java.util.zip.ZipEntry; import java.util.zip.ZipInputStream;  public boolean unzip(InputStream inputStream, File outputFolder) throws IOException {      ZipInputStream zis = new ZipInputStream(inputStream);      ZipEntry entry;     boolean isEmpty = true;     while ((entry = zis.getNextEntry()) != null) {         isEmpty = false;         File newFile = new File(outputFolder, entry.getName());         if (newFile.getParentFile().mkdirs() && !entry.isDirectory()) {             FileOutputStream fos = new FileOutputStream(newFile);             IOUtils.copy(zis, fos);             IOUtils.closeQuietly(fos);         }     }      IOUtils.closeQuietly(zis);     return !isEmpty; } 

Answer 2

The magic bytes for the ZIP format are 50 4B. You could test the stream (using mark and reset - you may need to buffer) but I wouldn't expect this to be a 100% reliable approach. There would be no way to distinguish it from a US-ASCII encoded text file that began with the letters PK.

The best way would be to provide metadata on the content format prior to opening the stream and then treat it appropriately.