9

编码-1

文章启发来源:

  1. cnblogs
  2. 阮一峰
  3. 知乎

字符编码方式

note from wiki:

从维基百科上得到的一些理解,一个字符的unicode编码是确定的,但是在传输过程中,由于不同系统平台的设计不一致,所以对unicode编码的实现方式是有所不同的。unicode的实现方式成为unicode转换格式(简称UTF)例如对于一个包含基本7位ASCII字符的unicode文件,如果都使用2字节的原unicode编码传输,会造成浪费。对于这种情况可以使用UTF-8编码,它是一种变长编码,对于基本ASCII字符仍然采用7位编码表示,占用一个字节。

意思其实就是,unicode规定了符号的二进制代码的符号集,但是并没有规定二进制代码应该如何存储。也就是说,在计算机的存储中,一个字符的存放方式并不一定会与它的unicode编码一致。这是因为采用了不同的编码方式所导致的。

自己整理的一些背景:

编码一开始是使用ASCII码来进行编码的,但是这个编码方式是针对英文为基础的国家的。后来,各个地区因为各自的需要,开始使用127位以后的扩展位。比如中国,因为几万个汉字,所以单靠单个127位是根本不够的,所以就规定,使用高于127位的两个字节来表示汉字。当然也就顺便把原来的一些其他扩展西方字符给出重新编码了。即,全角字符(半角字符可类推)GB2312。

后来标准随着发展,GBK变成了GB18030,即,只要第一个字节表示的十六进制数大于127,就表示汉字的开始。(DBCS,双字节字符。台湾地区的BIG5)。

后来unicode开始制定了,它的制定标准在上面的引用中可以看到,使用的是两个字节来表示字符。因此在unicode标准里,无论是汉字的全角字符还是英语的半角字符,都是一个字符,两个字节。但是unicode如何在网络上传播也是一个问题。于是,便有了UTF。UTF与unicode的转换关系如下:

note:

0000 0000-0000 007F | 0xxxxxxx

0000 0080-0000 07FF | 110xxxxx 10xxxxxx

0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

其中的x是要用左边的十六进制码转化为二进制码后,代替相关的位。UTF-8的编码规则很简单,只有二条:

1)对于单字节的符号,字节的第一位设为0,后面7位为这个符号的unicode码。因此对于英语字母,UTF-8编码和ASCII码是相同的。

2)对于n字节的符号(n>1),第一个字节的前n位都设为1,第n+1位设为0,后面字节的前两位一律设为10。剩下的没有提及的二进制位,全部为这个符号的unicode码。

在查阅了几篇blog后,举个例子:比如说你现在的file用的是编辑器等(比如说是windows上的记事本,且设置它为ASCIIunicode(其实是带BOM的utf-8))默认的编码方式,那么存储的时候用的就是这种编码方式对应的在硬盘中的存储方式。比如说,此刻我用sublime 3打开,而且我的sublime 3 中只有utf系列和一些西文字体的编码方式,那么如果打开的文件用的是ASCII保存的文件,则此时会显示的乱码;而如果使用的是unicode的编码方式,也是能打开的,而且不会出现乱码的情况。

在终端或者编辑器中,如果没有进行特殊声明的话,就会使用它们默认的编码格式进行编码,或者是GBK或者是UTF,如果是ascii的话,汉字字符是无法存储的,因为没有配套的编码。所以一般能显示汉字的地方,使用的是GBK等等编码格式,要转码的话,先转换为unicode,然后再转换为其他东西。

关于python的encoding

参考知乎上的一个回答传送门

以我自己的理解就是:

  • 首先得分清楚编码问题,在不同的环境中,编码是不同的。在终端的情况下,(windows 中是cmd,ubuntu 下的terminal,远程登录是xshell),所以他们的编码是不同的。shell环境下,windows的编码是GBK,ubuntu一般是utf-8。-------在文本编辑的情况下,与上面的情况类似,是根据编辑器的情况决定的.
  • 在python中的情况是,unicode(A,B)的意思是用B的编码方案将A解码,并将结果返回为unicode字符串。所以一般在出现UnicodeDecodeError时候,错误的来源应该就是:
  1. 文件保存时的编码方式是编辑器默认的保存方式,而在运行环境中默认的编码方式与该文件方式并不相同,很有可能是有非ANIS的字符出现所致。因为环境无法编码该文件。
  2. 在文件保存的时候,带有BOM 。BOM(byte order mark)是为 UTF-16 和 UTF-32 准备的,用于标记字节序(byte order)。微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 ASCII 等编码明确区分开,但这样的文件在 Windows 之外的操作系统里会带来问题。 所以啊,最后在文件的头里面需要加入utf-8的说明,最好不要用BOM。

一点有意思的扩展,在pythonIDE中

两种终端下的显示

# 环境是sublime 3
    1 >>> u"知乎".encode('utf-8')
    2 '\xe7\x9f\xa5\xe4\xb9\x8e'
    3 >>> u"知乎".encode('gb2312')
    4 '\xd6\xaa\xba\xf5'
    5 >>> '知乎'.encode('utf-8')
    Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 0: ordinal not in range(128)
   7 >>> '知乎'
     '\xe7\x9f\xa5\xe4\xb9\x8e'
   8 >>> u'知乎'
     u'\u77e5\u4e4e'
   9 >>> u'知乎'.encode('utf-8').decode('utf-8')
     u'\u77e5\u4e4e'    


# 环境是windows:
    >>>'知乎'
    '\xd6\xaa\xba\xf5'
    >>>u'知乎'
    u'\u77e5\u4e4e'
    >>> u"知乎".encode('utf-8')
    '\xe7\x9f\xa5\xe4\xb9\x8e'
    >>> u"知乎".encode('gb2312')
    '\xd6\xaa\xba\xf5'

    #还是补充一下举这个例子的本意:
    #从第七行(数字标出的,以下也是一样)以及第一二行中可以看出,两个输出结果是相同的,第一行说明  将    u'知乎'  unicode字符串按照utf-8的编码方式进行编码,并以字节串的形式输出来。
    #但是如果换成的是 u'知乎' 的话,则表示的是将这个汉字用unicode编码的形式存放。(猜测是自动调用了encode方法)。所以呢,第九行意思是将utf-8编码的字符串用utf-8解码出来。
    #下面又在windows上补充了下,可以看出在不同的终端下,使用的编码方式可能是不同的,比如在windows上就有可能是,当输入汉字的时候,终端用gbk的编码方式将汉字编码。

最后再贴一个链接参考blog

总结

在这两天的调试过程中,开始将unicode的相关知识模块化,所以在此也特地写下这些东西,作为一个总结。在写代码的时候,如果一个文件中有超过ascii的字符的话,那么需要在py文件的第一行加以声明。这是因为不同的环境,不同的编译器所默认的编码字符的格式是不同的。最好能够统一以unicode字符串为基础进行转换。

update

这是一个在segmentfault网站上回答过的一个东西的链接。链接1

AMPP配置