Le 5 avr. 2005, à 21:59, Peter Marschall a écrit :
It is not said that Net::LDAP::LDIF is the part with the problems. It might as well be MIIS.
That's entirely possible. although the odd behaviour is that when I do a full import of the complete data file created from raw text files without any encoding of attribute values, it doesn't complain. When I take that file and do a ldifdiff against an older file, the generated LDIF file using the Net::LDAP::LDIF library coughs up an entry like the following :
dn: cn=Jose|NUNEZ ALVAREZ|11/05/1959|J0215077|0215077|0019416||Mr||/loc/kittot
al/947336.jpg, ou=BCHPARISPERSONS_PERS, o=metatemp
changetype: add
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: tfePerson
c: FRA
employeenumber: J0215077
employeetype: S
facsimiletelephonenumber: +33 01 41 35 40 13
givenname: Jose
givennameetatcivil: Jose
iggnumber: 0215077
ou: RM/SG/SI/MKT/CBT
roomnumber: 0215
site: Paris La Defense - Michelet B/C
sn: NUNEZ ALVAREZ
snetatcivil: NUNEZ ALVAREZ
src_faxposte_bch: 4013
src_givenname:: Sk9TyQ==
src_givennameetatcivil:: Sk9TyQ==
src_iggnumber: J0215077
src_roomnumber_bch: DEFBC 0215
src_site_bch: DEFBC 0215
src_telposte_bch: 9509
src_telprefixfr_bch: 014135
src_tfebirthdate_yyyymmdd: 19591105
src_title_fre: MR
telephonenumber: +33 01 41 35 95 09
telprefixfr: +33 01 41 35
tfebirthdate: 11/05/1959
tfebranchpki: RM
tfeinternalphonenumber: 9509
tfemapsearchorg: AVAL
tfephotopath: /loc/kittotal/947336.jpg
title: Mr
uid: 0019416
I'm trying to get a copy of the original unencoded object that was used to generate this one, but I do know that the original value was resolved as [éÉ] since it mapped the name correctly to Jose.
RFC 2849 (http://www.ietf.org/rfc/rfc2849.txt) states:
4) Any dn or rdn that contains characters other than those defined as "SAFE-UTF8-CHAR", or begins with a character other than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded.
The interesting parts are the senctences containing MAY.
In my interpretation this says that an LDAP server must understand
Base64 encoded values even if it is not necessary for these values to be
encoded.
Ditto - although what's curious is that it's not a global issue - there are many other entries that work just fine with the encoded attribute values. My issues are generally not around the DN though, since I normalise the data before creating the DNs.
On the other hand, not encoding vlaues that need to be encoded is against
the RFC.
True, although the context appears to be limited to the DN and not attribute values. If the importing application is on the same codepage as the source data, then it should be OK to pass in any raw value within the codepage, DN excepted.
Currently Net::LDAP::LDIF encodes Base64 if the output value matches
/(^[ :<]|[\x00-\x1f\x7f-\xff])/ which encodes a few values more than
absolutely necessary, but prevents control characters from being written
to the file.
Can you find a minimal test case so that we can find out where exactly the
problem is ?
Example above.
Cheers,
Erik
