Joseph L. Casale wrote: > 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)
Note that all modules in python-ldap up to 2.4.10 including module 'ldif' expect raw byte strings to be passed as arguments. It seems to me you're passing a Unicode object in the entry dictionary which will fail in case an attribute value contains NON-ASCII chars. python-ldap expects raw strings since it's not schema-aware and therefore does not have any knowledge about the LDAP syntax used for a particular attribute type. So automagically convert Unicode strings will likely fail in many cases. => The calling application has to deal with it. > I now have the exact the value I started with. Ensuring where I ever handle > the original > values that I return utf-8 decoded objects for use in a modlist to later > write and Sub > classing LDIFWriter and overriding _unparseAttrTypeandValue to do the > encoding has > eliminated all the errors. Don't muck with overriding _unparseAttrTypeandValue(). Simply pass the properly encoded data into ldif module. Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list