一文搞懂Python字符编码问题，值得收藏( 三 ) _Python

文章插图
如果记住了我之前说的关于乱码的那两个要点的同学，应该很容易明白这里为什么会出现乱码。原因很简单，这里a变量的编码是gbk的，而我们运行脚本的编辑器pycharm设置的环境编码却是utf8，两者编码方式并不一致，所以必定会出现乱码。那么怎么解决呢？解决方式有几种，一种是修改#coding:gbk为#coding:utf8，二是可以在'中国'前面加一个u，即a=u'中国' 。在前面加u是将“中国”强制转换为unicode编码，即“无编码”，此时变量的type将会变为unicode 。前面已经说过，对于unicode编码的字符，python将自动根据环境编码进行显示，所以也就是会自动帮我们编码为utf8进行显示。还有一种方式是通过encode和decode函数，比如像下面：

文章插图
使用decode方法可以将字符串进行解码，解码后格式就是Unicode了，所以a.decode('gbk')这句跟u"中国"效果是等价的，打印出来当然是没问题的。当然，我们也可以明确写出要编码的类型，比如a.decode('gbk').encode('utf8')，这样将Unicode明确地编码为utf8，也是一样的效果。这里大家要注意一点，我们对所有非Unicode类型的字符只能进行decode操作，不能进行encode操作。对Unicode类型的只能是encode而不能decode，这个大家要注意。
搞明白了pycharm里面的行为后，我们再看看如果这个脚本不是在pycharm里面运行，而是直接在命令行里面运行，又会发生什么问题呢？就将就上面这个文件，我们在命令行里面运行，结果如下：

文章插图
果不其然，b1正常显示了，b2却出现了乱码。这次出现乱码的原因又是什么呢？这里大家要知道，命令行里面的环境编码是gbk格式，由于b1是Unicode编码，Unicode编码的字符会自动随着环境编码来输出，所以不管在什么环境下，b1都能正常显示输出。而b2由于被encode成了utf8格式，所以它只能在环境编码为utf8的环境中才能正常显示，在命令行这种环境下就会出现由于编码不一致而导致的乱码。大家可以试试直接print a，由于文件是coding:gbk的，所以a是可以直接正常显示的。比如代码如下：

文章插图
在pycharm中无法正常显示a的值，但在命令行中却可以，如下图：

文章插图
如果是py3的脚本的话，则要简单得多。因为py3中，所有的字符串不再受系统环境编码的影响，统一使用Unicode来进行编码，类型统一为str，所以不再需要在中文前面加u来使中文字符变为Unicode这种写法。而且所有py3的脚本默认都是utf8来编码的，所以我们也不需要在脚本开头指定coding:xxxx了。打印显示的时候也会方便很多，由于是字符串都是Unicode格式，所以不管在命令行中还是pycharm中，都会正常显示而不会出现乱码。
上面是通过脚本来运行的情况，那么如果是直接在命令行中写脚本，又会出现什么问题呢？其实不管在哪里运行，上面说的两个原则始终不变，大家永远记住无非我们就是要弄清楚字符本身的编码和环境编码，只要这两者一致了，那一定不会出现乱码。在python shell（即命令行）中直接写代码运行时，大家只需注意在windows下，命令行的默认编码是gbk的，而在Linux环境下，命令行的默认编码是utf8的，其他没什么区别。所以我们接下来分别来看看。
在windows环境下，我们在命令行中写一段代码来看看，运行效果如下：

文章插图
大家注意，第一行我们在定义a="中国"时，并不会报错，因为在命令行中默认是gbk编码，所以此时其实a的编码已经是gbk了，支持中文没有任何问题。直接显示a变量时，打印出来的不是乱码，而是该字符串的字节码表示方式，大家可以理解成给计算机看的，不是给人看的，只有print出来的内容才是给人看的。print a也不会报错，因为按照gbk方式编码并且在gbk环境中运行，不可能会出问题。下面直接将a进行decode解码时，解码方式必须跟编码方式是一致的，所以gbk方式编码的内容不能解码为utf8格式，只能decode为gbk 。decode之后，字符串会变为Unicode，也可以正常显示。最后，我们将Unicode编码为utf8时，字符的编码格式又跟环境编码不一致了，所以再次出现了乱码。py3同理，就不再赘述了，如果掌握了之前说的原则，应该完全不会出现问题。如果是在Linux下面的命令行中运行，道理也是一样，只是需要注意linux下命令行默认的编码格式是utf8的就可以了。