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