Python打印报错的一个原因
 
当使用Python写代码出现中文时，若只是乱码那还好处理，开头加
 

#-*- coding=utf-8 -*-
 
并且所有编码一致，网上有很多案例。
 
有一天我在整一个在线写爬虫代码的项目时，创建Python项目并书写代码使用cmd运行时，打印中文直接报错无法执行
 
 
 
显然这并不是代码编码问题，代码中已经统一了编码，使用cmd运行，应该是跟系统环境有关，换java代码执行，发现中文都是问号
 
 
果断百度一下，网上教程还是蛮丰富的，按照别人的教程更改cmd默认代码页无效，根据百度经验
 
https://jingyan.baidu.com/article/6fb756eca32b60241958fb76.html
 
更改注册表，发现可以显示中文了，但是不能输入，而且使用Runtime运行cmd运行Python还是一样，直到发现这篇详解
 
https://blog.csdn.net/haiross/article/details/36189103
 
更改设置区域 Control Panel > Clock, Language, and Region > Administrator > Change system locale > Chinese(Simple)
 
文章相当详细，真是及时雨啊！万恶的代码页，我的电脑环境是英文的，怎么就把这个问题忽略了呢？果断改为中文，再次尝试，终于不再报错了，也不再出现问号了，但是动态运行java变乱码了，更改输出流的编码为GBK后，终于柳暗花明！
 
动态运行代码详见：
 
 

转载：Java插入中文到数据库中文变成问号解决
 
之所以会出现乱码，就是编码方式不一致导致的
 
我们应该首先确定
 
 1. eclipse和mysql数据库中的编码方式是否一致
 
 2. 在链接数据时，有没有在url里面加上characterEncoding=utf8，也就是下图这样
 
 
 
如果都解决了基本就没有问题了。
 

但是我"确定"了以上的方式都没问题，还是出现乱码
 
 
 
链接数据库的时候也加上了编码方式，但是还是会乱码，一定还是编码方式不一致导致的。eclipse的编码方式和数据库的编码方式都是一样的，但是原因到底是怎么回事，为什么一直不行，我就在数据库下面查询了各个编码方式如下：
 
 
发现确实数据的编码方式为utf8
 
把character_set_connection设为utf8编码发现还是不行
 
然后发现character_set_client和character_set_results编码方式都为latin1，接下来，我直接把两个的编码方式都设为gbk
 
 
再次运行java代码，然后在数据库中查看
 
 
发现插入数据的内容正常了，但是之前插入的数据内容的就出现乱码，毕竟上面插入内容的时候编码方式和现在不一样，所以问题到此就结束啦~~~~~~~~~~
 
注意：设置变量只对当前连接有效，当退出窗口后，再次登录mysql，还需要再次设置变量。
 
注：以前2个来确定,可以使用set names utf8,set names gbk设置默认的编码格式;
 执行SET NAMES utf8的效果等同于同时设定如下：
 SET character_set_client='utf8';
 SET character_set_connection='utf8';
 SET character_set_results='utf8';
 
指定默认编码（一劳永逸解决办法）
　　在my.ini（MySQL安装目录里）中设置character-set-server=utf8即可，它可以修改三个变量：client、results、connection。

 
在基于Java的编程中，经常会碰到汉字的处里及显示的问题，比如一大堆乱码或问号。 
这是因为JAVA中默认的编码方式是UNICODE，而中国人通常使用的文件和DB都是基于GB2312或者BIG5等编码，故会出现此问题。以前我也经常为这个问题而苦恼，后来经查了些资料，终于解决了，我知道一定有很多朋友也会碰到这个问题，所以特就总结了一下，来拿出来让大家一起分享了。 
1、在网页中输出中文。 
JAVA在网络传输中使用的编码是"ISO-8859-1"，故在输出时需要进行转化，如： 
String str="中文"; 
str=new String(str.getBytes("GB2312"),"8859_1"); 
但假如在编译程序时，使用的编码是“GB2312”,且在中文平台上运行此程序，不会出现此问题，一定要注重。 
2、从参数中读取中文 
这正好与在网页中输出相反如： 
str=new String(str.getBytes("8859_1"),"GB2312"); 
3、操作DB中的中文问题 
一个较简单的方法是：在“控制面扳”中，把“区域”设置为“英语(美国)”。假如还会出现乱码，还可进行如下设置： 
取中文时：str=new String(str.getBytes("GB2312")); 
向DB中输入中文：str=new String(str.getBytes("ISO-8859-1"));
 
 
4、在jsp中的中文解决：
 
 
在“控制面扳”中，把“区域”设置为“英语(美国)”. 
在JSP页面中加入： 
假如还不行正常显示，则还要进行下面的转换： 
如：name=new String(name.getBytes("ISO-8859-1"),"GBK"); 
就不会出现中文问题了。 

 
 
