That is right. On the other hand, you never prevent malformed MIME
parameters.
Remember that we're not talking about malformed MIME parameters; we're
talking about entirely valid ones.
It is not a problem in case of one or two missing or substituted
symbols in long text. We can guess what is the me?ning of the word.
For many non-convertible symbols reading of such a text is more
similar to solving a crossword puzzle. What could be '??o??w??d'
I understand that, but my answer is basically: yes, it's non-reversible.
So what? Note that the original data is still in the email if the user
wishes to example it directly.
We're talking about things that are being presented to a user, or
something that ends up as a filename (for filenames, I wasn't thinking
of using ? as a replacement character, but that's a minor detail).
It's not clear to me from your response what you think should be done
in these cases: should we simply not use the MIME parameter at all?
Somehow that seems like wrong choice. Jerrad mentioned the Recode
library, but it doesn't seem like something that I'm interested in
using. Skipping over the offending character is an option as well, but
still seems lousy.
I understand your point about it being difficult to figure out what the
original text is, but I am trying to understand exactly WHAT should be
done. Just rejecting the text out of hand seems to be a much worse
solution. As you say, if there is confusion the user can go to the original
mail, but to me that's an argument for giving the user at least something
that they might be able to understand.
FWIW, I wanted to see what other MUAs do, so I decided to look at mutt;
if iconv() fails and the target character set is UTF-8, it substitutes
U+FFFD, otherwise it substitutes '?'.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers