El interface DirContext proporciona los siguientes m�todos de b�squeda:
- search(Name name, Attributes matchingAttrs)
- search(Name name, Attributes matchingAttrs, String[] retAttrs)
- search(Name name, String filter, SearchControls ctls)
- search(Name name, String filterExpr, Object[] filterArgs, SearchControls ctls)
Cada uno de estos m�todos tiene una versi�n sobrecargada que acepta un nombre java.lang.String en vez de un Name como primer argumento.
�Usar Correspondencia de Atributos
La primera forma, search(Name name, Attributes matchingAttrs), es equivalente a la segunda forma, search(Name name, Attributes matchingAttrs, String[] retAttrs), con null suministrado como el argumento retAttrs.
search(name, matchingAttrs, null);
El ejemplo b�squeda b�sica muestra c�mo usar estos dos m�todos.
En estos m�todos, el argumento matchingAttrs es convertido en un String de filtro seg�n la RFC 2254 que es una expresi�n conjuntiva de atributos de matchingAttrs. Por ejemplo, un matchingAttrs que contiene los siguientes atributos:
sn: Geisel mail: (No value)
se traduce en el String de filtro "(&(sn=Geisel)(mail=*))".
Cada valor de atributo se trata literalmente--es decir, se espera que el atributo en la entrada del directorio contenga exactamente ese valor. Por lo tanto, si el valor del atributo contiene un asterisco ("*") u otros caracteres especiales definidos en la RFC 2254, el proveedor LDAP aplicar� las reglas de codificaci�n apropiadas. Por ejemplo, un matchingAttrs que contenga los siguientes atributos:
sn: Geisel mail: *
se traduce en el String de filtro "(&(sn=Geisel)(mail=\2a))". En este caso, la entrada del directorio debe contener un atributo "mail" cuyo valor es el string "*".
Si el valor del atributo es un array de byte, se codifica usando la notaci�n de atributos no-string, como se describe en la RFC 2254. Por ejemplo, un matchingAttrs que contenga los siguientes atributos:
jpegphoto: 82 12 38 4e 23 e3 (byte array)
se traduce en el String de filtro "(jpegphoto=\82\12\38\4e\23\e3)".
�Usar un String de Filtro
La secci�n Filtros de B�squeda tiene una r�pida introducci�n a la s�ntaxis de los filtros de b�squeda y contiene ejemplos de c�mo usar la tercera forma de los m�todos de b�squeda. search(Name name, String filter, SearchControls ctls). El String de filtro sigue la s�ntaxis especificada en la RFC 2254, excepto en que tambi�n se permiten caracteres Unicode. Es preferible usar caracteres Unicode que octetos UTF-8 codificados.
Por ejemplo, en el lenguaje Java, podemos especificar la letra griega alfa como el caracter Unicode \u03b1. Para buscar una entrada cuyo valor de atributo contenga este caracter, podemos usar el string "\u03b1" o "\ce\b1" (con los escapes apropiados para las barras invertidas ("\") si estamos usando el caracter como un string literal del lenguaje Java). La forma Unicode es la preferida. El proveedor de servicio LDAP traducir� los caracteres Unicode en sus correspondientes representaciones UTF-8 para su transmisi�n al servidor.
�Usar String de Filtro con Argumentos
La cuarta forma del m�todo de b�squeda, search(Name name, String filterExpr, Object[] filterArgs, SearchControls ctls), nos permite construir el String de filtro usando una expresi�n de filtro filterExpr y un array de argumentos filterArgs.
El argumento filterExpr puede contener strings de la forma "{n}", donde el en�simo elemento de filterArgs reemplaza la ocurrencia del string "{n}" en filterExpr en el string de filtro resultante. Cada string "{n}" podr�a aparecer como un nombre de atributo, un valor de atributo, o un componente del valor de atributo. (O m�s precisamente, cada string "{n}" podr�a aparecer en lugar de "attr" o de "value" en la secci�n 4 de RFC 2254.)
Durante la sustituci�n, los objetos de filterArgs se codifican de la siguiente forma:
- Cada byte del array de byte (byte[]) se codifica como string, de acuerdo a la RFC 2254. Por ejemplo, el array {0, 1, 10, 100} se codificar� como el string "\00\01\0a\64".
- Los Strings son tratados como literales; los "*" y otros caracteres especiales definidos en la RFC 2254 que aparezcan en el string ser�n codificados de acuerdo a las reglas de la RFC 2254. Por ejemplo, un string de "*" se codifica como el string "\2a". Por lo tanto, para usar caracteres especiales en el filtro, debemos ponerlos en una expresi�n de filtro filterExpr.
- Los objetos que no son ni un String ni un byte[] se convierten a su forma string mediante Object.toString() y luego se aplican las reglas para String.
Aqu� tenemos un ejemplo que demuestra el uso de este m�todo:
// Specify the filter arguments
byte[] key = {(byte)0x61, (byte)0x62, (byte)0x63, (byte)0x64,
(byte)0x65, (byte)0x66, (byte)0x67};
String name = "User";
// Perform the search
NamingEnumeration answer = ctx.search("ou=NewHires",
"(&(mySpecialKey={0}) (cn=*{1}))", // Filter expression
new Object[]{key, name}, // Filter arguments
null); // Default search controls
La expresi�n de filtro especifica dos sustituciones. Los contenidos del array de byte key reemplazan a "{0}" y name reemplaza a "{1}". Observa el uso del comod�n para la porci�n "cn" del filtro en la expresi�n de filtro. Al ejecutar este ejemplo tendremos la siguiente salida:
>>>cn=S. User
{myspecialkey=myspecialkey: abcdefg,
sn=sn: User,
objectclass=objectclass: top, person, organizationalPerson,
inetOrgPerson, extensibleObject,
mail=mail: [email protected],
userpassword=userpassword: [B@1dacd79e,
cn=cn: S. User
}