Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.002 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'attribute': 0.07; 'encoded': 0.07; 'parser': 0.07; 'problem?': 0.07; 'string': 0.09; 'interpreted': 0.09; 'parsed': 0.09; 'strings.': 0.09; 'subject:module': 0.09; 'python': 0.11; 'windows': 0.15; '"is': 0.16; '2.7.3': 0.16; 'attr': 0.16; 'base64': 0.16; 'dict': 0.16; 'encoding.': 0.16; 'guessing': 0.16; 'ldif': 0.16; 'michael,': 0.16; 're-read': 0.16; 'received:172.18.0': 0.16; 'right:': 0.16; 'skip:[ 30': 0.16; 'written': 0.21; '>>>': 0.22; 'code,': 0.22; 'to:name:python-list@python.org': 0.22; 'byte': 0.24; 'entries': 0.24; 'unicode': 0.24; 'server.': 0.24; 'looks': 0.24; 'source': 0.25; 'url:edu': 0.26; 'asking': 0.27; 'values': 0.27; 'header:In- Reply-To:1': 0.27; 'to:2**1': 0.27; 'character': 0.29; 'characters': 0.30; 'said,': 0.30; 'to?': 0.30; 'especially': 0.30; "i'm": 0.30; 'reply.': 0.31; "skip:' 10": 0.31; 'breaking': 0.31; 'context.': 0.31; 'gather': 0.31; 'globally': 0.31; 'grazie': 0.31; 'file': 0.32; 'another': 0.32; 'text': 0.33; 'problem': 0.35; 'usual': 0.35; 'add': 0.35; 'there': 0.35; 'really': 0.36; 'entry': 0.36; 'method': 0.36; 'thanks': 0.36; 'url:org': 0.36; 'should': 0.36; 'example,': 0.37; 'half': 0.37; 'list': 0.37; 'being': 0.38; '2008': 0.38; 'ends': 0.38; 'requiring': 0.38; 'handle': 0.38; 'to:addr:python-list': 0.38; 'files': 0.38; 'does': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'skip:u 10': 0.60; 'read': 0.60; 'above,': 0.60; 'received:unknown': 0.61; 'break': 0.61; 'new': 0.61; "you're": 0.61; 'here:': 0.62; 'back': 0.62; 'such': 0.63; 'more': 0.64; 'holding': 0.65; 'to:charset:iso-8859-1': 0.74; 'dict.': 0.84 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=x4wvebh7U2otgv2g1Q/ELETKOrtBkVhBqv1eL6GwWag= c=1 sm=1 a=CRTDazI5n6YA:10 a=xv9iwkAQU-cA:10 a=7PYXob_7ZXMA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=xqWC_Br6kY4A:10 a=oNw28mxuUhXRB3mVwYQ4Ag==:17 a=48vgC7mUAAAA:8 a=f2PIqq2XAAAA:8 a=aX5gmnGHAQ_ny2BOiT4A:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 From: "Joseph L. Casale" To: =?iso-8859-1?Q?Michael_Str=F6der?= , "python-list@python.org" Subject: RE: Ldap module and base64 oncoding Thread-Topic: Ldap module and base64 oncoding Thread-Index: AQHOWiLA2gcVydFyA0eXB9j8yy7c/ZkXmxfJ Date: Sun, 26 May 2013 16:19:57 +0000 References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.0.200] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 71 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1369585225 news.xs4all.nl 15909 [2001:888:2000:d::a6]:33040 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:46082 > I'm not sure what exactly you're asking for.=0A= > Especially "is not being interpreted as a string requiring base64 encodin= g" is=0A= > written without giving the right context.=0A= > =0A= > So I'm just guessing that this might be the usual misunderstandings with = use=0A= > of base64 in LDIF. Read more about when LDIF requires base64-encoding her= e:=0A= > =0A= > http://tools.ietf.org/html/rfc2849=0A= > =0A= > To me everything looks right:=0A= > =0A= > Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2=0A= > Type "help", "copyright", "credits" or "license" for more information.=0A= > >>> 'ZGV0XDMzMTB3YmJccGc=3D'.decode('base64').decode('utf-8')=0A= > u'det\\3310wbb\\pg'=0A= > >>>=0A= > =0A= > What do you think is a problem?=0A= =0A= Michael,=0A= Thanks for the reply. The issues I am sure are in my code, I read the ldif = source file and up=0A= with a values such as 'det\3310wbb\pg' after the base64 encoded entries are= decoded.=0A= =0A= The problem I am having is when I add this to an add/mod entry list and wri= te it back out.=0A= As it does not get re-encoded to base64 the ldif file ends up seeing a text= entry with a ^]=0A= character which if I re-read it with the parser it causes the handle method= to break midway=0A= through the entry dict and so the last half re-appears disjoint without a d= n.=0A= =0A= Like I said, I am pretty sure its my poor misunderstanding of decoding and = encoding.=0A= I am using the build from http://www.lfd.uci.edu/~gohlke/pythonlibs/ on a w= indows=0A= 2008 r2 server.=0A= =0A= I have re-implemented handle to create a cidict holding all the dn/entry's = that are parsed as=0A= I then perform some processing such as manipulating attribute values in the= entry dict. I=0A= am pretty sure I am breaking things here. The data I am reading is coming f= rom utf-16-le=0A= encoded files and has Unicode characters as the source directory is globall= y available, being=0A= written to in just about every country.=0A= =0A= Is there a process for manipulating/adding data to the entry dict before I = write it out that I=0A= should adhere to? For example, if I am adding a new attribute to be compose= d of part of=0A= another parsed attr for use in a modlist:=0A= =0A= {'customAttr': ['foo.{}.bar'.format(entry['uid'])]}=0A= =0A= By looking at the value from above, 'det\3310wbb\pg', I gather the entry di= ct was parsed=0A= into byte strings. I should have decoded this, where as some of the data is= Unicode and=0A= as such I should have encoded it?=0A= =0A= I really appreciate the time.=0A= =0A= Grazie per tutto,=0A= jlc=