`search-zip` 应该使用标准化的文件检测,而不是扩展名

我意识到这实际上是 #2085，但我不认为这是一个小众用例，考虑到 ripgrep 可以很容易地实现这一点。 实际上，几乎所有标准压缩格式都在头部中包含一个魔术数字，可以作为扩展的替代，而且使用这个数字似乎比使用扩展更好。 虽然我也认为直接使用纯 Rust 实现的解压缩而不是外部程序（这意味着所有的头部检测都已经包含在代码中），但我理解不这么做，并认为这是一个合理的妥协。 请注意，这与期望语言格式检测使用更复杂的算法不同，而且如果您已经打算打开文件以确定它们是否为文本，则实际上非常简单。 仅仅为了列出这些的简单性，我决定查找 ripgrep 支持的所有格式的头部： * gzip: 1F 8B * bzip: 42 5A 68 * xz: FD 37 7A 58 5A 00 * lz4: 04 22 4D 18 * lzma: __ __ __ __ __ FF FF FF FF FF FF FF FF (请参阅脚注) * br: (不提供) * zstd: FD 2F B5 * uncompress: 1F 9D 脚注： * Brotli 没有专用的魔术数字，因此，您必须依赖 .br 扩展。 * LZMA 也处于类似的境地，尽管它有一个非常可靠的 8 字节的标志，用于流式数据，并且由 libmagic 用作可靠的检测器。 * 所有这些数字都来自 文件签名列表维基百科页面 (易于阅读) 或直接来自 libmagic 的源代码 (难以阅读)。 如上所述，由于这些文件正在进行读取，因此自动检测这些文件而不是依赖扩展（扩展并不总是存在）会很有帮助。 例如，一些常见格式，如 mtree，默认情况下通常通过另一种格式进行压缩（在这种情况下是 gzip），尽管它们只是文本。 而不是建议 ripgrep 考虑到所有这些特定示例，而是直接读取文件的两个字节似乎是一个更可靠的解决方案。