-
Notifications
You must be signed in to change notification settings - Fork 931
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trouble with wrongly encoded non-ASCII filenames #651
Comments
Someone else has the same problem: http://www.redmine.org/issues/14865 |
Maybe a more robust version of the monkey patch above:
|
👍 |
We have the same problem. Solved it for now by using the monkey patch... |
I believe the problem is specifically if it contains non-ASCII characters which are not valid in whatever encoding the e-mail itself is in (for instance, if the e-mail is encoded in UTF-8 and the filename is Shift-JIS). Just throwing out all non-ASCII characters doesn't seem like a very satisfying solution though. |
More liberal parsing is welcome so long as it doesn't break legit common-case parsing. No exception on current master with the following patch: diff --git a/lib/mail/utilities.rb b/lib/mail/utilities.rb
index e962d68..abc8658 100644
--- a/lib/mail/utilities.rb
+++ b/lib/mail/utilities.rb
@@ -39,7 +39,7 @@ module Mail
# Returns true if the string supplied is free from characters not allowed as a TOKEN
def token_safe?( str )
- not TOKEN_UNSAFE === str
+ str.ascii_only? && !(TOKEN_UNSAFE === str)
end
# If the string supplied has TOKEN unsafe characters in it, will return the string quoted >> puts m.encoded
Date: Thu, 09 Jan 2014 00:00:00 +0100
From: Test <test@test.test>
To: test@test.test
Message-ID: <1234567890@test.test>
Subject: Test
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary=------------090202060701010202050308
Content-Transfer-Encoding: 7bit
This is a multi-part message in MIME format.
--------------090202060701010202050308
Content-Type: text/plain;
charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 7bit
Test
--------------090202060701010202050308
Content-Type: image/png;
name*=utf-8'en'%C3%BCberraschung.png
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*=utf-8'en'%C3%BCberraschung.png
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAAGElEQVQY02P8
z8Dwn4EIwMRAJBhVSB2FAD2cAhLPzm83AAAAAElFTkSuQmCC
--------------090202060701010202050308-- |
If the filename in the Content-Disposition header of an attachment contains non-ASCII characters, then the following code fails with an error:
Here is the used mail.txt:
Normally, the filename parameter of the Content-Disposition header should be encoded as described in RFC 2183 and RFC 2184. But not all mail clients are doing this.
The following monkey patch solves the problem by replacing all non-ASCII characters in the Content-Disposition header:
(I can't use
Mail::Encodings.param_encode
in thecleaned
method becausestring
contains the whole header and not only the value of the filename parameter.)I haven't created a pull request with tests, because I am not sure if the above solution is the correct way to handle this.
The text was updated successfully, but these errors were encountered: