Question

我使用看似非标准但可以使用的字符进行故意错误：

var ᛨ={};
ᛨ.causeError()

Uncaught TypeError: è.causeError is not a function

显然ᛨ字符是è字符的版本

（utf-8正常文本字符a，b，c是文本）

VS

（非文本☎，®，෴，％）

è=== http://unicode-table.com/en/00E8/

Encoding      hex             dec (bytes)    dec            binary
UTF-8         C3 A8           195 168        50088          11000011 10101000
UTF-16BE      00 E8           0 232          232            00000000 11101000
UTF-16LE      E8 00           232 0          59392          11101000 00000000
UTF-32BE      00 00 00 E8     0 0 0 232      232            00000000 00000000 00000000 11101000
UTF-32LE      E8 00 00 00     232 0 0 0      3892314112     11101000 00000000 00000000 00000000

ᛨ=== http://unicode-table.com/en/16E8/

Encoding      hex            dec (bytes)     dec            binary
UTF-8         E1 9B A8       225 155 168     14785448       11100001 10011011 10101000
UTF-16BE      16 E8          22 232          5864           00010110 11101000
UTF-16LE      E8 16          232 22          59414          11101000 00010110
UTF-32BE      00 00 16 E8    0 0 22 232      5864           00000000 00000000 00010110 11101000
UTF-32LE      E8 16 00 00    232 22 0 0      3893755904     11101000 00010110 00000000 00000000

我没有看到相关性！

如何测试非标准字符以查看它们是否与普通文本字符相关？

我会寻找什么样的关系？

出于兴趣;这个Unicode问题是否记录在任何地方？

[此问题经过进一步思考后尚未完全解决（见评论）]

Answer 1

è'巧合'是西方ANSI编码中的字符E8，这也是您特殊字符的UTF-16代码点的第二个字节（以及UTF-16中的`è，顺便说一句。）

如果您使用的是源文件：您可能使用错误的编码保存了文件，可能是ANSI，可能是UTF-16。确保您的源文件以正确的编码保存。 “正确”编码几乎可以是任何东西（尽管建议使用UTF-8），只要它与您在文件中发送的Content-Encoding标头相匹配，它就可以包含您想要放入其中的每个字符。

如果你在控制台上工作：如果它只是控制台搞砸了，这仍然解释了这个问题。在内部，浏览器可能使用与UTF-8不同的编码，因为UTF-8对于传输是有效的，但是不方便使用。最有可能的是它使用UTF-16（或UCS2）。然后，您的角色将以双字节代码点16 E8进行编码。如果控制台尝试将每个字节显示为单独的字符，它将显示E8为'è'并完全跳过16，因为它历史上是ASCII控制字符（SYN，用于同步空闲）并不打算显示。

Answer 2

使用名为ಠ_ಠ的变量进行测试，错误消息包含“_”（空格下划线空格）。看起来编写错误消息的代码不支持尽可能多的字符。

控制台中也出现同样的问题，因此它不是文件编码问题。此外，在自动错误消息中管理字符时没有任何问题。即使写throw new Error("ಠ_ಠ");也没有问题。

这似乎是一个相当具体的错误，但它会影响Chrome和Firefox。

显然，一些非标准字符被视为常规字符

2 个答案: