wasm-demo/demo/ermis-f/imap-protocol/cur/1600095057.22756.mbox:2,S

53 lines
1.9 KiB
Plaintext

MBOX-Line: From slusarz at curecanti.org Tue Nov 1 22:02:40 2011
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun 8 12:34:47 2018
Subject: [Imap-protocol] Character encoding question
In-Reply-To: <4EB0C241.6060900@comaxis.com>
References: <4EB0C241.6060900@comaxis.com>
Message-ID: <20111101230240.Horde.I0QRQoF5lbhOsM7wX2WU_SA@bigworm.curecanti.org>
Quoting Jeff Mckay <jeff.mckay@comaxis.com>:
> I am dealing with a Sun Java imap server that seems a little screwy
> in regards to
> encoding certain non-English character strings - hopefully this is
> my problem but
> I'm not sure what is going on. Here are a couple examples of folder names
> from this server:
>
> visible in client: test/A hegyek h?val bor?tott
> encoded by imap: "test/A hegyek h&APM-val bor&AO0-tott\"
>
> visible in client: Temp/New??
> encoded by imap: "Temp/New&bUuL1Q-"
Both of those mailbox names look fine.
> In the first case, it is necessary to take the &AMP- part and base64
> decode it,
> then treat the result as modified UTF7.
I am assuming that you are intending to convert the IMAP server stored
mailbox name to a displayable representation on the client side. If
so, your description is incorrect. The mailbox name on the server
**is** modified UTF-7. Once you base64 decode (and remove the & and -
delimiters), the resulting mailbox string is now in the charset of the
MUA (e.g. UTF-8).
> In the second case, the base64 decode
> step is unnecessary, it is already in UTF7 format.
Mailbox names on the IMAP server are ALWAYS modified UTF-7. So not
sure what you mean by "unnecessary".
> So my question is, when do I do a base64 decode and when not?
Generally, IMHO, it will be easiest to work with mailbox names in the
native charset on the MUA side. So you only need to convert to/from
modified UTF-7 when either sending or parsing an IMAP command.
michael