见鬼了：数据库中有“A+A”，但页面搜不到？？？

概述

近期，用户反馈在使用我们的品牌搜索功能时，无法找到包含“A+A”这个品牌，搜索其它品牌时无异常。经过复现测试，确认了这一问题的存在。本文将详细分析导致该问题的原因，并提出相应的解决方案。

问题复现

在进行问题复现的过程中，我们发现当尝试在搜索框中输入“A+A”并执行搜索时，结果页面中没有A+A。

原因分析

用户搜索时期望的效果与mysql like %搜索关键字%相同。 由于品牌的数量有限且数据量不大，在实际实现时，也是这样做的。

是不是“A+A”这个品牌不存在？

不是。 在品牌列表中是有的：

其他的都正常，"A+A"为什么没搜到？

也不知道。查了下日志，发现系统收到的查询关键字变了，不是A+A，而是：A%20A

%20是什么？是空格。

也就是在前端页面输入的+，到了服务器，变成了空格！！！

对比使用A+A的搜索结果，发现命中的都是带有“A A”的品牌信息：

为什么“+”变成空格了呢？

如下图所示，查询参数放在QueryString中了，也就是查询参数“A+A”是通过Url来传递的。

那么，问题搞清楚了： 根本原因在于，在URL中，加号（+）被视为一个特殊字符，通常用于表示空格。

因此，Web服务器将URL上的“A+A”理解为“A A”。 这导致服务器无法使用“A A”匹配到用户期望的“A+A”，从而影响了搜索结果的准确性。

复盘

回顾整个问题的发生，我们意识到在设计API时，没有充分考虑到特殊字符的处理。尽管加号在URL中有特定的含义，但在我们的应用场景中，它应该被视为普通字符进行处理。这一疏忽导致了用户在搜索包含加号的内容时遇到了困难。

解决方案

方案1、使用body来传递查询参数

这个方案的优缺点： 缺点：前后端都需要进行改动。都要重新开发、测试、发布。 优点：彻底。不会再因为参数中URL中的特殊字段，而导致参数传递时出现发收不一致。

推荐作为长期方案。

方案2、服务端对“A A”进行特殊处理

这个方案的优缺点： 优点：只需要后端进行改动。 缺点：用户输入A+时无法搜到期望的结果。品牌名称中出现其它URL保留字时，仍然会搜到期望的结果。

临时过渡方案，不推荐作为长期方案。

方案3、给“A+A”品牌起个别名，譬如“A加A”

这个方案的优缺点：

优点：只需要后端进行改动。 缺点：品牌名称中出现其它URL保留字时，仍然会搜不到期望的结果。 增加用户的学习成本，用户需要知道如果想搜“A+A”，需要输入“A加A”。 并且在用户看来，这个知识有些不可理解。这会影响用户体验，影响用户对系统强大与否的心智。

临时过渡方案，不推荐作为长期方案。

小结

通过仔细分析和解决问题，我们成功地解决了用户反馈的“A+A”搜索问题。这次经历提醒我们在设计和开发过程中要充分考虑特殊字符的处理，并确保服务器能够准确地理解和满足用户的搜索需求。通过持续改进和优化，我们致力于为用户提供更加准确、便捷的搜索体验。

REFERENCE

UrlEncode编码/解码 https://tool.chinaz.com/tools/urlencode.aspx