因为一个空格引发的编程“惨案“

共 2675字,需浏览 6分钟

 ·

2020-08-28 13:19

转自:互联网全栈架构


“案情”回顾(情景模拟):

小张是一名软件工程师,工作兢兢业业、一丝不苟且精益求精,天性乐观的他每天愉快地做着增删改查的工作,对于这些看似简单的CRUD,小张从来不会掉以轻心,他也笃定地坚信,自己向数据库里插入了什么数据,就能按条件把这些数据查询出来,毕竟,像MySQL这样的数据库,在全世界广为流行,大行其道,不可能不严谨。


然而,意想不到的悲剧还是发生了。

小张做的项目与语言处理有点关系,他们把处理的结果也就是字符串保存到在数据库里面,后续需要按照条件把这些数据查询出来,但需要对这些字符串做严格的区分,也就是说,如果查询A字符串,不能把B字符串查询出来,哪怕这两个字符串只有一个空格的差异。对于这样的需求,小张觉得太天经地义了,根本无需多言,像MySQL这样的数据库天生就是干这样的事,所以当时就自信满满地拍着胸脯保证一定如期开发完成。

随着工作的推进,小张猛然发现MySQL对于字符串的处理貌似不那么严谨,特别是对于空格字符,比如这两个字符串:"Tom"和"Tom ",后面的字符串多了一个空格,然而,MySQL竟然把它们当成了相同的字符串。


我们来测试一下,看看具体的情况,先创建一个表:

CREATE TABLE `white_space`(
`id` bigint(20)unsigned NOT NULL AUTO_INCREMENT,
`name`varchar(128NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
ENGINE=InnoDBDEFAULT CHARSET=utf8


然后向表里插入两条数据:

INSERT INTO white_space(nameVALUES('Tom');
INSERT INTO white_space(nameVALUES('Tom ');
 
注意,后面那条记录在最后多了一个空格。假设我们需要查询名字为Tom的记录(没有空格),SQL很简单:

SELECT * FROM white_space WHERE name = 'Tom';

 然而,让小张大跌眼镜的是,上面的SQL竟然返回两条数据,也就是说,本来查找"Tom"(没有空格),却把"Tom "(有空格)也查询出来了:



这也太不严谨了,空格也是字符啊,为什么就生生的把它忽略了呢?这样的话,就满足不了项目的需求了,而且,小张还发现,不管后面有多少个空格,都会被忽略。我们再插入一条记录,名字是"Tom          ",后面一共有10个空格:

INSERT INTO white_space(nameVALUES('Tom          ');

再执行上面的查询语句,这时仍然还是返回了三条记录:

SELECT * FROM white_space WHERE name = 'Tom';


这简直太不可理喻了!感觉MySQL在这里完全无视空格的存在,但空格也是一个正正经经的字符啊,而且是一个非常常见的字符,咋就这么没有存在感呢。

当然,如果是前置空格,或者空格在中间是不会有这个问题的,比如数据库里保存的名字为" Tom"(最前面是一个空格),或者是"To m",再按"Tom"(没有空格)去查询的话,是找不到这条记录的。

这就麻烦了,当初可是拍着胸脯保证可以如期完成的,现在碰到这样的问题,小张可真是有点慌了神,不知道该如何来解决,而且这也是非常不可思议的事情,强悍如斯、威武如斯、名声震天响的MySQL竟然如此不严谨。幸亏空格不会说话,要不然它还不得骂街啊,作为一个名正言顺的字符,就这样生生地被忽略了,这也太不尊重人了。

事已至此,小张只能去寻找问题的解决方法,抱怨是没有用的,经过一番辛勤探索和研究,小张终于找到了办法,也就是加上BINARY关键字,像下面这样:

SELECT * FROM white_space WHERE BINARY name = 'Tom';

这时候就会严格地进行匹配,只返回了一条记录,如果要查询包含空格的记录,比如"Tom "(有空格),就会只返回有空格的这条记录:

SELECT * FROM white_space WHERE BINARY name = 'Tom ';


完美!项目就是需要这样的效果,字符串要进行严格的匹配与区分,现在加上BINARY关键字就彻底地解决了这个问题,小张不禁有些沾沾自喜,他也觉得MySQL确实太强大了,不管什么样的问题貌似都有办法解决,怪不得它会风靡全世界,成为了万千企业的首选。

然而,小张还没有高兴没多久,新的问题就又出现了。BINARY是MySQL独有的关键字,Oracle数据库并不认识什么BINARY,而项目需要适配不同的数据库,主要包括MySQL和Oracle。公司有一套ORM来做这样的适配,开发人员只要按照标准来写SQL就可以了,但是,如果在SQL语句中加上BINARY,切换到Oracle数据库就会出错,这可怎么办?当然,也可以判断数据库的类型,如果是MySQL数据库,就加上BINARY关键字,否则就不加(Oracle数据库可以严格区分后置空格),但是,这样的改动也太大了,因为MySQL中的语句都完全忽略了后置空格的存在,比如GROUP BY:

SELECT name,COUNT(*) FROM white_space GROUP BY name


返回这样的结果:



也是完全忽略了后置空格,当然,加上BINARY也是可以解决问题的。


这样看来,只要涉及到需要严格区分字符串的地方,都需要做这样的改动,而这样的字段还有好几个,改动实在太大了!

事到如今,小张依然还没有找到完善的解决方案,开发的工期也一拖再拖,可以说是一桩不折不扣的“惨案”了。

你有什么好的解决方案吗?欢迎后台留言讨论。

-End-

更多精彩:

SpringSecurity + JWT 权限系统

非常强悍的 RabbitMQ 总结,写得真好!

这个IDEA插件,专门解决Maven依赖冲突

RabbitMQ+WebSocket实现大屏幕消息推送

这7 款 MySQL 客户端工具,用了都说好!

Spring 和 Spring Boot 最核心的 3 大区别

关注公众号,查看更多优质文章

明天见(。・ω・。)ノ♡

浏览 58
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报