Chrome中注释行的">"为何影响charCodeAt()返回值？

问题还原 #

一段获取字符¶编码的脚本，在Firefox中返回正确的182（0xB6），但在Chrome中返回35386；移除注释行里的>相关实体后，Chrome也返回182，codePointAt()方法表现一致。

对应的HTML代码：

<!DOCTYPE html>
<html>
<body>
<p id="p"></p>
<script>
// a&gt;b
a = "¶ELLO";
b = a.charCodeAt(0);
document.getElementById("p").innerHTML = b;
</script>
</body>
</html>

原因分析 #

这不是Chrome的Bug，是浏览器对HTML脚本内容的编码解析逻辑差异，核心原因如下：

1. HTML实体的预解析：HTML解析器会先于JavaScript引擎处理<script>标签内的内容，所有&开头的HTML实体（比如>）都会被先解析成对应字符（这里是>），不管它在注释里还是代码里。
2. 编码解析的差异：
   • 你的HTML文件大概率是以GBK（或兼容的GB2312/GB18030）编码保存的，¶在该编码中是单字节0xB6，但GBK是双字节编码，0xB6属于双字节字符的起始字节。
   • Firefox处理<script>内容时，默认按Latin-1（ISO-8859-1）编码解析，0xB6直接对应Unicode字符¶（U+00B6），所以返回182。
   • Chrome在解析到注释里的>实体后，编码解析逻辑出现细节变化，将后续的0xB6（¶的字节）和下一个字节0x45（E的字节）组合成GBK双字节字符0xB645，对应Unicode的U+8A3A（十进制35386），所以返回这个值。
3. 移除>后的变化：去掉注释里的>后，Chrome的编码解析逻辑恢复正常，0xB6被正确识别为单字节的¶，所以返回182。

解决方案 #

要避免这种跨浏览器差异，建议：

• 在HTML头部明确指定编码，比如添加<meta charset="UTF-8">，确保所有浏览器按统一编码解析文件。
• 直接在<script>中使用原始字符（比如写// a>b而非// a>b），避免HTML实体干扰解析。

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