zoukankan      html  css  js  c++  java
  • Unicode,GBK和UTF8

    前言

    其实这是个老生常谈的问题了,相信大家在第一次遇到Unicode编码问题时,都会在网上搜索一通,
    找到几个解释,虽然有点杂乱,但还是感觉自己明白了些什么,然后就继续忙别的事情.
    而我之所以就这个问题专门写一篇文章,原因是前两天在与公司一位有十几年工作经验的JAVA程序员对接
    API时, 我问他返回的汉字是什么编码的, 而他回答说"直接返回unicode". 一个如此有经验的老程序员
    对这种基本问题都不甚清楚, 因此我觉得还是有必要好好说一下这个问题的.

    字符集

    在介绍他们之间的区别时, 我们先讲下什么是Unicode. 简单来说,Unicode是一个字符集(character set),
    和ASCII一样, 其作用是用一系列数字来表示字符(character), 这些数字有时也称为码点(code points).
    在PC刚出来的时候,使用英文的几位先驱认为计算机需要表示的字符不多,26个英文字母加几个回车换行等
    特殊符号,总共一百个字符顶天了,于是就有了ASCII. ASCII码的大小为1个字节,定义了128个字符,
    分别表示为0-127. 比如字符'A'的码点为65,回车符' '的码点为10, 如下所示:

    >>> ord('A')
    65
    >>> ord('0')
    48
    >>> ord('
    ')
    10
    

    当然, 后来人们发现, 世界上的字符远远不止128个, 因此就需要一个新的字符集能表示世上所有的字符,
    包括一个英文字符,一个汉字字符,一个象形文字等. 这个字符集就是Unicode. Unicode前向兼容了ASCII,
    最多可以表示2^21(大概200万)个字符,已经足够囊括当今所有国家的文字, 如下所示:

    >>> u'ソ'
    u'u30bd'
    >>> u'龍'
    u'u9f8d'
    >>> u'A'
    u'A'
    

    目前unicode字符集表示完所有字符后还有剩余, 这些暂时用不到的部分通常用占位符FFFD表示.

    字符编码

    有了字符集, 我们现在可以用任意数字来表示现实中的字符了. 但字符要保存在计算机中,必须要先经过编码.
    有人问, 数字直接保存在内存里不就行了吗? 但是用多少个字节表示一个数字,以及每个字节的范围这都是需要
    预先约定的,这种约定就叫编码. 假如我们有四个数字,1,2,3,4要保存在计算机里, 如果约定了utf-8编码,
    那么在内存中的表示则如下:

    00000001 00000010 00000011 00000100
    

    其他的编码规则有utf-16,gb2312,gbk等,具体的编码规则不在本文的范围内,想要深入了解的可以在网上查阅相关的文档.
    因此,我们可以看到,如果不按照约定的规则来解码,就很有可能无法还原出原来的数据,也就是我们经常遇到的"乱码".
    下面以几个例子来简单说明:

    >>> u'你好'
    u'u4f60u597d'
    >>> u'你好'.encode('utf8')
    'xe4xbdxa0xe5xa5xbd'
    >>> u'你好'.encode('gbk')
    'xc4xe3xbaxc3'
    >>> u'你好'.encode('utf8').decode('gbk')
    u'u6d63u72b2u30bd'
    >>> 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'烫'
    u'u70eb'
    >>> u'烫'.encode('gbk')
    'xccxcc'
    >>> u'屯'
    u'u5c6f'
    >>> u'屯'.encode('gbk')
    'xcdxcd'
    

    前面也说过, unicode暂时没用到码点会用占位符FFFD来表示, 如果这个占位符被错误解析, 就会被当作有意义的内容了:

    >>> u'uFFFD'.encode('utf8')
    'xefxbfxbd'
    >>> u'锟斤拷'.encode('gbk')
    'xefxbfxbdxefxbfxbd'
    >>> print (u'uFFFD'.encode('utf8')*2).decode('gbk')
    锟斤拷
    

    可以看到,汉字"锟斤铐"(Unicode)的gbk编码分别为xefxbf, xbdxef和xbfxbd, 正好是unicode码FFFD的utf8编码
    的叠加, 因此如果平时遇到多个utf8编码的Unicode占位符且不巧用了gbk的方式解码,那就会看到熟悉的锟斤铐了.

    其他

    在Windows的Notepad.exe中, 保存文件的格式可以看到有如下几种:

    notepad

    可刚刚不是说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和后两者不是一类事物, 是无法进行对比的.

    博客地址:

    欢迎交流,文章转载请注明出处.

  • 相关阅读:
    Blazor Webassembly本地化的实现
    一分钟搞清C++中的指向常量的指针和常量型指针
    如何使新Edge和旧Edge并行使用
    Build 2020上公布的C# 9.0 新特性
    C# 8.0 新特性之二:接口默认实现
    如何用代码来快速批量下载人教社中小学电子教材
    三大常用数据库事务详解之三:事务运行模式
    三大常用关系型数据库事务详解之二:基本事务命令
    三大关系型数据库事务详解之一:基本概念
    自然语言处理学习笔记之一:概要
  • 原文地址:https://www.cnblogs.com/pannengzhi/p/5678495.html
Copyright © 2011-2022 走看看