30 lines
1.0 KiB
Plaintext
30 lines
1.0 KiB
Plaintext
MBOX-Line: From jkt at flaska.net Sun Oct 28 15:30:15 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= <jkt@flaska.net>
|
|
Date: Fri Jun 8 12:34:49 2018
|
|
Subject: [Imap-protocol] Decoding RFC2047-encoded data from ENVELOPE fields
|
|
Message-ID: <508DB1F7.5050409@flaska.net>
|
|
|
|
Hi,
|
|
I'm writing some test cases for my RFC2047 decoder. It is used only for
|
|
decoding of data which come from IMAP's ENVELOPE fetch item, so it
|
|
doesn't deal with stuff like comments.
|
|
|
|
What's the correct decoding of "Domen =?UTF-8?Q?Ko=C5=BEar?=" -- is the
|
|
space found after "Domen" in the input to be included in the decoded
|
|
output? This is a real example of what Evolution 2.30.2 produces (my
|
|
apologies to Domen for bringing the attention to his mail). Thunderbird
|
|
renders that as two words separated by space.
|
|
|
|
I'm asking because an example in the RFC says that this:
|
|
"(=?ISO-8859-1?Q?a?= b)"
|
|
shall decode into "(ab)". There's no example for the other order of
|
|
elements.
|
|
|
|
Cheers,
|
|
Jan
|
|
|
|
--
|
|
Trojita, a fast e-mail client -- http://trojita.flaska.net/
|
|
|