Blog

The following is a post I made to the Poptray user/developer forum message board on August 20, 2008. I am archiving a copy of my message on my blog as well for historical purposes.

I have taken a look at the source code for PopTray and the RFC spec on email headers, and I believe the subject encoding problem is one that could easily be resolved without waiting for Indy components to do character set conversion. (I don’t actually have a Delphi compiler set up to write and test a patch, but here’s an outline of the proposal for a solution I’ve come up with so far:

In uMain.pas, there is a procedure ShowMailMessage(…). In particular, on line 1295, there is a line:
SubItems.Add(Accounts[num-1].Mail[i].Subject);
I believe at this point you need to “translate” the subject. The subject is interpreted by the Indy components as Ansi, which is correct based on the email header RFC. However, there’s some stuff that was added as an after-thought for how to accomodate international subjects in headers that only ascii is allowed in. So we can “undo” or fix the subject line at this point.
Maybe that line becomes:
SubItems.Add(FixEncoding(Accounts[num-1].Mail[i].Subject));
and you add a new procedure FixEncoding(subject:string) : string
that will “fix” the subject encoding into something more human readable.

According to the RFC, the format for specifying a non-ansi subject is:
“=?” charset “?” encoding “?” encoded-text “?=”
This should be simple enough format to tokenize using standard string tokenizing libraries. if the string does not follow this pattern, return the string as is. Otherwise, we have to process it and fix its encoding.

Encoding is either “Q” for Quoted-Printable or “B” for Base64. Those are the only two options, so not too complicated there, other than locating or creating a library function to decode those two encodings. Base64 allows for longer subjects with foriegn characters, but its not human readable, whereas quoted printable only changes spaces and non-ascii characters using escape codes. I haven’t researched this yet, but I would imagine a library or example code for how to decode Base64 and Quoted-Printable back to “normal text” is not difficult to find.

Charset slightly more complicated, in that there’s a larger list of choices that are possible. I don’t know how good Delphi’s built in support for doing charset conversion is, I’ve only done them in C++ and Java. In C++ everything had to be converted to Unicode instead of UTF-8 and displayed as “wide strings” which is a little weird at first, but doable, though it required a few format strings with %S conversions to change from ansi-unicode and vice versa. In Java its as simple as passing the string and a string with its encoding to a special library function and it auto-magically swaps the encoding. But if its particularly complicated, even just adding support for the most common one, UTF-8, would very much benefit users of pop-tray. UTF-8 to Unicode is a relatively simple conversion even if you have to code it manully. Getting the list component to display wide strings rather than ansi strings may be automatic, or might require a minor change somewhere, not sure.

I hope that is helpful! I’d be happy to discuss implementing this feature farther or do some more research if one of these steps turns out to be a hang-up…its a feature I’d very much like to see!