Lab1-Misc Report¶

Task 1.1：乱码情形探究¶

这里我们把 python，vscode，CyberChef 都尝试一下，输出不同的就都截图放在报告里，相同的就只选择 python 的输出结果了。

乱码情况 1：用 GBK 解码 UTF-8 编码的文本¶

首先我们知道 utf-8 与 GBK 两种编码方式都是兼容 ASCII 码的，都是使用一个字节来表示 ASCII 码能表示的字符。

因此对于大小写字母这些包含在 ASCII 码中的两者转换并没有区别。

在 utf-8 编码中，汉字是用 3 个字节来表示的，特殊的汉字还会用 4 个字节来表示，于是“战队”二字在 utf-8 编码下就形成了 6 个字节。

但是在 GBK 编码中，一个汉字是用 2 个字节来表示的，于是对于 utf-8 形成的 6 个字节的编码在 GBK 中就会被解码为 3 个汉字，形成乱码问题。

乱码情况 2：用 UTF-8 解码 GBK 编码的文本¶

跟 1.1 中的解释相似，GBK 编码将"战队"编码为 11010101 10111101 10110110 11010011，而对于 utf-8 编码来说，第一个字节前三位为 110，这意味着这个字符应当是两个字节来保存的，因此 utf-8 将前两个字节编为一个字符，但是第三个字节前两位却显示的是 10，utf-8 就不知道该怎么解码了，因此在 python 中会显示 UnicodeDecodeError；CyberChef 则将错误的字节解码为了其他奇怪的字符；而 vscode 则将其解码为奇怪的符号。

乱码情况 3：用 latin-1 解码 UTF-8 编码的文本¶

Latin-1，即 ISO-8859-1，是单字节编码，本身无法表示中文。由上面所说的，utf-8 将每个汉字编码为三个字节，因此用 Latin-1 解码 utf-8 编码的文本会出现 6 个奇怪的字符。

乱码情况 4：用 latin-1 解码 GBK 编码的文本¶

同理，GBK 将每个汉字编码为两个字节，因此用 Latin-1 解码 utf-8 编码的文本会出现 4 个奇怪的字符。

乱码情况 5：先用 GBK 解码 UTF-8 编码的文本，再用 UTF-8 解码前面的结果¶

这里我们只使用 vscode 实现（python 在该文本下 GBK 解码就报错，无法解码）

原文本：

GBK 解码：

重新用 GBK 编码再用 utf-8 解码：

可以看到，“逼”这一个字被编成了奇怪的字符，我们查看原文本与最后文本的十六进制：

这是可以解释的，在起初“牛逼”二字被编码为 11100111 10001001 10011011 111010001 10000000 10111100 ，用 GBK 解码时会被错误地解释为其他字符或者无法识别的字节序列（这也就是为什么 python 会报错），那么解码后的十六进制就已经编成了下面的那些，最后 utf-8 转换时也就出现了乱码。

先用 UTF-8 解码 GBK 编码的文本，再用 GBK 解码前面的结果¶

原文本：

utf-8 解码：

再用 GBK 解码：

锟斤拷乱码出现了！我们查看十六进制：

根据 1.2 也可以解释这个，因为 utf-8 特定的编码格式，导致解码时有些字符无法被解读，而 vscode 将错误的字节流替换，才得到了现在的乱码。

研究后的讨论¶

可恢复？¶

从之前的研究来看，不可恢复的情况在于解码时若遇到不存在于解码格式当中的十六进制字节流时，vscode 会进行篡改使得其符合解码格式，这样就造成了不可恢复。而且我们默认解码之后同时用这种编码方式重新编码，并保存字节流到文件。那理论上来说，以上六种乱码形式都有不可恢复的可能，因为重新编码会导致篡改的发生。

“锟斤拷”？¶

“锟斤拷”乱码的来源就在于 utf-8 特殊的编码格式，当解码时有些字符不符合编码格式时，无法匹配到正确的 utf-8 码，vscode 会将其填充为 EF BF BD。我们假设有三个连续的字符不符合编码格式，那么最后填充完得到的字节流是 EF BF BD EF BF BD EF BF BD EF BF BD，在GBK编码表中，查找对应编码，并解码为汉字，由于 EF BF 对应锟，BD EF 对应斤，BF BD对应拷，从而得到“锟斤拷锟斤拷”。