从 JS 里的 MD5 转换踩坑开始说起

发表于 更新于 分类于 ， ，

写 JS 代码的同学们不知道有没有注意过，后台接口通过 JSON 处理汉字字符、emoji 时，返回的是像 \u00ff 这样转义处理的字符，而不是它们的明文原文。这是为什么呢？

1
2
3
<?php
echo json_encode('再会，谢谢所有的🐟');
// -> "\u518d\u4f1a\uff0c\u8c22\u8c22\u6240\u6709\u7684\ud83d\udc1f"
1
2
3
4
import json

print(json.dumps('再会，谢谢所有的🐟'))
# -> "\u518d\u4f1a\uff0c\u8c22\u8c22\u6240\u6709\u7684\ud83d\udc1f"

以及，这个问题和今天要说的 MD5 转换编码的踩坑又有什么关系呢？

踩坑

最近在小程序项目中，对于一些请求数据的防篡改处理，与后台约定了在表单内增加一个校验字段，为原始数据进行 MD5 换算后的结果。最初调试走通后没发现什么问题，就发布上线了。

之后陆续有部分用户反馈，偶尔发现部分页面无法正常显示，与后台同学定位发现这些用户请求时无法通过防篡改校验，导致被拦截策略误伤。只好对这些情况作了一些白名单的临时处理，待有时间时再彻底定位处理。

后来逐渐发现，出现 MD5 处理结果异常的用户，往往名字里有 emoji 或者生僻汉字出现，莫非问题和这些字符的编码方式有关——

通过与后台对比 emoji 的编码结果，发现两端确实出现了不一致的情况，看来这些字符确实是问题的充分条件了。

阅读与学习

于是，在某次版本之后得以稍微喘口气的某个周末，开始阅读之前同事从网上找到的纯 JavaScript 实现的 MD5 模块源码——发现并看不懂，还得先找找 MD5 算法的原理，结合着参考对照阅读，终于大致明白了各个函数的作用。

《MD5算法原理及其实现》

经过阅读对比，发现目前项目里使用的这套算法中分组、线性函数 F(x,y,z)/G(x,y,z)/H(x,y,z)/I(x,y,z)和16个分组的4轮运算过程看起来都没什么问题。

而在开始这些处理之前，有个对于输入字符串的处理函数，目前是这样写的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function encodeUTF8(string) {
    let output = '';
    for (let n = 0; n < string.length; n++) {
        const c = string.charCodeAt(n);
        if (c < 128) {
            output += String.fromCharCode(c);
        } else if ((c > 127) && (c < 2048)) {
            output += String.fromCharCode((c >> 6) | 192);
            output += String.fromCharCode((c & 63) | 128);
        } else {
            output += String.fromCharCode((c >> 12) | 224);
            output += String.fromCharCode(((c >> 6) & 63) | 128);
            output += String.fromCharCode((c & 63) | 128);
        }
    }
    return output;
};

很显然，这个函数的作用自然就是“编码为UTF8”，顾名思义嘛——

不过这时候有同学可能就要问了：等等，我们平时在项目中写代码时，用的已经是 UTF-8 编码了啊？为什么还要再编码成 UTF-8？

编码方式

这里就涉及到文件编码与 JS 引擎内部编码的区别了，有兴趣的同学可以阅读一下相关文章：

《Unicode 编码及 UTF-32, UTF-16 和 UTF-8》

《JavaScript 的内部字符编码是 UCS-2 还是 UTF-16》

《Unicode与JavaScript详解》

《Unicode 一览表》

没有时间自己详细阅读前因后果的同学，也可以参考一下我的理解（不保证绝对准确无误）：

  • Unicode 是一套字符集，为各种语言的每个字符定义了对应的编号——码点/码位（Code Point），但不代表其最终的表示和存储形式。
  • 实际计算机系统中根据不同的需求，对其有不同的编码方式实现，如今依然常见的有 UTF-8、UTF-16。
  • JavaScript 因历史原因，使用的是近似于 UTF-16 的 UCS-2 方案（编码中操作处理时表现为 UCS-2，浏览渲染显示时基于 UTF-16 重新显示为 Unicode 字符）。

所以，这个模块在 JavaScript 的字符串进行 MD5 计算前，“尝试”将 JS 引擎内的 UTF-16/UCS-2 格式的字符串先转换成了基于 UTF-8 格式表示的 Unicode 字符，再将其对应编码值进行 MD5 计算处理。

