Keith Moore writes:
if there's no good way to save state (like the original header fields)
unchanged across that edit, so that the encoder has the ability to
tell whether the human user changed those fields from those
originally specified, then I can understand the difficulty.
Of course there are such ways.
If I were writing an MUA that used such an arrangement for editing
header fields I'd try to find some way to save that state and make it
available to the encoder - perhaps by using hidden fields that the
human can't change, or by storing the original state in a parent
process and having the editor run in a subprocess, or something.
Sure. I've been down that road myself. Not once, but twice. My
decode2047() was liberal, and my encode2047() was conservative, and I
found myself in a position where the code would nevertheless generate
monstrosities like "Re: =?latin_1?q?=80?=' (which should be "Re:
=?iso-8859-15?q?=A4?=" but can be decoded).
After spending a few hours trying to rewrite the decoder such that I
could know whether the raw text was something a conservative encoder
could make, I decided that the result wasn't worth the complexity.
I can understand why a lot of people don't even start down that road.
--Arnt