Notas sobre codificación de caracteres
El problema más importante con el acceso via LDAP a X.500 es que la versión
2 de LDAP no indica la codificacion de los valores de atributos que sean
tipo texto. Por tanto los servidores que hacían de pasarela con X.500, como
ldapd enviaban al cliente las cadenas con caracteres especiales de
la misma forma que estaban en el directorio, es decir, en T.61. Por tanto
las librerías LDAP que circulan por ahí están preparadas para recibir T.61.
En la versión 3 de LDAP, se especifica que la codificación de estas cadenas
debe ser UTF-8. El servidor LDAP que incluye ISODE ICR5 es compatible con
la versión 3, pero da problemas.
El servidor ISODE ICR5, al estar basado en X.500 (93) soporta tres
codificaciones de caracteres especiales:
- T.61, como hasta ahora.
- Unicode con 2 bytes por carácter (UCS-2): BMPString
- Unicode con 4 bytes por carácter (UCS-4): UniversalString
Lo lógico (pienso yo) sería que cuando recibe una conexión de un cliente
LDAP v3 convirtiera los valores de atributos que tenga internamente
codificados de alguna de esas tres formas a UTF-8, pero las pruebas que
he hecho parecen indicar que no es así. Los valores que tiene almacenados
como UCS-2 sí los envía en UTF-8, pero los que tiene en T.61 los envía
en T.61, lo cual hace que los clientes V3, que esperan UTF-8, no los
vean bien.
Hay por tanto dos opciones:
- Dejar los datos en T.61. De esta forma lo clientes V2 compilados con
traducción T.61<->Latin1 (STR_TRANSLATION) lo verán todo bien.
Esto incluye la pasarela web500gw, pine, exmh, etc.
Los clientes LDAP v3 no verán bien los acentos y caracteres especiales.
- Meter los datos en UCS-2. Así los clientes LDAP v3 lo verán todo
bien, pero a los clientes v2 les salen cadenas del tipo
{UCS-2}F\E1tima (en caso del nombre Fátima).
Hay que tener en cuenta que hasta que se imponga la version 3 de LDAP,
la gente usa clientes de ambas versiones:
- Los productos de Netscape y Microsoft usan ambos LDAP v3.
- Muchos programas de UNIX se compilan con librerías v2. En nuestro caso
lo más importante es la pasarela web500gw, que consulta mucha
gente.
Una solución que propongo es meter los datos en el directorio en UCS-2.
De esta forma los clientes v3 irán bien.
Para los clientes v2, modificar la librería LDAP de forma que cuando
reciba una cadena que comienze por {UCS-2} la pase a Latin1.
Esto no afecta a las cadenas que estén en T.61, que el parche no
tocaría; la propia librería se encarga de pasarlas a Latin1 (si se compila
con STR_TRANSLATION).
Habría que relinkar las aplicaciones UNIX que usen esa librería,
y hay que tener en cuenta que los clientes v2 de PC no verán los
acentos. Otro problema es que la gente que consulte nuestro directorio
desde sus pasarelas web500gw no verán tampoco bién los acentos.
En cualquier caso, ya he modificado la librería LDAP de la distribución
OpenLDAP tal como he dicho. He
linkado el web500gw y pine y así veo bien en ambos tanto las cadenas metidas
con T.61 como las metidas en UCS-2. Me gustaría que se discutiera esta
posibilidad, así como otras alternativas.
x500@uco.es - Luis Meléndez, Servicio de Informática, Universidad de Córdoba.
Noviembre, 1999