在基于Java的编程中，经常会碰到汉字的处里及显示的问题，比如一大堆乱码或问号。 
 这是因为JAVA中默认的编码方式是UNICODE，而中国人通常使用的文件和DB都是基于GB2312或者BIG5等编码，故会出现此问题。以前我也经常为这个问题而苦恼，后来经查了些资料，终于解决了，我知道一定有很多朋友也会碰到这个问题，所以特就总结了一下，来拿出来让大家一起分享了。
 1、在网页中输出中文。 
 JAVA在网络传输中使用的编码是"ISO-8859-1"，故在输出时需要进行转化，如： 
 String str="中文"; 
 str=new String(str.getBytes("GB2312"),"8859_1"); 
 但假如在编译程序时，使用的编码是“GB2312”,且在中文平台上运行此程序，不会出现此问题，一定要注重。 
 2、从参数中读取中文 
 这正好与在网页中输出相反如： 
 str=new String(str.getBytes("8859_1"),"GB2312"); 
 3、操作DB中的中文问题 
 一个较简单的方法是：在“控制面扳”中，把“区域”设置为“英语(美国)”。假如还会出现乱码，还可进行如下设置： 
 取中文时：str=new String(str.getBytes("GB2312")); 
 向DB中输入中文：str=new String(str.getBytes("ISO-8859-1"));
 
 
4、在jsp中的中文解决：
 
 
在“控制面扳”中，把“区域”设置为“英语(美国)”. 
 在JSP页面中加入： 
 假如还不行正常显示，则还要进行下面的转换： 
 如：name=new String(name.getBytes("ISO-8859-1"),"GBK"); 
 就不会出现中文问题了。 
 资料引用:http://www.knowsky.com/364154.html
 
 

 
 
 
java乱码的原因,原理,解决方法.
 String odsStr = "测试";
 String newStr = new String(odsStr.getBytes("GBK"), "ISO8859_1");
 
 最近在编写Java程序的时候，偶尔会遇到中文字乱码的问题，或者偏僻字不能正常显示的问题，经过查找资料并通过几次测试，目前已经完全解决。
 
 首先需要说明一下我们经常用到的字符集，有ISO8859-1，GB2312，GBK，GB18030，UNICODE。这里ISO8859-1字符集只包含英文字符，使用一个字节存储。GB2312、GBK和GB18030字符集包含中文字符，他们都兼容ISO8859-1字符集，他们的字符存储格式是变长的，其中GB18030包含GBK，GBK包含GB2312。UNICODE包含世界上所有国家的字符，UNICODE又分为UTF-8，UTF-16和UTF-32三种，UTF-8是变长字符集，它兼容ISO8859-1，即英文字符使用一个字节编码，而其他的字符使用2到4个字节编码，其中中文字符大部分都是使用3个字节进行编码，少量偏僻字使用4个字节编码，UTF-16统一都使用2个字节编码，它不兼容ISO8859-1，英文字符也使用两个字节，UTF-32统一使用4个字节编码，也不兼容ISO8859-1，可见UTF-16和UTF-32都比较浪费空间。
 
 

 
 
 

 
 
 
乱码问题的产生最根本的原因就是使用错误的字符集解码字节流或者将给定的字符串用错误的字符集编码成错误字节流造成的，例如”中文”两个汉字，如果用ISO8859-1字符集将其编码为字节流，因为这个字符集不支持中文，所以就会出错，输出结果为3f3f，其意义就是??。再例如”中文”二字的GBK的字节流为d6 d0 ce c4，可是我们要是用不兼容的字符集去解码，例如用ISO8859-1或者UTF-8，这随后产生的字符串就是乱码，或者是其他的某个字符。
 
 从开发Java程序到运行Java程序的过程中都存在着编码问题，所以要想避免乱码产生，就必须了解在其中任何时候的编码处理的情况。
 
 源代码：在编写java源代码的时候，我们必须把编写的文本保存在文件中，这个时候不管用什么编辑器，都存在一个问题，就是以什么样的字符集将这些源代码（包含汉字）保存到文件中，大部分编辑器都会通过系统的环境变量得到系统的当前默认字符集，编辑器就会使用这个字符集将我们编写的源代码保存到文件中。一般我们的中文Windows系统的默认字符集是GB18030，AIX英文环境的默认字符集是ISO8859-1，AIX中文环境的默认字符集是IBM-eucCN。
 
 

 
 
 

 
 
 
