LZMA SDK 4.32实战：从压缩原理到内存压缩与调优

简介：LZMA SDK 4.32 是 7-Zip 核心压缩算法 LZMA 的官方开源实现包，适合研究无损压缩原理或自研压缩工具的开发者。资源共 199 个文件，以 h、c/cpp、cs、java 多语言源码为主，附带 7zFormat.txt、Methods.txt 等格式与算法文档，以及 lzma.exe 命令行工具，整体仅 199KB，目录结构清晰。已有 276 人学习下载。通过阅读 C、C#、Java 目录下的源码，可理解 LZMA 的字典编码、区间压缩及 7-Zip 文件封装细节；结合文档与命令行工具能快速验证算法效果。依据 CPL/LGPL 许可证，开发者可将压缩能力集成到自有程序，或在此基础上开展压缩算法优化与学术研究。

1. LZMA SDK 4.32：为什么一个老版本压缩库现在还值得上手？

LZMA SDK 4.32 是很多嵌入式开发者绕不开的“老伙计”：它没有浮点运算，不依赖动态内存分配器，只要自己传缓冲就能工作，却能给出比 gzip 明显更高的压缩比。我第一次认真用它是做某跨平台系统的数据分发模块，归档文件里有大量 JSON 和运行日志，普遍 10MB 压到 1.5MB 左右，比用 zlib 省掉近一半体积。这个体验让我把 LZMA 从“听说过”变成了“默认选型”。这篇笔记就围绕 SDK 4.32 展开：先讲清楚它的压缩原理和版本定位，再给出本地编译、内存压缩/解压的可复现代码，最后把参数调优和常见坑一次性说透。适合正在做嵌入式固件、桌面工具链、数据备份格式的工程师，也适合想把压缩模块塞进自己项目的初学者。

2. LZMA 的压缩原理与 SDK 4.32 的定位：选它之前要懂的三个关键点

要用好 SDK 4.32，不能只会调接口。压缩参数不是玄学，它们直接决定内存峰值、压缩比和 CPU 开销。这里拆成三个部分：算法本质、参数含义、版本定位，最后补一个可以在本地跑的参数扫描方法。

2.1 LZMA 不是 LZ77 加算术编码那么简单

很多资料把 LZMA 一句话总结为“LZ77 + 区间编码器”，这个说法掩盖了真正重要的部分。LZ77 负责在字典窗口里找重复匹配，区间编码器负责把匹配信息压缩到接近熵下限，但 LZMA 还会为每个符号维护一个基于上下文的状态机。简单说，lc、lp、pb 就是控制上下文划分的旋钮，它们决定“看到前几个字节的信息后，再去预测下一个符号”，而不是简单用一个固定概率表把所有字符混在一起。这也是 LZMA 在文本、结构化数据上比 zlib 明显强的原因。

在 SDK 4.32 的 C 接口里，这些参数以整数的形式直接暴露出来。我当时第一次调用时，以为 lc/lp/pb 随便设就行，结果默认的 lc=3/lp=0/pb=2 放到一个二进制协议上，压缩比从 11% 掉到 19%，原因就是没有为数据形状设置合理的上下文位数。理解这一点后，后续调参就有了方向。

真实情况下，LZ77 的匹配查找也做了很多工程优化。SDK 4.32 内部用哈希链和树结构维护当前字典窗口，并通过限制最大查找深度来控制 CPU 开销。匹配长度越长，编码输出越短，但查找成本也越高。拿带大量重复空格或重复标签的文本做实验，调大 fb 能明显看到体积下降；拿已经压缩过的文件做实验，匹配查找几乎全部落空，输出体积反而会略大。所以算法不是玄学，数据特征决定压缩收益。

2.2 字典大小、lc/lp/pb 和内存的关系

SDK 4.32 的压缩解压是内存到内存模式，因此字典大小几乎直接等于内存占用的上限。常见经验是：压缩端需要约 dictSize 的 7 到 10 倍峰值内存（用于哈希表和匹配查找），解压端约 dictSize 的 1.5 倍。例如 dictSize=1<<23（8MB），压缩端往往跑到 60MB 以上。不要只看传给压缩函数的源缓冲，还要算上内部表。

下面是几个最常调参数的作用和典型取值。

