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