zlib项目中文本文件与二进制文件的高效识别方法-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00438/article/details/148487568

zlib项目中文本文件与二进制文件的高效识别方法

zlib A massively spiffy yet delicately unobtrusive compression library. 项目地址: https://gitcode.com/gh_mirrors/zl/zlib

引言

在日常开发工作中，我们经常需要处理来自不同来源的文件。准确识别一个文件是纯文本文件还是二进制文件，对于后续的处理流程至关重要。虽然这个问题看似简单，但要实现高精度的识别却需要复杂的语义分析。zlib项目提出了一种基于启发式规则的高效识别方法，能够在保证高准确率的同时实现接近100%的召回率。

传统识别方法的局限性

早期的PKZip等压缩工具采用了一种简单的识别方案：如果文件中超过80%的字节落在[7..127]范围内，就将其标记为文本文件，否则标记为二进制文件。这种方法存在两个主要缺陷：

对非拉丁字母支持不足：希腊语、西里尔字母或亚洲语言文本经常使用[128..255]范围内的字节，容易被错误识别为二进制文件（误判率高）
二进制文件误判问题：包含大量文本字符的二进制文件容易被误判为文本文件（误识别率高）

zlib的改进算法

zlib项目提出的新算法将字节码[0..255]划分为三类：

允许列表（文本字节）：
- 9 (TAB)、10 (LF)、13 (CR)
- 32 (SPACE) 到 255
容忍列表（可接受的字节）：
- 7 (BEL)、8 (BS)、11 (VT)、12 (FF)、26 (SUB)、27 (ESC)
禁止列表（非文本字节）：
- 0 (NUL) 到 6
- 14 到 31

判断规则：

如果文件包含至少一个允许列表中的字节，且不包含任何禁止列表中的字节，则判定为文本文件
否则判定为二进制文件
空文件自动归类为二进制文件

算法设计原理

这个算法基于两个关键观察：

ASCII控制字符使用情况：
- 虽然ASCII标准定义了完整的7位代码[0..127]，但实际应用中很少使用[0..31]范围内的控制字符
- 广泛使用的控制字符只有TAB(9)、LF(10)和CR(13)
- 其他控制字符如BEL(7)、BS(8)等通常不会单独使用
二进制文件特征：
- 大多数二进制文件包含控制字符，特别是NUL(0)
- 即使二进制文件包含[128..255]范围内的字节，通常也会同时包含控制字符

算法优势

编码无关性：不依赖字节计数，无论使用ISO-8859-16还是UTF-8等编码，都能得到一致的结果
高准确率：实验表明，在各种平台和应用生成的文件上都能保持高准确率
处理边界情况：明确处理了空文件和"污染"文本文件（包含少量非文本字符）的情况

实际应用建议

对于需要在项目中实现文件类型识别的开发者，可以考虑以下实现方式：

int is_text_file(FILE *fp) {
    int ch;
    int has_text = 0;
    
    while ((ch = fgetc(fp)) != EOF) {
        if (ch >= 0 && ch <= 6) return 0;
        if (ch >= 14 && ch <= 31) return 0;
        if (ch >= 32) has_text = 1;
        // 特殊处理允许的控制字符
        if (ch == 9 || ch == 10 || ch == 13) has_text = 1;
    }
    
    return has_text;
}