ISO-8859-1 乱码解码

0
  • 字符编码：
0

说明

ISO-8859-1 编码范围使用了单字节内的所有空间，在支持 ISO-8859-1 的系统中传输和存储其他任何编码的字节流都不会被抛弃。
换言之，把其他任何编码的字节流当作 ISO-8859-1 编码看待都没有问题。 这是个很重要的特性，MySQL 数据库默认编码是 Latin1 就是利用了这个特性。ASCII 编码是一个 7 位的容器，ISO-8859-1 编码是一个 8 位的容器。
用 Latin 1 存储中文有没有问题？答案是没有问题，但是并不建议。
因为如此数据库层面不再提供任何正确的字符语义，排序、比较、长度、函数结果全部错乱。
例如你把 UTF-8 编码的“中”字（UTF-8 编码为 0xE4B8AD，占三个字节）存入了 Latin 1 编码的 Mysql 表，那么在 Mysql 眼里，你存入的并不是一个“中”字，而是三个 Latin 1 的字母（0xE4，0xB8，0xAD）。本质上，你存的数据值依然是 0xE4B8AD，这种“欺骗”Mysql 的行为并没有导致数据丢失，只不过你需要注意读取出来该值的时候，自己要以 UTF-8 编码的方式显示出来，要不然就是乱码。
所以这个工具的作用就是先把乱码（实际是 Latin 字符）转成十六进制，然后再选择合适的字符集解码成原始的字符。比如汉字“中”，以 UTF-8 编码之后是 0xE4B8AD，再以 ISO-8859-1 编码显示是 中。还原的步骤就是把中以 ISO-8859-1 编码成十六进制得到 E4B8AD，再以 UTF-8 解码就得到原始的汉字“中”。
使用 C# 还原乱码示例： 
byte[] raw = Encoding.GetEncoding("ISO-8859-1").GetBytes("中");
string result = Encoding.UTF8.GetString(raw);
Console.WriteLine(result);
乱码总结
  • 你看到的“ISO-8859-1 乱码”几乎 100 % 并不是真的 ISO-8859-1，而是 “本来应该是 UTF-8（或 GBK）的字节流，被终端/浏览器/数据库按 ISO-8859-1 解码了”。
  • 因此“解码”要做的其实是把误用的 ISO-8859-1 还原成原始字节流，再重新用真正的编码去解析。
  • 只要字节还在，这个过程可逆，不会丢信息；一旦中间某个环节把字节转成了“字符”并做了转码，就可能永远救不回来。