但在windows下编写python程序的时候，我们一般采用的编码是utf-8
二者不一致是导致乱码的根本原因！
在pycharm下，为了中文不乱码，那么需要注意一下几个方面：
一、每一个源程序文件头部，需要加上
#-*-coding:utf-8-*-
这样就没有乱码了
这个问题是你操作系统的默认编码格式和你程序的编码格式不一致。但是所有的系统都是认可unicode编码的，所以你在前面加u就可以正常显示。两种办法，一种就是改变操作系统的默认编码格式，比如windows,利用命令行，将其改成utf-8编码格式；另一种就是类似在前面加u这种办法，在py文件里面，利用python的方法（decode,encode）将其解码，然后编码成window默认的gbk形式的（当然你用的其他系统的话，不一样的，你自己上网了解一下）。发现问题，我第一时间找度娘，发现好多人在写这个问题，给了一大堆方案，基本都是配置环境的。配置项有LANG、JAVA_TOOL_OPTIONS、PYTHONIOENCODING等等；配置的位置有人说在Jenkins的Global Environment variables，有人说要配到系统的环境变量里，也有人说要改jenkins.xml。
上面这些方法我都试了， 均无效！！ 当然有博主自己写说生效了，可能环境上还是有未知的差异吧。没有大腿可抱的情况下，只能自己蒙了。
出现乱码肯定是编码不对，但究竟是怎么不对的，要搞清楚正确的(文字实际用的编码)是什么，错误的(显示时使用的编码)是什么。可观测到现象有下面几个：
从1、3推断， Jenkins默认显示用的编码是GBK，文字自身的编码是UTF8 。但这跟2的现象似乎是冲突的，因为Log文件本身是UTF8编码，而其显示的出来的也是乱码，且跟Jenkins的一致。
这时候做个简单的实验来验证结论。用Notepad++建一个UTF8的文件，里面写上“中文”俩字，然后用ANSI编码去看。
实验证实了上面推断的正确性，那么Log里的乱码又是为什么呢？在上面的Log里展示了原因，Py中stdio的编码为cp936(也就是GBK)。这个情况是，Jenkins将UTF8的命令行传给了Py，然后Py用GBK解析，并转码为内部的UTF8，最后用UTF8输出Log。
原因找到了，接下来就是解决问题。既然外部配置都无效，只能在Py内部处理了。我第一反应是，错误的编码在里面逆向纠正就好了。
我尝试的方案是处理sys.argv里记录的内容：
我先用“Pok2盟友”做测试，发现问题解决了。欣喜的跑上面“中文”，结果直接报错程序挂了Orz...，我还天真的以为是Py检查严格给了报错，让它跳过检查就好了。于是加了errors="ignore"参数，忽略报错，decode完输出空白了，结果啥也不是。
仔细想想， 不匹配的转码其实是“有损的” ，因为两种编码使用的字节数不同。“中文”用GBK是4bytes，UTF8是6Bytes。忽略报错后，Py应该会把无法解码的byte直接丢弃。UTF8=》GBK丢失一部分内容；GBK=》UTF8又丢弃一些，最后直接丢没了。
到这里我主观上能想到的解决方案已经没了，走投无路！！！
在我麻木的Google过程中，鬼使神差般又去尝试了一下chcp，结果成功了！！！真的成功了，一切问题都得到解决！！！
chcp在很早之前就尝试过，当时写法是
这次想尝试分两行写，然后就成了~
上面过程描述其实不完整（中间尝试了各种方向，细节实在太多），甚至还有些凌乱，所以最后，清晰的总结下：
做完上面的处理，应该所以内容都处于UTF8的状态下。
