Неожиданные результаты Java GZIPOutputStream - PullRequest
Новая
       62

Неожиданные результаты Java GZIPOutputStream

0 голосов
/ 12 марта 2019

У нас есть следующий метод Java для сжатия файлов с использованием GZIPOutputStream 

 private void archive(Path originalFile) {
    Path tempFile = originalFile.resolveSibling(originalFile.toFile().getName() + TEMPORARY_FILE_EXTENSION);
    Path gzippedFile = originalFile.resolveSibling(originalFile.toFile().getName() + ARCHIVED_FILE_EXTENSION);
    try {
        try (FileInputStream input = new FileInputStream(originalFile.toFile());
            BufferedOutputStream output = new BufferedOutputStream(new GZIPOutputStream(new FileOutputStream(tempFile.toFile())))) {
            IOUtils.copy(input,output);
            output.flush();
        }
        Files.move(tempFile, gzippedFile, StandardCopyOption.REPLACE_EXISTING);
        Files.delete(originalFile);
        LOGGER.info("Archived file {} to {}", originalFile, gzippedFile);
    } catch (IOException e) {
        LOGGER.error("Could not archive file {}: " + e.getMessage(), originalFile, e);
    }
    try {
        Files.deleteIfExists(tempFile);
    } catch (IOException e) {
        LOGGER.error("Could not delete temporary file {}: " + e.getMessage(), tempFile, e);
    }
}

Проблема в том, что если мы вручную распаковываем обратно файл: 

gzip -d file_name

Полученная распакованнаяфайл не соответствует исходному файлу. Размер файла и общее количество строк уменьшены.Например, от 33 МБ до 32 МБ с потерей линий 800 КБ.

Может ли проблема быть связана с кодированием ( EBCDIC ) файлов, которые мы сжимаем?https://en.wikipedia.org/wiki/EBCDIC

1 Ответ

0 голосов
/ 13 марта 2019

После нескольких тестов мы не смогли воспроизвести проблему, она, вероятно, была связана с , не имеющим достаточно места на томе во время сжатия. @SirFartALot спасибо за указание на это.

...