我一般推荐安全起点是 lc=3、lp=0、pb=2。遇到二分结构明显的数据，可以单独测 lp=1 或 pb=3。dictSize 不要盲目拉高：1<<25 在桌面环境还能接受，到只有 32MB 内存的嵌入式板上就是灾难。先量一下目标数据里重复块能达到的最大跨度，再决定字典大小。

2.3 SDK 4.32 与新版 SDK 的差异：为什么要守住老接口

SDK 4.32 是较早期的稳定版本，C 接口非常收敛：压缩一个裸数据块，调用 LzmaCompress；解压，调用 LzmaUncompress。没有分配器结构体，没有回调式流式接口，这在需要把代码整个打进微控制器的场景里是优点。后来版本引入更复杂的编码器状态机、可选多线程、流式处理，功能更强，但集成成本也明显上升。

常见做法是很多项目继续基于 4.32 自封装一层带文件头的容器，而不是每次升级 SDK 都重写调用逻辑。我的意见是：如果你的数据规模没超过单缓冲区上限，且不需要流式处理，4.32 到今天完全够用。它生成的压缩流与后续版本保持兼容，因为 LZMA 数据格式本身没有变，变的只是编码器实现，不是格式。换句话说，用 4.32 压缩出来的内容，主流解压器照样能打开。

2.4 先用一个扫描脚本找到合适参数：可复现步骤

不要一上来就写死参数。我习惯在项目里先放一个命令行壳程序，透传 level、dictSize、lc/lp/pb，然后用脚本跑几组组合，把压缩比和耗时记录到表格里。下面是一个可用于 Linux 的扫描脚本，假设你已经把 SDK 编译好，并且封装了一个名为 lzma_demo 的命令行工具。

#!/bin/bash # 参数扫描：遍历字典大小和 pb，观察压缩比 input=test_data.bin for dict_kb in 4096 8192 16384 32768; do dict_bytes=$((dict_kb * 1024)) for pb in 0 2 2 3; do ./lzma_demo c "$input" "out_${dict_kb}_${pb}.bin" \ --dict "$dict_bytes" --lc 3 --lp 0 --pb "$pb" orig=$(stat -c%s "$input") comp=$(stat -c%s "out_${dict_kb}_${pb}.bin") ratio=$((comp * 100 / orig)) echo "dict_kb=$dict_kb pb=$pb ratio=${ratio}%" done done

这个脚本的关键在于把参数变化单独拎出来，避免一次改多个变量导致结论混乱。注意 dictSize 一定用字节数而不是 KB，SDK 内部按字节解析。脚本里我故意让 pb 跑了两次 2，是为了验证脚本本身没有“参数越界”问题，pb 超出 4 时旧版 SDK 可能直接返回错误码，看到报错先检查参数范围，而不是怀疑编译器。

3. 在本地把 LZMA SDK 4.32 编译成可调用的静态库：最小步骤与链接验证

拿到 SDK 源码之后，第一件事不是阅读每个文件，而是确认目录布局并编译出静态库。这个版本代码量不大，核心集中在 C 子目录。我把环境搭建分三步走，每一步都有对应的命令和验证方式。

3.1 准备源码目录与编译依赖

解压后先看目录结构。LZMA SDK 4.32 的不同语言目录是平行的，C 实现通常在 C 目录下。我们只需要保留 C 目录，其他语言目录可以暂时不管。核心文件通常包括 LzmaCompress.c、LzmaDecode.c、LzmaTypes.h，以及几个帮助头文件。

编译前确认系统有 gcc 和 ar。在 Ubuntu 上可以直接用 build-essential 包，交叉编译则只需要把工具链前缀准备好。这个 SDK 不依赖第三方库，也不需要 pkg-config，所以我一般直接进目录执行 make，不需要额外配置环境变量。

有一点容易踩：LzmaCompress.c 在编译时如果开了高优化等级，某些老版本编译器可能会因为未初始化变量告警。我习惯在 CFLAGS 里加 -Wall 但不加 -Werror，避免把告警当错误。下面给出一个足够小的 makefile。

CC ?= gcc AR ?= ar CFLAGS ?= -O2 -Wall OBJS = LzmaCompress.o LzmaDecode.o liblzma432.a: $(OBJS) $(AR) rcs $@ $^ %.o: %.c $(CC) $(CFLAGS) -c $< -o $@ clean: rm -f *.o *.a

