网站首页 > 博客文章 正文
前言
其实这是个老生常谈的问题了,相信大家在第一次遇到Unicode编码问题时,都会在网上搜索一通,
找到几个解释,虽然有点杂乱,但还是感觉自己明白了些什么,然后就继续忙别的事情.
而我之所以就这个问题专门写一篇文章,原因是前两天在与公司一位有十几年工作经验的JAVA程序员对接
API时, 我问他返回的汉字是什么编码的, 而他回答说"直接返回unicode". 一个如此有经验的老程序员
对这种基本问题都不甚清楚, 因此我觉得还是有必要好好说一下这个问题的.
字符集
在介绍他们之间的区别时, 我们先讲下什么是Unicode. 简单来说,Unicode是一个字符集(character set),
和ASCII一样, 其作用是用一系列数字来表示字符(character), 这些数字有时也称为码点(code points).
在PC刚出来的时候,使用英文的几位先驱认为计算机需要表示的字符不多,26个英文字母加几个回车换行等
特殊符号,总共一百个字符顶天了,于是就有了ASCII. ASCII码的大小为1个字节,定义了128个字符,
分别表示为0-127. 比如字符'A'的码点为65,回车符'\n'的码点为10, 如下所示:
当然, 后来人们发现, 世界上的字符远远不止128个, 因此就需要一个新的字符集能表示世上所有的字符,
包括一个英文字符,一个汉字字符,一个象形文字等. 这个字符集就是Unicode. Unicode前向兼容了ASCII,
最多可以表示2^21(大概200万)个字符,已经足够囊括当今所有国家的文字, 如下所示:
目前unicode字符集表示完所有字符后还有剩余, 这些暂时用不到的部分通常用占位符FFFD
表示.
字符编码
有了字符集, 我们现在可以用任意数字来表示现实中的字符了. 但字符要保存在计算机中,必须要先经过编码.
有人问, 数字直接保存在内存里不就行了吗? 但是用多少个字节表示一个数字,以及每个字节的范围这都是需要
预先约定的,这种约定就叫编码. 假如我们有四个数字,1,2,3,4要保存在计算机里, 如果约定了utf-8编码,
那么在内存中的表示则如下:
00000001 00000010 00000011 00000100
其他的编码规则有utf-16,gb2312,gbk等,具体的编码规则不在本文的范围内,想要深入了解的可以在网上查阅相关的文档.
因此,我们可以看到,如果不按照约定的规则来解码,就很有可能无法还原出原来的数据,也就是我们经常遇到的"乱码".
下面以几个例子来简单说明:
>>> u'你好'
u'\u4f60\u597d'
>>> u'你好'.encode('utf8')
'\xe4\xbd\xa0\xe5\xa5\xbd'
>>> u'你好'.encode('gbk')
'\xc4\xe3\xba\xc3'
>>> u'你好'.encode('utf8').decode('gbk')
u'\u6d63\u72b2\u30bd'
>>> print u'你好'.encode('utf8').decode('gbk')
浣犲ソ
如上面的代码所示, "你好"两个汉字字符的unicode分别为4f60和597d, utf-8编码后占6个字节, 而gbk编码后占4个字节.
如果用utf8编码后错误地用gbk来解码, 就会得到3个unicode码点,分别表示字符浣
,犲
和ソ
;而如果用gbk编码后
错误地用utf8来解码, 则在解码第二个字符时无法凑够3个字节, 因此会得到未知的结果, 甚至会因为内存越界访问引起程序异常.
注: 本文的python代码示例是在Linux Terminal下运行的, 因此默认为utf-8编码, 如果你是在Windows cmd里运行, 则通常默认GBK编码, 因此乱码会在不同地方出现:)
知道字符编解码的用法之后,我们就可以解释一下常见的一些乱码由来了, 比如在Windows下,未初始化的栈会初始化为0xcc, 未初始化的堆内存会初始化为0xcd, 可以看到前者为'烫'的gbk编码,而后者正好为'屯'的gbk编码, 如下所示:
u'\ufffd'
>>> u'烫'
u'\u70eb'
>>> u'烫'.encode('gbk')
'\xcc\xcc'
>>> u'屯'
u'\u5c6f'
>>> u'屯'.encode('gbk')
'\xcd\xcd'
前面也说过, unicode暂时没用到码点会用占位符FFFD来表示, 如果这个占位符被错误解析, 就会被当作有意义的内容了:
>>> u'\uFFFD'.encode('utf8')
'\xef\xbf\xbd'
>>> u'锟斤拷'.encode('gbk')
'\xef\xbf\xbd\xef\xbf\xbd'
>>> print (u'\uFFFD'.encode('utf8')*2).decode('gbk')
锟斤拷
可以看到,汉字"锟斤铐"(Unicode)的gbk编码分别为\xef\xbf, \xbd\xef和\xbf\xbd, 正好是unicode码FFFD的utf8编码 的叠加, 因此如果平时遇到多个utf8编码的Unicode占位符且不巧用了gbk的方式解码,那就会看到熟悉的锟斤铐了.
其他
在Windows的Notepad.exe中, 保存文件的格式可以看到有如下几种:
可刚刚不是说Unicode只是字符集吗, 为什么上面显示可以保存为Unicode"编码"? 好吧, 其实这是Windows在命名上一个操蛋的
地方. 因为Windows内部使用UTF-16小端(UTF-16LE)作为默认编码,并且认为这就是Unicode的标准编码格式. 在Windows的世界中,
存在着ANSI字符串(在当前系统代码页中, 不可拓展),以及Unicode字符串(内部以UTF16-LE编码保存). 因此notepad里所说的
Unicode大端,其实就是UTF16-BE.
这其实也不怪Windows, 因为这是在Unicode出现的早期设计的, 那时我们还没意识到UCS-2的不足, 而且UTF-8还没有被发明出来. 这也是为什么Windows对UTF8的支持如此之差的原因之一吧.
后记
说了这么多, 现在让我们回到一开始的问题, 如果有人问你"Unicode,GBK和UTF-8有什么区别?", 我想你应该知道该怎么回答了吧: Unicode是 一种字符集, 而GBK和UTF-8都是编码, 因此Unicode和后两者不是一类事物, 是无法进行对比的.
博客地址:
- pannzh.github.io
- 有价值炮灰-博客园
猜你喜欢
- 2025-05-16 网络技术领域端口号备忘录,受益匪浅 !
- 2025-05-16 实现多态必须满足什么条件
- 2025-05-16 新手小白如何用STM32F103C8T6打造自己的开发板
- 2025-05-16 常见的 Ethernet II 报文类型(EtherType)及其对应的 十六进制值
- 2025-05-16 阿波罗 STM32F767 开发板资料连载第四十六章 NAND FLASH 实验
- 2025-05-16 基于c51单片机的智能温度控制系统设计与实现(含代码)
- 2025-05-16 基于msp430单片机1602 DS1802温度显示
- 2025-05-16 CPU缓存一致性:从理论到实战
- 2025-05-16 正点原子STM32F4/F7水星开发板资料连载第四十四章NAND FLASH实验
- 2025-05-16 D/A转换器DAC0832的应用
你 发表评论:
欢迎- 367℃用AI Agent治理微服务的复杂性问题|QCon
- 359℃手把手教程「JavaWeb」优雅的SpringMvc+Mybatis整合之路
- 358℃初次使用IntelliJ IDEA新建Maven项目
- 351℃Maven技术方案最全手册(mavena)
- 348℃安利Touch Bar 专属应用,让闲置的Touch Bar活跃起来!
- 346℃InfoQ 2024 年趋势报告:架构篇(infoq+2024+年趋势报告:架构篇分析)
- 345℃IntelliJ IDEA 2018版本和2022版本创建 Maven 项目对比
- 342℃从头搭建 IntelliJ IDEA 环境(intellij idea建包)
- 最近发表
- 标签列表
-
- powershellfor (55)
- messagesource (56)
- aspose.pdf破解版 (56)
- promise.race (63)
- 2019cad序列号和密钥激活码 (62)
- window.performance (66)
- qt删除文件夹 (72)
- mysqlcaching_sha2_password (64)
- ubuntu升级gcc (58)
- nacos启动失败 (64)
- ssh-add (70)
- jwt漏洞 (58)
- macos14下载 (58)
- yarnnode (62)
- abstractqueuedsynchronizer (64)
- source~/.bashrc没有那个文件或目录 (65)
- springboot整合activiti工作流 (70)
- jmeter插件下载 (61)
- 抓包分析 (60)
- idea创建mavenweb项目 (65)
- vue回到顶部 (57)
- qcombobox样式表 (68)
- vue数组concat (56)
- tomcatundertow (58)
- pastemac (61)
本文暂时没有评论,来添加一个吧(●'◡'●)