我想压缩相对较小的字符串，介于 1 到 10kb 之间，以便在我的服务器上存储。在实际请求期间，服务器和接收客户端应用程序将不会使用我选择的压缩。压缩将仅用于节省服务器上的存储空间。
在这种情况下，使用 gzip 及其标头真的有必要吗？我可以使用放气吗？甚至可能生放气，因为我知道所有情况下字符串的编码？
我看到的反对 deflate 的 #1 论点是浏览器中不一致的实现，但这在我的情况下似乎无关紧要。
我的想法有问题吗？
如果放气是这里 gzip 的可行替代方案，那么放气生呢？
首先是一些术语。放气是指原始放气格式，如 RFC 1951 中所述。因此，"放气"和"放气生"之间没有区别。您可能会想到错误命名的"deflate"HTTP编码，它实际上不是deflate，而是zlib，如RFC 1950中所述。
其次，将小字符串压缩为独立的、可解压缩的文件，这似乎是在暗示的，在大多数情况下会导致相当差的压缩。您应该连接这些字符串，以及能够再次将它们拉开所需的任何结构，至少达到大约 1 MB 级别并对这些字符串应用压缩。您没有说明以后要如何访问这些字符串，在这样的方案中需要考虑这些字符串。
第三，即使压缩 1 KB 到 10 KB 范围内的小字符串，gzip、zlib 和 deflate 之间的差异在占用的空间中基本上可以忽略不计。对于三种格式，标头和尾部分别占 18 个字节、6 个字节和 0 个字节。因此，如果您担心的是空间，那么远离gzip几乎没有什么好处。
第四，压缩时不计算CRC-32或Adler-32校验值(分别用于gzip和zlib)可能会有很小的速度优势，但与压缩所花费的时间相比，它也可以忽略不计。
在 Web 应用程序内部，您可以使用任何压缩 - 如果将未压缩的数据发送到 HTTP 客户端，则在网络上根本没有区别。
但是，这样做始终是一种权衡 - 服务器的实现将更加复杂，并且您将需要更多的 CPU 能力。它也仅在数据可压缩且大型对象(例如视频文件/磁盘图像)往往已经被压缩时才有效。
对于许多应用程序来说，磁盘空间不是问题，低延迟和最小复杂性是更重要的问题。如果您的应用程序存储大量很少被请求的可压缩数据，那么这样的压缩方案可能确实是一个好主意。
但在实现复杂代码之前，请计算它是否真的值得权衡。还要考虑文件系统级压缩(启用非常简单，实现是别人的问题)。如果你的目标是节省空间，你还应该考虑各种算法，从LZ4(非常快)到gzip/deflate/deflateRaw(都相同，只是不同的标头)到LZMA(非常慢但非常有效)。