Node.js对Unicode的支持有多好？
根据其语言规范， JavaScript在Unicode中有一些问题（如果我理解的话），因为文本总是作为一个由16位组成的内部字符处理。
JavaScript：好的部分以类似的方式说出来。
当你search谷歌的V8支持UTF-8，你会得到矛盾的说法。
那么：Node.js中Unicode支持的状态是什么（0.10.26是这个问题的当前版本）？ 它处理UTF-8将所有可能的代码点正确，或不是吗？
如果不是：可能的解决方法是什么？
你引用的两个来源， 语言规范和Crockford的“JavaScript：好的部分”（第103页）都是这样说的，尽pipe后者说得简明得多（显然，如果你已经知道这个话题）。 作为参考，我会引用克罗克福德：
JavaScript被devise的时候，Unicode预计最多有65,536个字符。 它已经发展到有超过100万字的能力。
JavaScript的字符是16位。 这足以覆盖原来的65,536（现在被称为基本多语言平面）。 每个剩余的百万字符可以表示为一对字符。 Unicode认为该对是单个字符。 JavaScript认为这对是两个截然不同的字符。
语言规范将16位单元称为“字符”和“代码单元”。 另一方面，“Unicode字符”或“代码点”可以（极less数情况下）需要两个16位“代码单元”来表示。
所有JavaScript的string属性和方法（如length ， substr()等）都使用16位“字符”（使用16位/ 32位Unicode字符（如UTF-16）字符）。 例如，这意味着，如果你不小心，用substr()你可以只留下一个32位UTF-16 Unicode字符的一半。 JavaScript不会抱怨，只要你不显示它，也许甚至不会抱怨，如果你这样做。 这是因为，正如说明书所说，JavaScript不检查字符是否是有效的UTF-16，它只是假定它们是。
在你的问题你问
[Node.js]处理UTF-8是否将所有可能的代码点正确，或不是？
由于在input之前所有可能的UTF-8码点都被转换为UTF-16（作为一个或两个16位“字符”），反之亦然，答案取决于“正确”的意思，但如果您接受JavaScript对“正确”的解释，则答案为“是”。
JavaScriptstringtypes是UTF-16，所以它的Unicode支持是100％。 所有的UTF格式都支持所有的Unicode代码点。
以下是常见forms的一般分类：
- UTF-8 – 8位代码单元; 可变宽度（代码点是1-4代码单元）
- UTF-16 – 16位代码单元; 可变宽度（代码点是1-2代码单元）; 大端或小端
- UTF-32 – 32位代码单元; 固定宽度; 大端或小端
当认为每个代码点都适合16位时，UTF-16被普及了。 此情况并非如此。 之后，UTF-16被重新devise，允许代码点采用两个代码单元，旧版本被重命名为UCS-2。
但是，事实certificate，可见宽度并不等同于内存存储单元，所以UTF-16和UTF-32的效用都是有限的。 自然语言是复杂的，在许多情况下，代码点序列以惊人的方式组合在一起。
“字符”的宽度的测量取决于上下文。 记忆？ 可见字素的数量？ 以像素渲染宽度？
UTF-16保持常用，因为当今许多stream行的语言/环境（Java / JavaScript / Windows NT）诞生于90年代。 它没有坏。 但是，UTF-8通常是首选。
如果您遇到数据丢失/损坏问题，通常是因为代码转换器存在缺陷或者误用了代码。