516806 - Encoding error when creating events from Lightning in Egroupware

Status: RESOLVED INVALID

(Calendar :: Provider: ICS/WebDAV, defect)

Description

[gergely.papp]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090915 Ubuntu/9.04 (jaunty) Shiretoko/3.5.4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Shredder/3.0b4pre

When I create an event from Lighting either from an e-mail or from an invitation in eGroupware (1.6.0.2) the encoding is messed up.

The encoding IS messed up in the ical, when I test with iconv -f UTF-8 it shows a character as an invalid UTF character.

I think it's Lightning that needs fixing, as Evolution is able to open the file.

I suspect the item is created in the original encoding, then either published as UTF-8 in the ical, or as an ical with mixed encoding, that is not consumed in eGroupware.

Reproducible: Sometimes

Steps to Reproduce:
1. Create an event from an e-mail in ISO-8859-2 encoding containing accented characters (éáőú) in e-Groupware
2. Restart thunderbird

Actual Results:  
The calendar cannot be loaded

Expected Results:  
The calendar should display the new event

In the error console I find the message:

Warning: There has been an error reading data for calendar: XXX. Error code: CAL_UTF8_DECODING_FAILED. Description: An error occured while decoding an iCalendar (ics) file as UTF-8. Check that the file, including symbols and accented letters, is encoded using the UTF-8 character encoding.

Comment 1

[gergely.papp]

Attachment: An ical that has problems

Comment 2

[Martin Schröder [:mschroeder]]

Gergely, how did you create the event from an email? There are obviously non-UTF-8 characters in this iCalendar data, and therefore it is not valid.

Comment 3

[gergely.papp]

After applying egroupware fixes found at http://k.noc.de/index.php?option=com_content&view=article&id=6&Itemid=8 the problem disappears.

Still it would be nice if in the case of a server reply the calendar wouldn't be completely disabled. The unparseable characters could be replaced with a ? just like with most unknown UTF characters.