目前的问题与this one不同。
我有一个LDAP条目，其中“supName”字段中的内容“这确实是一个SimpleTest”。
我需要编写一个过滤器，以便当我的软件用户在任何情况下（大写，小写或混合大小写）引入此内容的任何子字符串时，它会找到该条目。即使用户没有输入完整的单词（例如“实现”），它也必须工作。
supName字段遵循DirectoryString语法。这意味着默认匹配规则是精确且区分大小写的（“caseExactMatch”）。但是这种语法in theory，也应该允许“caseIgnoreMatch”和“caseIgnoreSubstringsMatch”匹配规则。我虽然我只需要强制使用最后一个（“caseIgnoreSubstringsMatch”），所以我尝试了这个过滤器：
(supName:caseIgnoreSubstringsMatch:=*impletes*)
但这不起作用。我使用Apache Directory Studio进行测试，该工具拒绝接受上述过滤器。它抱怨星号，我不明白为什么，因为我使用的是子串匹配（因此应该允许使用星号）。如果我从命令行运行过滤器（使用ldapsearch），我收到此错误消息：
ldap_search_ext: Bad search filter (-7)
因此，这不是Apache Directory Studio的问题。
所以我的问题是：在默认情况下区分大小写的字段上定义不区分大小写的子字符串过滤器的正确方法是什么？
以下是我测试的其他一些过滤器，以及它们不适合我的原因。
测试＃1过滤器：
(supName=*impleTes*)
此运算符（=）返回我的测试条目，但它不区分大小写。如果我将“implementTes”替换为“implements”，它就不会返回任何内容。
测试＃2过滤器：
(supName~=simpletest)
此运算符（〜=）有效，但是：
测试＃3过滤器：
(supName:caseIgnoreMatch:=this is a simpletest indeed)
这将返回我期望的条目，并且仅返回该条目。它也不区分大小写。但它强制用户编写该字段的整个内容：它不是子字符串搜索，而是不区分大小写的完全匹配搜索。
测试＃4过滤器：
(supName:caseIgnoreMatch:=*impletes*)
这会返回“错误的搜索过滤器（-7）”错误，因为我不允许在完全匹配的规则中使用子字符串语法。
最后，测试＃5过滤器：
(supName:caseIgnoreSubstringsMatch:=*impletes*)
我希望工作，但返回“错误的搜索过滤器（-7）”错误。
我找到了here（参见最后的“可扩展匹配”部分）相反案例的例子。在该示例中，字段“sn”默认使用“caseIgnoreMatch”匹配规则（使其不区分大小写）。因此，他们在示例中想要的是进行区分大小写的子字符串搜索。这是他们使用的过滤器：
(sn:caseExactSubstringMatch:=*S*)
但是我怀疑这个例子是否正确，因为如果我在我这边尝试完全相同的过滤器：
(supName:caseExactSubstringMatch:=*S*)
我收到“错误的搜索过滤器（-7）”错误。
所以也许我的问题是由于OpenLDAP 2.4.33的限制，但可以与其他LDAP服务器一起使用，尽管该示例来自一个应该涵盖OpenLDAP 2.x的指南...（？）
答案 0 :(得分：0)
如果我正确地阅读RFC 4515§3，则只能使用an assertion value（读取：固定字符串）而不是使用子字符串过滤器进行可扩展匹配。如果允许，我希望您的原始示例(supName:caseIgnoreSubstringsMatch:=*impletes*)能够正常运行。
答案 1 :(得分：-1)