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