例子说明

这里举几个例子：

1. 英文字母：“A”

作为基础拉丁字母的 A，它的 Unicode 码点为 65（转换成16进制为 0x41）。

其各种编码的16进制书写和在内存、硬盘等介质中2进制表现形式为：

编码 16进制 2进制
UTF-8 41 01000001
UTF-16BE 00 41 00000000 01000001
UTF-16LE 41 00 01000001 00000000
UTF-32BE 00 00 00 41 00000000 00000000 00000000 01000001
UTF-32LE 41 00 00 00 01000001 00000000 00000000 00000000

可以看出，对于码点较小的字符，位于几种编码的第一段区域时，表现格式其实差别不大：

  • UTF-8 在第一段与 ASCII 码、Unicode 码点一致，占用1个字节；
  • 而 UTF-16 和 UTF-32 相当于在高位补 0，分别占用2个和4个字节。

2. 汉字：“我”

作为常用汉字的“我”字，码点 25105（0x6211）：

  • 由于 0x6211 没有超过两个字节，所以使用 UTF-16 相当于直接对 Unicode 码点做16进制编码转换，仍只占用2字节；
  • 而相对于 UTF-8，它已经进入第三段范围（0x800 ~ 0xffff），已经需要3个字节来进行表示了。
编码 16进制 2进制
UTF-8 E6 88 91 11100110 10001000 10010001
UTF-16BE 62 11 01100010 00010001
UTF-16LE 11 62 00010001 01100010
UTF-32BE 00 00 62 11 00000000 00000000 01100010 00010001
UTF-32LE 11 62 00 00 00010001 01100010 00000000 00000000

3. 音乐符号：“𝅘𝅥𝅮”

而对于音乐符号，码点 119136（0x1D160）：

  • 它进入了 UTF-8 的第四段范围（0x10000 ~ 0x10ffff），就算是使用 UTF-8 也需要4个字节来编码表示了；
  • 使用 UTF-16 编码时，超过 0xffff 的它需要借助 低位代理&高位代理 进行辅助表示，也使用了4个字节。
编码 16进制 2进制
UTF-8 F0 9D 85 A0 11110000 10011101 10000101 10100000
UTF-16BE D8 34 DD 60 11011000 00110100 11011101 01100000
UTF-16LE 34 D8 60 DD 00110100 11011000 01100000 11011101
UTF-32BE 00 01 D1 60 00000000 00000001 11010001 01100000
UTF-32LE 60 D1 01 00 01100000 11010001 00000001 00000000

4. 扩展B区汉字和 emoji：

汉字“𠀾”（这个字怎么读？我也不会读……查了一下，似乎是吴越方言，读“pēi”），码点 131134（0x2003E）：

编码 16进制 2进制
UTF-8 F0 A0 80 BE 11110000 10100000 10000000 10111110
UTF-16BE D8 40 DC 3E 11011000 01000000 11011100 00111110
UTF-16LE 40 D8 3E DC 01000000 11011000 00111110 11011100
UTF-32BE 00 02 00 3E 00000000 00000010 00000000 00111110
UTF-32LE 3E 00 02 00 00111110 00000000 00000010 00000000

中日韩常用的统一汉字文字区——基本多文种平面 内的 0x4E00 ~ 0x9FFF 段落，其中基本含括了日常生活需要用到的常用汉字。

在2000年、2001年、2003年、2010年、2015年、2017年、2020年扩充了 A、B、C、D、E、F、G 这7个扩充区，包括各种古籍、生僻字、日语汉字、喃字、急用字等更多汉字。顺便一提，“biang biang 面”的“biang”于2020年被收录到了扩充区 G 中（码点 0x30EDD/0x30EDE），不过目前大部分字体和客户端都还无法支持渲染显示。

《中日韩统一表意文字扩展区》

《中日韓統一表意文字擴展區B》

Emoji（绘文字）“🐟”，码点 128031（0x1F41F）：

编码 16进制 2进制
UTF-8 F0 9F 90 9F 11110000 10011111 10010000 10011111
UTF-16BE D8 3D DC 1F 11011000 00111101 11011100 00011111
UTF-16LE 3D D8 1F DC 00111101 11011000 00011111 11011100
UTF-32BE 00 01 F4 1F 00000000 00000001 11110100 00011111
UTF-32LE 1F F4 01 00 00011111 11110100 00000001 00000000

