Joseph L. Casale wrote:
I had some time today, so I attempted to open the ldif files in binary mode
to simply
work with the raw byte strings but the moment the first entry was parsed,
parse()
stumbled on a character in the first entries dict and passed a dn of None for
the last half?
Joseph L. Casale jcas...@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
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
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.
Yup, I was.
python-ldap
Joseph L. Casale wrote:
I have some data I am working with that is not being interpreted as a string
requiring
base64 encoding when sent to the ldif module for output.
The base64 string parsed is ZGV0XDMzMTB3YmJccGc= and the raw string is
det\3310wbb\pg.
I'll admit my understanding of
Joseph L. Casale wrote:
Can you give an example of the code you have?
I actually just overrode the regex used by the method in the LDIFWriter class
to be far more broad
about what it interprets as a safe string.
Are you sure that you fully understood RFC 2849 before doing this?
Which
I'm not sure what exactly you're asking for.
Especially is not being interpreted as a string requiring base64 encoding is
written without giving the right context.
So I'm just guessing that this might be the usual misunderstandings with use
of base64 in LDIF. Read more about when LDIF
Joseph L. Casale wrote:
I'm not sure what exactly you're asking for.
Especially is not being interpreted as a string requiring base64 encoding
is
written without giving the right context.
So I'm just guessing that this might be the usual misunderstandings with use
of base64 in LDIF. Read
Hi Michael,
Processing LDIF is one thing, doing LDAP operations another.
LDIF itself is meant to be ASCII-clean. But each attribute value can carry any
byte sequence (e.g. attribute 'jpegPhoto'). There's no further processing by
module LDIF - it simply returns byte sequences.
The access
Can you give an example of the code you have?
I actually just overrode the regex used by the method in the LDIFWriter class
to be far more broad
about what it interprets as a safe string. I really need to properly handle
reading, manipulating and
writing non ascii data to solve this...
Shame
I have some data I am working with that is not being interpreted as a string
requiring
base64 encoding when sent to the ldif module for output.
The base64 string parsed is ZGV0XDMzMTB3YmJccGc= and the raw string is
det\3310wbb\pg.
I'll admit my understanding of the handling requirements of non
Can you give an example of the code you have?
From: jcas...@activenetwerx.com
To: python-list@python.org
Subject: Ldap module and base64 oncoding
Date: Fri, 24 May 2013 21:00:01 +
I have some data I am working with that is not being interpreted
12 matches
Mail list logo
