zoukankan      html  css  js  c++  java
  • Python编码与解码

     
     

    一、什么是编码

    编码是指信息从一种形式或格式转换为另一种形式或格式的过程。

    在计算机中,编码,简而言之,就是将人能够读懂的信息(通常称为明文)转换为计算机能够读懂的信息。众所周知,计算机能够读懂的是高低电平,也就是二进制位(0,1组合)。

    而解码,就是指将计算机的能够读懂的信息转换为人能够读懂的信息。

    二、 编码的发展渊源

    之前的博客中已经提过,由于计算机最早在美国发明和使用,所以一开始人们使用的是ASCII编码。ASCII编码占用1个字节,8个二进制位,最多能够表示2**8=256个字符。

    随着计算机的发展,ASCII码已经不能满足世界人民的需求。因为世界各国语言繁多,字符远远超过256个。所以各个国家都在ASCII基础上搞自己国家的编码。

    例如中国,为了处理汉字,设计了GB2312编码,一共收录了7445个字符,包括6763个汉字和682个其它符号。1995年的汉字扩展规范GBK1.0收录了21886个符号。2000年的 GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字,同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。

      

    但是,在编码上,各国”各自为政“,很难互相交流。于是出现了Unicode编码。Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。

    Unicode规定字符最少使用2个字节表示,所以最少能够表示2**16=65536个字符。这样看来,问题似乎解决了,各国人民都能够将自己的文字和符号加入Unicode,从此就可以轻松交流了。

    然而,在当时,计算机的内存容量可是寸土寸金的情况下,美国等北美洲国家是不接受这个编码的。因为这凭空增加了他们文件的体积,进而影响了内存使用率,影响工作效率。这就尴尬了。

    显然国际标准在美国这边不受待见,所以应运而生产生了utf-8编码。

    UTF-8,是对Unicode编码的压缩和优化,它不再要求最少使用2个字节,而是将所有的字符和符号进行分类:ASCII码中的内容用1个字节保存、欧洲的字符用2个字节保存,东亚的字符用3个字节保存。

    这样,大家各取所需,皆大欢喜。

    三、utf-8是如何节省存储空间和流量的

    当计算机在工作时,内存中的数据一直是以Unicode的编码方式表示的,当数据要保存到磁盘或者网络传输时,才会使用utf-8编码进行操作。

      在计算机中,”I'm 杰克"的unicode字符集是这样的编码表:

    I	0x49        
    '	0x27
    m	0x6d
     	0x20
    杰	0x6770
    克	0x514b
    

      每个字符对应一个十六进制数(方便人们阅读,0x代表十六进制数),但是计算机只能读懂二进制数,所以,实际在计算机内表示如下:

    I	0b1001001
    '	0b100111
    m	0b1101101
     	0b100000
    杰	0b110011101110000
    克	0b101000101001011
    

      由于Unicode规定,每个字符最少占用2个字节,所以,以上字符串在内存中的实际占位如下:

    I	00000000 01001001
    '	00000000 00100111
    m	00000000 01101101
     	00000000 00100000
    杰	01100111 01110000
    克	01010001 01001011
    

      这串字符总共占用了12个字节,但是对比中英文的二进制码,可以发现,英文的前9位都是0,非常的浪费空间和流量。

    看看utf-8是怎么解决的:

    I	01001001
    '	00100111
    m	01101101
     	00100000
    杰	11100110 10011101 10110000
    克	11100101 10000101 10001011
    

      utf-8用了10个字节,对比Unicode,少了2个字节。但是,我们的程序中很少用到中文,如果我们程序中90%的内容都是英文,那么可以节省45%的存储空间或者流量。

    所以,在存储和传输时,大部分时候遵循utf-8编码

      

    四、Python2.x与Python3.x中的编解码

    1. 在Python2.x中,有两种字符串类型:str和unicode类型。str存bytes数据,unicode类型存unicode数据

    由上图可以看出,str类型存储的是十六进制字节数据;unicode类型存储的是unicode数据。utf-8编码的中文占3个字节,unicode编码的中文占2个字节。

    字节数据常用来存储和传输,unicode数据用来显示明文,那如何转换两种数据类型呢:

    无论是utf-8还是gbk都只是一种编码规则,一种把unicode数据编码成字节数据的规则,所以utf-8编码的字节一定要用utf-8的规则解码,否则就会出现乱码或者报错的情况。

    python2.x编码的特色:

    为什么英文拼接成功了,而中文拼接就报错了?

    这是因为在python2.x中,python解释器悄悄掩盖掉了 byte 到 unicode 的转换,只要数据全部是 ASCII 的话,所有的转换都是正确的,一旦一个非 ASCII 字符偷偷进入你的程序,那么默认的解码将会失效,从而造成 UnicodeDecodeError 的错误。python2.x编码让程序在处理 ASCII 的时候更加简单。你付出的代价就是在处理非 ASCII 的时候将会失败。

    2. 在Python3.x中,也只有两种字符串类型:str和bytes类型。

    str类型存unicode数据,bytse类型存bytes数据,与python2.x比只是换了一下名字而已。

    还记得之前博文中提到的这句话吗?ALL IS UNICODE NOW

    python3 renamed the unicode type to str ,the old str type has been replaced by bytes.

    Python 3最重要的新特性大概要算是对文本和二进制数据作了更为清晰的区分,不再会对bytes字节串进行自动解码。文本总是Unicode,由str类型表示,二进制数据则由bytes类型表示。Python 3不会以任意隐式的方式混用str和bytes,正是这使得两者的区分特别清晰。你不能拼接字符串和字节包,也无法在字节包里搜索字符串(反之亦然),也不能将字符串传入参数为字节包的函数(反之亦然)。

    注意:无论python2,还是python3,与明文直接对应的就是unicode数据,打印unicode数据就会显示相应的明文(包括英文和中文)

     五、文件从磁盘到内存的编码

    当我们在编辑文本的时候,字符在内存对应的是unicode编码的,这是因为unicode覆盖范围最广,几乎所有字符都可以显示。但是,当我们将文本等保存在磁盘时,数据是怎么变化的?

    答案是通过某种编码方式编码的bytes字节串。比如utf-8,一种可变长编码,很好的节省了空间;当然还有历史产物的gbk编码等等。于是,在我们的文本编辑器软件都有默认的保存文件的编码方式,比如utf-8,比如gbk。当我们点击保存的时候,这些编辑软件已经"默默地"帮我们做了编码工作。

    那当我们再打开这个文件时,软件又默默地给我们做了解码的工作,将数据再解码成unicode,然后就可以呈现明文给用户了!所以,unicode是离用户更近的数据,bytes是离计算机更近的数据。

    其实,python解释器也类似于一个文本编辑器,它也有自己默认的编码方式。python2.x默认ASCII码,python3.x默认的utf-8,可以通过如下方式查询:

    import sys
    print(sys.getdefaultencoding())
    

    如果我们不想使用默认的解释器编码,就得需要用户在文件开头声明了。还记得我们经常在python2.x中的声明吗?

    #coding:utf-8
    

    如果python2解释器去执行一个utf-8编码的文件,就会以默认的ASCII去解码utf-8,一旦程序中有中文,自然就解码错误了,所以我们在文件开头位置声明 #coding:utf-8,其实就是告诉解释器,你不要以默认的编码方式去解码这个文件,而是以utf-8来解码。而python3的解释器因为默认utf-8编码,所以就方便很多了。

    参考资料

    1. http://www.cnblogs.com/yuanchenqi/articles/5956943.html

    2. http://www.cnblogs.com/284628487a/p/5584714.html

      

     
     
     
  • 相关阅读:
    【Java 学习笔记】 HashMultimap(guava)
    [论文笔记] Analysis of Integration Models for Service Composition (ACM workshop, 2002)
    浅谈论文笔记管理方法
    [论文阅读] 论文阅读2篇(COMPSAC09, JNW09)
    [论文笔记] Monitoring Dependencies for SLAs: The MoDe4SLA Approach (SCC, 2008)
    [论文收集] CEC (Commerce and Enterprise Computing) 2009相关论文列表
    [论文笔记] Service Provenance in QoSAware Web Service Runtimes (ICWS, 2009)
    [资料整理] Decentralized Services Orchestration, Choreography相关的几篇论文
    [论文收集] Clustering Algorithm在Web Service领域应用相关论文
    [论文笔记] A minimal role mining method for the web service composition (2009)
  • 原文地址:https://www.cnblogs.com/52py/p/8297283.html
Copyright © 2011-2022 走看看