我目前正在学习 C，并且在尝试制作一个利用 zlib 的小程序时遇到了一些问题。
我已经成功地使用 zlib 库编译了我的应用程序（使用 Codeblocks/MinGW），并且编译工作正常。我使用的示例基于在官方 zlib 站点 (zlib.net) 上找到的zpipe.c示例。
执行时，会创建输出 zip 文件，但它似乎格式错误和/或为空。我无法使用 7zip 打开它。
这是我修改过的代码。我只是替换了 zpipe.c 中的 main() 函数。
int main() {
printf("Compression test...");
int ret;
FILE *fpsource;
FILE *fpdest;
fpsource = fopen("test.txt", "rb");
fpdest = fopen("output.zip", "wb");
ret = def(fpsource, fpdest, Z_DEFAULT_COMPRESSION);
if (ret != Z_OK) {
printf("failure\n");
zerr(ret);
}
else {
printf("success..\n");
}
fclose(fpsource);
fclose(fpdest);
return EXIT_SUCCESS;
}
我没有收到任何错误，并且打印了我的“成功”消息。只是输出文件已损坏。
我正在尝试使用使用静态/预设字典gzip的 DEFLATE 算法编码的数据创建有效的 gzip 文件（可以使用标准 linux 解压缩） 。
我已经阅读了DEFLATE和gzip的规范，看起来这是不可能的。正如我从 DEFLATE 规范中得到的，压缩数据块有两种编码类型：
FDICT标志设置为 的标头开头0。FDICT = 1但我发现没有办法实际将这样的字典写入文件。是否可以在我的字典中添加一些标头，或者以其他方式使 gzip 解压缩用 编码的数据FDICT = 1？
PS 我正在尝试使用 Java 的Deflate类来完成它，但对以这种方式压缩的块的实际 gzip 支持感兴趣。
我广泛使用 zlib 来存储压缩数据。在读取数据时，大部分时间都花在了 inflate_fast 和 crc32 zlib 调用上。我正在探索加速解压的替代方案，有两个候选方案，来自 Intel 的 ipp_zlib 和来自 CloudFlare 的 zlib fork。我想知道：
CloudFlare fork 是否仅针对 AMD 处理器进行了调整？我看到相关分支在https://github.com/cloudflare/zlib/branches上标有“amd64” 。我有 Intel CPU，所以 amd64 无法达到目的。
我是否需要重写数据才能使用CloudFlare版本？如果是，那么我将不得不忽略这个库。
我尝试为我的 Linux 机器获取这两个库，但没有看到简单的方法，即下载链接。如果有人在上面安装过，请分享下载和构建的说明。
当 Git 存储文件的快照时，它会存储一个称为 blob 的对象。
这是使用 zlib 压缩的。请参阅http://nfarina.com/post/9868516270/git-is-simler；要么我是瞎子，要么他没有解释文件 blob 是如何在第一处解压缩的（而其他所有内容都像向菜鸟一样解释）
我们如何提取它并查看 blob 的内容？谷歌搜索的大部分结果适用于脚本/程序中的解压缩，而不是手动/CL：
Deflate 命令行工具， https://unix.stackexchange.com/q/22834
我一直在寻找一种单行命令行方法来在单个文件上执行此操作。
提前致谢！
（即使这个问题听起来像是重复的，但另一个链接中的一系列答案并不像这里的答案那么准确。我认为这个线程应该保持活跃，或者将这个答案发布在那里，以帮助其他人解决不复杂的问题泄气的方法）
我目前正在编写一个 C 程序，该程序从另一个生成的数据文件构建 PNG 图像。该图像是调色板类型。
Adler-32 校验和是根据未压缩数据计算得出的吗？
a) IDAT 数据块中的每个压缩块？
b) IDAT 数据块中的所有压缩块？
c) 跨越所有 IDAT 数据块的所有压缩块？
从http://www.w3.org/TR/PNG/、https://www.rfc-editor.org/rfc/rfc1950和 rfc1951 （与之前的地址相同）的文档中，我认为这是上面的情况“c”，允许 deflate 实现切割和更改每个块的数据压缩方式，并忽略压缩块在连续 IDAT 块之间的分割方式。
它是否正确？
我需要解压缩一个用 zlib 压缩的 git 对象。尽管该对象是用 zlib 压缩的，但它没有标头（我猜是为了节省带宽）。所以我试图在对象字节的顶部添加标头，但由于某些原因，zlib 仍然抱怨标头无效。我怀疑标题字节是作为字符串文字而不是字节添加的，但我不确定。请参阅下面的代码。
package main
import(
"compress/zlib"
"io/ioutil"
"bytes"
"fmt"
// "strings"
)
func main(){
b, err := ioutil.ReadFile("raw")
if err !=nil{
panic(err)
}
const header = "\x1f\x8b\x08\x00\x00\x00\x00\x00"
buf := bytes.NewBuffer(nil)
if _, err := buf.WriteString(header); err !=nil{
panic(err)
}
if _, err := buf.Write(b); err !=nil{
panic(err)
}
r, err := zlib.NewReader(buf)
if err !=nil{
panic(err)
}
defer r.Close()
var db []byte
if _, err := r.Read(db); err !=nil{
panic(err)
}
fmt.Printf("%s", db)
} …我正在尝试在 Python 中使用zlib中的crc32_combine函数。尽管可以使用各种其他 zlib 函数，但该函数不是“包含电池”标准库的一部分。我尝试了两种方法：从 C 代码到 Python 的端口和从 Python 调用 zlib 与 ctypes。两者都给了我不同的结果，尽管不是我期望的结果。我正在展示 ctypes 代码，因为我认为它执行得更快，并且出现其他程序员错误的可能性更小。
当提供第二个散列的数据长度时，该算法可以组合两个CRC32散列。crc32_combine定义如下：
crc32(crc32(0, seq1, len1), seq2, len2) == crc32_combine(
crc32(0, seq1, len1), crc32(0, seq2, len2), len2)
这是输出：
Expected CRC: 45E57586
Combined CRC: 567EE4E4
在 win32 上使用 Python 3.5.1 运行时，第二行总是不同的。不是 Python 2，但结果也不是我所期望的。将zlib1.dll放在与脚本相同的目录中进行尝试。
import zlib
def crc32_combine_ctypes(crc1, crc2, len2):
import ctypes
from ctypes import util
lib = util.find_library('zlib1')
_zlib = ctypes.CDLL(lib)
assert _zlib._name, "Can't find zlib"
_zlib.crc32_combine.argtypes …我在 Delphi 中使用 ZLib 单元解压时遇到了一个小问题
unit uZCompression;
interface
uses
uCompression;
type
TZZipCompression = class(TInterfacedObject, ICompression)
public
function DoCompression(aContent: TArray<Byte>): TArray<Byte>;
function DoDecompression(aContent: TArray<Byte>): TArray<Byte>;
function GetWindowsBits: Integer; virtual;
end;
TZGZipCompression = class(TZZipCompression)
function GetWindowsBits: Integer; override;
end;
implementation
uses
System.ZLib, System.Classes, uMxKxUtils;
{ TZCompression }
function TZZipCompression.DoCompression(aContent: TArray<Byte>): TArray<Byte>;
var
LContentStream, LOutputStream: TMemoryStream;
LCompressedStream: TZCompressionStream;
begin
LContentStream := ByteArrayToStream(aContent);
LOutputStream := TMemoryStream.Create;
LCompressedStream := TZCompressionStream.Create(LOutputStream, zcDefault, GetWindowsBits);
LCompressedStream.CopyFrom(LContentStream, LContentStream.Size);
LCompressedStream.Free;
Result := StreamToByteArray(LOutputStream);
LOutputStream.Free;
LContentStream.Free;
end;
function TZZipCompression.DoDecompression(aContent: TArray<Byte>): TArray<Byte>; …我对 zlib 数据格式很好奇，并试图理解 RFC1950 中描述的 zlib 标头（https://tools.ietf.org/html/rfc1950 ) 中。然而，我对这种低级解释很陌生，似乎与我的一些结论相冲突。
我有以下压缩数据（来自 PDF 流对象）：
b'h\xdebbd\x10`b`Rcb`\xb0ab`\xdc\x0b\xa4\x93\x98\x18\xfe>\x06\xb2\xed\x01\x02\x0c\x00!\xa4\x03\xc4'
在python中，我已经成功解压并重新压缩了数据：
b'x\xdacbd\x10`b`Rcb`\xb0ab`\xdc\x0b\xa4\x93\x98\x18\xfe>\x06\xb2\xed\x01!\xa4\x03\xc4'
正如我所了解的Deflate 和 inflate for PDF 中的讨论/答案，使用 zlib C++ 压缩数据的结果差异应该无关紧要，因为它是不同应用方法压缩数据的影响。
假设最后四个字节!\xa4\x03\xc4是 ADLER32（Adler-32 校验和），我的问题与前 2 个字节有关。
0 1 0 1 2 3 0 1 2 3
+---+---+ +---+---+---+---+ +=====================+ +---+---+---+---+
|CMF|FLG| | [DICTID] | |...compressed data...| | ADLER32 |
+---+---+ +---+---+---+---+ +=====================+ +---+---+---+---+
第一个字节代表 CMF，在我的两个实例中是
chr h = dec 104 = hex 68 = 01101000chr x = dec …我正在尝试在 Ruby 和 Python 中为相同的字符串生成 CRC32 校验和并获得不同的结果。
Python
from zlib import crc32
x = "SheetJS"
crc32(x)
#=> -1647298270
节点
var CRC32 = require('crc-32');
var x = "SheetJS";
CRC32.str(x);
#=> -1647298270
红宝石
require 'zlib'
x = "SheetJS"
Zlib::crc32(x)
#=> 2647669026