一, 搞懂 ASCII,GB2312,GBK,UNICODE,UTF-8 的关系
//ASCII
记住一句话: 计算机中的所有数据, 不论是文字, 图片, 视频, 还是音频文件, 本质上最终都是按照类似 01010101 的二进制存储的.
再说简单点, 计算机只懂二进制数字!
所以, 目的明确了: 如何将我们能识别的符号唯一的与一组二进制数字对应上? 于是美利坚的同志想到通过一个电平的高低状态来代指 0 或 1,
八个电平做为一组就可以表示出
256 种不同状态, 每种状态就唯一对应一个字符, 比如 A--->00010001, 而英文只有 26 个字符, 算上一些特殊字符和数字, 128 个状态也够
用了; 每个电平称为一个比特为, 约定 8 个比特位构成一个字节, 这样计算机就可以用 127 个不同字节来存储英语的文字了. 这就是 ASCII 编码.
扩展 ANSI 编码
刚才说了, 最开始, 一个字节有八位, 但是最高位没用上, 默认为 0; 后来为了计算机也可以表示拉丁文, 就将最后一位也用上了,
从 128 到 255 的字符集对应拉丁文啦. 至此, 一个字节就用满了!
//GB2312
计算机漂洋过海来到中国后, 问题来了, 计算机不认识中文, 当然也没法显示中文; 而且一个字节所有状态都被占满了, 万恶的帝国主义亡
我之心不死啊! 我党也是棒, 自力更生, 自己重写一张表, 直接生猛地将扩展的第八位对应拉丁文全部删掉, 规定一个小于 127 的字符的意
义与原来相同, 但两个大于 127 的字符连在一起时, 就表示一个汉字, 前面的一个字节 (他称之为高字节) 从 0xA1 用到 0xF7, 后面一个字节
(低字节)从 0xA1 到 0xFE, 这样我们就可以组合出大约 7000 多个简体汉字了; 这种汉字方案叫做 "GB2312".GB2312 是对 ASCII 的中文扩展.
//GBK 和 GB18030 编码
但是汉字太多了, GB2312 也不够用, 于是规定: 只要第一个字节是大于 127 就固定表示这是一个汉字的开始, 不管后面跟的是不是扩展字符集里的
内容. 结果扩展之后的编码方案被称为 GBK 标准, GBK 包括了 GB2312 的所有内容, 同时又增加了近 20000 个新的汉字 (包括繁体字) 和符号.
//UNICODE 编码:
很多其它国家都搞出自己的编码标准, 彼此间却相互不支持. 这就带来了很多问题. 于是, 国际标谁化组织为了统一编码: 提出了标准编码准
则: UNICODE .
UNICODE 是用两个字节来表示为一个字符, 它总共可以组合出 65535 不同的字符, 这足以覆盖世界上所有符号(包括甲骨文)
//utf-8:
unicode 都一统天下了, 为什么还要有一个 utf8 的编码呢?
大家想, 对于英文世界的人们来讲, 一个字节完全够了, 比如要存储 A, 本来 00010001 就可以了, 现在吃上了 unicode 的大锅饭,
得用两个字节: 00000000 00010001 才行, 浪费太严重!
基于此, 美利坚的科学家们提出了天才的想法: utf8.
UTF-8(8-bit Unicode Transformation Format)是一种针对 Unicode 的可变长度字符编码, 它可以使用 1~4 个字节表示一个符号, 根据
不同的符号而变化字节长度, 当字符在 ASCII 码的范围时, 就用一个字节表示, 所以是兼容 ASCII 编码的.
这样显著的好处是, 虽然在我们内存中的数据都是 unicode, 但当数据要保存到磁盘或者用于网络传输时, 直接使用 unicode 就远不如 utf8 省空间啦!
这也是为什么 utf8 是我们的推荐编码方式.
Unicode 与 utf8 的关系:
一言以蔽之: Unicode 是内存编码表示方案 (是规范), 而 UTF 是如何保存和传输 Unicode 的方案(是实现) 这也是 UTF 与 Unicode 的区别.
二, 记住下图
当出现问题之后, 对照下图, 看看哪里错在哪里, 再进行反思回顾, 找出问题所在
三, 常见编码错误的原因
Python 只要出现各种编码问题, 无非是哪里的编码设置出错了
常见编码错误的原因有:
Python 解释器的默认编码
Python 源文件文件编码
Terminal 使用的编码
操作系统的语言设置
掌握了编码之前的关系后, 挨个排错就好啦
来源: http://www.bubuko.com/infodetail-2981048.html