Created attachment 88422 [details]
Example of an incorrectly folded addressbook item

Exporting an addressbooks into a .vcf file produces incorrect data when folded (slit) long lines are written. RFC 822 (and, based on this, RFC2425 and RFC2426) specify that lines with a length exceeding 75 characters should be "folded" - splitting off continuation lines - and how this is to be done:

- according to these standards, splitting should be achieved by REPLACING a whitespace by a <CR>-whitespace sequence

- kaddressbook, rather than replacing a whitespace as specified, simply INSERTS a <CR> at - apparently - arbitrary places.

As a consequence, addressbook items exported from kaddressbook may contain wrong additional whitespaces; worse, if such an extraneous whitespace appears within a string that specifies an UTF-encoded character, importing the addressbook data into another program will normally fail.

Ordinarily, the length of most addressbook items does not exceed 75 characters - this problem therefore is unlikely to strike in addressbooks with only English items (that do not contain characters that require UTF encoding).

But, if adressbook-items contain characters that, on export, produce UTF-encoded strings, the string representing such items are much longer and
the bug becomes very annoying: it is practically not possible to use kaddressbook for exporting French or German addressbooks, for instance for synchronising with tabletts or smart phones.