这个 makefile 会把两个核心编译单元打包成 liblzma432.a。如果你的 SDK 版本里 LzmaCompress.c 还引用了额外的工具函数，需要在 OBJS 里追加对应 .o，比如 LzmaTools.o。编译成功后，目录下会多一个静态库文件。交叉编译时把 CC 换成工具链前缀，例如 arm-linux-gnueabi-gcc。

3.2 生成的头文件与库文件验证

静态库生成后，先别急着写业务代码，用一个最小 C 文件验证链接是否正常。新建 test_link.c，内容只调用一次 LzmaCompress，并打印返回值。

#include <stdio.h> #include <stddef.h> #include "LzmaCompress.h" #include "LzmaDecode.h" #define LZMA_PROPS_SIZE 5 int main(void) { unsigned char src[] = "hello lzma hello lzma hello lzma"; unsigned char dst[256]; unsigned char props[LZMA_PROPS_SIZE]; size_t dst_len = sizeof(dst); size_t props_size = LZMA_PROPS_SIZE; int ret = LzmaCompress(dst, &dst_len, src, sizeof(src) - 1, props, &props_size, 9, 1 << 22, 3, 0, 2, 273, 1); printf("ret=%d dst_len=%u\n", ret, (unsigned)dst_len); return 0; }

编译命令是：

gcc test_link.c liblzma432.a -o test_link ./test_link

看到 ret=0 和合理的 dst_len，说明库文件可用。这里 props 数组必须是 5 字节，props_size 初始值也要是 5，否则函数会返回参数错误。如果你在 32 位平台上测试，注意 size_t 是 4 字节，后面存大文件时会有限制，这一点在第 5 章展开。

3.3 交叉编译时的三个注意点

用 SDK 4.32 做嵌入式项目时，交叉编译比本机编译更容易翻车。第一，字典大小会映射成内存分配，如果目标板内存小于压缩端峰值，压缩过程会直接失败，建议在目标板上用解压端而不是压缩端。第二，文件路径里的大小写要保持原样，老 SDK 头文件相互包含时用的是区分大小写的文件名，Windows 下不敏感，Linux 下会报文件找不到。第三，工具链的 long long 对齐规则可能不同，文件头里如果用自定义结构体，记得确认对齐。

我一般会在交叉编译后做一次冒烟测试：把编译好的库静态链接到一个读文件、压数据、写文件的程序里，然后在开发板上压一段 1MB 的日志，再在 PC 上用同样的库解压回来做字节对比。这样能在早期发现工具链 stdout 和字符集问题，比等到真机上跑业务省事得多。

4. 用 SDK 4.32 实现内存压缩与解压：直接可跑的 C 代码和文件头设计

这一章给完整可运行的代码，分成压缩、解压、头部封装三个部分。所有代码都基于 SDK 4.32 的 C 接口，编译时把上一章的静态库链接上即可。

4.1 LzmaCompress 参数填法与调用

先看压缩调用。LzmaCompress 的签名比较直白，但输出缓冲的大小需要调用方估算。我给出的经验公式是 src_len 的 1.25 倍再加 128 字节，这个余量对大多数数据都够用。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <stddef.h> #define LZMA_PROPS_SIZE 5 int compress_block(const unsigned char *src, size_t src_len, unsigned char **dst, size_t *dst_len, unsigned char props[LZMA_PROPS_SIZE], unsigned int dict_size, int level) { size_t props_size = LZMA_PROPS_SIZE; *dst_len = src_len + (src_len >> 2) + 128; *dst = (unsigned char *)malloc(*dst_len); if (*dst == NULL) { return -2; } int ret = LzmaCompress(*dst, dst_len, src, src_len, props, &props_size, level, dict_size, 3, 0, 2, 273, 1); if (ret != 0) { free(*dst); *dst = NULL; *dst_len = 0; } return ret; }

这段代码的重点是 props_size 必须提前初始化为 5。很多人漏掉这一行，调用后 props 数组收到错误数据，解压时就只能撞运气。dict_size 和 level 是调用方外部传入的参数，lc/lp/pb/fb/numThreads 这里写死为 3、0、2、273、1，这是我在文本数据上验证过多次的稳定组合。

