Re: Character set validation (with patch)
Hi Rocco,
On Friday, December 14, 2007 at 19:46:47 +0100, Rocco Rutte wrote:
> I used mutt_iconv_open() as fallback which executes iconv-hooks, so
> maybe this patch should use the same trick in general?
And mutt_iconv_open() also canonicalizes charset names before
anything else, so there should be no more reason to check the
PreferredMIMENames[] table yourself. flags=0 to not execute
charset-hooks. Yes, it seems a good idea.
Additionally to $*charset vars, you could also validate the target
(2nd parameter) of charset-hook commands in the exact same way.
The target of iconv-hooks is more specific: It must be directly
known by iconv. Validation could use a similar method, but using
iconv_open() instead of mutt_iconv_open(). Such validation would have
warned the user migrating muttrc from Solaris to Linux as in flea/2990.
> That way the example would still work as the -i variant would get
> mapped to 8859-8 because of the hook.
That would depend on the order of commands in muttrc: That's a
little bit annoying, but once documented I think that should be OK.
> issues exist with //TRANSLIT mutt shouldn't send out
Indeed, "//.*$" should be filtred out from label upon sending.
Setting //TRANSLIT or //IGNORE explicitly in $charset and $send_charset
should be allowed, used for mail conversion, but not for the MIME label.
Those suffixes are a library-specific kludge very likely to confuse
other platforms.
> If you enter something like "set charset=foobar", it can cause strange
> and undesired behaviour at some places in mutt.
Yes. But sometimes it's wanted, to voluntarily activate pass-thru
mode. An unknown $charset to stop all conversions. Or more specific an
unknown target for a charset-hook, to stop conversions from a given
charset. That feature is quite usefull, and should be retained, perhaps
by allowing a special keyword (pass-thru, pass-through, noconv, ???) to
this effect.
Well, iconv given such keyword does what's expected: Silently fail.
The idn code will still protest, and something should be done. I don't
know what, but recall that Thomas exposed an idea here, as followup to
one of the "Bad IDN" reports.
Validation will at least avoid unexpected pass-thru and "Bad IDN"
due to simple typos, and that's already a good thing.
Bye! Alain.
--
« Be liberal in what you accept, and conservative in what you send. »
Jon Postel / Robustness Principle / RFC 1122