标签: compression

我见过一些高度压缩的文件，比如 700MB 的数据压缩到 30-50MB 左右。

但是你如何获得这样的压缩文件呢？我曾尝试使用 WinRAR 和 7Zip 等软件，但从未实现过如此高的压缩率。

有哪些技术/软件可以让您如此出色地压缩文件？

（PS 我使用的是 Windows XP）

所以，我今天意识到我认为文件压缩是理所当然的。能够将几个文件捆绑在一起，并使其比任何一个文件都小，这是我接受的事实，但它实际上是如何工作的？

我对它的了解有限，包括用指针替换所有重复条目，以这种方式缩小，但除此之外我相当无能为力！

因为我总是对新知识持开放态度，正如我想象我们这里的大多数人一样，我想我会问。那么，超级用户，压缩实际上是如何工作的？

使用 7Z 和普通 ZIP 压缩，一个 398MB 的目录仅被压缩到 393MB。这是正常的吗？如果是这样，为什么人们继续在 Windows 上使用 ZIP？

在 Windows XP 上执行磁盘清理时是否应该选中“压缩旧文件”选项？优缺点都有什么？

同样，本地磁盘属性窗口中还有另一个选项：“压缩驱动器以节省磁盘空间”。检查它是否也合理？

我有数百个类似的大文件（每个 30 兆字节）要压缩。每对文件都有 99% 的相同数据（差异小于 1%），所以我希望存档不超过 40-50 兆字节。

单个文件可以从 30 MB 压缩到 13-15 MB（使用xz -1, gz -1, bzip2 -1），但是在压缩两个或更多文件时，我希望存档的大小为13-15MB + N*0.3MBN 是文件数。

当使用tar（创建实体存档）和xz -6（定义压缩字典大于一个文件 -更新 - 这还不够！）时，我仍然有大小为N*13MB.

我认为无论是gzip和bzip2不会帮助我，因为他们有字典小于1 MB，和我的焦油物流有重复，每30 MB。

如何使用标准工具在现代 Linux 中归档我的问题？

是否可以调整xz以快速压缩，但使用大于 30-60 MB 的字典？

更新：用tar c input_directory | xz --lzma2=dict=128M,mode=fast,mf=hc4 --memory=2G > compressed.tar.xz. 不确定必要的mf=hc4和--memory=2G选项；但是dict=128M将字典设置得足够大（大于一个文件），mode=fast并使该过程比-e.

我在Trisquel GNU/Linux上使用GNU Icecat（Mozilla Firefox 的 GNU 版本）。为了在网上冲浪时最小化/优化数据使用，我想使用谷歌的数据压缩代理。

那么，如何在 Firefox 上使用 Google 数据压缩代理？

^{注意/历史：我四处游荡以解决我的问题。The Answer把我带到一个聊天室，在那里我终于找到了方法。}

我想压缩一个 MP3 文件，我在搜索谷歌时看到了很多参考资料，但现在看来一定有人找到了一些简单的东西，并且保证可以工作。

将 MP3 文件压缩为 ZIP 存档文件并不能充分压缩文件，但我也担心音频质量损失太多。

这有什么经验？

我的 SSD 磁盘空间不足，我看到建议使用“压缩您的操作系统驱动器”来节省一些磁盘空间。

我的问题：

1. 我不确定压缩操作系统驱动器是否有任何性能损失。
2. 而且我什至不确定此选项是否与 C 驱动器属性中的“压缩此驱动器以节省磁盘空间”相同，如下所示。此选项似乎会带来性能损失。

编辑：

我的电脑信息：

1. 视窗 10
2. 12GB 内存
3. 4 核 Intel i7

在 Finder 中，我注意到如果我复制了一些 .app 文件（在 Applications 文件夹中），Finder 将显示复制的 .app 文件与原始文件的大小不同。我复制的所有 .app 文件都不会出现这种文件大小差异，但似乎 .app 文件越大，副本显示的大小与原始文件不同的可能性就越大。这里有些例子：

GarageBand.app - 381.7 MB
GarageBand copy.app - 373.2 MB

iMovie.app - 695.3 MB
iMovie copy.app - 635.4 MB

Install Xcode.app - 1.81 GB
Install Xcode copy.app - 1.57 GB

现在我是 Mac 新手，在我注意到这个文件大小差异问题后，我发现 .app 文件实际上不是文件 - 它们实际上是目录，但 Finder 将它们显示为文件。所以我想也许复制过程没有复制原始 .app 目录的所有内容，这解释了“文件大小”的差异。但是后来我下载并安装了 DeltaWalker，这是一个文件/文件夹差异工具，DeltaWalker 说重复的 .app 目录与原始 .app 目录完全相同。因此复制过程运行良好，因此似乎是 Finder 报告文件大小的问题。

我还使用“du”命令检查了终端中目录的大小，这也显示了原始目录和重复目录之间的大小差异：

du -k /Applications/GarageBand.app/
212868  /Applications/GarageBand.app/

du -k /Applications/GarageBand\ copy.app/
397880  /Applications/GarageBand copy.app/

du -k /Applications/iMovie.app/
629644  /Applications/iMovie.app/ …

看起来，Windows 以尽可能低的压缩率压缩 NTFS 压缩文件夹。虽然这可能有利于提高速度和降低 CPU 负载，但对于很少访问的文件（备份文件夹），有可能提高压缩率会更明智。是否可以调整一些参数来实现这一点？