* Fail to encode attachement filenames properly.
@ 2002-04-30 3:16 Jinhyok Heo
2002-04-30 13:33 ` Jesper Harder
0 siblings, 1 reply; 7+ messages in thread
From: Jinhyok Heo @ 2002-04-30 3:16 UTC (permalink / raw)
If I send a non-latin filename attachment, Gnus seems to fail to
encode it properly.
For example, a correct attachement mime part would start like the
following.
,--------------------------------------------
|Content-Type: application/octet-stream;
| name="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
|Content-Transfer-Encoding: base64
|Content-Disposition: attachment;
| filename="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
`--------------------------------------------
But my Gnus which I got it from cvs recently makes mime parts like
,--------------------------------------------
|Content-Type: application/octet-stream
|Content-Disposition: attachment;
| filename*=euc-kr''kin_%bc%b3%b9%ae%c1%f6.hwp
|Content-Transfer-Encoding: base64
`--------------------------------------------
Gnus seems to fail to encode filenames correctly.
--
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
| are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fail to encode attachement filenames properly.
2002-04-30 3:16 Fail to encode attachement filenames properly Jinhyok Heo
@ 2002-04-30 13:33 ` Jesper Harder
2002-05-02 0:56 ` Jinhyok Heo
0 siblings, 1 reply; 7+ messages in thread
From: Jesper Harder @ 2002-04-30 13:33 UTC (permalink / raw)
novembre+dated+1020567757.8c22a8@ournature.org (Jinhyok Heo) writes:
> If I send a non-latin filename attachment, Gnus seems to fail to
> encode it properly.
>
> For example, a correct attachement mime part would start like the
> following.
> ,--------------------------------------------
> |Content-Type: application/octet-stream;
> | name="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
> |Content-Transfer-Encoding: base64
> |Content-Disposition: attachment;
> | filename="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
> `--------------------------------------------
This is not standards compliant. The filename parameter should be
encoded using RFC 2231, not an RFC 2047 encoding as in your example.
> But my Gnus which I got it from cvs recently makes mime parts like
> ,--------------------------------------------
> |Content-Type: application/octet-stream
> |Content-Disposition: attachment;
> | filename*=euc-kr''kin_%bc%b3%b9%ae%c1%f6.hwp
> |Content-Transfer-Encoding: base64
> `--------------------------------------------
This looks correct to me.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fail to encode attachement filenames properly.
2002-04-30 13:33 ` Jesper Harder
@ 2002-05-02 0:56 ` Jinhyok Heo
2002-05-02 3:40 ` Jesper Harder
0 siblings, 1 reply; 7+ messages in thread
From: Jinhyok Heo @ 2002-05-02 0:56 UTC (permalink / raw)
>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:
JH> novembre+dated+1020567757.8c22a8@ournature.org (Jinhyok Heo) writes:
> If I send a non-latin filename attachment, Gnus seems to fail to
> encode it properly.
>
> For example, a correct attachement mime part would start like the
> following.
> ,--------------------------------------------
> Content-Type: application/octet-stream;
> name="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="=?euc-kr?B?tOuxuLGztbW80ijAzrHHwKew+LmuKS5od3A=?="
> `--------------------------------------------
JH> This is not standards compliant. The filename parameter should be
JH> encoded using RFC 2231, not an RFC 2047 encoding as in your example.
Well, I didn't know that which one is standard comliant. I appreciate
your information.
The above one was excerpted from a M$-outlook mail.
> But my Gnus which I got it from cvs recently makes mime parts like
> ,--------------------------------------------
> Content-Type: application/octet-stream
> Content-Disposition: attachment;
> filename*=euc-kr''kin_%bc%b3%b9%ae%c1%f6.hwp
> Content-Transfer-Encoding: base64
> `--------------------------------------------
JH> This looks correct to me.
But people who use M$-outlook or many webmails have trouble with
attachments I send to them.
I just have to wait and see for M$-outlook to be standard compliant in
the future?
--
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
| are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fail to encode attachement filenames properly.
2002-05-02 0:56 ` Jinhyok Heo
@ 2002-05-02 3:40 ` Jesper Harder
2002-05-02 9:04 ` Fail to encode attachment " Jinhyok Heo
0 siblings, 1 reply; 7+ messages in thread
From: Jesper Harder @ 2002-05-02 3:40 UTC (permalink / raw)
novembre+dated+1020732359.ff68e2@ournature.org (Jinhyok Heo) writes:
>>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:
>
> JH> This is not standards compliant. The filename parameter should be
> JH> encoded using RFC 2231, not an RFC 2047 encoding as in your example.
>
> Well, I didn't know that which one is standard comliant. I appreciate
> your information.
>
> The above one was excerpted from a M$-outlook mail.
Mozilla used to have the same bug, but I think it was fixed recently --
see <http://bugzilla.mozilla.org/show_bug.cgi?id=63656>
> But people who use M$-outlook or many webmails have trouble with
> attachments I send to them.
>
> I just have to wait and see for M$-outlook to be standard compliant in
> the future?
That could be a long wait :-) In the mean time
(defalias 'mail-header-encode-parameter 'rfc2045-encode-string)
should make Gnus use the "wrong" encoding, which Outlook can decode.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fail to encode attachment filenames properly.
2002-05-02 3:40 ` Jesper Harder
@ 2002-05-02 9:04 ` Jinhyok Heo
2002-05-02 18:18 ` Jesper Harder
0 siblings, 1 reply; 7+ messages in thread
From: Jinhyok Heo @ 2002-05-02 9:04 UTC (permalink / raw)
>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:
JH> That could be a long wait :-) In the mean time
JH> (defalias 'mail-header-encode-parameter 'rfc2045-encode-string)
JH> should make Gnus use the "wrong" encoding, which Outlook can decode.
Your suggestion doesn't solve the problem.
For example, with the setting above. An attachment filename generated
the following.
|Content-Type: application/octet-stream
|Content-Disposition: attachment; filename=020415~~~.hwp
|Content-Transfer-Encoding: base64
Korean characters are not properly encoded. "~~~" part was Korean
letters.
--
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
| are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fail to encode attachment filenames properly.
2002-05-02 9:04 ` Fail to encode attachment " Jinhyok Heo
@ 2002-05-02 18:18 ` Jesper Harder
2002-05-05 23:55 ` Jinhyok Heo
0 siblings, 1 reply; 7+ messages in thread
From: Jesper Harder @ 2002-05-02 18:18 UTC (permalink / raw)
novembre+dated+1020762014.ee9fa2@ournature.org (Jinhyok Heo) writes:
>>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:
>
> JH> That could be a long wait :-) In the mean time (defalias
> JH> 'mail-header-encode-parameter 'rfc2045-encode-string) should
> JH> make Gnus use the "wrong" encoding, which Outlook can decode.
>
> Your suggestion doesn't solve the problem.
>
> For example, with the setting above. An attachment filename generated
> the following.
>
> |Content-Type: application/octet-stream
> |Content-Disposition: attachment; filename=020415~~~.hwp
> |Content-Transfer-Encoding: base64
>
> Korean characters are not properly encoded. "~~~" part was Korean
> letters.
Right, I only tested it with Latin-1 (where it does work).
Does this work for you?
(defun jh-broken-ms-encoding (param value)
(concat param "=\"" (rfc2047-encode-string value) "\""))
(defalias 'mail-header-encode-parameter 'jh-broken-ms-encoding)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fail to encode attachment filenames properly.
2002-05-02 18:18 ` Jesper Harder
@ 2002-05-05 23:55 ` Jinhyok Heo
0 siblings, 0 replies; 7+ messages in thread
From: Jinhyok Heo @ 2002-05-05 23:55 UTC (permalink / raw)
>>>>> "JH" == Jesper Harder <harder@ifa.au.dk> writes:
JH> Does this work for you?
JH> (defun jh-broken-ms-encoding (param value)
JH> (concat param "=\"" (rfc2047-encode-string value) "\""))
JH> (defalias 'mail-header-encode-parameter 'jh-broken-ms-encoding)
Yes, it does! Thanks a lot.
Now ugly M$-outlook client(and some webmails) can recognizes my gnus
attachment filenames, though unix pine users come to have problems
with them.
--
| Jinhyok Heo (novembre @ ournature.org || http://ournature.org/~novembre/)
|--------------------------------------------------------------------------
| "We are still reaching for the sky. In the developed countries people
| are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-05-05 23:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-30 3:16 Fail to encode attachement filenames properly Jinhyok Heo
2002-04-30 13:33 ` Jesper Harder
2002-05-02 0:56 ` Jinhyok Heo
2002-05-02 3:40 ` Jesper Harder
2002-05-02 9:04 ` Fail to encode attachment " Jinhyok Heo
2002-05-02 18:18 ` Jesper Harder
2002-05-05 23:55 ` Jinhyok Heo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).