For complete details, see RFC 2849 “The LDAP Data Interchange Format (LDIF)—Technical Specification.” An LDIF file consists of a series of records. Each LDIF file begins with a Version record and then is followed either by a series of Change records or Content records. Change and Content records cannot be in the same file.
This section describes the following general LDIF formatting conventions:
Version record
Comment specifier
Record separator
Line folding
Valid string characters
Version Record. Each LDIF file should start with a Version record. If no Version record is specified, any application processing the file is allowed to assume the file is version 0. Both the Novell Import Convert Export utility and the LDAP utilities support Version records. A Version record must be the first non-comment line in the file. It has the following format.
version: 1
Zero or more spaces are allowed after the colon.
Comment Specifier. Lines beginning with the pound (#) sign are treated as comments and are ignored when processing the file.
Record Separator. Records are separated by one or more blank lines (created by either a linefeed or carriage return/linefeed pair). The last record in the file must be terminated with a record separator (one or more blank lines).
Line Folding. Each record consists of a series of fields, one field per line. However, sometimes the information required by a field does not fit on one line. To fold a line, insert a line separator (either a linefeed or carriage return/linefeed pair) followed by a space. The LDIF parser processes this sequence by concatenating the lines and discarding the leading space.
Valid String Characters. Every operation takes a distinguished name. A colon following the specifier indicates that the name is in safe UTF-8 format, for example,
dn: cn=aperson,o=anorg,c=any
Safe strings can begin with any character in the range 0x00 to 0x7F except for the following characters:
Subsequent characters in a safe string can be any character in the range 0x00 to 0x7F except the following:
Two colons following the specifier indicates that the name is a Base64 encoded name. The following example Base64 encodes the name Kim (which really doesn't require encoding because all of its characters are safe):
givenName:: a2lt
Any name or value that contains a prohibited character must be Base64 encoded. For more information on Base64 encoding, see Section 5.2 of RFC 1521.