为何维基百科称UTF-16已过时，但JavaScript仍在使用该编码？

这个问题确实戳中了一个很有意思的技术历史遗留矛盾，咱们一步步把它理清楚：

首先，维基百科说的“过时”是针对Web内容传输/存储编码场景 #

维基百科里的这段描述，核心是针对网页本身的编码格式：

UTF-16 is the only encoding (still) allowed on the web that is incompatible with 8-bit ASCII. However it has never gained popularity on the web, where it is declared by under 0.004% of public web pages (and even then, the web pages are most likely also using UTF-8). UTF-8, by comparison, gained dominance years ago and accounted for 99% of all web pages by 2025.

简单说，作为网页内容的编码格式，UTF-16确实已经被淘汰了：

• 它不兼容ASCII，早期很多老系统处理起来容易出乱码；
• 传输单字节字符（比如英文、数字）时会浪费一倍带宽；
• 还有字节序（大端/小端）的问题，容易引发解析错误，甚至存在安全风险——这也是WHATWG明确要求浏览器不要用UTF-16处理网页内容的原因，同时把UTF-8定为所有文本的强制编码。

而JavaScript用UTF-16，是历史遗留的内存表示方案 #

这得追溯到JavaScript诞生的90年代中期：

• 当时Unicode还处于早期阶段，UTF-8还没成为主流，行业里普遍用的是UCS-2（UTF-16的前身，固定用16位存储每个字符）；
• JS的字符串设计直接沿用了这个方案，把字符串表示为16位的字符单元序列，这个设计一直保留到现在，成为了语言的核心特性之一。

这里要划个重点：JS的UTF-16和Web上的内容编码完全是两回事：

• 浏览器会先把UTF-8编码的网页内容（HTML、JS代码、文本内容）解析成内存中的UTF-16格式字符串，再执行JS逻辑或渲染页面；
• 用户看到的网页是UTF-8传输的，但JS在内存里操作的是UTF-16的字符单元——两者各司其职，并不冲突。

补充：现代JS已经在弥补UTF-16的不足 #

虽然历史遗留了这个设计，但现代JS引擎做了很多优化：

• 比如对ASCII字符会用单字节存储来节省内存，只是对外暴露的接口保持UTF-16的行为；
• 还新增了codePointAt()、String.fromCodePoint()等方法，让开发者能更方便地处理Unicode中的辅助平面字符（那些需要用两个16位单元表示的字符）。

总结一下：维基百科说的“过时”是针对Web内容的传输编码场景，而JavaScript用UTF-16是语言历史遗留的内存表示方案，两者的应用场景完全不同，所以看似矛盾的现象其实是合理的技术演化结果。

内容来源于stack exchange