那么乱码是如何产生的,并且如何修复呢?我们接下来就一步步对此进行解释编码规则字符串,本质上都是一个字节一个字节的数据,连在一起存储的。
而要将这些数据显示在屏幕上,则需要按一种编码规则进行解析。
ASCIIASCII编码是最容易理解的。
ASCII编码因为每个字符仅占用7bit,所以最多只能存储127个字符,而每个字符都有唯一的一个数字与其对应。
例如:数字0x35在这种编码规则下,会被解析为字符5数字0x6C在这种编码规则下,会被解析为字符l数字0x4C在这种编码规则下,会被解析为字符L具体对应规则,可以在网上搜索ASCII 码表查看按照这种规则,一串hello,用16进制数据表示就是68 65 6C 6C 6FGB2312因为ASCII只能显示127个字符,远远不能满足中文字符的显示需求,所以中国国家标准总局于1980年发布了国家标准代码 GB 2312 标准(目前最新标准为 GB 18030)简单来说,在这套编码规范下,每个中文字符可以由2个字节表示,例如:啊的实际数据为0xB0 0xA1测的实际数据为0xB2 0xE2试的实际数据为0xCA 0xD4同时,因为ASCII编码下每字节使用了7bit(0x00-0x7f),GB2312为了对其进行兼容,规定每个中文字符的高位字节(第一个字节)使用0xA1–0xF7的范围,避开了ASCII编码使用的区域。
也就是说,想下面的一串混用了中英文的数据,也可以正常被解析并显示出来:UTF-8UTF-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编码存储数据
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)