为什么前后端算出来的 MD5 不一致？字符集编码 (UTF-8 vs GBK) 隐形坑

一、问题概述：编码不一致引发的哈希计算偏差陷阱

许多开发者将 MD5 误认为是针对“字符串文本”的映射函数，但哈希算法实际接收的是字节流。中文文本“中文”在 UTF-8 下占用 6 个字节 (e4 b8 ad e6 96 87)，在 GBK 下占用 4 个字节 (d6 d0 ce c4)；输入字节不同，MD5 结果必然不同。

二、最小复现：相同中文文本在 UTF-8 与 GBK 下计算出不同 MD5

下面的示例展示了相同中文字符串在转换为 UTF-8 字节数组与 GBK 字节数组后计算 MD5 的物理结果差异：

/* 假设字符串为 "中文" */
const text = "中文";

// 1. 前端/现代后端默认：UTF-8 编码 (6 字节: E4 B8 AD E6 96 87)
// MD5("中文" in UTF-8) -> "a7bac2239fcdcb3a067903d8077c73a5"

// 2. 传统 Java/C# 后端默认：GBK 编码 (4 字节: D6 D0 CE C4)
// MD5("中文" in GBK)   -> "b2ea9170eedece3f0e0c8b323671a742"

/* 结论：相同的字面量字符串，因字符集编码导致的字节流不同，MD5 计算结果绝对不匹配！ */

三、根因分析：哈希算法的 Byte-level 特性与默认字符集陷阱

1. 字节流输入：MD5 (RFC 1321) 按 512 位 (64 字节) 分块迭代，只识别 0 和 1 二进制流，不理解 Unicode 字符概念。2. 隐性系统默认值：传统 Java 系统 string.getBytes() 在未显式指定参数时会使用系统默认编码 (GBK 或 Windows-1252)；而现代 JavaScript TextEncoder 默认且仅支持 UTF-8。3. MD5 安全定位：MD5 存在严重碰撞缺陷，仅适合非安全性数据完整性校验或遗留系统对接，严禁用于密码存储。

四、推荐方案：显式 UTF-8 字节流规范与编码转换层

1. 统一接口契约：所有 Hash 签名与校验接口都应明确字符编码，优先统一为 UTF-8。2. 显式指定编码参数：Java 等后端禁止依赖默认 getBytes()，应使用 getBytes(StandardCharsets.UTF_8)。3. 遗留系统兼容：浏览器原生 TextEncoder 与 TextEncoderStream 只输出 UTF-8；必须兼容 GBK 时，应使用经过测试、明确支持 GBK 的转码实现，或在受控服务端完成转码，并用固定字节向量做联调。

五、完整代码：显式 UTF-8 编码与字节诊断

下面的 TypeScript 代码只使用浏览器原生支持的 UTF-8 编码，并把实际输入字节输出为十六进制，便于前后端先对齐字节再比较摘要。

// 浏览器原生 TextEncoder 只支持 UTF-8。
function encodeUtf8(text: string): Uint8Array {
  return new TextEncoder().encode(text);
}

function bytesToHex(bytes: Uint8Array): string {
  return Array.from(bytes)
    .map((b) => b.toString(16).padStart(2, "0"))
    .join(" ");
}

const inputStr = "开源工具";
const utf8Bytes = encodeUtf8(inputStr);

console.log("输入文本:", inputStr);
console.log("UTF-8 物理字节:", bytesToHex(utf8Bytes));
// 输出: e5 bc 80 e6 ba 90 e5 b7 a5 e5 85 b7 (12 字节)
// 将 utf8Bytes 传入 MD5 算法可确保前后端计算结果完全一致

六、常见错误方案

在代码中直接对 Unicode 字符串进行按位截断；假设所有系统默认字符集都是 UTF-8；使用 MD5 存储用户密码或敏感密钥。

七、边界条件：BOM 头、Emoji 与 Surrogate Pair 字符处理

UTF-8 BOM (EF BB BF) 会给输入增加 3 个前导字节；Emoji 👋 的码点是 U+1F44B，在 JavaScript 内部由一对 UTF-16 surrogate 表示。双方必须先约定是否做 Unicode 规范化，再使用同一种字符编码，才能得到一致字节流。

八、如何验证前后端哈希一致性

联调时先输出输入的十六进制字节序列，而不是只比较最终 MD5；建立包含空串、中文、👋、组合字符、BOM 与换行符的固定测试向量，并在前后端断言字节与摘要都一致。

九、FAQ

问：为什么英文数字字符串前后端算出来的 MD5 通常一样？答：ASCII 范围字符在 UTF-8、GBK 和许多单字节编码中的字节值相同；一旦出现非 ASCII 字符，编码差异就会暴露。

问：前端能把文本转为 GBK 字节流算 MD5 吗？答：可以，但浏览器原生编码器不支持 GBK，必须选择明确支持 GBK 的可信转码实现并用固定向量验证，不能把 UTF-8 polyfill 当成 GBK 编码器。

问：MD5 现在还安全吗？答：MD5 存在实用碰撞攻击，不能用于密码存储、签名或对抗恶意篡改；遗留校验场景也应优先迁移到 SHA-256。

十、总结

哈希计算的是物理字节流而非字符文本。强制前后端统一使用显式 UTF-8 编码转码字节流，是避免 MD5 / SHA 哈希比对失败的最基础法则。