Hi!
I'd say: Get the proper app (eg. BabelPad on Windows, see attachment) and then BASE64-encode the string.
Regards, Ulrich
Thanks, but windows is not an option. Again, base64 encoding is fine with echo -en "" | base64. With a browser I can search for the symbol and do copy paste into the ldif. All that works fine, even if my console font does not even support that symbol. I've done it. But feels a bit hackish.
I just hoped, there was an option, to tell the server, when the ldif has this sequence, interpret it as an ecoding, not as a literal string. Now I know, this does only work for the dn (and maybe only openldap, will test, see other post), and for the rest I do have a work around.
Ede Wolf wrote:
Hi!
I'd say: Get the proper app (eg. BabelPad on Windows, see attachment) and then BASE64-encode the string.
Regards, Ulrich
Thanks, but windows is not an option. Again, base64 encoding is fine with echo -en "" | base64. With a browser I can search for the symbol and do copy paste into the ldif. All that works fine, even if my console font does not even support that symbol. I've done it. But feels a bit hackish.
I just hoped, there was an option, to tell the server, when the ldif has this sequence, interpret it as an ecoding, not as a literal string. Now I know, this does only work for the dn (and maybe only openldap, will test, see other post), and for the rest I do have a work around.
The server doesn't do any reprocessing on the received strings. The escaping was done by the client (or libldap) when parsing your input. The server only processes UTF-8. You can see this in the slapd logs associated with the example ops I sent before:
63f4fd23.22d06a0c 0x7f1ceadfe640 conn=1004 op=1 do_add 63f4fd23.22d07cdf 0x7f1ceadfe640 ber_scanf fmt ({m) ber: 63f4fd23.22d08b9b 0x7f1ceadfe640 conn=1004 op=1 do_add: dn (cn=😀 face,ou=people,dc=example,dc=com)
The escaping is purely a client-side concern.
Howard Chu wrote:
Ede Wolf wrote:
Hi!
I'd say: Get the proper app (eg. BabelPad on Windows, see attachment) and then BASE64-encode the string.
Regards, Ulrich
Thanks, but windows is not an option. Again, base64 encoding is fine with echo -en "" | base64. With a browser I can search for the symbol and do copy paste into the ldif. All that works fine, even if my console font does not even support that symbol. I've done it. But feels a bit hackish.
I just hoped, there was an option, to tell the server, when the ldif has this sequence, interpret it as an ecoding, not as a literal string. Now I know, this does only work for the dn (and maybe only openldap, will test, see other post), and for the rest I do have a work around.
The server doesn't do any reprocessing on the received strings
Never mind this message.
Am 22.02.23 um 11:28 schrieb Howard Chu:
The server doesn't do any reprocessing on the received strings. The escaping was done by the client (or libldap) when parsing your input. The server only processes UTF-8. You can see this in the slapd logs associated with the example ops I sent before:
...
The escaping is purely a client-side concern.
Got it. After all your help I have still been riding the wrong horse. Until now.
So it turns out, we are just somewhat lucky, that ApacheDS and ldapadd behave the same way in this regard. For importing ldif as well as for searching.
Then we'll have to wait and see, how the ibmldap tools will behave :)
Thanks again for the heads up
Ede
openldap-technical@openldap.org