第27章序列化与校验

课程目录第27章序列化与校验

序列化与校验：CRC32校验和、MD5哈希、数据完整性验证

数据在序列化之后，要经过网络传输、存储、再读取。这中间任何一个环节出了差错，数据就变了。你想想看，一个嵌入式设备采集的温度值，从传感器到云端，中间经过好几层转发，如果某一位被翻转了，那后果可能很严重。

所以，校验不是可选项，而是刚需。今天我们就聊聊三种常用的校验手段：CRC32、MD5，以及它们背后的数据完整性验证思路。

为什么需要校验？

我在项目中遇到过一件挺尴尬的事。有一次调试一个远程升级模块，固件包通过串口下发，每次校验都通过，但设备跑起来就死机。查了两天，最后发现是串口波特率有微小偏差，导致每100个字节里就有1个字节被错误接收。而当时用的简单累加和校验，恰好没发现这个错误。

从那以后，我对校验这件事就特别较真。简单说，校验要解决三个问题：

检测随机错误：比如电磁干扰导致的位翻转
检测突发错误：比如连续几个字节丢失或损坏
检测恶意篡改：虽然嵌入式场景不多，但也要考虑

不同的场景，选不同的校验算法。没有银弹。

CRC32：嵌入式领域的“老黄牛”

CRC（循环冗余校验）是我用得最多的校验方式。它不加密，不防篡改，但检测随机错误的能力非常强。尤其是CRC32，在以太网、ZIP压缩、嵌入式通信协议里随处可见。

它的原理说白了就是多项式除法。发送方把数据当作一个巨大的二进制数，除以一个约定的多项式，余数就是CRC值。接收方做同样的除法，如果余数为0，说明数据大概率没问题。

核心要点：CRC32的检错能力极强，能检测出所有单比特错误、双比特错误、奇数个错误，以及长度不超过32位的突发错误。对于嵌入式通信来说，够用了。

下面是一个标准的CRC32实现，我习惯用查表法，速度比逐位计算快很多：

#include <stdint.h>

// CRC32查表法实现
static uint32_t crc32_table[256];

// 初始化CRC32查找表
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, uint32_t len) {
    uint32_t crc = 0xFFFFFFFF;
    for (uint32_t i = 0; i < len; i++) {
        uint8_t index = (crc ^ data[i]) & 0xFF;
        crc = (crc >> 8) ^ crc32_table[index];
    }
    return crc ^ 0xFFFFFFFF;
}

我的习惯：在序列化结构体的末尾直接附加CRC32值。反序列化时先校验CRC，再解析数据。这样能第一时间发现数据损坏，避免用错误数据做后续处理。

MD5：哈希校验的“老前辈”

MD5虽然现在不推荐用于密码学场景，但做数据完整性校验还是可以的。它把任意长度的数据映射成一个128位的哈希值。哪怕原数据只改了一个比特，哈希值也会面目全非。

我在项目中用MD5的场景主要是两个：

固件包完整性校验：下载完成后，计算整个固件的MD5，和服务器下发的MD5对比
大数据块的分块校验：比如把1MB的数据分成64KB一块，每块算一个MD5，这样能精确定位哪一块坏了

MD5的算法实现比较复杂，我一般直接复用开源库，比如mbedtls或者libmd。但要注意，MD5的计算速度比CRC32慢不少，在资源受限的MCU上要掂量一下。

#include <stdio.h>
#include <string.h>
#include "md5.h"  // 假设使用了mbedtls的MD5实现

// 计算数据的MD5哈希值
void calc_md5(const uint8_t *data, uint32_t len, uint8_t output[16]) {
    mbedtls_md5_context ctx;
    mbedtls_md5_init(&ctx);
    mbedtls_md5_starts(&ctx);
    mbedtls_md5_update(&ctx, data, len);
    mbedtls_md5_finish(&ctx, output);
    mbedtls_md5_free(&ctx);
}

// 将MD5值转换为可读的十六进制字符串
void md5_to_string(const uint8_t md5[16], char str[33]) {
    for (int i = 0; i < 16; i++) {
        sprintf(str + i * 2, "%02x", md5[i]);
    }
    str[32] = '\0';
}

注意：MD5存在碰撞风险，即两个不同的数据可能算出相同的MD5值。对于嵌入式场景，这种概率极低，基本可以忽略。但如果涉及安全认证，建议改用SHA256。

CRC32 vs MD5：怎么选？

我经常被问到这个问题。我的回答是：看场景。

对比维度	CRC32	MD5
输出长度	32位（4字节）	128位（16字节）
计算速度	极快（硬件加速常见）	较慢（软件实现）
检错能力	强（针对随机错误）	极强（针对任意改动）
防篡改	弱（可被绕过）	中等（有碰撞风险）
典型应用	通信协议、存储校验	文件完整性、固件校验

我个人习惯是：通信协议用CRC32，文件完整性用MD5。如果资源允许，两个都用，双重保险。

数据完整性验证的实战套路

光有算法还不够，得有一套完整的验证流程。我总结了一个四步法：

序列化时附加校验值：在数据末尾追加CRC32或MD5
传输或存储：保持数据+校验值的整体
反序列化前先校验：重新计算校验值，和附带的校验值对比
校验通过才解析：不通过则丢弃或请求重传

下面是一个完整的示例，演示了序列化结构体并附加CRC32校验：

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

// 传感器数据结构体
typedef struct {
    uint32_t timestamp;
    float    temperature;
    float    humidity;
    uint8_t  status;
} SensorData;

// 序列化后的数据包（包含CRC32）
typedef struct {
    SensorData data;
    uint32_t   crc32;
} SensorPacket;

// 序列化并附加CRC32
void serialize_with_crc(const SensorData *data, uint8_t *buffer, uint32_t *len) {
    SensorPacket packet;
    memcpy(&packet.data, data, sizeof(SensorData));
    packet.crc32 = crc32_calc((uint8_t*)&packet.data, sizeof(SensorData));
    memcpy(buffer, &packet, sizeof(SensorPacket));
    *len = sizeof(SensorPacket);
}

// 反序列化并校验CRC32
int deserialize_with_crc(const uint8_t *buffer, uint32_t len, SensorData *data) {
    if (len != sizeof(SensorPacket)) return -1;
    
    SensorPacket packet;
    memcpy(&packet, buffer, sizeof(SensorPacket));
    
    // 校验CRC
    uint32_t calc_crc = crc32_calc((uint8_t*)&packet.data, sizeof(SensorData));
    if (calc_crc != packet.crc32) {
        return -2;  // 数据损坏
    }
    
    memcpy(data, &packet.data, sizeof(SensorData));
    return 0;  // 成功
}

避坑指南：我曾经在CRC计算时把校验值本身也算进去了，结果永远校验不通过。记住，CRC只计算数据部分，不包括校验值本身。

知识体系总览

下面这张图总结了序列化校验的核心逻辑，从数据产生到最终验证的完整链路：

从这张图可以看得很清楚：校验不是事后诸葛亮，而是贯穿整个数据生命周期的守护者。序列化时算一次，反序列化时再算一次，两次一致，数据才是可信的。

好了，关于序列化校验就聊到这里。CRC32和MD5各有千秋，选对场景比选对算法更重要。下次你在调试通信协议时，不妨先问问自己：我的校验够不够强？

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

📚 课程目录

序列化与校验：CRC32校验和、MD5哈希、数据完整性验证

为什么需要校验？

CRC32：嵌入式领域的“老黄牛”

MD5：哈希校验的“老前辈”

CRC32 vs MD5：怎么选？

数据完整性验证的实战套路

知识体系总览