其实这次出现的乱码问题完全是个人的失误引起的。创建数据库,在选择编码的时候不小心选了utf8mb3,本来是该选择utf8的,杯具!不过,塞翁失马,焉知祸福?开始猛查。。。
首先,在之前的之前就已经对Mysql测试过纯JDBC和jsp下,中文乱码是没问题的了,且统一都设成了GBK的。所以一开始根本就没注意到数据库本身上来。只考虑,在前台这边是不是没统一编码的格式!于是添加啊添加,结果该添加的都添加上了。而且在jsp中添加记录时,数据库里是可以显示中文的。到了servlet来取数据时,就开始来乱码了。
其实也只好开始Google,浏览了大部分相关内容,大同小异还是无法知道哪儿出了问题。在肯定了前台编码没什么问题的情况下,无奈找出了之前测试的代码还是一样都成功通过了。于是,将两个小表进行对比。以下是关于各方面乱码的解决方法:
场合:页面本身有中文的时候
解决办法:servlet:
resp.setContentType("text/html;charset=gbk");
Jsp:
<%@ page contentType="text/html;charset=gb2312"%>
注意:一定要写在PrintWriter out = resp.getWriter();之前
|
场合:解决get方式乱码问题:
解决办法:
修改
server.xml
à
URIEncoding="GBK"
|
场合:解决post方式提交内容的乱码
解决办法:
request.setCharacterEncoding("GBK");
注意:一定要写在存取第一个参数之前
不要调用response.setCharacterEncoding("GBK");
|
场合:<jsp:param name="user" value="<%=s%>"/>,url地址包含中文参数
解决办法:
<%request.setCharacterEncoding("GBK");%>
注意:
|
。。。。来自尚学堂。 尽管参照了,但还是很迷茫。完全不知道自己乱码乱在哪个位置上。怀疑过tomcat、怀疑过浏览器,就是没怀疑Mysql。不过,查找错误的思路还是比较明确的,找个成功的数据库来参照就Ok了。
在Mysql的前端Navicat 8 for Mysql 下,不知道如何查编码。只好回到命令行了。登陆之后,输入:status,显示结果大概如下:
一切都正常嘛。切换到出现错误的myblog 数据库下,同样输入:status 结果有点在意料之中。
额,一不小心看到了Db characterset: utf8mb3 。 估计,也只能估计是这儿出了错误了。。。然后还是小心翼翼的Google了下。oh,no ,发现一帖子打着个大大的问号。。。
jsp无法正确读取utf8mb3中文字体,出现乱码,改为utf8正常,为什么?
算是可以肯定自己的问题也是在这儿了。知其然,知其所以然,稍后得好好了解下,不过,当下还是先改过来。其实,作为菜鸟级就是惨,模糊的记得这些编码是可以一条的改的,试了下:
mysql> set character_set_database=utf8;
Query OK, 0 rows affected (0.00 sec)
看到修改成功之后狂开心,跑会浏览器测一下,结果很杯具。还是乱成一片。。。又看到后半句 0 rows affected(0.00sec)不用消耗任何时间就能修改,不大可能吧。事实上,用status 返回结果是修改好了的。那问题又在哪儿呢?????????
这年头要是人品不好,要是跟自己死较劲的话,一个小问题还能把自己给逼疯了。不知道大家到这一步知道啥问题不?反正我自己还不知道。使出最笨的办法了。在同个数据库下,建立一个不同表名同属性的表来测一下,一测就通过了。杯具。。。
其实问题还是出现在utf8mb3的设置下,天知道的是一但在建立数据库设了这个值了,它的表的属性也跟这个值,表里面的列也跟着这个值。而且鬼知道,你把数据库的这个值改了,它的表的这个属性是不改的,同样表里面的这个值也是不改的;同样,改了表的这个属性也没用;直到最后把varchar 的这个utf8mb3改了,才大功告成。
本来大可以重建数据库的。。。觉得麻烦,以为一条set character_set_database=ufte就能搞定了。没想到。。。万万没想到!
最后还好有了Navicat 8 for Mysql 这个东东,挺好用的。也挺好改的。。。。。。贴图如下。
数据库的:
表:在【选项】
列:点击列时,下面就有相应的属性可以改。
==========================================================================