[Date Prev][Date Next]
Re: Defining STR_TRANSLATION (ITS#600)
Please note that STR_TRANSLATION routines are experimental
and will not be supported in future releases as proper
translation such requires knowledge of schema which the BER
library doesn't have.
At 06:15 PM 6/20/00 GMT, firstname.lastname@example.org wrote:
>> I know I have to compile the ldap and lber libraries with an extra switch
>> but I cannot figure out where to insert it?
>> Any guidance would be appreciated.
>You have to define STR_TRANSLATION to anything and define LDAP_CHARSET_8859
>to 88591 or something similar. Or define LDAP_DEFAULT_CHARSET (but I think
>However, you cannot do it from configure, your have to do it by hand.
>Anyway, consider STR_TRANSLATION as a deprecated feature is is being
>removed from the next OpenLDAP version.
>The concept is broken, charset translation cannot be done at that level.
>Some attribute types contain blob values that must not be messed with.
>Using ldap_get_values_len to detect that is fragile (you can use that
>API function to get string values, IIRC some Perl modules use it
>Charset translation can only be done by looking at the schema and then
>doing translation for only those values where it makes sense. So
>either the library has schema knowledge or the application gets
>it, either wired in or found at runtime. The library does not have
>schema knowledge, so that leaves it to the application...
>Besides, STR_TRANSLATION assumes that you have your data in T.61 and
>makes them useable from the (UNIX) command line and simple
>clients. Most LDAP clients out there expect data to be in UTF-8.
>So you should be planning transitioning to UTF-8 instead. Netscape
>will be happy, Outlook will be happy, Java will be happy, you can
>more or less handle it from Perl, etc. That leaves your C/C++ programs.
>Since you are from Canada, I presume you are interested in ISO-8859-1.
>Translation from/to UTF-8 is trivial, you don't need tables.
>STR_TRANSLATION is a dead end. Plan to do without it.