CSV attachment displayed as text instead of opening in Excel



9 years ago
3 years ago


(Reporter: mike001, Unassigned)


Windows XP

Thunderbird Tracking Flags

(thunderbird3.1 ?)


(Whiteboard: [gs], )

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 

Just-upgraded to 3.1.2, and can no longer open attachments containing CSV (comma-separated values) part.  Before upgrade to 3.1.2, used to open Excel.

Reproducible: Always

Steps to Reproduce:
1. Receive a multipart-mixed email with a "text/plain" part and "application/octet-stream" parts
2. Double-click to open the attachment
3 [review].
Actual Results:  
Attachment is displayed by TB as text.

Expected Results:  
Attachment will be opened by Excel

First part header:
Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable
[contains "body" of message]

Second part header:

Content-Type: application/octet-stream;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

May have same cause as Bug 587660.  Have full email available.

[again selected "Windows XP" as platform because I'm not sure what "NT 5.1" is]
[severity set at "normal", but if parsing "application/octet-stream" is broken, should be higher]
Whiteboard: [gs]
This is INVALID as Content-Type: application/octet-stream; name="P1YYMMDD.CSV" clearly doesn't say something like application/vnd.ms-excel.

Mike, does it work better is the attachment is named "P1YYMMDD.csv" ?
I don't think it's invalid, as -- according to the user -- this used to work.  From what I can tell, there IS code to handle "digging into" application/octet-stream attachments and deciding what to do based on the filename extension; see:

I don't know for sure that code ever gets involved when trying to display/save attachments, but I don't know what else it purpose would be.  I tried to figure out what MIME type would be returned based on a particular filename extension, but the "mapping" of extension-to-MIME-type is OS and user-dependent.  

Someone more familiar with where execution would proceed, given a particular filename extension, could probably determine if there were any changes in that area between early 3.x and 3.1.2.

If the filename/extension is case-sensitive, I'd say that's a bug (at least by my cursory examination of RFCs 2183 and 1521).

Finally, "This is INVALID as [...] clearly doesn't say something like application/vnd.ms-excel."

No, it doesn't -- but it doesn't say "application/vnd.thunderbird", either.  If TB isn't supposed to try to open a compatible "AppHelper", then it certainly shouldn't display the attachment as text; the user should be asked if he/she wants to save the file.
I have the same problem : I want to open csv files with excel and txt files with notepad.

But both attachments are mime type Text/Plain. So Thunderbird always use the program associated with txt files.

The only solution I found is not to associate txt files with notepad. Each time I want to open a txt file, I have to confirm the message box (without prompting the option always do this action).

I tried to manually modify the file mimeTypes.rdf in my profile. But I don't find a solution.

If someone knows a better solution, I will use it.
I've found a work-around. As noted above, the problem is when a mail client marks the attachment as Text/Plain. Outlook handles csv attachments correctly (open in Excel) because Excel is a Microsoft product, so it presumably "just knows". To fix this for Thunderbird, the client must send the csv attachment as Content-Type: application/vnd.ms-excel. Thunderbird, as a client, DOES do this.

I am using mail(x). To make this work with the mailx client, the following entry must exist in /etc/mime.types:

application/vnd.ms-excel        csv

That did the trick for me. Other clients (e.g. mutt), also have mime.type settings.
You need to log in before you can comment on or make changes to this bug.