String.fromCharCode vs output from &#(charcode);

String.fromCharCode vs output from &#(charcode);

本文关键字：charcode amp fromCharCode vs output from String      更新时间：2023-09-26

谁能解释一下为什么我看到在127和160之间的代码中使用String.fromCharCode(charcode)和打印出&#charcode;之间的输出差异?在firefox, chrome, mac/win和ie上，两者的输出对于数千个其他值是相同的，但不是该范围内的代码。从fromCharCode()中输出字符串将在该范围内创建缺失字符。

如果你想特别遇到这种情况，这里有一些来源。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" 
"http://www.w3.org/TR/1998/REC-html40-19980424/loose.dtd">
<HTML LANG="en">
<HEAD>
<TITLE></TITLE>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="author" content="(cogknight@yahoo.com)">
<META name="date" content="Tue Oct 25 02:35:44 CDT 2011">  
<STYLE TYPE="text/css">
BODY { font-family: helvetica, sans-serif; }
table { border: 1px solid black; }
td { border: 1px solid black; }
</STYLE>
<SCRIPT TYPE="text/javascript">
function init()
{
   var elem = document.getElementById('msg');
   var msg = "<TABLE STYLE='border:1px solid black;'>";
   msg += "<tr><th>code</th><th>fromCharCode</th><th>ampersand</th></tr>";
   var ccode = 0;
   for (;ccode < 180; ccode++)
   {
      msg += "<TR><TD>";
      msg += ccode;
      msg += "</TD><TD>";
      msg += String.fromCharCode(ccode);
      msg += "</TD><TD>";
      msg += "&#" + ccode + ";";
      msg += "</TD</TR>";
   }
   msg += "</TABLE>";
   elem.innerHTML = msg;
}
</SCRIPT>
</HEAD>
<BODY>
<DIV ID="msg">
</DIV>
<SCRIPT>
init();
</SCRIPT>
</BODY>
</HTML>

谢谢你的时间，BBB

我至少在运行Chrome和Firefox的Mac上验证了http://jsfiddle.net/E8S9J/上的输出。

右列显示了邪恶的Windows-1252字符集的输出。

您可以在这里看到0x80-0x9F(128-159)范围内的字符的问题:http://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT

有趣的是，JavaScript String.fromCharCode从代码中生成正确的字符，而HTML实体却没有。浏览器就是这样做的，尽管它们可能不应该这样做。以下是维基百科的解释:

使用HTML数字字符引用，如¡一些旧的浏览器错误地将128-159范围内的代码解释为对本机字符集的引用;但是，数字字符引用是HTML中输入没有命名实体的特殊字符的唯一方法，例如土耳其字母。由于代码点128到159在ISO-8859-1和Unicode中都不用于可显示的字形，因此在该范围内的字符引用(例如ƒ)在HTML中是非法的并且是不明确的，尽管它们被许多网站普遍使用。几乎所有的浏览器都将ISO-8859-1视为Windows-1252，在该空格中确实有可打印的字符，并且它们经常出现在英语项目的文章标题中，这在试图创建到上述页面的跨wiki链接时确实造成了混乱。

我认为浏览器制造商这样做是因为他们认为很多网页作者不懂字符编码，无论如何都会使用Windows-1252字符集(不得不把那些旧的微软Word文档"放在网上")。HTML本质上是非常非常宽容的。它试图做到最好，即使在所有的加价都被打击。使用这个范围内的实体(毕竟它们是控制字符)有点乱，所以宽容的浏览器会显示它所能显示的，，即使它必须显示作者不想要的字符集中的字形

128-159不是unicode字符。

我的猜测:在javascript领域，字符被解释为utf-16，所以128-159是一种"合法的非字符"。在html领域，utf-8为王(假设您使用的是utf-8)，因此单字节字符的最后一位必须始终为零，这意味着这些字符最多只能达到127(有点像有一个符号位)。如果你想检查，你可以看到'10000000'在二进制中等于128。

因此，在utf-8中，由于编码的机制，在128-159范围内的字符是不可能的。在utf-16中，可以表示该范围内的一个字符，即使该范围内不存在字符。

相关文章：