我最近备份了即将过期的大学主目录，将其作为tar流发送到我的终端并进行压缩:ssh user@host "tar cf - my_dir/" | bzip2 > uni_backup.tar.bz2 .
这让我想到:我只知道压缩工作的基本原理，但我可以想象这种压缩数据流的能力会导致更差的压缩，因为算法需要在某一点完成处理数据块，将其写入输出流并继续处理下一个块。
是这样吗?或者这些程序只是简单地把大量的数据读入内存压缩，写入，然后再重复一遍?或者在这些"流压缩器"中使用了什么巧妙的技巧?我看到bzip2和xz的手册页都在讨论内存使用，而且man bzip2还暗示了这样一个事实，即在将要压缩成块的数据切割时几乎没有损失:
较大的块大小使边际收益迅速递减。大部分压缩来自块大小的前两三百k，在小型机器上使用bzip2时，这一点值得牢记。同样重要的是要认识到，解压缩内存需求是在压缩时通过选择块大小来设置的。
我仍然希望听到是否使用了其他技巧，或者我可以在哪里阅读更多关于这一点。
这个问题更多地与缓冲区处理有关，而不是压缩算法，尽管它也有一些可说的。
一些压缩算法本质上是"基于块的"，这意味着它们绝对需要处理特定大小的块。这就是bzip2的情况，它的块大小是通过"level"开关选择的，从100kb到900kb。因此，如果您将数据流输入它，它将等待该块被填充，并在该块满时开始压缩该块(或者，对于最后一个块，它将处理它接收到的任何大小)。
其他一些压缩算法可以处理流，这意味着它们可以使用保存在内存缓冲区中的旧数据不断压缩新数据。基于"滑动窗口"的算法可以做到这一点，通常zlib能够实现这一点。
现在，即使是"滑动窗口"压缩器也可能选择将输入数据分割成块，要么是为了更容易地管理缓冲区，要么是为了开发多线程功能，如pigz。