Name | Date | Size | |
---|---|---|---|
.. | 2013-06-02 02:29:49 | 15 | |
Authentication.tp2.base64.ldif | 2013-06-02 02:29:49 | 219 | |
Authentication.tp3.add.base64.ldif | 2013-06-02 02:29:49 | 225 | |
Authentication.tp3.del.base64.ldif | 2013-06-02 02:29:49 | 175 | |
Authentication.tp3.mod.base64.ldif | 2013-06-02 02:29:49 | 232 | |
Authentication.tp4.base64.ldif | 2013-06-02 02:29:49 | 220 | |
Authentication.tp5.base64.ldif | 2013-06-02 02:29:49 | 290 | |
Data_Comparison.Ref.base64.ldif | 2013-06-02 02:29:49 | 12.7 KiB | |
Data_Comparison.tp1.base64.ldif | 2013-06-02 02:29:49 | 33.8 KiB | |
European.base64.ldif | 2013-06-02 02:29:49 | 83.6 KiB | |
I18n_Authentication_Test.base64.ldif | 2013-06-02 02:29:49 | 2.9 KiB | |
LDAPcmds_tp1_Add.base64.ldif | 2013-06-02 02:29:49 | 114.5 KiB | |
LDAPcmds_tp2_Add.base64.ldif | 2013-06-02 02:29:49 | 13.6 KiB | |
LDAPcmds_tp2_Modify.base64.ldif | 2013-06-02 02:29:49 | 8.8 KiB | |
LDAPcmds_tp3_Add.base64.ldif | 2013-06-02 02:29:49 | 4.9 KiB | |
LDAPcmds_tp3_Modify.base64.ldif | 2013-06-02 02:29:49 | 3.1 KiB | |
README | 2013-06-02 02:29:49 | 1.5 KiB | |
Schema_extension.base64.ldif | 2013-06-02 02:29:49 | 1.1 KiB |
README
This directory contains files with base64 encoded UTF-8.
The operation of converting UTF-8 data to base64 has been done because of issue 2813.
From Matthew :
"If LDIF data containing non-ASCII data is provided to either ldapmodify or import-ldif then the behavior is undefined. Ideally, the tools should "do the right thing" and use either the default character set encoding to decode the values or default to UTF-8 unless otherwise specified via a CLI option. I think I prefer the second option.
This problem is currently being tracked by issue https://opends.dev.java.net/issues/show_bug.cgi?id=2813.
> In these tests for DSEE, ldif files containing double-byte data converted to UTF-8 are imported (with ldapmodify -a).
> Today, with openDS and taking into account issue 2813, do you think such files can be imported, or do I need to convert them to base64 before, to avoid an 'undefined behavior' ?
I would convert them to base64.
The base64 tool delivered with opends has been used that way :
aconit[sgouvern]$ base64 encode -d "o=�\207ándide Rùiz"
bz3Dh8OhbmRpZGUgUsO5aXo=
-> all the dn must be encoded, not only the value
The format to be used as per the LDIF encoding rules in ldif files is :
dn:: <base-64 encoded DN>
All base64 values in the ldif files in this directory had been converted being in LANG=en_US.ISO8859-1 using the following command :
echo "nonAsciiValue\c" | iconv -f 8859-1 -t UTF-8 | base64 encode
base64 being the base64 tool delivered with opends