I have experienced the same results when using straight .ldif files to load some of the directory servers, but I've not made a definitive study to see why. The values reload and match properly from what I've experienced, so we never bothered about it further. It seemed that the single leading space in a value was enough to convince the directory server that the value was binary 'blobish' and to handle it as such for all compares,exports, and imports. We've made attempts to clean up some perl code (not net::ldap) that had similar problems, so I don't think this is related to net::ldap. Has anyone seen any RFC info on leading spaces?... It would be good to know without digging through them if there is something about it ...
Doug.
Neo - wrote:
This is follow-up of my pervious question ...when i try to add values
say
CN=" test"; (Having a white space character in front)
or name =" "; (null value)
i expected the values as cn= test;
but when i read the cn attribute in directroy server its giving me in
non readable format like VGVzdCwgT3RoZXIgVGVsICA=
Any body came across this issue.
Any advise will greatly help me.
Thanks in advance .
Graham Barr <[EMAIL PROTECTED]> wrote: ----- Forwarded message from Neo - -----
Date: Thu, 29 May 2003 08:41:09 -0700 (PDT)
To: [EMAIL PROTECTED]
From: Neo - Subject: Writing in nonascii (binary) format
Hi grahm,
I am new bee to net ldap your documentation really helped me to get through all my needs . also now i got into a problem while adding or modifying the data some of the attributes are added in non ascii format .. i checked the data which i supposed to write its in ascii format but when i checked in directory server its in non ascii format (binary) but the attribute is not defined as binary...I would really appreciate any help.
Regards, Neo
--------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM). ----- End forwarded message -----
--------------------------------- Do you Yahoo!? Free online calendar with sync to Outlook(TM).
