Apache Commons: IOUtils.write - how to restrict bytes-stream during write

[Andrey Dmitriev]

I realised reading a file into bytes-array with next writing this array to file in another directory by the following approach:

try(FileInputStream fis = new FileInputStream(attachFile)){
ZipOutputStream zipOutputStream = null;
byte[] bytes = new byte[BUFFER_SIZE];
int length;
while ((length = fis.read(bytes)) >= 0) {
      zipOutputStream.write(bytes, 0, length);
   }
}

And this code done well - in target directory appear new file with the relevant content (for example: "abcd").

Further I tried to improve my approach through ApacheCommons abilities.

try(FileInputStream fis = new FileInputStream(attachFile)){
  ZipOutputStream zipOutputStream = null;
  byte[] bytes = new byte[BUFFER_SIZE];
  IOUtils.read(fis, bytes);
  IOUtils.write(bytes, zipOutputStream);
}

But this approach entails the problem: in target directory the new file appeals, but this written content is irrelevant. Besides the written text (for example: "abcd") it contains some unreadable unencoded symbols, and I see the warning about problem with encoding.

I suppose this problem is related to the fact, that some excess bytes read and/or write to OutpumStream. And this problem (probably) arise due to the fact I don't restrict read and write-operations, applying IOUtils (second approach).

And in first approach I restrict the write of byte-array in OutputStream by size of length-variable:

while ((length = fis.read(bytes)) >= 0)

If problem in that I must have a way to restrict the write by tools of AppacheCommons.
But I don't see any way to do so in IOUtils-methods.

[Rob Spoor]

You're writing to a ZipOutputStream. That class doesn't just write content directly but creates ZIP files. That includes some "magic" code in between the possibly readable stuff. But the thing is, you shouldn't try to read it as a text file, because ZIP files are not text files, they are always binary files.

By the way, if you're using IOUtils, why not use its copy methods? Because there is another issue with your second code snippet that the first one didn't have. You create a byte[] of size BUFFER_SIZE. That's a byte array with all 0 bytes. You then read into it. There are three possibilities:
1) The file size is exactly BUFFER_SIZE. Everything will work just fine.
2) The file size is larger than BUFFER_SIZE. The output file will only contain the first BUFFER_SIZE bytes.
3) The file size is smaller than BUFFER_SIZE. The output file will have a size of exactly BUFFER_SIZE bytes - each byte after the file size will be the 0 they started out as, and those are also written to the file.