Re: Special character

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 04:25 AM 12/24/2004, Tony Earnshaw wrote:
>Howard Chu:
>
>[...]
>
>>>> convert your ldif file to UTF-8,iconv(1) might be of help.
>>>>
>>> Actually, simply base-64 encoding the relevant attribute fields will do it.
>>>
>> Not with anything newer than OpenLDAP 2.0. Dieter's reply is correct.
>
>Openldap 2.2.18:
>
>Evidence:

>Conclusion: I do not have to use utf-8 to encode my ldifs with "funny
>letters", I do have to base-64 encode attribute fields with these fls.

Your conclusion is flawed.  In your "evidence", the attribute value
itself is UTF-8 encoded.  Base64 encoding this value for inclusion
in the LDIF file is unnecessary but harmless.  The UTF-8 value
could have been used directly in the LDIF, as the format of the
LDIF file itself is UTF-8.

However, if say the application has a UTF-16 (or other incompatible
encoding or character set) encoding of "foo" for a common name (CN),
simply base64 encoding the UTF-16 encoding, e.g.:
  CN:: AGYAbwBv

would make for valid LDIF representation of an invalid value for
the CN attribute.  That is, the LDIF parser would be happy, but
the server (or other verifying program) would error.  The
application needs to present the value of CN in UTF-8 to LDAP.
When representing that UTF-8 encoded value in LDIF, the UTF-8
value may be (unnecessarily) base64 encoded.

But the LDIF file itself must always be UTF-8 encoded.  If
you, for instance, convert the file to UTF-32 and feed it to
ldapmodify(1), ldapmodify(1) should fail to parse the file.

>Whether Openldap utf-8 encodes them is another matter.

OpenLDAP Software requires that LDIF be properly formed (e.g.,
UTF-8) **AND** values transferred be properly formed (e.g.,
UTF-8 for (most) character string).

Kurt