It is possible compress an stream (without saving in a file?)

I'm using java.util.zip package to compress/uncompress streams.

My objective is translate a file into a string (coding it to base64), and then, decoding it.

But, before to coding it i'm trying to compress the stream in order to have less bytes.

For compress the file, i think that i've no problem. The problem is with the uncompressing.

I give a pice of code to have more accurate idea :

String cad;

.... /* now, this 'cad' is the result of compressed OutputStream (GZIPOutputStream.toString()) */

....

ByteArrayInputStream bis = new ByteArrayInputStream(cad.getBytes());

GZIPInputStream gis = new GZIPInputStream(bis);

ByteArrayOutputStream bou = new ByteArrayOutputStream();

...

byte[] buffer = new byte[gis.available()];

gis.read(buffer); /* here it crash with this error #1 */

bou.write(buffer);

bou.flush();

...

But when JVM wants to read directly from GZIPInputStream #1 it crashes with this error :

java.util.zip.ZipException: oversubscribed literal/length tree

...

I'm using GZIPInputStream but i'm in a Windows plataform, i hope that this fact wasn't a problem.

The main reason to the utilitzation of GZIPInputStream is becouse it seems less dependent of file (if you use a ZipInputStream class you need an ZipEntry , etc...). I don't know if it is possible to do the compression of stream without file with ZipInputStream, but i think that no.

Thanks for all, and sorry about my english, it isn't my natural language, but i hope that more or less you understand my message.

[1635 byte] By [armandua] at [2007-11-27 2:18:16]
# 1

If the problem is with the uncompressing you have probably compressed it wrong. You would have to show us how you constructed the data fed into the ByteArrayInputStream to solve this exception. Your statement about OutputStream (GZIPOutputStream.toString()) doesn't make any sense whatsoever.

But I don't understand why you are doing this at all.

Why encode it in base-64, which increases the size, and then compress? Why not just compress the raw file data?

ejpa at 2007-7-12 2:17:36 > top of Java-index,Core,Core APIs...
# 2
> Why encode it in base-64, which increases the size,> and then compress? Why not just compress the> raw file data?He may want to send the string over the internet using a certain protocol that requires base-64 encoding.
toon_macharisa at 2007-7-12 2:17:36 > top of Java-index,Core,Core APIs...
# 3

> byte[] buffer = new byte[gis.available()];

Have you checked the value of the method available()? For ObjectInputStreams the returned value is typically 0, even if you have flushed to corresponding ObjectOutputStream. This method may not behave as expected.

try

int c;

while((c = gis.read()) != -1) {

bou.write(c);

}

> I'm using GZIPInputStream but i'm in a Windows

> plataform, i hope that this fact wasn't a problem.

> The main reason to the utilitzation of

> GZIPInputStream is becouse it seems less dependent of

> file (if you use a ZipInputStream class you need an

> ZipEntry , etc...). I don't know if it is possible to

> do the compression of stream without file with

> ZipInputStream, but i think that no.

GZIPStreams are for 1 file only, ZipStreams can be used for multiple files and internally require a manifest file to organise them, that is why the API may seem more complicated.

toon_macharisa at 2007-7-12 2:17:36 > top of Java-index,Core,Core APIs...
# 4

>> (GZIPOutputStream.toString()

This makes no sense whatever.

>> byte[] buffer = new byte[gis.available()];

>

> Have you checked the value of the method available()?

> For ObjectInputStreams

Err, this is a GZIPInputStream. But you're right, this call shouldn't be used as an indication of how many bytes are in the stream in total. That's not what it does and it's not what it's for. There are also several implementations that just return zero, although AFAIK ObjectInputStream's is not one of them.

ejpa at 2007-7-12 2:17:36 > top of Java-index,Core,Core APIs...