SQLite3是否压缩数据？游戏.db存档Blob异常数据排查求助

问题数据对比 #

预期的明文十六进制内容：

2f 47 61 6d 65 2f 4d 61 70 73 2f 4c 65 76 65 6c 30 31
2f 4c 65 76 65 6c 30 31
5f 4d 61 69 6e 2e
4c 65 76 65 6c 30 31 5f 4d 61 69 6e
3a 50 65 72 73 69 73 74 65 6e 74
4c 65 76 65 6c

存档Blob中实际存储的十六进制内容：

2f 47 61 6d 65 2f 4d 61 70 73 2f 4c 65 76 65 6c 30 31
08 20 68
5f 4d 61 69 6e 2e
0d 20 b1
3a 50 65 72 73 69 73 74 65 6e 74
17 20 a0

核心结论：大概率是游戏自定义的字符串复用机制，而非SQLite3自带压缩 #

1. 排除SQLite3自带压缩的可能
   SQLite本身没有默认的Blob压缩功能，即便使用第三方压缩扩展，也需要显式配置压缩/解压逻辑，且DB Browser默认不会自动识别这类扩展的压缩格式，因此可以排除是SQLite层面的压缩行为。

2. 游戏自定义机制的关键证据
   从数据对比能明显看到规律：被替换的都是重复或关联的字符串（比如2f 4c 65 76 65 6c 30 31、4c 65 76 65 6c 30 31 5f 4d 61 69 6e这类和关卡/地图相关的固定路径名），替换后的3字节十六进制值更像是字符串池索引——游戏将频繁出现的字符串存入全局字典，用短编码指代，读取时再从字典中还原对应内容，以此减少存档体积。

排查验证方法 #

• 检查存档中的字典存储：查看.db文件中是否有额外的表或Blob字段，存储了字符串列表，编码值可能对应列表的索引位置。
• 多存档对比：找同游戏的不同存档，观察相同字符串是否被替换为相同的编码值，若一致则可确认是字符串池机制。
• 逆向游戏逻辑：如果能获取游戏的存档读取代码（或通过逆向工具分析），直接定位Blob解码函数，就能明确具体的编码规则。
• 验证DB Browser的读取逻辑：DB Browser能正常显示明文，说明它要么兼容了该游戏的自定义编码（比如部分引擎的存档格式被DB Browser内置支持），要么编码逻辑是简单的字典映射，被DB Browser自动识别。

内容的提问来源于stack exchange，提问作者Kazzit