[SyncEvolution] Char encoding in syncevo config

[Patrick Ohly]

On Thu, 2016-03-24 at 00:13 +0100, deloptes wrote:
> Patrick Ohly wrote:
> 
> > On Wed, 2016-03-23 at 08:39 +0100, deloptes wrote:
> > When you receive vCards from those phones and they contain data in
> > ISO-8859-15, does the vCard contain a CHARSET parameter on the property
> > with the non-ASCII content?
> 
> My assumption was wrong that it was not UTF (may be). It says quoted
> printable/utf-8. Could be that the UTF there is misleading?

N;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:H=C3=B6sch;;;; seems to decode
fine to "Hösch", so it should be correct.

> > It is possible to override the default charset for specific phones. See
> > "11.36.19 <outputcharset>" in
> > libsynthesis/doc/SySync_config_reference.pdf
> > 
> > There is an example of that in
> > syncevolution/src/syncevo/configs/remoterules/server/00_sony_ericsson.xml
> > 
> > You can add similar .xml fragments for your phones, using manufacturer
> > and model tags to limit the effect to certain phones.
> > 
> 
> I attach here some snippets from the log. I see the data properly
> converted/mapped to the internal fields, only I don't know at which stage
> it is done.

In the Synthesis vCard parser. It knows about ENCODING and CHARSET
parameters. I'm not exactly sure where in the source, though.

>  The result however in the Addressbook is not readable (for the
> cyrillic) and mangled for the ö.

What's mangled about the ö? The name "Hösch" looks okay to me, at least
in the internal representation. I can't read cyrillic, so no idea
whether that example is okay.

If it is wrong after storing in your local database, then you need to
dig further in the processing pipeline. The internal representation will
get re-encoded again as vCard for storage, and that string then gets
passed to your backend.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.