转变养殖方式才能够成功逆袭(养殖转型)
2024-05-04
更新时间:2024-05-04 09:01:57作者:未知
相信大家在日常生活中,都见过类似下面的这些类似的字符串:
上面这种,看起来不明所以的内容,通常被称作乱码。那么乱码是如何产生的,并且如何修复呢?我们接下来就一步步对此进行解释
编码规则
字符串,本质上都是一个字节一个字节的数据,连在一起存储的。而要将这些数据显示在屏幕上,则需要按一种编码规则进行解析。
ASCII
ASCII编码是最容易理解的。ASCII编码因为每个字符仅占用7bit,所以最多只能存储127个字符,而每个字符都有唯一的一个数字与其对应。
例如:
数字0x35在这种编码规则下,会被解析为字符5
数字0x6C在这种编码规则下,会被解析为字符l
数字0x4C在这种编码规则下,会被解析为字符L
具体对应规则,可以在网上搜索ASCII 码表查看
按照这种规则,一串hello,用16进制数据表示就是68 65 6C 6C 6F
GB2312
因为ASCII只能显示127个字符,远远不能满足中文字符的显示需求,所以中国国家标准总局于1980年发布了国家标准代码 GB 2312 标准(目前最新标准为 GB 18030)
简单来说,在这套编码规范下,每个中文字符可以由2个字节表示,例如:
啊的实际数据为0xB0 0xA1
测的实际数据为0xB2 0xE2
试的实际数据为0xCA 0xD4
同时,因为ASCII编码下每字节使用了7bit(0x00-0x7f),GB2312为了对其进行兼容,规定每个中文字符的高位字节(第一个字节)使用0xA1–0xF7的范围,避开了ASCII编码使用的区域。
也就是说,想下面的一串混用了中英文的数据,也可以正常被解析并显示出来:
UTF-8
UTF-8可以使用1-4字节来表示字符,因为其兼容性强,可以对Unicode字符集中的所有有效编码点进行编码,是目前使用最广泛的编码标准。
与GB2312一样,UTF-8同样兼容ASCII编码。只是UTF-8比GB2312包含了更多字符,并且每种字符的字节数并不是完全固定的。由于编码规则比较复杂,这里不作具体解释,只会举例说明:
啊的实际数据为0xE5 0x95 0x8A
测的实际数据为0xE6 0xB5 0x8B
试的实际数据为0xE8 0xAF 0x95
其他编码
除了GB2312、UTF-8和ASCII编码,还有许多编码标准,他们大部分互不兼容。
存储和传输字符串数据
数据都是要进行存储和传输的
存储
微软使用BOM 头这种技术来为纯文本文件标记其编码,这样打开文件时就可以用正确的编码进行解析。
而大部分Linux不使用类似技术,所以读取后只能靠猜测,或强行指定,来进行显示。
传输
传输不仅指字符串数据在互联网上的传输,也包括了在各类函数调用过程中的传输。这类操作通常都不会带有字符编码标准的标记,一般靠直接指定编码来解决。
产生乱码
聪明的你应该已经想到了,如果一串某编码的数据,被人使用另一种编码标准进行解析,那么得出的结果几乎一定是错误的。
比如测试解析结果这几个字,我们使用UTF-8编码,得到下面16进制数据:
如果,收到这些数据的人尝试使用GB2312编码来显示,那么结果就是我们非常熟悉的乱码了:
上面的过程就是典型的乱码形成过程
修复乱码
乱码是否可以还原?答案是肯定的,只需要按乱码形成时的操作反过来做一遍就可以恢复了。但是有些编码中会出现?这种无法解析显示的数据,这部分数据就完全丢失了。
一般的乱码修复操作,就是把各种编码可能性都试一遍,看哪个结果可靠,那么就是原始内容。
这里推荐使用开源的工具 llcom (llcom.papapoi.com),来进行乱码恢复工作
我们用上一节生成的乱码数据作为例子,尝试修复:
可以看到可靠的结果已经显示出来,修复成功
避免乱码
建议在写代码时统一使用UTF-8编码,这是目前互联网的最主要的编码形式
如果是资源占用紧张,但依旧需要中文显示的地方,可以考虑使用GB2312编码存储数据
本站发布的相关文章已登记【鲸版权】未经许可不得转载!否则本站有权进行维权!