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

Bjørn Mork bjorn at mork.no
Wed Aug 22 09:16:17 UTC 2007


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



More information about the sync mailing list