Re: [SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)
Patrick Ohly wrote:
On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote:
> Patrick Ohly wrote:
>
> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote:
>
> >>
> >> Hi,
> >> I hope you have not forgotten about this problem. Please look into my
> >> last message and let me know if I can do something more. If it is the
> >> same issue as the TDE/libkcal one, the fix should be really simple.
> >
> > There was a misunderstanding: I need you to re-run the sync as
> > explained above (loglevel=4 as command line parameter), and *then* the
> > resulting log html file will have more information. The one you sent
> > doesn't include information about the detailed item conversion.
> >
>
> Might be my bad - sorry.
>
> Here
> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10',
> localID='' remoteID='526'
>
>
DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82
> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A=
> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0
> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A=
>
> Note ==0D=0A=
>
> It is also visible in syncevolution-log_trm002_003_incoming.xml
Sorry, I'm still confused about what the actual, unmodified incoming
data is. Can you attach the entire log file?
I doubt that I will have time to fix this, but at least I should be able
to reproduce it and point you into the right direction in the code.
I am not sure how to get the raw message that comes from the phone. It might
be specific to N9 and Cyrillic UTF8
I tracked the issue down to src/synthesis/src/sysync/mimedirprofile.cpp
static void decodeValue
I add a look ahead for the case '=' followed by '=' and '0D',
which solves
the problem.
I still have a problem with new lines '\n'. The '\' is escaped and I see
it
in the text, so from
aasdföä\nTest
it does
aasdföä\\nTest
I'm not sure if it is the right place to do it as those =0D=0A are scattered
all over the place.
According specs "quoted-printable" line ends with '=\r\n' in my case we
see '=' left over '\r\n' converted into '=0D=0A' and '='
added. I guess
simple '\n' terminates the line.
Is it possible that '\r\n' is converted into '=0D=0A=' before decodeValue
is
called?
I think this is an odd bug, but I'm not sure how to proceed with it
thanks