文件校验：CRC32计算、MD5计算、文件完整性校验的C语言实现

文件校验，说白了就是给你的文件打个「指纹」。

我在嵌入式项目里吃过不少亏——明明烧录的固件一样，设备跑起来就是各种诡异。后来才发现，是传输过程中文件被「动过手脚」。从那以后，文件校验就成了我代码里的标配。

为什么需要文件校验？

你想想看，文件从A点传到B点，中间可能经过网络、U盘、甚至人工拷贝。任何一个bit翻转，都可能导致程序崩溃、数据错乱。校验的目的很简单：确认你拿到的文件，和原始文件一模一样。

核心思想：对原始数据计算一个固定长度的「摘要值」，接收方用同样的算法再算一次。两个值一致，文件就是完整的。

CRC32：轻量级校验，适合嵌入式

CRC32（Cyclic Redundancy Check，循环冗余校验）是我在嵌入式项目中最常用的校验方式。它计算速度快，硬件支持好，很多MCU甚至内置CRC外设。

CRC32的原理不复杂：把数据看作一个巨大的二进制数，用约定的多项式做模2除法，余数就是CRC值。嗯，这里要注意——不同的CRC32实现，多项式可能不同。最常见的是IEEE 802.3标准，多项式是0x04C11DB7。

CRC32的C语言实现

我个人习惯用查表法，速度比逐位计算快很多。先预计算一个256项的查找表，然后逐字节处理数据。

#include <stdint.h>

// CRC32查找表
static uint32_t crc32_table[256];

// 初始化查找表
void crc32_init_table(void) {
    uint32_t crc;
    for (int i = 0; i < 256; i++) {
        crc = i;
        for (int j = 0; j < 8; j++) {
            if (crc & 1)
                crc = (crc >> 1) ^ 0xEDB88320;
            else
                crc >>= 1;
        }
        crc32_table[i] = crc;
    }
}

// 计算CRC32
uint32_t crc32_calc(const uint8_t *data, size_t len) {
    uint32_t crc = 0xFFFFFFFF;
    for (size_t i = 0; i < len; i++) {
        uint8_t index = (crc ^ data[i]) & 0xFF;
        crc = (crc >> 8) ^ crc32_table[index];
    }
    return crc ^ 0xFFFFFFFF;
}

小技巧：初始值取0xFFFFFFFF，最后异或0xFFFFFFFF，这是标准做法。我曾经见过有人直接初始化为0，结果和标准库算出来的值对不上，排查了半天。

MD5：更强的抗碰撞性

CRC32虽然快，但它的碰撞概率在安全场景下不够低。说白了，CRC32只有32位，理论上2^32次计算就可能出现两个不同文件有相同CRC值。MD5输出128位摘要，碰撞概率低得多。

MD5算法流程：

  1. 填充数据：在数据末尾补位，使长度模512等于448
  2. 追加长度：在填充后的数据末尾追加64位的原始数据长度
  3. 初始化缓冲区：四个32位寄存器，初始值固定
  4. 分组处理：每512位一组，进行四轮非线性变换
  5. 输出摘要：四个寄存器的值拼接成128位

MD5核心代码片段

#include <string.h>
#include <stdint.h>

#define F(x, y, z) (((x) & (y)) | ((~x) & (z)))
#define G(x, y, z) (((x) & (z)) | ((y) & (~z)))
#define H(x, y, z) ((x) ^ (y) ^ (z))
#define I(x, y, z) ((y) ^ ((x) | (~z)))

// 左循环移位
#define LEFT_ROTATE(x, n) (((x) << (n)) | ((x) >> (32 - (n))))

// MD5主循环（简化示意）
void md5_process(uint32_t state[4], const uint8_t block[64]) {
    uint32_t a = state[0], b = state[1];
    uint32_t c = state[2], d = state[3];
    uint32_t x[16];
    
    // 将block转换为32位小端整数
    for (int i = 0; i < 16; i++) {
        x[i] = block[i*4] | (block[i*4+1] << 8) |
               (block[i*4+2] << 16) | (block[i*4+3] << 24);
    }
    
    // 第一轮
    a = b + LEFT_ROTATE((a + F(b,c,d) + x[0]  + 0xd76aa478), 7);
    d = a + LEFT_ROTATE((d + F(a,b,c) + x[1]  + 0xe8c7b756), 12);
    // ... 后续轮次省略，完整实现约64步
    
    state[0] += a;
    state[1] += b;
    state[2] += c;
    state[3] += d;
}