分析问题

现在，我们回过头来看最初那个 UTF-8 编码转换函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function encodeUTF8(string) {
    let output = [];
    for (let n = 0; n < string.length; n++) {
        const c = string.charCodeAt(n);
        if (c < 128) {
            output += String.fromCharCode(c);
        } else if ((c > 127) && (c < 2048)) {
            output += String.fromCharCode((c >> 6) | 192);
            output += String.fromCharCode((c & 63) | 128);
        } else {
            output += String.fromCharCode((c >> 12) | 224);
            output += String.fromCharCode(((c >> 6) & 63) | 128);
            output += String.fromCharCode((c & 63) | 128);
        }
    }
    return output;
};

先不论其中的位运算是否有问题，已经可以看出，这个算法的转换结果只有1~3字节这三种情况，不会输出4字节的结果——

所以，问题很明显了：它能处理常见的英文、汉字字符，但是无法处理结果为4字节的 0x10000 ~ 0x10ffff 范围内的字符，其中就包括上面的音符特殊字符、汉字扩展B区、emoji 的几种情况。

特殊解决方案

找到问题原因后，就可以调整搜寻方向，比如找找其它的 UTF-8 转码的 JavaScript 实现方案。

其中就找到一个很神奇的方法，看起来真是意外的简单，甚至完全没有需要用到任何位运算处理: unescape(encodeURIComponent(string))。

它真的有用吗，我们来试一试：

