D.4. Searching an Internationalized Directory
D.4. Searching an Internationalized Directory When performing search operations, the Directory Server can sort the results based on any language for which the server has a supporting collation order. For a listing of the collation orders supported by the directory, see Section D.2, "Supported Locales" . Note An LDAPv3 search is required to perform internationalized searches. Therefore, do not set the LDAPv2 option on the call for ldapsearch . This section focuses using matching rule filters to return international attribute values. For more information on general ldapsearch syntax, see Section 14.3, "LDAP Search Filters" . Section D.4.1, "Matching Rule Formats" Section D.4.2, "Supported Search Types" Section D.4.3, "International Search Examples" D.4.1. Matching Rule Formats The matching rule filters for internationalized searches can be represented in any several ways, and which one should be used is a matter of preference: As the OID of the collation order for the locale on which to base the search. As the language tag associated with the collation order on which to base the search. As the OID of the collation order and a suffix that represents a relational operator. As the language tag associated with the collation order and a suffix that represents a relational operator. The syntax for each of these options is discussed in the following sections: Section D.4.1.1, "Using an OID for the Matching Rule" Section D.4.1.2, "Using a Language Tag for the Matching Rule" Section D.4.1.3, "Using an OID and Suffix for the Matching Rule" Section D.4.1.4, "Using a Language Tag and Suffix for the Matching Rule" D.4.1.1. Using an OID for the Matching Rule Each locale supported by the Directory Server has an associated collation order OID. For a list of OIDs supported by the Directory Server, see the /etc/dirsrv/config/slapd-collations.conf file. The collation order OID can be used in the matching rule portion of the matching rule filter as follows: The relational operator is included in the value portion of the string, separated from the value by a single space. For example, to search for all departmentNumber attributes that are at or after N4709 in the Swedish collation order, use the following filter: D.4.1.2. Using a Language Tag for the Matching Rule Each locale supported by the Directory Server has an associated language tag. For a list of language tags supported by the Directory Server, see the /etc/dirsrv/config/slapd-collations.conf file. The language tag can be used in the matching rule portion of the matching rule filter as follows: The relational operator is included in the value portion of the string, separated from the value by a single space. For example, to search the directory for all description attributes with a value of estudiante using the Spanish collation order, use the following filter: D.4.1.3. Using an OID and Suffix for the Matching Rule As an alternative to using a relational operator-value pair, append a suffix that represents a specific operator to the OID in the matching rule portion of the filter. Combine the OID and suffix as follows: Note This syntax is only supported by the mozldap utility and not by OpenLDAP utilities, such as ldapsearch . For example, to search for businessCategory attributes with the value softwareprodukte in the German collation order, use the following filter: The .3 in the example is the equality suffix. For a list of OIDs supported by the Directory Server, see the /etc/dirsrv/config/slapd-collations.conf file. For a list of relational operators and their equivalent suffixes, see Table D.2, "Search Types, Operators, and Suffixes" . D.4.1.4. Using a Language Tag and Suffix for the Matching Rule As an alternative to using a relational operator-value pair, append a suffix that represents a specific operator to the language tag in the matching rule portion of the filter. Combine the language tag and suffix as follows: Note This syntax is only supported by the mozldap utility and not by OpenLDAP utilities, such as ldapsearch . For example, to search for all surnames that come at or after La Salle in the French collation order, use the following filter: For a list of language tags supported by the Directory Server, see the /etc/dirsrv/config/slapd-collations.conf file. For a list of relational operators and their equivalent suffixes, see Table D.2, "Search Types, Operators, and Suffixes" . D.4.2. Supported Search Types The Directory Server supports the following types of international searches: equality (=) substring (*) greater-than (>) greater-than or equal-to (>=) less-than (<) less-than or equal-to (<=) Approximate, or phonetic, and presence searches are supported only in English. As with a regular ldapsearch search operation, an international search uses operators to define the type of search. However, when invoking an international search, either use the standard operators (=, >=, >, <, <=) in the value portion of the search string, or use a special type of operator, called a suffix (not to be confused with the directory suffix), in the matching rule portion of the filter. Table D.2, "Search Types, Operators, and Suffixes" summarizes each type of search, the operator, and the equivalent suffix. Table D.2. Search Types, Operators, and Suffixes Search Type Operator Suffix Less-than < .1 Less-than or equal-to <= .2 Equality = .3 Greater-than or equal-to >= .4 Greater-than > .5 Substring * .6 D.4.3. International Search Examples The following sections show examples of how to perform international searches on directory data. Each example gives all the possible matching rule filter formats so that you can become familiar with the formats and select the one that works best. D.4.3.1. Less-Than Example Performing a locale-specific search using the less-than operator (<), or suffix ( .1 ) searches for all attribute values that come before the given attribute in a specific collation order. For example, to search for all surnames that come before the surname Marquez in the Spanish collation order, any of the following matching rule filters would work: D.4.3.2. Less-Than or Equal-to Example Performing a locale-specific search using the less-than or equal-to operator (<=), or suffix ( .2 ) searches for all attribute values that come at or before the given attribute in a specific collation order. For example, to search for all room numbers that come at or before room number CZ422 in the Hungarian collation order, any of the following matching rule filters would work: D.4.3.3. Equality Example Performing a locale-specific search using the equal to operator (=), or suffix ( .3 ) searches for all attribute values that match the given attribute in a specific collation order. For example, to search for all businessCategory attributes with the value softwareprodukte in the German collation order, any of the following matching rule filters would work: D.4.3.4. Greater-Than or Equal-to Example Performing a locale-specific search using the greater-than or equal-to operator ( >= ), or suffix ( .4 ) searches for all attribute values that come at or after the given attribute in a specific collation order. For example, to search for all localities that come at or after Quebec in the French collation order, any of the following matching rule filters would work: D.4.3.5. Greater-Than Example Performing a locale-specific search using the greater-than operator (>), or suffix ( .5 ) searches for all attribute values that come at or before the given attribute in a specific collation order. For example, to search for all mail hosts that come after host schranka4 in the Czech collation order, any of the following matching rule filters would work: D.4.3.6. Substring Example Performing an international substring search searches for all values that match the given pattern in the specified collation order. For example, to search for all user IDs that end in ming in the Chinese collation order, any of the following matching rule filters would work: Substring search filters that use DN-valued attributes, such as modifiersName or memberOf , do not always match entries correctly if the filter contains one or more space characters. To work around this problem, use the entire DN in the filter instead of a substring, or ensure that the DN substring in the filter begins at an RDN boundary; that is, make sure it starts with the type = part of the DN. For example, this filter should not be used: But either one of these will work correctly:
attr:OID :=( relational_operator value ) departmentNumber:2.16.840.1.113730.3.3.2.46.1:=>= N4709 attr:language-tag :=( relational_operator value ) cn:es:== estudiante attr: OID+suffix := value businessCategory:2.16.840.1.113730.3.3.2.7.1.3:=softwareprodukte attr: language-tag+suffix := value sn:fr.4:=La Salle sn:2.16.840.1.113730.3.3.2.15.1:=< Marquez sn:es:=< Marquez sn:2.16.840.1.113730.3.3.2.15.1.1:=Marquez sn:es.1:=Marquez roomNumber:2.16.840.1.113730.3.3.2.23.1:=<= CZ422 roomNumber:hu:=<= CZ422 roomNumber:2.16.840.1.113730.3.3.2.23.1.2:=CZ422 roomNumber:hu.2:=CZ422 businessCategory:2.16.840.1.113730.3.3.2.7.1:==softwareprodukte businessCategory:de:== softwareprodukte businessCategory:2.16.840.1.113730.3.3.2.7.1.3:=softwareprodukte businessCategory:de.3:=softwareprodukte locality:2.16.840.1.113730.3.3.2.18.1:=>= Quebec locality:fr:=>= Quebec locality:2.16.840.1.113730.3.3.2.18.1.4:=Quebec locality:fr.4:=Quebec mailHost:2.16.840.1.113730.3.3.2.5.1:=> schranka4 mailHost:cs:=> schranka4 mailHost:2.16.840.1.113730.3.3.2.5.1.5:=schranka4 mailHost:cs.5:=schranka4 uid:2.16.840.1.113730.3.3.2.49.1:=* *ming uid:zh:=* *ming uid:2.16.840.1.113730.3.3.2.49.1.6:=* *ming .. uid:zh.6:=* *ming (memberOf=*Domain Administrators*) (memberOf=cn=Domain Administrators*) (memberOf=cn=Domain Administrators,ou=Groups,dc=example,dc=com)