Блог

Хорошо это или плохо, я без проблем использую код, подобный следующему:

 ZipFile aZipFile = new ZipFile(fileName);   
InputStream zipInput = aZipFile.getInputStream(name);  
int theSize = zipInput.available();  
byte[] content = new byte[theSize];  
zipInput.read(content, 0, theSize);
 

Я использовал это (эта логика получения доступного размера и чтения непосредственно в байтовый буфер)
для File ввода-вывода без каких-либо проблем, и я также использовал его с zip-файлами.

Но недавно я столкнулся с тем, что zipInput.read(content, 0, theSize); фактически считывается на 3 байта меньше, чем theSize доступно.

И поскольку код не находится в цикле для проверки длины, возвращаемой zipInput.read(content, 0, theSize); I, я прочитал файл с пропущенными 3 последними байтами
, и позже программа не может функционировать должным образом (файл является двоичным файлом).).

Как ни странно, с разными zip-файлами большего размера, например, 1075 байт (в моем случае проблемная zip-запись составляет 867 байт), код работает нормально!

Я понимаю, что логика кода, вероятно, не самая «лучшая», но почему у меня вдруг возникла эта проблема сейчас?

И почему, если я немедленно запускаю программу с большей zip-записью, она работает?

Любой ввод приветствуется

Спасибо

Из InputStream read документов API:

Предпринимается попытка прочитать столько байтов, сколько len, но может быть прочитано меньшее число.

… и:

Возвращает: общее количество байтов, считанных в буфер, или -1, если данных больше нет, поскольку достигнут конец потока.

Другими словами, если метод read не возвращает -1, для чтения доступно еще больше данных, но вы не можете гарантировать, что read они будут считывать точно указанное количество байтов. Указанное количество байтов является верхней границей, описывающей максимальный объем данных, которые он будет считывать.

Использование available() не гарантирует, что оно подсчитало общее количество доступных байтов для end of stream .
Обратитесь к методу Java InputStream . available() В нем говорится, что

Возвращает оценку количества байтов, которые могут быть прочитаны (или пропущены) из этого входного потока без блокировки при следующем вызове метода для этого входного потока. Следующий вызов может быть тем же потоком или другим потоком. Одно чтение или пропуск такого количества байтов не блокируется, но может считывать или пропускать меньше байтов.

Обратите внимание, что, хотя некоторые реализации InputStream будут возвращать общее количество байтов в потоке, многие этого не сделают. Неверно использовать возвращаемое значение этого метода для выделения буфера, предназначенного для хранения всех данных в этом потоке.

Пример решения вашей проблемы может быть следующим:

 ZipFile aZipFile = new ZipFile(fileName);   
InputStream zipInput = aZipFile.getInputStream( caImport );  
int available = zipInput.available();  
byte[] contentBytes = new byte[ available ];  
while ( available != 0 )   
{   
    zipInput.read( contentBytes );   
    // here, do what ever you want  
    available = dis.available();  
} // while available  
...   
 

Это точно работает для всех размеров входных файлов.

Лучший способ сделать это должен быть следующим:

 public static byte[] readZipFileToByteArray(ZipFile zipFile, ZipEntry entry)
    throws IOException {
    InputStream in = null;
    try {
        in = zipFile.getInputStream(entry);
        return IOUtils.toByteArray(in);
    } finally {
        IOUtils.closeQuietly(in);
    }
}
 

где IOUtils.Метод toByteArray (in) продолжает чтение до EOF, а затем возвращает массив байтов.