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

问题描述 投票:0回答:1

如果您在用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还是我可以做些什么来解决这个问题。

windows utf-8 character-encoding notepad
1个回答
0
投票

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

似乎是“布什隐瞒事实”的经典案例的变体。 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。您可以在文本前插入换行符以打破模式。

希望有所帮助!

© www.soinside.com 2019 - 2024. All rights reserved.