摘要

  • RFC 1558 为 LDAP 的二进制 Filter 定义了前缀式文本表示；括号、&、|、!、比较符和 * 都是可执行结构，而非说明性标点。
  • 过滤器只是 SearchRequest 的一个字段。搜索基点、范围、别名策略、限制、模式匹配规则、访问控制和最终结果共同决定服务器实际做了什么。
  • 后续 RFC 逐步引入标准轨、LDAPv3、UTF-8 与十六进制八位组转义。RFC 1558 本身属于 Informational，且明确没有讨论安全问题；这些文献不能证明部署、事故或当前漏洞。

一个星号，三种权限

RFC 1558 正文里最值得追踪的对象只有一个字符。在 attr=* 中，星号构成“存在”过滤器；在 (o=univ*of*mich*) 中，它把若干片段连成子串条件；当属性值本身含有星号时，1993 年文本要求在前面加反斜杠，避免它被解释成运算符。

三种写法的视觉差异很小，执行含义却完全不同。(cn=Babs Jensen) 是等值条件；(!(cn=Tim Howes)) 对条件取反；(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) 则形成一棵以 AND 为根、内部带 OR 和子串匹配的谓词树。服务器不是在阅读一句自然语言，而是在解析一套分支指令。

Datatracker 记录与 RFC Editor 状态页确认该文档发表于 1993 年 12 月，类别为 Informational，并不规定任何互联网标准。纯文本档案提供另一份文本核对，勘误页把后续纠错与原文分开。原文的安全章节只说没有讨论安全问题。因此，今天可以用它分析结构化输入风险，却不能声称它当年已经记录“LDAP 注入”、某次泄露或某个有漏洞的产品。

文本只是二进制对象的表面

RFC 1487早已定义 LDAP SearchRequest：其中有以 BER 在网络上传输的 Filter，也有搜索基点、范围、别名解引用方式、大小与时间限制、是否只返回属性类型以及请求哪些属性。RFC 1558 的工作很窄——给 Filter 一种共同的人类可读表示。

这种克制非常重要。它没有把整个搜索压进一行文本，也没有让文本成为唯一事实。相同过滤器放在不同基点之下，会访问不同目录区域；从单层改成整棵子树会扩大候选集合；别名解引用可能把搜索带到别处；限制会让结果提前结束；属性选择则决定匹配之后可以请求什么。RFC 1488为当时的标准属性语法提供字符串形式，但它也不是未来所有目录值与匹配规则的总契约。

解析成功不等于服务器给出二值答案

现行协议 RFC 4511把过滤器定义为“某个条目要匹配搜索必须满足的条件”，其官方记录则保存文档身份。服务器按照三值逻辑求值：TRUE、FALSE 或 Undefined。只有 TRUE 才可能返回条目，而且仍受访问控制和其他限制。

未知属性、缺少适当匹配规则、未知规则标识或无效断言值，都可能产生 Undefined。于是，字符串符合语法只证明解析器接受了外壳，不证明模式认识其中每个字段，更不证明操作者预想的比较语义被执行。

结果同样不是一个瞬间的“成功”。搜索可以先返回零个或多个 SearchResultEntry、SearchResultReference，最后才有一个 SearchResultDone。引用表示仍有区域未被本次搜索探索；条目中的属性值也可能因请求方式、访问控制或管理策略而缺失。匹配、返回、完整探索和成功结束必须分别取证。

转义规则为什么继续演化

RFC 1960在 1996 年保留了熟悉的前缀语法，并以 Proposed Standard 取代 RFC 1558；其状态记录也显示它后来被 RFC 2254 取代。

RFC 2254把表示法扩到 LDAPv3 的可扩展匹配，并进入 UTF-8 语境；特殊八位组改用反斜杠加两位十六进制数表示。它在演化链中的位置见官方状态页。

现行 RFC 4515及其状态页进一步明确：星号、左右括号、反斜杠和 NUL 对应的八位组必须转义，生成的字符串要满足有效 UTF-8。例子 (cn=*\2a*) 中，外侧星号仍是子串运算符，\2a 才是值里的字面星号。

这不是装饰性清理，而是可复现性边界。如果日志只留下显示后的字符串，却丢掉原始八位组、转义器版本与解析树，事后就无法确定某个字符究竟扩大了搜索，还是属于数据。

共同表示不是共同授权

可读格式带来了真实收益：配置可以评审，模板可以交换，二进制 BER 不再是唯一观察入口。问题不在“文本化”，而在把共同表示误当成共同决定。

Heng Lu 的最小初始规范、未来决策本地化与自愿采用提供了一种事后分析框架：共同层只承担确定且最小的协调，依赖本地模式、数据和策略的判断仍要留在可识别的责任面。Running-Code Primacy提醒我们，RFC 是规范证据，不是某台服务器的运行凭证；现实分层则要求把显示字符串、解析树、BER 请求、求值、返回数据与应用动作分开。

1993 年的资料没有给出事故、受影响安装、当前实现、暴露数据或采用率。后续规范的存在也不等于所有部署都完成迁移。RFC 1558 真正留下的历史贡献，是让一个协议对象可以被人看见；它留下的治理问题，则是可见性不能代替对执行权的追踪。

来源