[sync] [patch] Re: Charset problems when syncing SE W880i calendar

[munzli]

hi

the problem with solving it like this is that sunbird/lightning starts 
to get errors after using a nokia to sync.
would be great if somebody could make a fix.

thanks a bunch


Bjørn Mork wrote:
> Bjørn Mork <bjorn at mork.no> writes:
>   
>> Karsten Fourmont <fourmont at gmx.de> writes:
>>
>>     
>>> But this hints in the direction that iso-8559-1 is the default when
>>> using quoted printable for the old non rfc VCALENDAR1.0 format.
>>> I put an according patch into cvs (iCalendar module).
>>>
>>> Please give it a try.
>>>       
>> Hmm, can't get it to work.  Will do some further testing.
>>     
>
>
> I tried commenting out the "isOldFormat()" test, just to verify that
> the fix should have worked:
>
>                 // Charset and encoding handling.
>                 if ((isset($params['ENCODING'])
>                      && String::upper($params['ENCODING']) == 'QUOTED-PRINTABLE')
>                     || isset($params['QUOTED-PRINTABLE'])) {
>
>                     $value = quoted_printable_decode($value);
>                     if (isset($params['CHARSET'])) {
>                         $value = String::convertCharset($value, $params['CHARSET']);
>                     } else {
>                         // Assume utf8 as default for vcalendar 2.0 and
>                         // vcard 3.0, iso-8559-1 otherwise.
>                   //      if ($this->isOldFormat()) {
>                             $value = String::convertCharset($value, 'iso-8859-1');
>                   //      } else {
>                   //          $value = String::convertCharset($value, 'utf-8');
>                   //      }
>                     }
>                 }
>
>
> And it did work, of course.
>
> So my next question was:  Why isn't isOldFormat() true for these
> vcalendar objects?  I tried following the logic setting it, and found
> that it is supposed to default to true if $this->_version < 2 (for
> vCalendars anyway).  
>
> The problem is that _version is not set by the time the vEvent
> subcomponent is parsed, because parsevCalendar() does
>
>   1) handle VTIMEZONE subcomponents
>   2) handle other subcomponents
>   3) handle attributes
>
>
> I.e., the vCalendar object looks like:
>
> BEGIN:VCALENDAR
> VERSION:1.0
> BEGIN:VEVENT
> DTSTART:20070821T210000Z
> DTEND:20070821T213000Z
> DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Laget av Bj=F8rn
> SUMMARY;ENCODING=QUOTED-PRINTABLE:Test =F8 test
> LOCATION;ENCODING=QUOTED-PRINTABLE:P=E5 B=F8
> LAST-MODIFIED:20070821T211243Z
> X-SONYERICSSON-DST:4
> X-IRMC-LUID:00000000005B
> END:VEVENT
> END:VCALENDAR
>
> but it will be parsed like
>
> BEGIN:VCALENDAR
> BEGIN:VEVENT
> DTSTART:20070821T210000Z
> DTEND:20070821T213000Z
> DESCRIPTION;ENCODING=QUOTED-PRINTABLE:Laget av Bj=F8rn
> SUMMARY;ENCODING=QUOTED-PRINTABLE:Test =F8 test
> LOCATION;ENCODING=QUOTED-PRINTABLE:P=E5 B=F8
> LAST-MODIFIED:20070821T211243Z
> X-SONYERICSSON-DST:4
> X-IRMC-LUID:00000000005B
> END:VEVENT
> VERSION:1.0
> END:VCALENDAR
>
>
>
> I believe the special handling of VTIMEZONE is solving only half the
> problem.  Composite objects should really be parsed like this
>
>   1) handle attributes
>   2) handle VTIMEZONE subcomponents
>   3) handle other subcomponents
>
> Since _any_ attribute of the container object could affect the
> subcomponents, couldn't it?  Otherwise they wouldn't have any meaning,
> IMHO.
>
> I don't have the faintest clue about php, but the attached diff seems to
> work for me.  There are probably far more elegant ways of solving this.
>
>
> Bjørn
>
>