There is a partial solution and a full solution. The full solution comprises the two fixes that are the highest priority issues anyway: enhancing Herme to display Unicode and enabling it to forward messages without corrupting them. (There is nothing special needed to eliminate these two infelicities; they will simply disappear once these enhancements are completed.)
The partial solution would be to make special cases for some of the characters that give rise to these awkward intrusions. I would especially like to do that for the non-breaking space (which gets displayed as 'Â'). We can do this simply by converting it to a standard space. This would mean it would still be displayed inappropriately in some contexts (giving rise to an unwanted end-of-line) but, on the whole, the behaviour would, I think, be much preferable. And there may be similar conversions that we can do for a few other characters. The good news is that this partial solution should be easily implemented once we get a complete working build of the main executable made -- and we are working hard on this. The full solution will take longer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any solution to the extra characters that occur when both receiving and forwarding email in Eudora 7.1?
Often they at capital A with a caret and followed by question marks.
ie: Wednesday or Pro Men’s or  ??
There is a partial solution and a full solution. The full solution comprises the two fixes that are the highest priority issues anyway: enhancing Herme to display Unicode and enabling it to forward messages without corrupting them. (There is nothing special needed to eliminate these two infelicities; they will simply disappear once these enhancements are completed.)
The partial solution would be to make special cases for some of the characters that give rise to these awkward intrusions. I would especially like to do that for the non-breaking space (which gets displayed as 'Â'). We can do this simply by converting it to a standard space. This would mean it would still be displayed inappropriately in some contexts (giving rise to an unwanted end-of-line) but, on the whole, the behaviour would, I think, be much preferable. And there may be similar conversions that we can do for a few other characters. The good news is that this partial solution should be easily implemented once we get a complete working build of the main executable made -- and we are working hard on this. The full solution will take longer.