Tickets :: Comment on [#14618] Attachments with special file names (RFC 2231)

* Your Email Address
* Spam protection	Enter the letters below: . ,. ,.__ . ,.___ \./ \./ [__) \./ [__ \| \| \| \| \|
Comment	> In some cases, the RFC 2231 encoding of the file name for attached > files is wrong, causing trouble on the receiving side of email with > such attachments. This seems to be happening when the content of an > attachment is pure ASCII but the filename contains non-ASCII > characters. > > Example: > Given a file by the name of "File with a long name coñtaïning strånge > characters but pure ASCII content.txt" that does, as the name > implies, contain only ASCII characters and thus will have a MIME > encoding of "Content-Type: text/plain". When attaching this file, the > file name will be encoded like this: > > name0=us-ascii''File%20with%20a%20long%20name%20co%F1ta%EFning%20str%E5ng; > name1=e%20characters%20but%20pure%20ASCII%20content.txt > > Note that the charset used for the encoding of the filename (given > before the first single-quote character in the "name0" line) is > "us-ascii" in this case. Cleary, this cannot be the case as ASCII > does not contain the character "ñ". In fact, ASCII does not contain > any character with hex code above 0x7F, so an encoding that uses a > hex code "F1" with "us-ascii" must be wrong. The actual charset would > be ISO-8859-1 or similar, as it contains the "n" with tilde at > position 0xF1 (241 decimal). > > This error does not happen, however, when the attachment's content > has non-ASCII characters in it. When attaching a file that has got > both non-ASCII content and a non-ASCII name, the encoding generated > by Horde is fine. For example, a file by the name of "Example file > with name coñtaïning strånge characters which has non-ASCII content > too.txt" that does in fact contain non-ASCII content (e.g. the string > "Hallo Bärbel") is encoded correctly. In this case, the encoding > generated would be > > name0=utf-8''Example%20file%20with%20name%20co%C3%B1ta%C3%AFning%20str; > name1=%C3%A5nge%20characters%20which%20has%20non-ASCII%20content%20too.tx; > name2=t > > which is perfectly right. For instance, the "ñ" is encoded here as > two characters in UTF-8, 0xC3 and 0xB1, which is correct. > > The root cause of the problem seems to be that Horde uses the charset > of the attachment's content to encode the attachment's filename. > This is wrong because the filename can use a different encoding than > the content. This issue manifests itself as well when there is an > attachment that contains non-ASCII characters but the filename uses > pure ASCII: the filename will be encoded as "UTF-8". This does not > cause real problems because any ASCII text is also valid UTF-8 text, > but it adds to my assumption that Horde wrongfully uses the content's > charset in the place where the filename's charset should be used. > > I will attach a zip file with four files that can be used to > illustrate the problem: > 1. File with ASCII content and ASCII filename --> OK. > 2. File with ASCII content and non-ASCII filename --> wrong. > 3. File with non-ASCII content and ASCII filename --> OK in a way > because UTF-8 is a superset of ASCII. > 4. File with non-ASCII content and non-ASCII filename --> OK. > > I hope the file names will be preserved correctly in the zip file. > This zip file was generated using Microsoft Windows's built-in ZIP > functionality, so the file names might not be recognized as they > should everywhere. If you are unable to read them, I will try some > other way to send them.
Attachment
Watch this ticket

Saved Queries