6.0.0-git
2019-03-24

[#1591] utf-8 mime encoding
Summary utf-8 mime encoding
Queue IMP
Queue Version 4.0.2
Type Bug
State Resolved
Priority 2. Medium
Owners Horde Developers (at)
Requester alex (at) vc (dot) bks (dot) by
Created 2005-03-21 (5116 days ago)
Due
Updated 2005-05-12 (5064 days ago)
Assigned 2005-05-12 (5064 days ago)
Resolved 2005-05-12 (5064 days ago)
Milestone
Patch No

History
2005-05-12 16:07:48 Jan Schneider Comment #16
State ⇒ Resolved
Reply to this comment
Great! Works now in all combinations. Thanks for not giving up! :-)
2005-05-12 15:45:19 Michael Slusarz Comment #15 Reply to this comment
My mistake.  I forgot to take out the code that was setting the 
filename to the sending character set.  I've fixed it so that this 
filename is always stored in the character set of the browser (i.e. 
NLS::getCharset()).  Hopefully, this fixed it (*cringe* - thanks for 
your patience).
2005-05-12 12:10:46 Jan Schneider Comment #14 Reply to this comment
Ah, and i always use utf-8 on the browser side of course, so the 
filename should always be in utf-8.
2005-05-12 12:09:52 Jan Schneider Comment #13 Reply to this comment
Still no go. My tests are with a UTF-8 encoded file name containing 
Traditional Chinese letters. I test sending the attachment with three 
different charsets, latin1 - my default one, utf-8 and big5; both 
specifying the email charset before and after uploading the 
attachment. The only case that works is if i set the email charset to 
utf-8 before uploading the attachment. All other cases fail. The 
latin1 tests must fail of course.
2005-05-12 05:26:56 Michael Slusarz Comment #12
State ⇒ Feedback
Reply to this comment
2005-04-14 10:44:38 Jan Schneider Comment #11
State ⇒ Assigned
Reply to this comment
No. It's now encoded in the charset that the user has set in his 
preferences, not in the charset that he selected in the compose 
screen. If I select a different charset in the compose screen *before* 
uploading the attachment, the correct charset is used in the header 
encoding, but the filename is not converted from the UI charset to the 
selected.
2005-04-14 07:08:44 Michael Slusarz Comment #10
State ⇒ Resolved
Reply to this comment
This for real should be fixed now (it was actually a bug in Horde - 
framework/MIME/MIME/Part.php) and has been fixed in 3.0.5.
2005-04-13 17:29:54 Jan Schneider Comment #9
State ⇒ Assigned
Reply to this comment
This patch didn't help, the attachment names are always sent as utf-8 
if this is the UI charset.
2005-03-25 00:08:31 Michael Slusarz Comment #8
State ⇒ Resolved
Reply to this comment
Well, it's working just fine for me so, due to the lack of feedback, 
I'm going to go ahead and commit it to 4.0.3.
2005-03-23 04:01:07 Michael Slusarz Comment #7 Reply to this comment
Either somebody that is running head should confirm this fix works for 
them or you will have to manually patch the files (which shouldn't be 
too hard since framework is pretty well synced with HEAD at this point 
and there isn't more than 5 or 6 lines that changed).  I just wanted 
feedback from someone before I merged this with stable.
2005-03-22 16:04:23 alex (at) vc (dot) bks (dot) by Comment #6 Reply to this comment
Am using stable version of Horde/Imp, not Head.

Can I try get some file from cvs, or I must get whole tree?

If I can - what file?
2005-03-22 07:40:29 Michael Slusarz Comment #5
State ⇒ Feedback
Reply to this comment
Can you try what i just committed to CVS?
2005-03-21 16:42:56 Jan Schneider Comment #4
State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
Reply to this comment
That should be fixed.
2005-03-21 16:33:56 alex (at) vc (dot) bks (dot) by Comment #3 Reply to this comment
Sorry, it's my mistake. I set up locking for "sending_charset" in 
imp/prefs.php without defining any "value".

Then, I have another question - setting that value to, for example 
"windows-1251", I see that charset is used for encoding headers, but 
filenames in attachments still encoded with UTF-8.

If it right, can I change default encoding for filenames?
2005-03-21 16:02:37 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
Works fine here.
2005-03-21 15:42:27 alex (at) vc (dot) bks (dot) by Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ utf-8 mime encoding
Queue ⇒ IMP
Reply to this comment
I check out source of message, sended by Imp, and found string like 
this "Subject: =??b?0L/RgNC+0LLQtdGA0LrQsA==?=".

As it's a utf8-encoded subject, why it not contain "=?utf-8?" at 
begin? Some mail clients may not correct detect encoding of this 
message.

Saved Queries