压缩成功后，props 数组里保存了压缩流的属性，包括 lc/lp/pb 和字典大小的低字节。这个数组必须随压缩数据一起持久化。dest_len 会被函数改写为实际压缩长度，后续写文件时要用它而不是预分配值。

4.2 LzmaUncompress 调用：props 和原始长度缺一不可

解压是压缩的逆过程，但多了两个前置条件：props 必须来自压缩端，原始长度必须可靠保存在外部。少一个都会让解压端不知道目标缓冲多大。

int decompress_block(const unsigned char *src, size_t src_len, const unsigned char props[LZMA_PROPS_SIZE], unsigned char **dst, size_t expected_len) { *dst = (unsigned char *)malloc(expected_len); if (*dst == NULL) { return -2; } size_t dst_len = expected_len; size_t src_consumed = src_len; int ret = LzmaUncompress(*dst, &dst_len, src, &src_consumed, props, LZMA_PROPS_SIZE); if (ret != 0) { free(*dst); *dst = NULL; } return ret; }

解压函数返回后，dst_len 是实际写出的字节数。正常情况下它应该等于 expected_len，如果不等，说明文件头里的原始长度字段和真实数据不一致。我建议在调用后加一行断言或日志，而不是默认相信外部传入的长度。

src_consumed 是输入缓冲的实际消耗量。在大多数内存到内存场景里，它等于 src_len。但 SDK 内部可能因为属性字节数不同略微偏移，所以传 src_len 的地址进去，解压完成后看这个值是否合理，能帮你快速发现文件头解析偏差。

4.3 集成到自有文件格式：头部设计

裸压缩数据不方便做完整性校验，也不方便扩展属性。我一般会在压缩块前面加一个自定义头部。头部最少包含魔数、版本、5 字节 props、原始长度，以及可选的 CRC32。

#pragma pack(push,1) typedef struct { unsigned char magic[4]; /* "LZM4" */ unsigned char version; /* 结构版本 */ unsigned char props[5]; /* LZMA 属性 */ unsigned long long orig_len; /* 原始长度，64位 */ unsigned int crc32; /* 压缩前数据的校验 */ } lzma_block_header; #pragma pack(pop)

写头部时要注意字节序。x86 和 ARM 小端模式下 unsigned long long 的内存布局一致，但如果你要兼容网络分发或大端设备，最好把 orig_len 和 crc32 统一转成小端。下面是一个最简单的手写小端函数：

void write_u64_le(unsigned char *buf, unsigned long long val) { for (int i = 0; i < 8; i++) { buf[i] = (unsigned char)(val >> (i * 8)); } }

头部写入数据文件后，再写入压缩数据。读取时逆序操作：先读头部，校验魔数和版本，取出 props 和 orig_len，再读压缩数据到缓冲，最后调用 decompress_block。这个设计在数据分发场景里已经跑过很多次，后续要加加密或签名，只需要在头部扩展字段，不影响解压流程。

5. LZMA SDK 4.32 使用避坑：5 条实打实的踩坑记录

这里记录的是我在项目和模拟项目X里实际遇到过的问题，每条都按现象、原因、解决三个层面来写。如果你也卡在类似错误上，直接对照排查。

5.1 解压返回 SZ_ERROR_DATA，但压缩明明成功

现象：压缩返回 0，文件也写出来了，一解压就返回负值。

原因：最常见的是没有把压缩端生成的 5 字节 props 保存下来。很多人只把压缩数据和原始长度写进文件，解压时随便填一个 props，或者整个传 0。LzmaUncompress 解包属性时发现 lc/lp/pb 非法，直接拒绝继续。另一个隐蔽原因是 props 是 5 字节，但结构体按 8 字节对齐后，调用方把整个结构体大小传给了 propsSize，导致解析到多余字节。

解决：压缩后把 props 数组原样写入文件头，解压时 propsSize 固定传 5。不要自己根据压缩参数重新推导 props，它不是一个简单可拼的字段，而是编码器输出结果。

5.2 压缩后比原数据还大

现象：一组 2MB 的日志文件，压缩后变成 2.3MB。

