我们知道加密数据对模糊查询不是很友好。本文将谈谈对加密数据进行模糊查询的实现，希望对大家有所启发。为了数据安全，我们经常在开发过程中对重要数据进行加密存储。常见的包括：密码、手机号码、电话号码、详细地址、银行卡号、信用卡验证码等信息。这些信息需要加密和解密。他们有区别。例如，我们需要对密码进行加密存储。一般采用不可逆的慢散列算法。慢速哈希算法可以避免暴力破解（通常以时间换取安全性）。我们在搜索的时候不需要解密或者模糊查找，直接使用密文进行匹配，但是手机号不能这样，因为我们需要查看手机号的原始信息，同时还需要支持模糊搜索对于手机号，所以我们今天就支持可逆加解密数据的模糊查询，看看有哪些实现方式。随便在网上搜了一下，关于《加密后的模糊查询》的帖子很多。顺便整理了一下实现方法。不得不说，很多都是不靠谱的方法，甚至还有一些沙雕方法。接下来我们就这些方法说说实现思路和优缺点。如何对加密数据进行模糊查询我整理了一下。对加密数据的模糊查询大致分为三种，如下：沙雕法（不要用脑子去想直男的思维，只是实现功能，从不深入思考问题）常规方法（考虑到查询性能问题，为了性能使用一些存储空间等）超自然的方法（从算法层面对比高端方法）下面我们一一说说这三种实现方式的实现思路和实现方式。优缺点，首先我们来看一下沙雕法。沙雕法将所有数据加载到内存中进行解密。解密后，通过程序算法进行模糊匹配，将密文数据映射到明文映射表，俗称标签表，然后模糊查询标签，将密文数据关联起来。看第一种方法，将所有数据加载到内存中进行解密。如果数据量不大，可以使用这种方法。它既简单又实惠。如果数据量很大，那将是一场灾难。我们粗略算一下。一个英文字母（不区分大小写）占一个字节，一个汉字占两个字节。以DES为例，加密字符串HE9T75xNx6c5yLmS5l4r6Q==24字节。BytesMB100w240022891000w240228891242288.89的数量可以从数百兆字节到千兆字节不等，因此应用程序可以在几分钟内转换为Outofmemory。几万条记录完全可以这样做，但是如果数据量很大，强烈不建议这样做。推荐一个SpringBoot基础实战教程：https://github.com/javastacks...沙雕2再看第二种方法，将密文数据映射到一个明文映射表，然后模糊查询映射表进行关联密文数据，什么？？？！！！那我们为什么要对数据进行加密呢，不直接加密岂不是更好！由于我们对数据加密肯定有安全需求，所以我们会这样做。添加明文映射表违反安全要求。这既不安全也不方便。常规做法我们来看看常规做法，这也是使用最广泛的方法。这种方式满足了数据安全，查询友好。在数据库中实现加密算法功能，在模糊查询时使用decode(key)like'%partial%对密文数据进行分段，对分段组合的结果集进行加密，然后存入扩展列，并通过keyLike'%partial%'常规查询时，实现了与数据库中程序一致的加解密算法，修改了模糊查询条件，利用数据库加解密函数先解密再模糊查找。这样做的好处是实施成本低，开发使用成本低。对之前的模糊搜索稍作修改即可实现，但缺点也很明显。这样就不能利用数据库的索引来优化查询，甚至有些数据库也不一定能保证和程序一样的加解密算法，但是对于常规的加解密算法是可以保证的与应用一致。如果对查询性能要求不是特别高，对数据安全性要求一般，使用AES、DES等常用的加解密算法也是不错的选择。如果公司有自己的算法实现，没有提供多端算法实现，要么找算法好的人研究完成多端实现，要么放弃使用这种方式。将常规的两对密文数据切分组合，切分组合的结果集分别加密，然后存储在扩展列中。查询时，使用像'%partial%'这样的键。这是一种比较划算的实现方式。我们先分析一下。看看它的实现思路。先将固定长度的字符分组，将一个字段拆分成多个。例如，使用4个英文字符（半角）和2个汉字（全角）作为搜索条件。例如：ningyu1使用4个字符是一组加密方式，第一组是ning，第二组是ingy，第三组是ngyu，第四组是gyu1……以此类推。如果需要检索所有包含搜索条件4个字符的数据，如：ingy，将字符加密后，使用“%partial%”这样的key来搜索数据库。我们都知道加密后长度会增加。增加的长度存储是我们不得不花费的额外成本。典型的使用成本是用速度来换取的。密文的增长速度随算法的不同而不同。以DES为例，13800138000加密前11个字节，加密后的字符串HE9T75xNx6c5yLmS5l4r6Q==24个字节，增加了2.18倍，所以一个优秀的算法是多么的重要，它可以为公司节省很多成本，但是话又说回来了，算法工程师的工资不低，所以不知道是节约成本还是增加成本，哈哈哈。。。你自己想办法吧。回到正题，虽然这种方法可以实现加密数据的模糊查询，但是对模糊查询的字符长度有要求。上面我举的例子，模糊查询字符的原文长度必须大于等于4个英文/数字，或者2个汉字，不管长度多短，都不推荐，因为数字分词组合的数量会增加，这会增加存储成本并降低安全性。你连接过淘宝、拼多多、京东的API吗？他们对平台订单数据中的用户敏感数据进行加密，同时支持模糊查询。这是使用的方法。下面我整理了几个电商平台的密文字段，对于搜索方案的说明，有兴趣的可以查看下面的链接。淘宝密文字段检索方案：https://open.taobao.com/docV3...阿里巴巴文本字段检索方案：https://jaq-doc.alibaba.com/d...拼多多密文字段检索方案：https：//open.pinduoduo.com/ap...京东密文字段检索解决方案：https://jos.jd.com/commondoc?...ps。它们基本相同，果然互相抄袭，连加密后的数据格式都一样。这种方法的优点是实现起来并不复杂，使用起来也比较简单。是一种折衷的方法，因为扩展字段的存储开销会增加，但是可以通过数据库索引来优化查询速度。推荐使用此方法。来看看超神的绝妙手段吧。这些方法难度都比较大，都是从算法层面考虑的。有些人甚至设计了一种新算法。虽然有一些现成的算法参考，但大部分都是半成品，不能用。直接拿来用，还是需要有人深入研究，集成到自己的应用中。从算法层面思考，你甚至可以设计一个新的算法来支持模糊搜索。这个层次多是专业算法工程师的研究领域。设计一个有序的、不可逆的、非不可逆的、不能增长太快的算法并不是什么难事。简单的东西，大体思路是这样的，用解码的方式进行加解密，保持密文和原文顺序一致，这样就可以支持密文模糊匹配。它更笼统，因为我不是该领域的专家。没有更深的一步步研究，所以从网上找了一些资料供参考。数据库中字符数据的模糊匹配加密方法：https://www.jiamisoft.com/blo...这里提到的希尔密码处理和模糊匹配加密方法FMES可以重点关注。基于BloomFilter的改进加密文本模糊搜索机制研究：http://kzyjc.cnjournals.com/h...如何加密支持快速查询的数据库：https://www.jiamisoft.com/blo...基于Lucene的云搜索和密文基于模糊查询：https://www.cnblogs.com/arthu...基于Lucene的思路和我们上面介绍的常规方法2类似。字符等长切分，切分后的结果集加密。存储，但是存储的db不同，一个是关系型数据库，一个是es搜索引擎。一种云存储中可验证的模糊查询加密方案：http://jeit.ie.ac.cn/fileDZYX...总结这里介绍了所有加密数据的检索方案，首先提到的是搜索沙雕网上随处可见的方法。这里也提一下，不推荐这些沙雕方法，尽量用常规的方法。如果公司有专业的算法人才，不妨考虑基于算法层面的灵异手段。一般来说，从投入、产出比、实施和使用成本上来说，第二种套路方法是非常推荐的。来源：ningyu1.github.io/20201230/encrypted-data-fuzzy-query.html近期热点文章推荐：1.1000+Java面试题及答案（2022最新版）2.厉害了！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
