Post by Franzw Post by email@example.com Post by Franzw
TDI continues to amaze me ;-)
Is this documented somewhere - I have taken a look in the APIDOC and the formal documentation - but I cannot find this solution documented anywhere ?
I was reading https://docs.oracle.com/javase/jndi/tutorial/ldap/misc/attrs.html
The LDAP v3 allows options to be appended to an attribute name. Each option is preceded by a semicolon character (";"). Options are like attribute subclassing. That is, an attribute named without the option is treated as the superclass of an attribute named with an option. The only option defined by the protocol is binary ( indicated by using the string ";binary"), which means that the attribute's value should be transmitted in binary format (regardless of its actual syntax). This option is reserved for transmitting ASN.1 encoded data (such as certificates: "caCertificate;binary"). Servers that support attribute subclassing may support identification of the attribute without its binary option, but it is best always to include the binary option in the attribute name.
I certainly learned something new there :-) I had not thought of this being a JNDI feature...
That said - TDI uses its own wa-y of regarding attributes binary - I do not really believe that the problem is lying outside the different TDS versions and their content.
I would like to see examples of the attributes dumped from the TDSes via db2ldif of ldapsearch -L (the first is preferred). That should reveal what the TDS thinks it has stored...
Hi franz, running some test i manage to find that this is a problems caused by TDI, seems like at some point before write on the LDIF file after being read the attributes lose the correct encoding and regard i say to the parser that all the attributes must be writed on ISO-8859-1(Try using UTF-8 but as far as i now this data must be ISO-8859-1 when is parsed on a ldif) when the bulkload cmd read this information is not read correctly of at least the charset is not right.
To make my point, when i download this information using jXplorer on the current LDAP i see this type of characters: �, after y load this information on the new version they are load like this: ?.
Right now we are looking for some options for this, but if you have any idea of what could be the source of this problem let me know.