I can't reproduce this bug. How have you created/modified your card? From the Web interface or a fat client?

I did nothing with the card(s) whatsoever. I'm writing a program to search and display contacts for the mutt mail client. To this I use libcurl.

Using curl one can get the data from a carddav service like this:
1) create a xml query file

<?xml version="1.0" encoding="utf-8" ?>
<C:addressbook-query xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav">
<D:prop>
<D:getetag/>
<C:address-data>
<C:prop name="EMAIL"/>
<C:prop name="FN"/>
</C:address-data>
</D:prop>
<C:filter test="anyof">
<C:prop-filter name="FN">
<C:text-match collation="i;unicode-casemap"
match-type="contains">QUERY-TERM</C:text-match>
</C:prop-filter>
<C:prop-filter name="EMAIL">
<C:text-match collation="i;unicode-casemap"
match-type="contains">QUERY-TERM</C:text-match>
</C:prop-filter>
</C:filter>
</C:addressbook-query>

Now lets curl for the cards containing your QUERY-TERM in FN and/or EMAIL:
$ curl -v -i -X REPORT -H 'Content-Type: text/xml; charset=utf-8'
-u 'user:pass' -d @query.xml <SOGo-Contacts-URL>

If a records contains a german umlaut (ä for instance) it will become &#<NUMBER>; - i.e. FN:Max;Musterm&#<NUMBER>;nn

Both my ARCH-linux system and libcurl are up-to-date. I use de_DE.UTF-8 as locale.

Ahh I see - I can't enter html entities... I will make a screen shot

• Screenshot uploaded

another question came to my mind: why is the server answering twice?

first) a vcard within <C:address-data>
second) the same vcard within <C:addressbook-data>

see screenshot.

From the web interface, show us the raw source of the problematic vcard (select "Show raw source" from the contextual menu).

the source is valid:

BEGIN:VCARD
UID:5136-51080900-9-68BA3880.vcf
VERSION:3.0
CLASS:PUBLIC
PROFILE:VCARD
N:Rabarber;Fränzchen
FN:Fränzchen Rabarber
EMAIL;TYPE=work:franz@rabarber.com
END:VCARD

RFC6352 says:

Note: The address data embedded within the CARDDAV:address-data XML
element MUST follow the standard XML character data encoding
rules, including use of <, >, & etc., entity encoding or
the use of a <![CDATA[ ... ]]> construct. In the latter case, the
vCard data cannot contain the character sequence "]]>", which is
the end delimiter for the CDATA section.

SOGo returns the data following the XML data encoding rules. If we decide or not to encode entities, it doesn't matter - it just takes a bit more bytes at the end. On the other end, a CardDAV client MUST decode (following the XML data de/encoding rules) the received address-data BEFORE parsing it as a vCard object.