Re: Problems with function ldap.explode_dn()

[<mi...@st...>]

OHU...@sp... wrote:
>=20
>>>>dn=3D"uid=3Dascii,l=3DM=FCnchen_iso-8859-1"
>>>>ldap.explode_dn(dn)
>=20
> ['uid=3Dascii']

Hmm, this looks wrong. Using ISO-8859-1 is wrong with LDAPv3 anyway.

>>>>ldap.explode_dn(dn.decode('latin'))
> [..]
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in pos=
ition 13: ordinal not in range(128)

Off course you can't encode the raw string. dn is supposed to be an Unico=
de=20
object.

>>>>ldap.explode_dn(dn.decode('latin').encode('utf'))
>=20
> ['uid=3Dascii', 'l=3DM\\C3\\BCnchen_iso-8859-1']

Now this shows that the underlying OpenLDAP function ldap_explode_dn() is=
=20
aware of DN strings having to be UTF-8 encoded Unicode.

Note that you SHOULD use 'utf-8' as unique ID for UTF-8.

>>>>vgl=3Dldap.explode_dn(dn.decode('latin').encode('utf'))[1]
>>>>vgl
>=20
> 'l=3DM\\C3\\BCnchen_iso-8859-1'
>=20
>>>>vgl=3D=3D"l=3DM=FCnchen_iso-8859-1".decode('latin').encode('utf8')
>=20
> False

The DN string normalization (with back slash representation) is done with=
in=20
the OpenLDAP libs. The behaviour changed from OpenLDAP 2.0 to 2.1. I alre=
ady=20
had a discussion with Kurt Z. about that. His argument was that LDAP=20
applications should treat DNs as being opaque. There's nothing we can do =

about it. This breaks things when accessing OpenLDAP 2.0 server since 2.0=
=20
did not implement correct matching rules for DNs. Oh yeah...

> Beeing very RFC-strict I would have to use utf-8 encoding. But the resu=
lt
> also should be utf-8 encoded, which isn't the case. Any ideas?

Input and output of ldap_explode_dn() both have to be a valid DN string=20
representation as of RFC2253 which is the case. Guess you have to live wi=
th=20
that.

Ciao, Michael.