我正在计划一个 .NET 项目，该项目涉及从最多样化的类型自动上传文件，从各种分布式客户端到服务器群，有时文件扩展名可能与实际文件类型不匹配（长话短说）。
使用 HTTP 压缩并不总是一种选择，在这个项目案例中，最好花费更多的客户端处理而不是带宽或服务器存储。但是如果我们可以确定压缩是否会给出可行的结果，那么如果我们可以跳过压缩过程会更好。
我知道没有“正确答案”，但我们将不胜感激。
【问题讨论】：
标签： .net compression
按文件类型过滤是个好主意。即使某些文件的扩展名错误，总体而言它应该是一个不错的选择。
例如文本文件的压缩效果非常好。压缩 mp3、jpg/gifs 或 divx 文件几乎没有用处。
【讨论】：
鉴于你所说的扩展，我可以看到几种方法
首先：你能在不使用扩展名的情况下确定文件的类型吗？许多文件类型都有标准标题，因此您可以解析标题并确定这是您为其实现过滤器的十几种常见文件类型之一。
第二：一个更简单的骗局是从文件中间抓取 100 个字节，看看这是否是标准的 ascii，例如每个字节都有一个介于 9 和 126 之间的值。这在给定的时间百分比是错误的，不适用于许多语言的文本，也不适用于 unicode 文本。
【讨论】：
之前是指在实际压缩或发送之前？您可能会保留一些数据并以此为基础做出决定；将文件类型、扩展名和大小映射到压缩时间和最终大小，看看你是否可以了解什么是有效的
【讨论】：
您可以尝试使用非常快速的压缩器来压缩文件。如果压缩器无法将其压缩得足够多，那么尝试更好地重新压缩它是没有用的。是的，这是一个愚蠢的想法，但从技术上讲，.zip 文件可以包含使用“存储”格式的 txt 文件（因此没有压缩），并且 .zip 将是高度可压缩的，所以没有灵丹妙药。
（从技术上讲，您可以测量文件的熵，但是按照这里的建议How to calculate the entropy of a file?，gzip 对其进行测试:-)）
【讨论】：
您可以通过执行字节频率分析获得指针，也许还可以使用 MTF 步骤将局部重复转换为更可测量的内容。成本低廉，对文件进行线性扫描。
【讨论】：
您可以在发送之前尝试在内部压缩每个文件的前几 KB，然后查看它压缩到多少字节。如果结果看起来足够好，请在发送之前压缩整个内容。
使用这种方法时您应该注意的一件事是，许多文件格式的前“少数”KB 可能是类似标题的数据，不代表文件的其余部分。因此，您可能想要增加样本量，从文件的另一部分获取样本，从文件的不同部分获取多个子样本以形成您的样本，等等。
【讨论】：