C++ ZLib gZip压缩生成损坏的结果

我尝试使用以下代码从xml生成gzip压缩文件：

stream.next_in = inbuf; 
   stream.avail_in = 0; 
   stream.next_out = outbuf; 
   stream.avail_out = myBufferSize; 

   int infile_remaining = inFileSize; 

   if (deflateInit2(&stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, windowsBits  + 16, 9, Z_DEFAULT_STRATEGY) != Z_OK)
   {
      return 0;
    }

   for ( ; ; ) 
   { 
      int status; 
      if (!stream.avail_in) 
      { 
         int n = min(BUFFER_SIZE, infile_remaining); 
         if (MyFileReadFunc(pInfile, inbuf, n) != n) 
         { 
            deflateEnd(&stream);
            return -1;
         } 

         stream.next_in = inbuf; 
         stream.avail_in = n; 
         infile_remaining -= n; 
      } 

      status = deflate(&stream, infile_remaining ? Z_NO_FLUSH : Z_FINISH);
      if ((status == Z_STREAM_END) || (!stream.avail_out)) 
      { 
         int w = myBufferSize - stream.avail_out; 
         if (MyFileWriteFunc(pOutfile, outbuf, w) != w) 
         { 
            deflateEnd(&stream);
            return -1;
         } 

         stream.next_out = outbuf; 
         stream.avail_out = myBufferSize;
      }

      if (status == Z_STREAM_END) 
         break; 
      else if (status != Z_OK) 
      { 
         deflateEnd(&stream);
         return 0;
      } 
   }

   if (deflateEnd(&stream) != Z_OK) 
   { 
      return 0; 
   } 

我测试的输入xml文件是2kb，结果似乎总是损坏的。

---

注意：当我从文件中删除一些数据时，它似乎起作用（然后我在不同的输入文件上测试了它，得到了相同的结果）。

首先，不使用

int readed

和

int writed

，也不设置

n

和

w

。也许你的意思是

intn

和

intw

---

其次，

else if（status！=Z_OK）

过于严格。您还可能得到一个

Z_BUF_错误

，您应该继续，而不是出错

Z_BUF_ERROR

并不是一个真正的错误，它只是一个警告，说明上次通话没有取得任何进展。您可以从那里继续，提供更多的输入和/或输出空间

---

其他要点：您可能不想对每个缓冲区使用

Z_SYNC\u FLUSH

。这会不必要地降低压缩，除非您有理由插入同步标记。只需使用

Z\u NO\u FLUSH

。此外，9的

memLevel

可能会减少压缩。你应该用你的数据做实验。通常情况下，8（默认值）效果更好。

首先，不使用

int readed

和

int writed

，也不设置

n

和

w

。也许你的意思是

intn

和

intw

---

其次，

else if（status！=Z_OK）

过于严格。您还可能得到一个

Z_BUF_错误

，您应该继续，而不是出错

Z_BUF_ERROR

并不是一个真正的错误，它只是一个警告，说明上次通话没有取得任何进展。您可以从那里继续，提供更多的输入和/或输出空间

---

其他要点：您可能不想对每个缓冲区使用

Z_SYNC\u FLUSH

。这会不必要地降低压缩，除非您有理由插入同步标记。只需使用

Z\u NO\u FLUSH

。此外，9的

memLevel

可能会减少压缩。你应该用你的数据做实验。通常情况下，8（默认值）工作得更好。

是的，我更新了样本中的读写变量。问题是任何调用都没有返回错误，但生成的文件已损坏。您使用的是哪种系统？代码的其余部分在哪里？文件读写是否使用二进制模式？“无进展”也可能意味着未压缩的数据是输出缓冲区大小的精确倍数（例如1024字节）。在这种情况下，尝试解压缩最后的字节（同步标记）不会产生任何数据。但这不是问题，因为您已经获得了所有字节！解压器应该意识到这一点，不要因为错误而崩溃。

Z_BUF_错误

不是错误。它的名字错了。这只是一个警告，得到警告后，解压操作总是可以继续进行的。问题是任何调用都没有返回错误，但生成的文件已损坏。您使用的是哪种系统？代码的其余部分在哪里？文件读写是否使用二进制模式？“无进展”也可能意味着未压缩的数据是输出缓冲区大小的精确倍数（例如1024字节）。在这种情况下，尝试解压缩最后的字节（同步标记）不会产生任何数据。但这不是问题，因为您已经获得了所有字节！解压器应该意识到这一点，不要因为错误而崩溃。

Z_BUF_错误

不是错误。它的名字错了。这只是一个警告，得到警告后，解压操作始终可以继续。