问题
最近,在用SSH框架完成一个实践项目时,碰到了一个莫名其妙的Bug困扰了我好久,最后终于解决,记录如下。
问题:同学在测试系统的时候突然发现,数据库保存的账户本来应该是admin,结果该同学用Admin账户居然登录成功了……
……EXM???这样也行?好吧,我还是查找这个Bug发生的原因吧。然后就是各种排查程序的过程,找来找去也没发现什么问题。终于想到,不用hql,自己写sql语句在数据库里面直接查询试试,结果果然发现了问题所在:
select * from user where username = 'admin' and password = 'admin'; select * from user where username = 'Admin' and password = 'admin';
用上面的两条sql语句分表查询,出来的结果居然是一样的!……!!去搜索引擎搜索关键词:MySQL 查询 大小写,果然找到问题了!MySQL查询是不区分大小写的!这可真的是惊呆我了,虽然知道一般情况下,关键字是不区分大小写的,但是没想到连要查询的参数都是不区分大小写的!!再尝试下面的sql语句,果然还是一样的结果。
select * from user where username = 'ADMIN' and password = 'admin';
解决方案
网上搜索到一篇相关的文章,写的挺好的,这里直接贴上该文章解释吧:
Mysql默认的字符检索策略:utf8_general_ci,表示不区分大小写;utf8_general_cs表示区分大小写,utf8_bin表示二进制比较,同样也区分大小写 。(注意:在Mysql5.6.10版本中,不支持utf8_genral_cs!!!!)
创建表时,直接设置表的collate属性为utf8_general_cs或者utf8_bin;如果已经创建表,则直接修改字段的Collation属性为utf8_general_cs或者utf8_bin。
-- 创建表: CREATE TABLE testt( id INT PRIMARY KEY, name VARCHAR(32) NOT NULL ) ENGINE = INNODB COLLATE =utf8_bin; -- 修改表结构的Collation属性 ALTER TABLE TABLENAME MODIFY COLUMN COLUMNNAME VARCHAR(50) BINARY CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL;
直接修改sql语句,在要查询的字段前面加上binary
关键字即可。
-- 在每一个条件前加上binary关键字 select * from user where binary username = 'admin' and binary password = 'admin'; -- 将参数以binary('')包围 select * from user where username like binary('admin') and password like binary('admin');
注意:在我的这次项目中用的是hibernate框架,使用的并不是sql,而是hql语句,使用
from User where binary username = ? and binary password = ?;
结果报错,再试from User where username like binary(?) and password like binary(?);
才没有报错。原因暂时不知。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。如果你想了解更多相关内容请查看下面相关链接
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
稳了!魔兽国服回归的3条重磅消息!官宣时间再确认!
昨天有一位朋友在大神群里分享,自己亚服账号被封号之后居然弹出了国服的封号信息对话框。
这里面让他访问的是一个国服的战网网址,com.cn和后面的zh都非常明白地表明这就是国服战网。
而他在复制这个网址并且进行登录之后,确实是网易的网址,也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情,因为以前都没有出现这样的情况,现在突然提示跳转到国服战网的网址,是不是说明了简体中文客户端已经开始进行更新了呢?