注意：MD5在密码学上已被攻破，存在已知的碰撞攻击。如果你需要防恶意篡改，建议用SHA-256。但用于文件完整性校验（非对抗场景），MD5仍然够用。

文件完整性校验的完整流程

在实际项目中，我通常这样设计校验流程：

  1. 生成校验文件：计算原始文件的CRC32和MD5，保存到单独的校验文件（如 .crc 或 .md5）
  2. 传输文件：将原始文件和校验文件一起发送
  3. 接收端校验：接收文件后，重新计算校验值，与校验文件中的值对比
  4. 结果判定：全部一致则通过，否则提示文件损坏

校验函数实现

#include <stdio.h>

typedef struct {
    uint32_t crc32;
    uint8_t  md5[16];
} FileChecksum;

// 计算文件的CRC32和MD5
int calc_file_checksum(const char *filename, FileChecksum *checksum) {
    FILE *fp = fopen(filename, "rb");
    if (!fp) return -1;
    
    uint8_t buffer[4096];
    size_t bytes;
    
    // 初始化CRC32和MD5上下文
    crc32_init_table();
    uint32_t crc = 0xFFFFFFFF;
    // MD5上下文初始化（略）
    
    while ((bytes = fread(buffer, 1, sizeof(buffer), fp)) > 0) {
        // 更新CRC32
        for (size_t i = 0; i < bytes; i++) {
            uint8_t index = (crc ^ buffer[i]) & 0xFF;
            crc = (crc >> 8) ^ crc32_table[index];
        }
        // 更新MD5（略）
    }
    
    checksum->crc32 = crc ^ 0xFFFFFFFF;
    // 获取MD5摘要（略）
    
    fclose(fp);
    return 0;
}

// 校验文件完整性
int verify_file_integrity(const char *filename, 
                          const FileChecksum *expected) {
    FileChecksum actual;
    if (calc_file_checksum(filename, &actual) != 0)
        return -1;
    
    if (actual.crc32 != expected->crc32)
        return 1;  // CRC32不匹配
    
    if (memcmp(actual.md5, expected->md5, 16) != 0)
        return 2;  // MD5不匹配
    
    return 0;  // 校验通过
}

知识体系结构图

下面这张图帮你理清文件校验的核心脉络：

文件完整性校验知识体系 文件完整性校验 CRC32 校验 MD5 校验 CRC32 特点 • 32位摘要，计算极快 • 适合嵌入式、通信校验 MD5 特点 • 128位摘要，抗碰撞性强 • 适合文件完整性验证 查表法 / 硬件CRC外设 四轮非线性变换 / 分组处理 固件升级 / 文件传输 / 数据备份

实际项目中的避坑指南

做文件校验这么多年，我踩过不少坑。分享几个典型的：

  • 字节序问题：我曾经在ARM和x86之间传输文件，CRC32算出来总是不对。后来发现是大小端没统一。记住：CRC32和MD5的输入数据必须按网络字节序处理。
  • 文件打开模式：在Windows上，一定要用"rb"模式打开文件。用"r"模式会导致换行符被转换，CRC32算出来肯定不对。这个坑我至少见过三次。
  • 大文件处理：不要一次性把整个文件读入内存。用4KB或8KB的缓冲区分块读取，既省内存又高效。
  • 校验文件的管理：我习惯把CRC32和MD5放在同一个校验文件里，格式简单点：文件名 + CRC32值 + MD5值，一行一个。

我的经验：在嵌入式OTA升级中，我通常先用CRC32做快速校验（硬件CRC外设几毫秒就算完了），通过后再用MD5做二次确认。这样既保证了速度，又保证了可靠性。

总结

文件校验不是什么高深的技术，但用好了能省很多排查问题的时间。CRC32适合快速校验，MD5适合更严格的完整性验证。实际项目中，我建议两者结合使用——CRC32做第一道防线，MD5做最终确认。

记住：校验不是万能的，但不校验是万万不能的。尤其是做嵌入式开发，文件传输过程中出问题的概率比你想象的高得多。

公众号：蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →