Примерный поиск с openldap - PullRequest
Новая
       15

Примерный поиск с openldap

0 голосов
/ 28 ноября 2011

Я пытаюсь написать запрос, который запрашивает наш сервер каталогов, работающий с openldap.

Пользователи будут искать, используя имя или фамилию человека, которого они интересуют.

Я обнаружил проблему с акцентированными символами (например, áéíóú), потому что имя и фамилия написаны на испанском языке, поэтому, хотя правильный путь - Pérez, он может быть записан для поиска как Perez без акцента.

Если я использую '(cn=*Perez*)', я получаю только результаты без акцента.

Если я использую '(cn=*Pérez*)', я получаю только акцентированные результаты.

Если я использую '(cn=~Perez)', я получаю странные результаты (или, по крайней мере, ничего, что я могу использовать, потому что, хотя результаты содержат как Perez, так и Pérez вхождения, я также получаю некоторые результаты, которые, очевидно, не имеют ничего общего с запрос ...

На испанском это случается довольно часто ... будь то лень, будь то, как вы хотите это назвать, дело в том, что для такого рода вещей люди, как правило, НЕ пишут акценты, потому что они предполагают, что все эти поиски работают с оба варианта (я полагаю, поскольку Google это разрешает, все предполагают, что это должно работать именно так).

Кроме обновления базы данных, удаления всех акцентов и обрезки их в запросе ... вы можете придумать другое решение?

Ответы [ 2 ]

0 голосов
/ 16 апреля 2013

Фильтры поиска ("запросы") задаются как RFC2254 .

Кодирование: RFC2254 на самом деле требует фильтров (косвенно определены), чтобы быть OCTET STRING , т.е. ASCII 8-байтовая строка: AttributeValue is OCTET STRING, MatchingRuleId и АтрибутDescription
LDAPString, LDAPString - строка октетов.

Стандарт на экранирование: используйте «\» для замены специальных символов (http://tools.ietf.org/html/rfc4515#page-4, примеры http://tools.ietf.org/html/rfc4515#page-5). Цитата:

Правило гарантирует, что вся строка фильтра допустимая строка UTF-8 и обеспечивает, что октеты, которые представляют Символы ASCII "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 0x29), "\" (ASCII 0x5c) и NUL (ASCII 0x00) представлен в виде обратной косой черты "\" (ASCII 0x5c), за которой следуют две шестнадцатеричные цифры представляет значение закодированного октета.

Кроме того, вам, вероятно, следует заменить все символы, которые семантически модифицируют фильтр (грамматика RFC 4515 дает список), и сделать Regex заменой не-ASCII символов на символы подстановки (*), чтобы убедиться. Это также поможет вам с такими символами, как «é».

0 голосов
/ 30 ноября 2011

У вас есть ~ и = поменялись местами выше.Это должно быть (cn ~ = Perez).Я до сих пор не знаю, насколько хорошо это будет работать.Soundex всегда был странным.Поскольку многие атрибуты являются многозначными, включая cn, вы можете сохранить второе значение в атрибуте, в котором расширенные символы преобразованы в их базовые версии.По крайней мере, у вас будет первоначальное значение, которое все равно будет отсутствовать, когда вам это нужно.Вы также можете получить реальную фантазию и добавить к преобразованному префиксу что-нибудь и использовать valuesReturnFilter, чтобы отфильтровать его от результатов. 

#Sample object
dn:cn=Pérez,ou=x,dc=y
cn:Pérez
cn:{stripped}Perez
sn:Pérez
#etc.

Затем измените запрос, используя выражение или. 

(|(cn=Pérez)(cn={stripped}Perez))

И вы бы включили в него значенияReturnFilter, которые выглядели бы как 

(!(cn={stripped}*))

См. RFC3876 http://www.networksorcery.com/enp/rfc/rfc3876.txt для получения подробной информации.Способ добавления элемента управления запросом зависит от того, какую платформу / библиотеку вы используете для доступа к каталогу.

...