DN解析需用ldap_str2dn()状态机而非split或正则，因其能正确处理,、+等转义及多值RDN；解析后须双重循环遍历RDN与AVA，用bv_len而非strlen取值；UTF-8值需确保输入合法且后续API指定CP_UTF8。
DN 字符串里为什么 \ 和 + 会破坏解析逻辑
LDAP 的 DN 是结构化字符串，但不是标准的 URI 或 JSON——它用逗号 , 分隔 RDN（Relative Distinguished Name），用等号 = 分隔属性名与值，而值中允许出现逗号、等号、反斜杠甚至空格，这时就必须转义。常见错误是把 DN 当成简单 CSV 处理，直接按 , 切分，结果在 CN=John, Doe,OU=Eng+Admin,DC=example,DC=com 这类字符串上崩掉：第一个 , 表示字面逗号，不该切；+ 同理，+ 在 RDN 中是多值分隔符（如 CN=John+SN=Doe），但被转义后就只是普通加号。
真正安全的做法是逐字符状态机解析，而非正则或 split。libldap 自带的 ldap_str2dn() 就是这么做的——它识别转义序列（xx 十六进制或单字符转义）、引号包围的值（"CN=foo, bar"）、以及括号嵌套（极少见但合法）。
-
ldap_str2dn()是唯一被 OpenLDAP 官方保证能处理所有 RFC 4514 合法变体的 C 接口，包括空格前导/尾随、双引号包裹、十六进制转义A - 不要自己写
std::regex去 match，RFC 4514 允许的转义组合和边界条件太多，正则极易漏判或过度切分 - 若不能链接 libldap（如嵌入式环境），可用 OpenLDAP 源码中的
ldap_str2dn()实现 提取精简版，它不依赖其他 LDAP 功能，纯字符串状态机
用 ldap_str2dn() 解析后，如何安全访问每个 AVA（Attribute Value Assertion）
调用 ldap_str2dn() 成功后返回的是 LDAPDN 类型（本质是 LDAPRDN **），每层是 RDN 数组，每个 RDN 又是 AVA 数组。这不是扁平结构——一个 DN CN=foo+UID=123,OU=dev,DC=ex 包含 3 个 RDN，其中第一个 RDN 本身含两个 AVA（CN=foo 和 UID=123），顺序有意义（RFC 规定多值 RDN 中左侧优先）。
常见误操作是假设每个 RDN 只有一个 AVA，然后硬取 rdn[0]->ava[0]，一旦遇到 + 多值就会丢数据。
立即学习“C++免费学习笔记（深入）”；
- 必须双重循环遍历：
for (r = dn; *r; r++) { for (ava = *r; *ava; ava++) { ... } } -
ava->la_attr是属性名（如"CN"），ava->la_value.bv_val是值指针，la_value.bv_len是真实长度（注意：值可能含嵌入 null，不能当 C 字符串用strlen） - 若需复制值，必须用
strndup(ava->la_value.bv_val, ava->la_value.bv_len)，而不是strdup - 别忘了调用
ldap_dnfree(dn)释放内存，否则每次解析都 leak
C++ 封装时，为什么不能直接用 std::string 存储原始 DN 字符串做缓存
很多人图省事，把原始 DN 字符串（如 "CN=Test\, User,OU=Sales,DC=corp"）存进 std::string，后续需要某属性时再临时解析。这看似无害，但有两处隐蔽风险：
- 同一 DN 字符串可能被反复解析多次（比如查用户时先解析拿
DC，再解析拿CN），而ldap_str2dn()内部有少量内存分配和状态判断，性能可测出 2–3 倍差异 - 更严重的是语义漂移：如果上游系统返回的 DN 已经是规范格式（如大小写归一、空格压缩），但你的代码又用非标准方式拼接新 DN（比如手动
"CN=" + name + "," + base），再喂给ldap_str2dn()，可能因空格/转义不一致导致解析失败或属性错位 - 正确做法是解析一次，把结果结构化缓存为自定义对象（如
struct DnPart { std::string attr; std::string value; bool is_multi; };），原始字符串仅作只读备份，不参与构造逻辑
当 DN 含 Unicode（UTF-8）时，ldap_str2dn() 是否自动处理
是的，但有个关键前提：传入的 DN 字符串必须是合法 UTF-8 编码，且 libldap 编译时启用了 --enable-crypt 或至少 --enable-slapd（通常默认开启）。ldap_str2dn() 本身不进行编码转换，它只做语法解析；但它能正确跳过 UTF-8 多字节序列中的中间字节（如 é 表示 é），不会把 误判为转义起始。
真正容易出问题的是后续使用环节：
- 如果你把解析出的
ava->la_value.bv_val直接传给 Windows API（如MultiByteToWideChar(CP_ACP, ...)），而没指定CP_UTF8，就会乱码 - OpenLDAP 不验证 UTF-8 合法性——传入损坏的 UTF-8（如截断的
）会导致ldap_str2dn()返回LDAP_INVALID_SYNTAX，但错误信息不提示编码问题，只报“invalid DN” - 调试时可用
is_utf8((const char*)ava->la_value.bv_val, ava->la_value.bv_len)（参考 GLib 的g_utf8_validate()实现）预先校验
最常被忽略的一点：DN 中的属性名（如 CN、OU）是 ASCII 固定关键字，但值部分可以是任意 UTF-8，解析器绝不会对值内容做大小写折叠或规范化——你拿到的就是 wire 上的原样字节。
