对于这个问题，我们希望避免编写特殊查询，因为查询必须在多个数据库中不同。仅使用hibernate标准，我们希望能够转义特殊字符
这种情况是需要能够转义特殊角色的原因：
假设数据库中有表’foo’。表“foo”仅包含一个名为“name”的字段。“名称”字段可以包含在数据库中可能被视为特殊的字符。此类名称的两个示例是“name_1”和“name%1”。“\”和“%”都是特殊字符，至少在Oracle中是这样。如果用户希望在将这些示例输入数据库后搜索其中一个示例，则可能会出现问题
criteria=Restrictions.ilike（“name”、searchValue、MatchMode.ANYWHERE”）；
返回findByCriteria（null，criteria）；
在此代码中，“searchValue”是用户为应用程序提供的用于搜索的值。如果用户要搜索“%”，将返回数据库中的每个“foo”条目。这是因为“%”字符表示用于字符串匹配的“任意字符数”通配符，hibernate生成的SQL代码如下所示：
从foo中选择*
有没有办法告诉hibernate转义某些字符，或者创建一个不特定于数据库类型的解决方案
LikeExpression的构造函数都是受保护的，所以它不是一个可行的选项。此外，它也有自己的问题
我和一位同事创建了一个补丁，效果很好。补丁的要点是，对于使用MatchMode的LikeExpression构造函数，我们对特殊字符进行了转义。对于使用字符（转义字符）的构造函数，我们假设用户自己转义特殊字符
我们还对转义字符进行了参数化，以确保在SQL查询使用\或引号字符时不会损坏SQL查询
包org.hibernate.criteria；
导入org.hibernate.Criteria；
导入org.hibernate.hibernateeexception；
导入org.hibernate.dialogue.dialogue；
导入org.hibernate.engine.TypedValue；
公共类LikeExpression实现了这个标准{
私有最终字符串propertyName；
私有最终字符串值；
私人最终角色escapeChar；
受保护的类表达式(
字符串propertyName，
对象值）{
这是（propertyName，value.toString（），（字符）null）；
}
受保护的类表达式(
字符串propertyName，
字符串值，
匹配模式（匹配模式）{
这个（propertyName，matchMode.toMatchString）值
.toString（）
.replaceAll（“！”、“！！”）
.replaceAll（“%”、“！%”）
.replaceAll（“，”！），“！”）；
}
受保护的类表达式(
字符串propertyName，
字符串值，
字符转义（ECHAR）{
this.propertyName=propertyName；
这个值=值；
this.escapeChar=escapeChar；
}
公共字符串toSqlString(
标准，
CriteriaQuery（CriteriaQuery）抛出HibernateException{
方言方言=criteriaQuery.getFactory（）.getdia方言（）；
String[]columns=criteriaQuery.getColumnsUsingProjection（条件，propertyName）；
如果（columns.length！=1）{
抛出新的HibernateException（“Like只能与单列属性一起使用”）；
}
字符串lhs=lhs（方言，列[0]）；
返回lhs+“like？”+（escapeChar==null？”：“escape？”）；
}
公共类型值[]获取类型值(
标准，
CriteriaQuery（CriteriaQuery）抛出HibernateException{
返回新的TypedValue[]{
getTypedValue（条件，propertyName，typedValue（值）），
criteriaQuery.getTypedValue（criteria、propertyName、escapeChar.toString（））
};
}
受保护字符串lhs（方言、字符串列）{
返回列；
}
受保护的字符串类型值（字符串值）{
返回值；
}
}
如果您想知道lhs和typedValue方法的用途，那么新的IlikeExpression应该可以回答这些问题
包org.hibernate.criteria；
导入org.hibernate.dialogue.dialogue；
公共类IlikeExpression像Expression一样扩展{
受保护的IlikeExpression(
字符串propertyName，
对象值）{
super（propertyName，value）；
}
受保护的IlikeExpression(
字符串propertyName，
字符串值，
匹配模式（匹配模式）{
超级（propertyName、value、matchMode）；
}
受保护的IlikeExpression(
字符串propertyName，
字符串值，
字符转义（ECHAR）{
超级（propertyName、value、escapeChar）；
}
@凌驾
受保护字符串lhs（方言、字符串列）{
返回方言.getLowercaseFunction（）++'（'+column++'）；
}
@凌驾
受保护的字符串类型值（字符串值）{
返回super.typedValue（value.toLowerCase（）；
}
}
在此之后，唯一剩下的就是限制使用这些新类：
公共静态条件（字符串属性名称、对象值）{
返回新的LikeExpression（propertyName，value）；
}
公共静态条件，如（字符串属性名称、字符串值、匹配模式）{
返回新的LikeExpression（propertyName、value、matchMode）；
}
公共静态条件（字符串属性名称、字符串值、字符转义）{
返回新的LikeExpression（propertyName、value、escapeChar）；
}
公共静态条件ilike（字符串属性名称，对象值）{
返回新的IlikeExpression（propertyName，value）；
}
公共静态条件ilike（字符串属性名称、字符串值、匹配模式匹配模式）{
返回新的IlikeExpression（propertyName、value、matchMode）；
}
公共静态条件ilike（字符串属性名称、字符串值、字符转义）{
返回新的IlikeExpression（propertyName、value、escapeChar）；
}
编辑：哦，是的。这对甲骨文有效。不过，我们不确定是否还有其他数据库