Node.js Buffer的UCS-2编码对超范围字符的处理疑问（v18.19.0）

你看到的现象源于Node.js中ucs2编码的实际实现——它并非严格意义上的UCS-2，而是UTF-16LE的别名。以下是具体的处理逻辑：

1. UCS-2与UTF-16的差异
   严格的UCS-2仅支持U+0000至U+FFFF范围内的字符，而UTF-16通过「代理对」机制扩展了对U+10000至U+10FFFF补充平面字符的支持。Node.js的ucs2编码实现遵循UTF-16规则，而非严格UCS-2。

2. 你的示例解析
   字符😎的码点是U+1F60E，属于补充平面字符，它会被拆分为UTF-16代理对：

   • 高代理码元：U+D83D
   • 低代理码元：U+DE0E
     由于是小端序（LE）存储，每个16位码元会以「低字节在前、高字节在后」的顺序写入缓冲区：
   • U+D83D → 字节序列0x3D 0xD8
   • U+DE0E → 字节序列0x0E 0xDE
     拼接后就得到了你看到的<Buffer 3d d8 0e de>。

3. 为什么没有抛出错误？
   Node.js的ucs2编码设计目标是兼容UTF-16，因此会自动处理补充平面字符的代理对拆分，而非像严格UCS-2那样拒绝超范围字符并抛出错误。

4. 编码方案对比
   你提到的UTF-8编码结果<Buffer f0 9f 98 08>是该字符的UTF-8字节序列，和UTF-16LE的编码逻辑完全不同，两者属于不同的字符编码方案，自然结果不一致。

内容的提问来源于stack exchange，提问作者cmplx96