How can I make sure that all of the three attachments to this post will be displayed correctly in Roundcube when clicking on the attachment link?
Currently only the UTF-8 version will be displayed correctly. I'm not sure about how to deal with the Unicode version, but at least the plain text version is definitely lacking of a correct charset declaration (or better, of a charset declaration at all).
As this charset can't be detected or known by any other than the user who is attaching the text file, I suggest that there should be a facility to select the appropriate charset - sometimes...
But apart from that, I'm wondering which charset Roundcube is using at all when displaying the plain text file...? It is apparently not the local 8bit charset of my system (Windows-1252), as it should then being displayed this way:
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ DOS Codepage 437 ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
But see yourself what the output is (image attached as well)...
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 24.03.2013 22:01, schrieb Michael Heydekamp:
Currently only the UTF-8 version will be displayed correctly. I'm not sure about how to deal with the Unicode version, but at least the plain text version is definitely lacking of a correct charset declaration (or better, of a charset declaration at all).
As this charset can't be detected or known by any other than the user who is attaching the text file, I suggest that there should be a facility to select the appropriate charset - sometimes...
But apart from that, I'm wondering which charset Roundcube is using at all when displaying the plain text file...? It is apparently not the local 8bit charset of my system (Windows-1252), as it should then being displayed this way:
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ DOS Codepage 437 ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
But see yourself what the output is (image attached as well)...
Looking at the HTML source of RC's output, it appears that RC is using UTF-8 no matter what when displaying text files (unless the charset is declared, this needs still to be tested).
As UTF-8 can be safely detected (i.e. if the file is validly UTF-8 encoded or not), this isn't a good idea for text files in a plain 8bit charset.
Nonetheless, even then Roundcube (or any other MUA) can't display the file correctly if it doesn't know the charset (as not being declared). But using the local 8bit charset would in case of no valid UTF-8 encoding IMO still be better than blindly using UTF-8.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
Am 24.03.2013 22:44, schrieb Michael Heydekamp:
Looking at the HTML source of RC's output, it appears that RC is using UTF-8 no matter what when displaying text files (unless the charset is declared, this needs still to be tested).
Done: I managed to alter the original message with a correct charset declaration and to import it as a separate message into my test folder with the following CT header:
Content-Type: text/plain; charset=CP437; name="CP437 (plain).txt"
Indeed, the display is now totally different, but still not correct (see image attached).
Despite the now existent charset declaration, the HTML source of the output is still saying:
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
Hmm, shouldn't that now read "CP437" rather than "UTF-8"?
So it appears that RC does not only have no facility to declare a charset of an attached text file, but it does also not respect a correctly declared charset of such a file.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
I'm referring to my message below (and its attachments) and just encountered a strange behaviour with regards to those attachment warnings ("Show it anyway"):
Up to now, "Preferences > Displaying messages > Default Character Set" was set to UTF-8 here. With this setting, I can display all of the three .txt attachments of the message quoted below without any warning. I'm in this message not talking about the issue HOW they are being displayed, but at least they are being displayed.
A few moments ago, I changed "Preferences > Displaying messages > Default Character Set" to Windows-1252 (related to my most recent message with the subject "Subject empty upon replying?").
With this setting, only the file "CP437 (plain).txt" is still being displayed without any warning. The other two files "CP437 (Unicode).txt" and "CP437 (UTF-8).txt" are all of a sudden throwing the warning attached (they are detected as application/octet-stream) - although the Content-Type of ALL of the three files is of course still text/plain.
So apparently the charset defined under "Preferences > Displaying messages > Default Character Set" does have an influence how plain/text attachments (and probably other attachments as well?) are being detected and handled. This does confuse me and does not make any sense to me. The warning is simply wrong, and the fallback charset is in no way connected to the Content-Type (or better, it should not).
Furthermore, the display of the warning is truncated at the bottom - depending on the width of the window. If I reduce the windows width, the display becomes correct at the point where the text at the very beginning does consume three lines instead of just two (see also attached).
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany
On 24.03.2013 22:01, Michael Heydekamp wrote:
How can I make sure that all of the three attachments to this post will be displayed correctly in Roundcube when clicking on the attachment link?
Currently only the UTF-8 version will be displayed correctly. I'm not sure about how to deal with the Unicode version, but at least the plain text version is definitely lacking of a correct charset declaration (or better, of a charset declaration at all).
As this charset can't be detected or known by any other than the user who is attaching the text file, I suggest that there should be a facility to select the appropriate charset - sometimes...
But apart from that, I'm wondering which charset Roundcube is using at all when displaying the plain text file...? It is apparently not the local 8bit charset of my system (Windows-1252), as it should then being displayed this way:
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸ ³ DOS Codepage 437 ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
But see yourself what the output is (image attached as well)...
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany _______________________________________________ Roundcube Development discussion mailing list dev@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/dev
On 04/01/2013 10:51 PM, Michael Heydekamp wrote:
So apparently the charset defined under "Preferences > Displaying messages > Default Character Set" does have an influence how plain/text attachments (and probably other attachments as well?) are being detected and handled. This does confuse me and does not make any sense to me. The warning is simply wrong, and the fallback charset is in no way connected to the Content-Type (or better, it should not).
You're right that charset setting shouldn't change behaviour of that check. But it does because converting (or not converting) the charset can produce invalid content which then is detected as application/octet-stream.
This can be fixed by changing 3rd argument of get_part_content() method to true in line 128 and 130 of steps/mail/get.inc. I'm not sure if this change will have any security implications, but for sure is not the only change we need, because $part->body need to be converted (if needed) later. The value can be also cached, so it's not a simple change and need to be done with care. Open a ticket, please.
-
A.L.E.C -
Michael Heydekamp