windows 记事本中出现奇怪的 utf8 解码错误
Strange utf8 decoding error in windows notepad
如果您将以下字符串键入一个使用 utf8（无 bom）编码的文本文件并使用 notepad.exe 打开它，您将在屏幕上看到一些奇怪的字符。但是记事本其实可以在没有最后一个'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 错误还是我可以做些什么来解决这个问题。
做了更多研究；想通了。
似乎是 "Bush hid the facts" 经典案例的变体。
https://en.wikipedia.org/wiki/Bush_hid_the_facts
看起来记事本在保存文件时使用的默认字符编码与打开文件时使用的默认字符编码不同。是的，这确实像是一个错误。
但是对于正在发生的事情有一个实际的解释：
记事本检查 BOM 字节序列。如果找不到，它有 2 个选项：编码是 UTF-16 Little Endian（无 BOM）或纯 ASCII。它首先使用名为 IsTextUnicode 的函数检查 UTF-16 LE。
IsTextUnicode 运行一系列测试以猜测给定文本是否为 Unicode。其中一项测试是 IS_TEXT_UNICODE_STATISTICS，它使用统计分析。如果测试为真，则给定的文本可能是 Unicode，但不能保证绝对确定。
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-istextunicode
如果 IsTextUnicode returns 为真，记事本将使用 UTF-16 LE 对文件进行编码，从而产生您看到的奇怪输出。
我们可以用这个字ㄠ来证实这一点。其对应的ASCII字符为'1'（space一个）；这些 ASCII 字符对应的十六进制值是 space 的 0x20 和一个的 0x31。由于字节顺序是 Little Endian，因此 Unicode 代码点的顺序将是“1”或 U+3120，如果您查找该代码点就可以确认。
https://unicode-table.com/en/3120/
如果你想解决这个问题，你需要打破帮助 IsTextUnicode 确定给定文本是否为 Unicode 的模式。您可以在文本前插入一个换行符来打破这种模式。
希望对您有所帮助！
如果您将以下字符串键入一个使用 utf8（无 bom）编码的文本文件并使用 notepad.exe 打开它，您将在屏幕上看到一些奇怪的字符。但是记事本其实可以在没有最后一个'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 错误还是我可以做些什么来解决这个问题。
做了更多研究；想通了。
似乎是 "Bush hid the facts" 经典案例的变体。 https://en.wikipedia.org/wiki/Bush_hid_the_facts
看起来记事本在保存文件时使用的默认字符编码与打开文件时使用的默认字符编码不同。是的，这确实像是一个错误。
但是对于正在发生的事情有一个实际的解释：
记事本检查 BOM 字节序列。如果找不到，它有 2 个选项：编码是 UTF-16 Little Endian（无 BOM）或纯 ASCII。它首先使用名为 IsTextUnicode 的函数检查 UTF-16 LE。
IsTextUnicode 运行一系列测试以猜测给定文本是否为 Unicode。其中一项测试是 IS_TEXT_UNICODE_STATISTICS，它使用统计分析。如果测试为真，则给定的文本可能是 Unicode，但不能保证绝对确定。
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-istextunicode如果 IsTextUnicode returns 为真，记事本将使用 UTF-16 LE 对文件进行编码，从而产生您看到的奇怪输出。 我们可以用这个字ㄠ来证实这一点。其对应的ASCII字符为'1'（space一个）；这些 ASCII 字符对应的十六进制值是 space 的 0x20 和一个的 0x31。由于字节顺序是 Little Endian，因此 Unicode 代码点的顺序将是“1”或 U+3120，如果您查找该代码点就可以确认。
https://unicode-table.com/en/3120/
如果你想解决这个问题，你需要打破帮助 IsTextUnicode 确定给定文本是否为 Unicode 的模式。您可以在文本前插入一个换行符来打破这种模式。
希望对您有所帮助！