7:39 a.m.
Hi all,
I might be too frustrated recently and might have overseen something, but is
there a way to set up specific char encoding in SyncEvolution
configuration?
The reason is that I have few old phones in Latin1/ISO-8859-15 and a newer
N9 using UTF-8
While N9 works fine, I get mangled ö/ä/ü in the contacts from the older
phones.
I'm just thinking how can I solve this.
regards
8:13 a.m.
On Wed, 2016-03-23 at 08:39 +0100, deloptes wrote:
Hi all,
I might be too frustrated recently and might have overseen something, but is
there a way to set up specific char encoding in SyncEvolution
configuration?
The reason is that I have few old phones in Latin1/ISO-8859-15 and a newer
N9 using UTF-8
While N9 works fine, I get mangled ö/ä/ü in the contacts from the older
phones.
I'm just thinking how can I solve this.
The older phones presumably use vCard 2.1? 3.0 always uses UTF-8.
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?
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.
--
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.
11:13 p.m.
Patrick Ohly wrote:
On Wed, 2016-03-23 at 08:39 +0100, deloptes wrote:
> Hi all,
>
> I might be too frustrated recently and might have overseen something, but
> is there a way to set up specific char encoding in SyncEvolution
> configuration?
>
> The reason is that I have few old phones in Latin1/ISO-8859-15 and a
> newer N9 using UTF-8
> While N9 works fine, I get mangled ö/ä/ü in the contacts from the older
> phones.
> I'm just thinking how can I solve this.
The older phones presumably use vCard 2.1? 3.0 always uses UTF-8.
Yes it is vCard 2.1.
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?
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. The result however in the Addressbook is not readable (for the
cyrillic) and mangled for the ö.
I'll have a look next week as the time window for private work gets closed
now.
Thanks in advance
10:29 a.m.
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.
9:48 p.m.
Patrick Ohly wrote:
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.
yes indeed
> > 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.
What I mean that I see the Cyrillic as ????? and the ö as two squares. The
first happens according my experience when you convert to ASCII and the
latter when you do utf to utf - anyway this is not that important.
Important is that it is broken and most probably not in syncevolution.
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.
I now also think the problem is somewhere deeper. From what I see the vCard
passed to the backend looks properly encoded. I'll try to get it printed
out to check how it looks like when we receive it and after we've saved it
in the address book.
thank you for looking into it
regards
11:15 p.m.
New subject: [SyncEvolution] Char encoding in syncevo config [identified]
Hi Patrick,
thanks again for the input. It seems to be a bug in the vCard to addressee
converter in TDE.
regards
4:16 p.m.
Looking further into it I solved the issue by passing c_str() to parseVCard
TDEABC::Addressee addressee = converter.parseVCard(item.c_str());
works OK
and when reading an item the same, after converting the TQString into
std::string, passing the c_str() to the item object
item.assign(data_str.c_str());
works OK
so in both directions now encoding is preserved.
thanks for the hints and advises, without your help I wouldn't have solved
it so fast.
1801
days inactive
1803
days old
syncevolution@synevolution.org
7 comments
2 participants
participants (2)
-
deloptes -
Patrick Ohly