我在仔细研究OpenLDAP的源代码，并且看到了根DSE支持绝对filter的地方。 它看起来像它在RFC4526中指定它看起来像最初起草它的作者是在OpenLDAP项目上工作，所以我不知道这是否是有用的具体实施或什么。
RFC无论如何给出了这个定义：
An 'and' filter consisting of an empty set of filters SHALL evaluate to True. This filter is represented by the string "(&)". An 'or' filter consisting of an empty set of filters SHALL evaluate to False. This filter is represented by the string "(|)" 我的问题是：这有什么用处？ 我想不出有什么能够做你以前做不到的事情的例子。 如果你想要一个绝对的AND那么你不能(objectClass=*)filter，因为所有的条目必须至less有一个对象类？
我唯一能想到的就是绝对错误。 这可能是因为你只是想在服务器上做一个noop来确保通信仍然正常运行。 这仍然是多余的，因为我会认为查询根DSE和丢弃结果会做同样的事情，不可能是所有的计算成本昂贵。
在ldapsearch使用filter产生的结果，我想我应该期望给出上面的结果：
[root@hypervisor openldap]# ldapsearch -x -H ldap://policyServer.trunkator.com -b '' -s base "(|)" + # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (|) # requesting: + # # search result search: 2 result: 0 Success # numResponses: 1 [root@hypervisor openldap]#
使用绝对的真正的filter返回相同的东西，就像我做了一个(objectClass=*) （这是OpenLDAP的ldapsearch客户端的默认filter，如果你没有在命令行上指定的话）。
根据RFC，他们从原来的LDAPv3 RFC中删除了这些，所以作者经历了将它们添加回来的麻烦，我只是好奇为什么（我确定有一个原因）。
有任何想法吗？
编辑：
穷人位顶端：当我说“根DSE支持”一个更清晰的说法是，OpenLDAP中的根DSE硬编码回报，它支持绝对filter。
RFC的摘要和背景部分清楚地表明，这个特性在LDAP v3中被忽略了。 绝对filter的概念显然是X.500 / DAP的一部分，它们旨在帮助查询DSA特定的条目，这些条目可能没有与它们关联的对象类。 虽然这显然不是供应商特定的function，但它的实现由供应商来执行（例如，OpenLDAP似乎已经实现了它）。 如果所使用的目录软件将所有条目（包括DSA特定条目）与使filter“（objectclass = *）”作用为绝对filter的对象类（例如，顶部）相关联，似乎并不是很有用这导致“真实”。 如果目录软件没有将DSA特定的条目与对象类或其特定值在search中将parsing为“真”的另一个属性相关联，则作为真/假切换的绝对filter成为必需特征（除非目录软件提供了专有的方法来检索这些条目，这可能不是一个好主意，因为这样的非标准实现会强制LDAP客户端受限于供应商/特定的）。
我怀疑这是让某些编程结构更容易。 例如，如果您在代码中构buildfilterexpression式，如下所示：
filter_string='(&' for filter in filters: filter_string = filter_string + '(' + filter + ')' filter_string = filter_string + ')'
…在没有filter的情况下，您以(&)结尾，并且您突出显示的RFC部分定义了这应该如何performance。 (|)也是一样的推理。