1
2
3
4
const encoded = unescape(encodeURIComponent('🐟'));
const hexArr = encoded.split('').map(c => c.charCodeAt(0).toString(16));
console.log(hexArr.join('');
// -> 'f09f909f'

通过它处理“🐟”之后，得到的正是这个 emoji 的 UTF-8 表示形式：0xF09F909F。

为什么会这样呢？其实原因不复杂，因为 encodeURIComponent 的转换是基于 UTF-8 进行计算的（估计是为了网络传输效率和常见服务器支持格式考虑而设计实现的），再将结果直接按字节地一一转换回 JavaScript 字符串，其中每个字符的 charCode 就变成对应 UTF-8 位置的结果了。

这个方案的问题在于 unescape 作为非标准函数，因为各种问题已经在很早时被宣布弃用（deprecated），我们最好还是找更为标准的解决方案，以免以后浏览器不再支持而无法正常工作。

《escape, encodeURI, encodeURIComponent有什么区别?》

改进解决方案

1. 基于 Unicode 码点操作

原本的 encodeUTF8 函数中通过 String.prototype.charCodeAt() 操作原始字符串，得到的是根据 UCS-2 计算的字长、相当于 UTF-16 的编码，基于这个结果再转换成 UTF-8 最好是先还原成 Unicode 码点再操作。

而好在 ES6 中增加了新的基于 Unicode 码点的处理方式 String.prototype.codePointAt()；而对于字长的处理则可以使用 Array.from()，它将会正确按照每个字符进行拆分：

1
2
3
4
5
6
7
8
9
10
11
'钓🐟'.length;
// -> 3

Array.from('钓🐟').length;
// -> 2

'钓🐟'.split('');
// -> ['钓', '\uD83D', '\uDC1F']

Array.from('钓🐟')
// -> ['钓', '🐟']

所以转换处理的循环部分可以改写一下，这里主要是要注意：需要基于 Array.from() 的结果进行循环，以及通过 codePointAt 进行码点获取时，只需要传入每个字符的下标0位置即可：

1
2
3
4
5
6
7
8
function encodeUTF8(string) {
    let charArr = Array.from(string);
    for (let n = 0; n < charArr.length; n++) {
        const cp = charArr[n].codePointAt(0);
        // ...
    }
    // ...
};

2. 4字节 UTF-8 的转换支持

Unicode 码点段落 UTF-8 编码
0x0 ~ 0x7f 0xxxxxxx
0x80 ~ 0x7ff 110xxxxx 10xxxxxx
0x800 ~ 0xffff 1110xxxx 10xxxxxx 10xxxxxx
0x10000 ~ ... 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

通过上面的格式可以看出，Unicode 码点大于 0xffff 的字符转换成 4字节的 UTF-8 时，处理方式大致分以下几步：

  • 将字符的所有二进制位分为最高3位 xxx 和之后三组6位 yyyyyy 这样的4组二进制位；
  • 最高3位 xxx 与 11110000（0xF0） 进行按位或运算，得到 11110xxx 的结果；
  • 最后3组 yyyyyy 与 10000000（0x80） 进行按位或运算，得到 10yyyyyy 的结果。

顺便把相关位运算的 <</>> 位移运算符改为 <<</>>> 无符号位移运算符。

最终算法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
function encodeUTF8(string) {
    const output = [];
    const arr = Array.from(string);
    for (let n = 0; n < arr.length; n++) {
        const cp = arr[n].codePointAt(0);
        if (cp < 0x80) {
            output.push(cp);
        } else if (cp < 0x800) {
            output.push(
                (cp >>> 6) | 0xC0,
                cp & 0x3F | 0x80,
            );
        } else if (cp < 0x10000) {
            output.push(
                (cp >>> 12) | 0xE0,
                ((cp & 0xFC0) >>> 6) | 0x80,
                cp & 0x3F | 0x80,
            );
        } else {
            output.push(
                (cp >>> 18) | 0xF0,
                ((cp & 0x3F000) >>> 12) | 0x80,
                ((cp & 0xFC0) >>> 6) | 0x80,
                cp & 0x3F | 0x80,
            );
        }
    }
    return output;
}

返回结果从字符串变成了更方便运算的类 byte[] 的数组，调用的位置也记得需要做相应调整。

拓展

几种 JavaScript 字符串内特殊字符的转义写法

1. 单字节字符

在常见编程语言里，我们经常通过 x 的前缀来书写16进制编码，JavaScript 看起来也支持这个写法：

1
2
3
4
5
6
7
8
9
10
11
console.log('\x41');
// -> A

console.log('\x4142');
// -> A42

console.log('\x41\x42');
// -> AB

console.log('\xF');
// Uncaught SyntaxError: Invalid hexadecimal escape sequence

可以看出，\x 后面固定为两位16进制格式，即只支持表示单个字节。那么对于汉字这样多字节字符，比如“谢”字（UTF-8: 0xE8B0A2, UTF-16BE: 0x8C22），该怎样书写呢？

2. 多字节字符

在 PHP 里，我们可以直接按字节顺序写出，最终打印出来的就是完整的汉字：

1
2
<?php echo "\xE8\xB0\xA2\xE8\xB0\xA2";
// -> 谢谢

但是在 JavaScript 中，如果你按照这样的方式书写，就会发现打印出来的并不是你预想中的“谢谢”：

1
2
console.log('\x8C\x22\x8C\x22');
// -> Œ"Œ"

为什么会这样呢？

通过输出结果我们可以看出，其中 \x8C 和 \x22 都被当成单个的字符进行处理了，而 JavaScript 中 UCS-2/UTF-16 的实现下，一个字符是以2或4个字节进行存储的。

所以，这里最终得到的字符串其实是: 0x008C 0x0022，而不是 0x8C22。

这种多字节字符的情况，就需要使用 JavaScript 提供的 \u 进行转义书写了：

1
2
console.log('\u8C22\u8C22');
// -> 谢谢

不过 \u 有着和 \x 类似的毛病，\x 后面固定为两位16进制，\u 后面默认则是固定4位16进制。

对于 “🐟”（UTF-16: 0xD83DDC1F, Code Point: 0x1F41F）就需要写成 \uD83D\uDC1F，或者使用 ES6 提供的码点写法整个写入 \u{1F41F}：

1
2
3
4
console.log('\uD83D\uDC1F');
// -> 🐟
console.log('\u{1F41F}');
// -> 🐟

这种格式下，一个码点就是一个字符，各个字符的边界更直观，更便于阅读和调整。

回顾

最后，我们回到最开始的问题：服务器为什么以 \uXXXX 的形式返回汉字和emoji？

服务器对于诸如汉字和 emoji 这些多字节字符，返回 JSON 字符串的时候如果直接返回明文，其实返回的是自己运行环境下的编码实现。比如 PHP 返回 谢谢 时，发出的将会是 0xE8 0xB0 0xA2 0xE8 0xB0 0xA2，对于 UCS-2/UTF-16 的 JavaScript 来说就变成乱码了。

而服务端实现 JSON 序列化时可能考虑到了这点，提前将其变为基于 UTF-16 的转义书写字符串字面量，这样浏览器内的 JavaScript 反序列化后就可以正常得到预期的 谢谢 了。

我的博客即将同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=ortdhu8zxomu