181557 - encoding of calendar information with non-ISO-8859-1 characters

Status: VERIFIED DUPLICATE of bug 167800

(Calendar :: Sunbird Only, defect)

Description

[Julian Reschke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016

Currently, Calendar seems to use ISO-8859-1 when writing ICS files (I think this
should default to UTF-8). Furthermore, non-ISO characters are currently lost
(for example, the Euro sign -- Unicode U+20AC -- seems to be written as 0xAC and
this won't be roundtripped.

Reproducible: Always

Steps to Reproduce:
1. Create event with non-ISO characters
2. Save
3. Reload

Actual Results:  
Instead of Euro sign, the character corresponding to 0xAC in ISO appears.

Expected Results:  
Euro sign should appear.

This should be compatible to what Outlook uses.

Comment 1

[Jano John Akim Franke]

WORKSFORME:
20021212/2002112809-cal shows the euro-sign € in frontend stored as 0xE282AC in
the .ics-file.

Comment 2

[Julian Reschke]

It works when saving to a local file, but it fails when the file is published
using HTTP PUT (publishing to remote URL).

Comment 3

[Jano John Akim Franke]

CONFIRMED:
Also on OS: Windows 98 using ftp-transport.

Additionally i did the following experiment:
I modified the published .ics-file to contain an ISO 8859-15 euro-sign (0xA4)
and served it as "Content-Type: text/calendar; charset=iso-8859-15" but got back
a ISO 8859-1 glyph-presentation (currency symbol). When served as "Content-Type:
text/plain; charset=iso-8859-15" the browser (not the calendar!) displays correct.

May be a general charset-issue. See http://www.cs.tut.fi/~jkorpela/latin9.html
for the ISO 8859-15.

Comment 4

[Mike Potter]

Marking confirmed based on comments.

Comment 5

[Simon Woods]

I have what appears to be the same problem with non ascii characters in German.
The Calendar stores the special characters in UTF-8 format in the local file. If
this is then published to a (in my case web) server and resynchronised (I can
only speak for http://www/mycalendar.ics method) the Calendar passes the
downloaded file though the UTF-8 encoding again. This unncessarily reencodes the
already UTF-8 encoded characters!

ä becomes Hex C3 A4 when saving for the first time to disk
I now upload the Calendar file to my web server ...
After downloading the file the C3 A4 (UTF-8 represenation for ä) gets converted
to Hex C3 83 C2 A4
Do it again and you get 8 Bytes, then 16 ......

It has taken a few turns for me to work out what is happening and now have a
real mess in the events text :-(

I will have to stick to ascii characters untill this is resolved.

Comment 6

[Dennis Haney]

this is a dup of bug 167800

Comment 7

[Eric Belhaire]

*** This bug has been marked as a duplicate of 167800 ***

Comment 8

[R.J. Keller]

VERIFIED

Comment 9

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: Sunbird Only. Be afraid for your sanity!