MimeKit.InternetAddress.TryParseMailbox fails with unknown CodePage about mimekit

[ziahamza]

Should it be considered a bug as this could be properly handled in the TryParseMailbox

[jstedfast]

Yea, this is a bug... I'll look into it.

[jstedfast]

Mono supports cp936 (aka gb2312) and cp54936 (aka gb18030), but, as you noted, does not support cp51936 (aka euc-cn) nor cp52936 (aka hz-gb-2312).

So... what to do?

You probably know more about this than I do... so, if 51936 doesn't exist on the system, should it try falling back to 936? Or should it try 54936? or will neither of those work as a fallback?

Same for 52936... how should that fall back?

[ziahamza]

I personally dont have experience in chinese. I happen to live in Hong Kong so I regularly get mails in this encoding. I guess falling back to 936 seems like the correct choice to do until mono gets full support for those encodings, and I think it should work for most characters.

[ziahamza]

But thats a guess from my side as I cant read chinese

[ziahamza]

firefox apparently fall backs to gb18030 which was then reported as a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=844082

[ziahamza]

and they plan to change it to GBK (gb2312) which is also what you propose.

[jstedfast]

Awesome discovery, thanks!

[ziahamza]

should it be pushed back in the mono runtime or just a fix in MimeKit? Other programs could benifit automatically if its pushed upstream

[jstedfast]

Well, System.Text.Encoding doesn't make any guarantees about what encodings it supports, so I don't think it's necessarily something that should be pushed down into Mono.

The TryParseMailbox() code should not have assumed that the codepage it got existed (although it should generally be safe to make that assumption...), so I added a try/catch around it. The encoding, at that point, is only needed to set on the MailboxAddress anyway.

I also fixed up CharsetUtils's charset mapping tables (this is how TryParseMailbox() got the correct codepage even when the system didn't support it).