Ldap module and base64 oncoding

[dieter]

"Joseph L. Casale" <jcasale at activenetwerx.com> writes:
> ...
> After parsing the data for a user I am simply taking a value from the ldif file and writing
> it back out to another which fails, the value parsed is:
>
> officestreetaddress:: T3R0by1NZcOfbWVyLVN0cmHDn2UgMQ==
>
>
>   File "C:\Python27\lib\site-packages\ldif.py", line 202, in unparse
>     self._unparseChangeRecord(record)
>   File "C:\Python27\lib\site-packages\ldif.py", line 181, in _unparseChangeRecord
>     self._unparseAttrTypeandValue(mod_type,mod_val)
>   File "C:\Python27\lib\site-packages\ldif.py", line 142, in _unparseAttrTypeandValue
>     self._unfoldLDIFLine(':: '.join([attr_type,base64.encodestring(attr_value).replace('\n','')]))
>   File "C:\Python27\lib\base64.py", line 315, in encodestring
>     pieces.append(binascii.b2a_base64(chunk))
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xdf' in position 7: ordinal not in range(128)
>
>> c:\python27\lib\base64.py(315)encodestring()
> -> pieces.append(binascii.b2a_base64(chunk))

This looks like a coding bug: "chunk" seems to be a unicode string;
"b2a_base64" expects an encoded string ("str/bytes"); as
a consequence, Python tries to convert the unicode to "str" by
encoding with its "default enconding" ("ascii" by default) - and
fails.

You could try to find out, why "chunk" is unicode (rather than "str").
That will probably bring you to the real problem.