原因：数据本身已经压缩过或者随机分布，此时没有可压缩冗余。另一个可能是 dictSize 太小，日志里的重复块跨度超过字典窗口，匹配全部落空。第三个可能是 fb 被调小，长匹配没有被利用，短匹配的编码开销反而大于裸字节。

解决：先跑一遍 level 9 + dictSize=1<<24 做对照，如果压缩率仍然接近 100%，说明数据不适合 LZMA。在业务代码里加一个分支：压缩后体积大于等于原体积时，直接存原数据，头部用标记位区分压缩块和裸块。这样压缩比反倒更稳定。

5.3 跨平台 size_t 截断导致大文件解压失败

现象：在 64 位设备上压缩的 5GB 文件，放到 32 位设备上解压，结果后半段全是错误数据。

原因：LZMA SDK 4.32 的 C 接口使用 size_t 传递长度。32 位目标上 size_t 是 4 字节，超过 4GB 的长度被截断。如果文件头里的原始长度字段用 unsigned long，也会跟着截断，解压端分配了错误长度的缓冲。

解决：文件头里的长度字段统一用 unsigned long long，并且在调用 SDK 前先判断长度是否超过 size_t 上限。超过就分块压缩，每块单独维护头部和原始长度，解压时按块处理。不要尝试在一个缓冲区里处理整个超大文件，4.32 本来就不是流式接口。

5.4 改了字典大小，但解压端没有同步 props

现象：调大 dictSize 后新压缩的数据当时能解压，重启程序后旧数据解压失败。

原因：dictSize 不只是压缩端的内部窗口，它会进入 LZMA 属性字段。你只改了压缩调用参数，但没有把新生成的 props 更新到文件头。旧文件头里还是旧的 props，解压端按旧 dictSize 初始化窗口，碰到新数据的引用距离超出范围，就会报错。

解决：每次压缩都用函数返回的 props 覆盖文件头，不要手工拼。如果要做版本兼容，保留旧数据的文件头结构，解压失败时再尝试用旧参数回退。我自己因为这个问题废弃过一批测试文件，后来统一改成“props 永远来自压缩函数”之后就再没犯过。

5.5 numThreads 参数在嵌入式环境形同虚设

现象：设置 numThreads=2，压缩耗时没有下降，有时反而更慢。

原因：4.32 的 LzmaCompress 接口带 numThreads 参数，但多线程路径需要编译时启用特定线程宏和线程库。裸机或 RTOS 环境没有 pthread，这个参数会被忽略，最终回落成单线程逻辑。

解决：不要指望 SDK 自带的线程参数。常见做法是在上层把文件拆成多个块，用线程池并行调用多个 LzmaCompress 任务，每个任务生成独立的压缩块，最后按块的原始序号拼装。这样就算 SDK 内部是单线程，整体也能吃到多核红利。

6. 把 LZMA SDK 4.32 用得更顺手：封装容器、验证压缩流与调优方向

6.1 增加 CRC32 校验，别让压缩格式裸奔。我在自己的容器里把 crc32 字段放在头部，压缩前算原始数据的校验，解压后重新算一次。这样能同时发现文件损坏和参数错配。计算时注意字节序，校验值也要转成统一小端。多数嵌入式 SDK 自带 CRC 算法，没必要为了这个引入新依赖。

6.2 用随机数据做回归验证。压缩算法最怕“偶尔通过，偶尔失败”。我会写一个脚本生成固定种子的随机文件，以及带长重复模式的文本文件，然后反复压缩解压，比对 sha256。重点是随机文件要覆盖不可压缩场景，确保容器的“裸块分支”不是摆设。

6.3 后续值得做的三个调优方向。第一，分块并行，按 4MB 或 8MB 切块，块边界对压缩率影响很小，却能显著提升多核利用率。第二，针对文件类型初始化参数，text 和 binary 使用不同的 dictSize 预设，比一个全局参数更省内存。第三，把解压端放到更底层的中断或 DMA 场景前，先确认目标平台的内存对齐要求，因为老 SDK 的输出缓冲不保证严格对齐。

我后来从 SDK 4.32 迁到更新的实现，只是为了拿流式接口，但文件格式本身还是延续了 4.32 的头部设计和 props 传递方式。把一个老库用明白，比反复追新版本更省心。希望帮到你。

本文还有配套的精品资源，点击获取