- Java 双重比较
- java - 比较器与 Apache BeanComparator
- Objective-C 完成 block 导致额外的方法调用?
- database - RESTful URI 是否应该公开数据库主键?
一些 HTTP 服务器发送 deflate 原始主体(没有 zlib header )而不是实际的 deflate 主体。参见讨论:Why do real-world servers prefer gzip over deflate encoding?
是否有可能检测到它们并在 Node.js 中正确处理膨胀?我的意思是除了尝试 createInflate
它们并捕获错误然后再次尝试 createInflateRaw
。
最佳答案
如果十六进制的第一个字节的低位字节为 8
,则它是一个 zlib 流。否则它是原始压缩流。 (假设您先验地知道唯一可能的选择是有效的 zlib 流或有效的 deflate 流。)原始 deflate 流永远不会在低第一个 nybble 中有 8
,但 zlib 流永远都会。
背景:
zlib 头格式将压缩方法放在第一个字节的低位字节。该压缩方法始终为 8
for deflate。
原始压缩流中的位序列从字节的最低有效位开始。如果前三位是 000
(对于 8
),则表示已存储(未压缩 block ),并且它不是最后一个 block 。存储 block 将输入的字节放在字节边界上。因此,压缩器在写入 000
位后要做的下一件事是用零位填充字节的其余部分,以到达下一个字节边界。因此,下一位永远不会是 1
,因此有效的 deflate 流的前四位不可能是 1000
,或者第一个 nybble 是 8
。 (请注意,这些位是从下往上读取的。)
有效压缩流的第一个(即低位)nybble 只能是0
..5
或a
.. d
。如果您看到 6
..9
、e
或 f
,则它不是有效的 deflate 流。
关于node.js - 我们如何区分 deflate 流和 deflateRaw 流?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37519828/
一些 HTTP 服务器发送 deflate 原始主体(没有 zlib header )而不是实际的 deflate 主体。参见讨论:Why do real-world servers prefer g
我想知道如何压缩 1 到 10kb 之间的相对较小的字符串以存储在我的服务器上。服务器和接收客户端应用程序在实际请求期间不会使用我选择的压缩。压缩将仅用于节省服务器上的存储空间。 在这种情况下,真的有
我是一名优秀的程序员,十分优秀!