Hi Eduard! Thanks for your feedback!
> Works almost, unfortunately it shows a typical problem with unhandled > iconv errors - if the charset is unknown, parts of lines are not > displayed after non-ascii chars. Well, of course this is really a bug in the sender's client, but I guess the behaviour as you suggest below, should be quite easy to implement: > I have not looked at the source yet, > but usualy there the complicated part begins. The simple solution would > be trying to continue with the next chars, ie. not displaying the > unconvertable chars. Yes, this is probably the nicest way of handling it. Hmm, looking at my patch again, I see now that I don't check the return value of the actual iconv() call at all... Should be easy enough to wrap it in a loop and handle all errors by just ignoring the failing chars. I'll fix up a new patch as soon as I've got some time. > I would try to convert to latin1 first, or try to > get a "most likely charset" mapping table from some program that does > automatic guessing already. Hmm, why not just fall back to ASCII? Of all the charsets, that should be the one most generally supported. Automatic guessing is probably quite hard to do in a somewhat reliable way. > Or just allow the user to specify a "fallback charset" via a config > settings, since most users know what they can expect from stupid > posters, eg. in middle europe you can expect windows'e @euro > encoding. That would also be nice, but one would probably want to be able to set the fallback on a per-group or per-hierarchy basis. -- Kind regards, +--------------------------------------------------------------------+ | Bas Zoetekouw | GPG key: 0644fab7 | |----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | +--------------------------------------------------------------------+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
