编辑器UTF-8编码与ECMAScript规范UTF-16字符串处理的技术疑问

针对你提到的编辑器UTF-8编码和JS规范UTF-16要求的差异，我把ECMAScript里字符串处理的关键规则拆解清楚：

1. 字符串的逻辑本质：UTF-16代码单元序列 #

不管你的编辑器用UTF-8存储文件，还是JS引擎在底层用什么格式存储字符串，在ECMAScript规范的逻辑层面，所有字符串都被视为UTF-16代码单元的序列。每个代码单元是一个16位无符号整数，取值范围是0x0000到0xFFFF。简单说，JS眼里的字符串就是一串16位数字，和你编辑器里的UTF-8字节不是一回事。

2. 字符串的索引：按UTF-16代码单元位置编号 #

字符串的位置索引完全基于UTF-16代码单元的位置，而不是我们日常认知的“字符”（Unicode码点）。举个直观的例子：

• 表情符号😀对应的Unicode码点是U+1F600，它需要两个UTF-16代码单元（0xD83D和0xDE00）来表示
• 所以执行"😀".length会返回2，而不是1
• 用"😀"[0]取到的是第一个代码单元对应的字符（实际是不可见的代理字符），而不是完整的表情

3. 字符串操作：只处理16位整数序列，不保证UTF-16有效性 #

除了少数明确标注为处理Unicode码点的API（比如ES6新增的codePointAt()、String.fromCodePoint()），所有标准字符串操作都只把字符串当成无差别的16位整数序列来处理。这意味着：

• 这些操作不会检查原始字符串的UTF-16有效性
• 操作后生成的新字符串也不保证符合UTF-16编码规则（比如你可以手动拼接两个单独的高代理代码单元，得到一个在UTF-16里无效的序列，JS不会报错，只会原样存储）

如果需要处理完整的Unicode字符（而不是UTF-16代码单元），推荐使用ES6及以后的Unicode友好API，比如Array.from(str)可以把字符串拆成完整的Unicode字符数组，str.normalize()可以处理Unicode归一化问题。

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