问如果表示JavaScript正在使用utf-8编码而不是utf-16

EN

元中的字符集

HTML告诉<meta charset=“utf-8”> (不那么草率地说: HTML解析器)页面的编码是utf8。

JS没有内置的工具来在不同的字符串编码之间切换-它始终是utf-16。

渐近界

我不认为编码转换会有O(n)方面的损失。每当这种编码更改到期时，就已经有了一个O(n)操作:读/写数据流。因此，每个二进制八位数上的任何固定数量的操作仍然是O(n)。编码更改只需要本地知识，即。仅具有固定长度的前瞻窗口，因此可以以O(1)的代价并入流读/写代码中。

您可以争辩说，空间惩罚是O(n)，尽管如果需要以任何标准编码存储字符串(即。在没有压缩的情况下)，移动到utf-16意味着最大因子为2，从而保持在O(n)界限内。

常量因子

即使关注的是最小化隐藏在O(n)表示法中的恒定因素，编码更改也会产生适度的影响，至少在时间域中是这样。对于大部分(西方)文本数据，以utf-8格式写入/读取utf-16流意味着每隔一秒跳过一次八位字节/插入空八位字节。与与套接字或文件系统连接所产生的开销和延迟相比，这种性能影响相形见绌。

当然，存储是不同的，尽管今天的存储相对便宜，并且2的上限仍然有效。从32位移动到64位对数字表示和指针有更高的内存影响。

JavaScript使用UTF-16

HTML5使用UTF-8

您的meta标记设置适用于HTML5编码，这是可选的，因为大多数现代浏览器都知道HTML5是UTF8。但是，它与JavaScript编码无关，也不会更改或影响JavaScript，只会告诉它使用UTF8编码对页面进行解码。

大多数现代Javascript引擎的工作方式是，它们确实读取UTF-8脚本、HTML标记和页面文本，并将其解码为UTF-16。但由于速度和其他原因，它们通常以原生形式存储第一个ASCII集(英语字符和数字)，或者像UTF-8或您的网页那样以一个字节的形式存储。这不是一个硬性的规则。因此，由Javascript读取和存储的HTML标签可能仍然存储在一个字节中，而不是V8 -16。

就存储在UTF-8中的大多数ASCII字符而言，这些脚本引擎背后发生的事情并不是您应该担心的。只有在流式传输更复杂的Unicode字符的上层“平面”时才会遇到问题。我读到过，Javascript存储和编码的UTF-16特征是可变的。在我看来，在你熟悉上层Unicode语言和Javascript中的字符集操作之前，这并不是大多数web开发人员需要担心的事情。这就是Node和许多开源引擎在解码和编码UTF-8和UTF-16方面所面临的困难，因为它们依赖于Javascripting引擎。

同样，因为现在一切都转向UTF-8编码(其中1-4字节可用于编码完整的Unicode字符集，而UTF-16从2字节集开始并向上)，您将看到Javascript处理所有UTF-8到UTF-16的解码，然后作为一个非常无缝的过程返回，其中有很多应急措施。

BTW....the的方式脚本引擎读取或弄清楚你的Javascript文件在UTF8编码，是Javascript首先侦听mime类型或“内容类型”和字符集的头部来自服务器，以查看所有的网页文件应该解码。如前所述，现在HTML5中几乎总是使用UTF-8。如果无法确定类型，则接下来检查脚本的<script>标记及其mime类型和/或字符集的自定义类型属性，以查看javascript源文件是否设置了该类型。在大多数情况下，这些都会丢失。最后，它检查网页的meta标签字符集，如果是UTF-8，或者如果使用了HTML5，则假定为UTF-8。脚本文件上也有“字节顺序标记”，很可能是UTF-8。即使它是用ASCII或者说拉丁文-1编码的，也可以直接翻译成UTF-8。一旦知道了编码，Javascript就会解码这些位，并将它们编码成如上所述的自己的2字节集。

在一天结束的时候，引擎为你做了很好的谈判工作。