起因：
在pycharm运行脚本的时候，发现
中文字符在控制台输出显示成乱码了。
。
各种百度，查解决方法，误打误撞的发现加个u可以解决乱码问题，其实没有真的懂为什么。
之后就像个抄作业的学渣，就知道“三长两短，选最长”那样，反正遇到要输出中文，管他三七二十一，通通加上u。
但是，把脚本放Linux上，在后台运行时就妥妥的报错了。。。
于是再次走上各种查资料，解决编码问题之路：
1.在脚本的开头加上
，意思是源程序用utf-8进行编码。
2.的‘中文’，此时还是utf-8编码。而的u'中文'，已经解码成Unicode了，即 print u‘中文’等效于print ‘中文’.decode('utf-8')。
3.在终端运行的时候，输出是按sys.stdout.encoding设置的进行编码。
如果是后台运行，对于字符串‘中文’，还是按照脚本开头声明的utf-8来进行编码。u'中文'，由于是Unicode，则按sys.getdefaultencoding()设置的进行编码。
4.Windows上：
sys.stdout.encoding的编码是cp936，即类似gbk的编码。
sys.getdefaultencoding()的编码是ascii，
Linux上：
sys.stdout.encoding的编码是utf-8，
sys.getdefaultencoding()的编码也是ascii，
5.所以，，在终端运行的时候，是将Unicode字符串
用cp936或者utf-8进行编码，且在编码范围内，能正确输出。
但是，后台运行的话，用的是ascii编码，超出了ascii的编码范围，就报错了。
解决：
方法一：
更改sys.setdefaultencoding的默认编码，脚本加上：
reload(sys)
sys.setdefaultencoding('utf-8')
但是不推荐，原因详解：https://blog.ernest.me/post/python-setdefaultencoding-unicode-bytes
方法二：
将已经解码成Unicode的字符串指定正确的编码方式.
print u'中文'.endoce('utf-8')
其他乱七八糟的尝试：
1.在后台执行的时候，查看进程运行情况。其中，运行第一个脚本时，没有报错，而第二个报错了。
看起来都是root来执行脚本的，
执行脚本时的当前目录和使用的解释器也一样
2.所以又回到脚本文件本身来查找原因，
发现，第一个脚本文件导入的模块中，有一个自定义模块是用方法一
，更改了Python的系统默认编码，所以没有报错。
而第二个脚本中，是没有导入这个自定义模块的。所以此时还是用ascii来对Unicode字符串进行编码的。