325484 - Events with certain characters cause formatting error when exported to .CSV

Status: RESOLVED WORKSFORME

(Calendar :: General, defect)

Description

[hockersc]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060201 Mozilla Sunbird/0.3a1+

Special characters(at least quotes) are not escaped correctly when exported to .CSV format.

Reproducible: Always

Steps to Reproduce:
1.Create an event with the title: ","
2.Select that event and export it to comma separated value
3.Open the resulting document

Actual Results:  
The resulting csv shows a subject of: ",",01/24/06"
Attempting to import the .csv causes an error in Outlook.

Expected Results:  
The relevant characters should be escaped using a backslash.

Comment 1

[Joey Minta]

I'm working off of http://www.rfc-editor.org/rfc/rfc4180.txt here.  They explain the problem pretty well when they say:
      Due to lack of a single specification, there are considerable
      differences among implementations.  Implementors should "be
      conservative in what you do, be liberal in what you accept from
      others" (RFC 793 [8]) when processing CSV files.

For the specific instance in question, they say:
   6.  Fields containing line breaks (CRLF), double quotes, and commas
       should be enclosed in double-quotes.  For example:

       "aaa","b CRLF
       bb","ccc" CRLF
       zzz,yyy,xxx

We do enclose our fields in double-quotes (at least in nightly builds).  So, really, we're stuck between "Do what the spec says" and "Support broken Outlook."  The ideal situation would be to get Outlook to accept .ics files, which have a very clearly defined structure, including character escaping.  I seem to recall it had at least basic support for this.

I guess first off, what version did you export this from?  If you didn't use a nightly build, can you try that and see if there's any improvement.

Comment 2

[Joey Minta]

This is WFM.  We're following the csv-spec from what I can tell.  There's no mention of backslash escaping that I can find.