笔记：“锟斤拷”究竟是怎么回事？

预览

最近用vscode编辑代码，中文总是变成乱码“锟斤拷”，无法恢复。

思考了一下，按理说就算别识别成另一种编码，我换成正确编码应该是能够正常显示的，但结果是不能。

所以究竟发生了什么？

这次终于认真研究了一下，用010editor对比二进制数据，终于发现…

数据已经改变了，还有一些特征。

//内存基址//锟节达拷锟街?

C4 DA | B4 E6 | BB F9 | D6 B7
EF BF BD DA | B4 EF BF BD | EF BF BD | D6 B7

对比之后发现，某些字节还是原始的，某些字节替换成了EF BF BD。

百度一搜EF BF BD，发现原来是这样的。

在众多的utf-8码点值中，除了ascii，你还应该记住「EF BF BD」，因为它是很多编程语言以及库中的备胎，即无效的码点值在编码的时候会默认用这个码点值进行替换，即utf-8中的超级「备胎」(REPLACEMENT CHARACTER)。utf-8 神秘符号 efbf bdef bfbd很多时候我们在打开utf-8的时候会有 � 等很多像问号的编码出现这时候我们打开这个文件的二进制就会发现 问号对应的十六进制编码就是efbf bdef bfbd。这个编码到底是什么呢？为什么会有这种编码呢。这就要从各种编码格式的转换说起。而且大部分出现这种问题的就是用gbk编码的文件用utf-8编码格式打开。当编码格式中出现utf-8无法解析的字节，那么这个字节就会被替换成 efbf bdef bfbd 这时我们会发现文件大小也发生了改变，因为未知字节全部变成三个未知字节。而这时候再将其转换为gbk锟 (0xEFBF)，斤（0xBDEF），拷（0xBFBD） 这就是 锟斤拷 那么我是在什么时候发现这个问题：python 的 print 我们一般都会把python代码设置成全局utf-8编码。这时候如果你收到的是一个gbk的编码，但是直接打出来。就会发现出现很多问号。这个时候直接复制粘贴再看二进制就不是真正接受的数据。因为print自动将收到的数据进行了utf-8解码。这样无法解析的编码就变成efbf bdef bfbd。所以在遇到乱码的时候就需要在数据的原始接受处，及第一次转码发生之前将数据用二进制写入文件留存

所以，本来代码使用的gbk（其实是ansi）编码保存的，用vscode打开时，自动识别成了utf8，也没注意到乱码了，只要此时一保存，完了。

已经被换成了锟斤拷（重新用gbk打开看到是锟斤拷）。

so，使用vscode的时候要注意打开编码是否正确，如果遇到此种情况，如法恢复。

因为替换成了EF BF BD，没法知道原始数据是什么。

最后就是吐槽，vscode识别编码（Auto Guess Encoding并不好用，经常会被识别成Windows 1252）不准确，相比来说notepad++这方面做的不错。