我有一个 ASCII 编码的文本文件，其中每行具有以下结构：
XYplorer nn.nn.nnnn [yyyy-mm-dd hh.mm.ss] [S256 S256].zip
↑↑ ↑↑ ↑↑↑↑ ↑↑↑↑ ↑↑ ↑↑ ↑↑ ↑↑ ↑↑ ↑64× ↑64×
因此一行有 177 个字符，其中 27 个字符不变，其他 150 个字符会变，两个哈希值共计 128 个这样的字符。我还假设哈希值基本上是随机文本，因此很难压缩，因此
27/177 = 15.3%固定文本
22/177 = 12.4%改变文本
128/177 = 72.3%随机文本
然而，在 Windows 上以标准方式（右键单击）压缩此类文件（1854 行）我实现了 49% 的压缩率，这让我感到困惑，因为它似乎太高/太高效了。
你能向我解释一下随机部分如何被压缩这么多吗？
答案1
这里的关键元素是这是一个 ascii 编码的文件。
因此，每个字符使用 8 位进行编码。每行 177 × 8 = 1416 位。但是 177 个字符不包括行尾，在 Windows 中，行尾被编码为“\r\n”（回车符，换行符），因此每行将使用 179 个字符，即每行 1432 位。
您的 SHA256 各有 64 个十六进制数字。十六进制数字可以轻易压缩为仅使用 4 位（2^4 = 16），即大小的一半。
让我们分解一下：
- （27+2）/179 = 16.2％固定文本（假设无限可压缩）
- 22/179 = 12.3% 修改文本
- 128/179 = 71.5％的文本可以使用％50大小进行编码。
仅使用该映射，我得到 128/2 + 22 = 86 字节或 688 位。
- 688/1432 = 原始大小的 48％。
这没有考虑到对变化的文本执行的任何额外压缩，它们看起来通常是 ascii 数字，遭受与 ascii 十六进制数字相同的打包损失。
说实话，我很惊讶 Windows 压缩包没有做得更好。