Hello, This is probably more a ldif than an OpenLDAP question, but still, maybe somebody knows the answer: Is there a way to put multibyte characters into an attribute value and let the server know, these are not to be treated literally, but are utf8 character encodings?

I've tried to dig into rfc3629 and 4517, but those were above my capabilities. It does of course work for the dn, it also works, if I provide base64 code to the attributes, but is there a way, to directly put them into a ldif an let the server know, these are character encodings? Also, rfc2849 only talks about not line breaking multi-byte characters.

In this silly, but easy, example, both cn: and description: are entered literally, while the dn words as intended: dn: cn=A \F0\9F\99\82 Test,dc=example,dc=com cn: A \F0\9F\99\82 Test objectClass: person sn: Test description: %xF0%x9F%x99%x82 Test This is about understanding, not about the intention, to really put a smily into a dn. I am aware, this a potential recipe for disaster. Also, I am aware, the OpenLDAP kindly adds a proper cn value anyway, but that does not help here. And still would leave the description open. Also, as mentioned before: echo -en "A \xF0\x9F\x99\x82 Test" | base64 is a viable workaround, but a cumbersome one. So maybe there is an easier way Thanks Ede

Am 20.02.23 um 18:06 schrieb Howard Chu: > Ede Wolf wrote: >> Hello, >> >> This is probably more a ldif than an OpenLDAP question, but still, maybe somebody knows the answer: Is there a way to put multibyte characters into an attribute >> value and let the server know, these are not to be treated literally, but are utf8 character encodings? > > Strings in LDAPv3 are all UTF-8, by definition. This is in RFC4511 section 4.1.2. ... > base64 encoding for LDIF values is mostly optional. As long as the string you're entering doesn't have > embedded NUL or CR/LF characters, you don't need to use base64. Thanks very much. Please, but how can I provide a non ascii character, that is not on my keyboard, for which I only have the code point or the hex values. Like I can do within the dn

> The same way you would enter Unicode in any other application. This > is not an LDAP- or LDIF-specific question. > > 1) use a terminal and locale that support UTF-8. > 2) use whatever tools your OS provides for entering Unicode > characters. Probably something named "Unicode character map" or > similar. Thanks again. But my question regards the values for attributes. Having a ldif file, for the dn I can enter: dn: cn=A \F0\9F\99\82 Test,dc=example,dc=com That would literally give me the utf8 smiley icon as part of my dn - provided my font feratures that, of course. So I can use the hex encoding representation to enter any UTF-8 character. I can even search for that icon, using that hex encoding as search base or part of the search filter. However, for a value, I cannot do this, and my question is, is there a way at all? This has nothing to do with my console. For a directorystring attribute (it value), is there any way of entering code points straight into my ldif - be it U+0000 or hex notation - and having the server interpret them, as it works for the dn? Not copy+paste from the command line, but, again, as encodigs where the ldap server knows, these are to be interpreted. As it does for the dn. Something like: cn: A \F0\9F\99\82 Test Just with a syntax that works. If that it possible at all.

Hello Ondřej, Thanks very much! That is exactly the anwer I have been looking for - even more so in fact, as additionally I have been educated, that the dn is a different part from the rest of the ldif. Makes sense, but I've never really thought of this before.

>> Ede Wolf <listac(a)nebelschwaden.de&gt; schrieb am 21.02.2023 um 16:10 in Nachricht

> The same way you would enter Unicode in any other application. This is not an LDAP- or LDIF-specific question. > > 1) use a terminal and locale that support UTF-8. > 2) use whatever tools your OS provides for entering Unicode characters. Probably something named "Unicode character map" or similar. > Thanks again. But my question regards the values for attributes. Having a ldif file, for the dn I can enter: dn: cn=A \F0\9F\99\82 Test,dc=example,dc=com

That would literally give me the utf8 smiley icon as part of my dn - provided my font feratures that, of course. So I can use the hex encoding representation to enter any UTF-8 character. I can even search for that icon, using that hex encoding as search base or part of the search filter. However, for a value, I cannot do this, and my question is, is there a way at all? This has nothing to do with my console. For a directorystring attribute (it value), is there any way of entering code points straight into my ldif - be it U+0000 or hex notation - and having the server interpret them, as it works for the dn? Not copy+paste from the command line, but, again, as encodigs where the ldap server knows, these are to be interpreted. As it does for the dn. Something like: cn: A \F0\9F\99\82 Test Just with a syntax that works. If that it possible at all. Thanks Ede

>> Ede Wolf <listac(a)nebelschwaden.de&gt; schrieb am 22.02.2023 um 11:03 in Nachricht

> It seems the backslash notation is not actually defined for LDIF. That indeed is a valuable hint, out of curiosity I will test, wether other ldap server implementations will also accept at least the \FF notation for the dn, but that is off topic here. > RFC 2849 (LDAP Data Interchange Format) says: > > SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR] > > SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F > SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B / %x3D-7F I have come across this way of writing in a couple of rfc, also one about unicode, but the %xFF notation (with or without the x) never worked for me. Not even within the dn.

dn: cn=A %xF0%x9F%x99%x82 Test,dc=example,dc=com Does not work as intended, unless I've made another mistake. But as said before, I am a bit overwhelmed with understanding these rfc. Or rather translate them into practical action. So far I had only luck with the \FF notation, and only for the dn, which is correct, as I know now. But, as mentioned above, I will also test against SDS and 389DS, to figure, wether those will also accept the backslash notation as well. Just to see, if this is kind of a defacto standard, even if not hardcoded into a rfc.