hi大足,刘根山,总裁的挂名新娘全文免费
近日使用了python交互终端写程序，发现一个奇怪的现象。
使用windows记事本编写py输出简单的一句话：
#!/user/bin/python # _*_ coding:GBK _*_ print "今朝有旧今朝醉？"
通过cmd运行如下：
将coding修改为UTF-8：
# _*_ coding:GBK _*_
依然可以正常显示，因为UTF-8兼容GBK大多数字符，注意，这里的coding指的是文件的解码。
接下来使用IDLE来编辑这个py：
好，乱码来了：
为什么捏？难道记事本跟python的IDLE存在差异？首先想到的就是两者保存文件编码差异导致，先确定cmd用的是什么解码：
确定是GBK，再看一下记事本和IDLE保存的编码：
记事本：
IDLE：
需要说明一下，ANSI是不同国家地区字符集的统称，GBK就是中国地区的ANSI编码。
可以看到，IDLE给出的选项默认是UTF-8，这跟记事本使用GBK编码保存文件不一致，于是记事本保存的py输出不会乱码，IDLE保存的py输出则会乱码。
那么将IDLE默认编码设置为GBK，也就是上图中的Locale-defined系统默认看看：
继续乱码，好吧，然并卵：
这个时候我再次用记事本打开再保存，发现一个细节，记事本的默认保存编码变成了UTF-8：
通常应用程序识别到文件是什么编码就会用对应的编码打开或保存：也就是说，python这个IDLE在我上次修改编码并没有生效，依旧UTF-8保存，简直坑人......
不过，这到底是windows坑了IDLE还是IDLE的问题？再次使用记事本打开，修改coding为GBK，然后以UTF-8保存，结果：
这又是什么毛病？GBK不能有BOM头？
说明一下：什么是BOM头，BOM Byte Order Mark头就是在文件开头的几个不表示任何字符的字节，通常的作用就是用来给程序区分文件内容是大端还是小端模式处理的，但是一般情况下，GBK和UTF-8都是无BOM的格式，对于UTF-8的文件如果存在BOM，那么BOM头就用来表示文件的编码为UTF-8。
经过刚才的测试，可得知IDLE是不会在UTF-8加BOM的，但是用记事本保存UTF-8的时候，它就会加BOM，而python编译的时候发现GBK编码有BOM果断的报了个错。所以，例如这个windows的记事本，就是用这种方式（前面加EF BB BF）来判断文件是否为UTF-8，却在某些时候造成不便，例如python编译，还有就是php，在html中头三个字符什么都没有就是占着位子，特别尴尬。
另外，再指出windows文本编辑器的其他毛病，例如这个Unicode其实就是UTF-16，Unicode是码表，不是编码方式，为何混为一谈？这是有历史原因的，早期的Unicode和UTF-16是可以做到键码一对一，但是这并不意味着微软应该固执的沿用下来：
big endian就是大端序
经过这次测试也总结出一点，使用windows记事本等非专业的文本编辑器，我建议使用默认方式保存即可，但是最好不要跟其他编辑器混用，避免出现UTF-8的BOM头问题，使用其他专业文本编辑器，最好保存为utf-8无BOM模式。虽然很多大牛和班都会让初学者用记事本敲代码，以训练语法，但是某些时候会造成很多困扰，不值得提倡。
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Python爬虫:Request Payload和Form Data的简单区别说明
浅谈Python中threading join和setDaemon用法及区别说明
Python3-异步进程回调函数(callback())介绍
python继承threading.Thread实现有返回值的子类实例
Python中使用threading.Event协调线程的运行详解
我要评论
网友评论