Windows记事本中的奇怪utf8解码错误

Question

如果您在用utf8（没有bom）编码的文本文件中键入以下字符串并使用notepad.exe打开它，您将在屏幕上获得一些weired字符。但是记事本实际上可以很好地解码这个字符串而没有最后一个'a'。非常奇怪的行为。我使用的是Windows 10 1809。

[19, 16, 12, 14, 15, 15, 12, 17, 18, 15, 14, 15, 19, 13, 20, 18, 16, 19, 14, 16, 20, 16, 18, 12, 13, 14, 15, 20, 19, 17, 14, 17, 18, 16, 13, 12, 17, 14, 16, 13, 13, 12, 15, 20, 19, 15, 19, 13, 18, 19, 17, 14, 17, 18, 12, 15, 18, 12, 19, 15, 12, 19, 18, 12, 17, 20, 14, 16, 17, 18, 15, 12, 13, 19, 18, 17, 18, 14, 19, 18, 16, 15, 18, 17, 15, 15, 19, 16, 15, 14, 19, 13, 19, 15, 17, 16, 12, 12, 18, 12, 14, 12, 16, 19, 12, 19, 12, 17, 19, 20, 19, 17, 19, 20, 16, 19, 16, 19, 16, 12, 12, 18, 19, 17, 18, 16, 12, 17, 13, 18, 20, 19, 18, 20, 14, 16, 13, 12, 12, 14, 13, 19, 17, 20, 18, 15, 12, 15, 20, 14, 16, 15, 16, 19, 20, 20, 12, 17, 13, 20, 16, 20, 13a

我想知道这是一个Windows bug还是我可以做些什么来解决这个问题。

Answer 1

做了更多研究;弄清楚了。

似乎是“布什隐瞒事实”的经典案例的变体。 https://en.wikipedia.org/wiki/Bush_hid_the_facts

看起来像记事本有一个不同的字符编码默认用于保存文件，而不是打开文件。是的，这似乎是一个错误。

但是对于正在发生的事情有一个实际的解释：

1. 记事本检查BOM字节序列。如果找不到，则有2个选项：编码为UTF-16 Little Endian（无BOM）或纯ASCII。它首先使用名为IsTextUnicode的函数检查UTF-16 LE。
2. IsTextUnicode运行一系列测试来猜测给定的文本是否为Unicode。其中一个测试是IS_TEXT_UNICODE_STATISTICS，它使用统计分析。如果测试为真，那么给定的文本可能是Unicode，但不能保证绝对确定性。 https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-istextunicode
3. 如果IsTextUnicode返回true，则Notepad会使用UTF-16 LE对文件进行编码，从而产生您看到的奇怪输出。我们可以用这个角色来确认这个。其对应的ASCII字符为'1'（空格一）;这些ASCII字符的相应十六进制值对于空间为0x20，对于一个为0x31。由于字节顺序是Little Endian，因此Unicode代码点的顺序将为“1”或U + 3120，您可以确认是否查找该代码点。 https://unicode-table.com/en/3120/

如果要解决此问题，则需要中断模式，以帮助IsTextUnicode确定给定文本是否为Unicode。您可以在文本前插入换行符以打破模式。

希望有所帮助！