编译：在编译.java文件的时候如果使用默认处理，则javac会使用系统当前的默认字符集去读取源文件，将源文件的内容转换为UTF-8编码，然后在进行编译，这时我们也可以通过-encoding参数指定一个字符集，让javac使用我们指定的字符集去读取源代码，然后编译。编译以后产生的class文件内部所有的中文字符都是用UTF-8的字符集进行编码的，这就是Java程序能处理任何国家文字的原因。
 
 运行时：Java程序在运行时，需要使用程序内部定义的中文字符串，也可能会使用从外部读取的中文字符串，这些经过处理，可能都会输出到程序外部，在这些过程中都涉及到编码的转换，程序内部定义的字符串都是用UTF-8存储的。而从外部读取和输出到程序外部的输出又使用什么字符集进行处理呢？在我们没有在程序中特别指定的情况下，JVM会根据系统属性确定使用哪个字符集，这个系统属性的名称为file.encoding，我们可以在启动java程序的时候通过-D参数设定这个值，如果没有设定，JVM会根据系统环境变量确定这个系统属性，一般我们的中文Windows系统的默认字符集是GB18030，AIX英文环境的默认字符集是ISO8859-1，AIX中文环境的默认字符集是IBM-eucCN。这样JVM在处理输入数据的时候就会把字节流根据这个参数进行解码，然后转成UTF-8格式，在Java程序内部处理，然后再根据这个参数把处理后的数据编码，输出到程序外部。这就是Java程序运行时字符集的使用情况。
 
 

 
 
 

 
 
 
现在有一个问题，我们平时都是Windows的中文环境下做开发，然后拿到AIX系统上去运行，AIX系统的默认语言环境是英文环境，这样就会出现乱码，分析过程如下：源文件编码格式为GB18030，默认编译，也采用GB18030读取源文件，正常转换为UTF-8，生成class文件，运行时没有进行特殊设置，语言环境为英文环境，默认编码为ISO8859-1，这样在输出中文的时候会把正常的UTF-8表示的汉字用ISO8859-1的字符集去编码生成字节流，因为ISO8859-1不支持汉字，结果输出的都是’？’。可是这个时候却发现，由外界输入给java程序的中文字符，却能正常输出，这又是为什么，其实这个也是运行时的默认字符集ISO8859-1造成的，Java程序运行时，在读取外部进入的字节流的时候，如果使用默认的读取方式，也是使用ISO8859-1的字符集进行解码处理，这样中间的处理过程中中文都已经不是原来的中文了，也就是说我们这个时候处理根本是我们认为的中文，而是一对乱码，虽然是乱码，但是其中的信息却没有丢失，在处理完后，在经过一次ISO8859-1的编码，又还原为正常的GB18030的编码输出，所有没有出现乱码。我们以前的解决方法是，在编译原文件的时候指定参数-encoding ISO8859-1，让编译器用ISO8859-1的字符集去解码源文件编译，然后运行程序，这时再输出程序的内部中文字符串也不是乱码了。看起来一切都解决了，可是却没有从根本上解决问题，class文件变得比平常大很多，程序中用到中文越多，class文件变大的越快。而且其中的中文信息也变味了。
 
 

 
 
 
另一个问题，如果我们正常编译程序，在AIX系统上线设定为中文环境，然后再运行Java程序，这样既不会使程序变大，也不会使中文变味，可是用了一段时间又发现问题了，处理过程中如果遇到偏僻的中文字，还是乱码，原因是AIX的中文环境使用的字符集是IBM-eucCN，我认为可能是这个字符集缺少偏僻汉字，无法解释其内容，所以偏僻字变成了乱码了。
 
 最后的解决办法是，在Windows中文环境下正常编写原程序，用默认的方式编译生成class文件，或者编译时指定参数-encoding GB18030，这样汉字都能正常解释并转换为UTF-8存储在class文件中，在运行的时候，我们需要制定参数，java –Dfile.encoding=GB18030 。。。。。，系统环境使用默认英文即可，这样JVM就不会根据系统的环境设定默认字符集，而是所有输入输出都使用我们指定的字符集，这样不但解决了英文环境下的中文输出问题，而且还解决了偏僻字的显示问题。
 
 

 
 
 
最后附上汉字的转码过程：
 1.‘中文’的GB18030编码为d6 d0 ce c4 对应java源码文件
 经过ISO8859-1解码为UTF-8为81 30 89 30 81 30 88 34 81 30 88 32 81 30 87 32 对应编译过程
 经过ISO8859-1编码为d6 d0 ce c4 对应Java程序输出汉字的过程
 d6 d0 ce c4经GB18030解释为‘中文’二字 对应系统显示汉字的过程。
 在这个过程中，虽然中间出现了乱码，但是信息没有丢，最后还是能还原为中文的，是比较蹩脚的处理过程。
 
 2. ‘中文’二字的UTF-8编码为e4 b8 ad e6 96 87，对应正常编译后的class文件存储内容
 经过ISO8859-1编码为3f 3f，已经出错，丢失信息，对应java程序汉字输出过程
 3f 3f经GB18030解释为汉字为？？，乱码，无法还原, 对应系统显示汉字的过程
 这个过程中，信息丢失，是个完全错误的处理过程。
 
 3. ‘中文’的GB18030编码为d6 d0 ce c4 对应java源码文件
 经过GB18030解码为UTF-8为e4 b8 ad e6 96 87 对应编译过程
 经过GB18030编码为d6 d0 ce c4 对应Java程序输出汉字的过长
 d6 d0 ce c4经GB18030解释为‘中文’二字 对应系统显示汉字的过程。
 这个过程是最为理想的处理过程，没有丢失信息，也没有出现任何蹩脚的信息。