Is there a way to recognize if the data is compressed or not?

[Siddharth bal sharma]

How do you differentiate between the zipped data and unzipped data before applying the compression APIs as they will throw an exception if you try to unzip the non-zip data?
Is there a way to recognize if the data is compressed or not?

[Joe Ess]

The easiest ways it probably to catch the exception, pretend it never happened and treat the file as an unzipped file.

[Siddharth bal sharma]

easiest but not the correct way. shouldn't catch exceptions to terminate a condition. I have both formats of data- zipped and unzipped that need to be processed(in the unzipping scenario).I can catch the exception while unzipping and assume that data is not compressed and do the normal processing but this is not the correct way. I should first gauge that the data is in zip format or not and then do the processing. try/catch blocks are anyways heavy.

[Joe Ess]

Originally posted by Siddharth bal sharma:
easiest but not the correct way.

That's rather strong. If it works, how can it not be "correct"?
I agree that under normal circumstances, using exceptions for testing is a Bad Thing (I loathe that ObjectInputStream/ObjectOutputStream signals EOF with an exception). However, you need some functionality. Someone has already implemented that functionality in the API. Does it really matter that you have to break convention to use it? I don't think so. If it does, then maybe someone else has a better idea (I don't).
As for performance, unless your app is churning through hundreds of files and users are waiting for them, I don't think it matters that it takes a few milliseconds to set up the try block in this case.

[Siddharth bal sharma]

lottsa retrofit required to make this try/catch in my case.
Does anyone know what is the header for a zip format. If we can check the header for a datastream- may be we have a chance to detmine!

[Ernest Friedman-Hill]

The first two characters of a zipfile are PK (0x50, 0x4B). Opening the file, reading the two characters, checking their identity is, indeed, going to be more efficient than the try/fail technique. But I agree with Joe that it's false economy to worry about it. The try/catch version is going to be simpler and more obvious; the character-checking version will be more complex and need an explanatory comment. I'd do it the simpler way unless and until it's shown to be a problem.

[Peter Chase]

Surely starting with "PK" is only a necessary, not a sufficient condition for checking for a ZIPped file. After all, a non-zipped file might happen to start with "PK" too. It's only two characters, so it's really not all that unlikely.

So, even if you check for "PK", you still need the try...catch as well.

[Siddharth bal sharma]

well..i need to handle both zip format and unzip format of data in the same piece of code, so a statement like

try
{
process zip data
}(catch ZipException)
{
process unzip data
}

is not neat .

[Carl Pettersson]

Something like

MyData data=getData();
try {
data=unzip(data);
} catch(NotZippedException) {
 // Ah well, data is fine as it is
} finally {
processData(data);
}

Should do what you want, right?