0x9d在英语的哪种8位类似ASCII的字符集中有意义？
我正在清理一些旧的数据文件，并偶尔在其他ASCII文本中找到0x9d。 (不，它不是UTF-8。)
在Windows-1252中无效。 Python的“latin-1”编解码器将其转换为Unicode 0x9D，即"Operating System Command"。那没有什么意义。在Unicode中，您会得到一个带有[009d]的框。 (在Python中，您可以将任何内容转换为Latin-1而不会引发错误，但这并不意味着这样做很有意义。)
我正在清理一个杂乱的数据库中带有Python类型转义的示例，该数据库结合了许多来源的文本:
Guitar Pro, JamPlay, RedBana\\\'s Audition,\x9d Doppleganger\x99s The Lounge\x9d or Heatwave Interactive\x99s Platinum Life Country,\\"
for example \\"I\\\'ve seen the bull run in Pamplona, Spain\x9d.\\" Everything
Netwise Depot is a \\"One Stop Web Shop\\"\x9d that provides sustainable \\"green\\"\x9d living
are looking for a \\"Do It for Me\\"\x9d solution
从上下文来看，我怀疑™或®。但是那些是什么8位代码呢？
最佳答案
这是一个完全荒谬的假设:
某些在此数据上使用过的(确实损坏过的)系统尝试将每个字符写为UTF-8，但实际上只写了每个序列的最后一个字节(也许在某处有一个奇怪的一字节长的缓冲区)。另外，它过去使用的是UTF-8，但是有人用不同的编码查看它，然后执行了搜索替换操作以删除字节0xE2 0x80，因为它们显然“不属于”并且没有意识到其余的“特殊字符”也不是他们想要的。
ASCII当然会通过，因为它的UTF-8编码将是一个字节长。
``正确的单引号''(U + 2019)’以UTF-8编码，字节0xE2 0x80 0x99。您拥有\x99s的地方就是让我走这条路的原因，因为在流行的文字处理软件中，s之前的撇号通常会转换为正确的弯引号。如果只保存了字符的最后一个字节，则那里只有0x99。
“正确的双引号”(U + 201D)”用UTF-8编码，字节为0xE2 0x80 0x9D。文本中的0x9D通常位于双引号字符串的结尾。而且，它通常在常规的直接"双引号旁边。我想知道是否有人试图对数据进行某种事先的清理传递，并设法将其放回结束报价中，但是却在其中留下了“怪异” 0x9D。
就像我说的那样，这是一个疯狂的假设，但是如果这是来自各种旧系统的数据的汇总，那么很难知道到底发生了什么。 UTF-8的最后一个字节只是最接近的“常规”英语编码，我发现它在英文文本中会包含一些合理的内容，并包含您要查找的字节。
关于python - 0x9d在哪个8位字符集中有意义？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/45749093/