Поврежденная строка Gzip из-за кодировки символов - PullRequest
1 голос
/ 05 мая 2011

У меня есть поврежденные файлы журнала Gzip, которые я пытаюсь восстановить. Файлы были переданы на наши серверы через веб-страницу с поддержкой Java. Файлы всегда отправлялись в виде простого текста, но недавно мы начали получать файлы журнала, которые были разархивированы. Похоже, что эти сжатые файлы повреждены, их нельзя распаковать, а оригиналы были удалены. Я считаю, что это из кодировки символов в методе ниже.

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

Спасибо за любую помощь, которую вы можете оказать!

 private String convertStreamToString(InputStream is) throws IOException {
    /*
     * To convert the InputStream to String we use the
     * Reader.read(char[] buffer) method. We iterate until the
     * Reader return -1 which means there's no more data to
     * read. We use the StringWriter class to produce the string.
     */
    if (is != null) {
        Writer writer = new StringWriter();

        char[] buffer = new char[1024];
        try {
            Reader reader = new BufferedReader(
                    new InputStreamReader(is, "UTF-8"));
            int n;
            while ((n = reader.read(buffer)) != -1) {
                writer.write(buffer, 0, n);
            }
        } finally {
            is.close();
        }
        return writer.toString();
    } else {
        return "";
    }
}

Ответы [ 2 ]

2 голосов
/ 05 мая 2011

Если у вас есть такой код, вы никогда не должны были конвертировать его в Reader (или фактически в String).Только сохранение в виде потока (или байтового массива) позволит избежать повреждения двоичных файлов.И как только он будет прочитан в строку .... недопустимые последовательности (а в utf-8 их много) будут отброшены.

Так что нет, если вам не повезло, нет способа восстановить информацию,Вам нужно будет предоставить другой процесс, в котором вы обрабатываете чистый поток и вставляете в виде чистого BLOB, а не CLOB

2 голосов
/ 05 мая 2011

Если это метод, который использовался для преобразования InputStream в String, то ваши данные почти наверняка потеряны.

Проблема в том, что в UTF-8 имеется довольно много байтовых последовательностей, которые просто не разрешены (то есть они не представляют никакого значения). Эти последовательности будут заменены символом замены Unicode.

Этот символ один и тот же независимо от того, какая неверная последовательность байтов была декодирована. Поэтому конкретная информация в этих байтах теряется.

...