.Net开发者社区富文本编辑器太难用了，还是简书的编辑器好用，然后掘金的版面好看，最后还是喜欢cnblog里面可以修改版面css。
尽瞎说大实话。
重新码一份好看的。
出问题的地方
出现问题的函数：
//https://source.dot.net/#System.Net.Mail/System/Net/Mail/SmtpClient.cs,966//https://referencesource.microsoft.com/#System/net/System/Net/mail/SmtpClient.cs,892void SendMailCallback(IAsyncResult result) {
... //注意这个ServerSupportsEai，这个位置是allowUnicode参数
message.BeginSend(writer, DeliveryMethod != SmtpDeliveryMethod.Network,
ServerSupportsEai, new AsyncCallback(SendMessageCallback), result.AsyncState);
...
}
ServerSupportsEai所在位置为allowUnicode参数。SmtpClient中所有涉及到allowUnicode参数的地方，赋值都为IsUnicodeSupported()返回值。但唯一这一处是例外。
我们看看IsUnicodeSupported函数：
//https://referencesource.microsoft.com/#System/net/System/Net/mail/SmtpClient.cs,382private bool IsUnicodeSupported() { if (DeliveryMethod == SmtpDeliveryMethod.Network) { //注意看这里的ServerSupportsEai和SmtpDeliveryFormat
return (ServerSupportsEai (DeliveryFormat == SmtpDeliveryFormat.International));
} else { return (DeliveryFormat == SmtpDeliveryFormat.International);
}
}
DeliveryFormat我们可以赋值，我们来找找ServerSupportsEai是在哪里取值的：
//https://referencesource.microsoft.com/#System/net/System/Net/mail/smtpconnection.cs,280internal void ParseExtensions(string[] extensions) {
... //如果服务器支持SMTPUTF8，那么ServerSupportsEai=true
else if (String.Compare(extension, 0, SMTPUTF8, 0, 8, StringComparison.OrdinalIgnoreCase) == 0) {
((SmtpPooledStream)pooledStream).serverSupportsEai = true;
}
...
}
产生的现象
SendMailCallback是SmtpClient.SendAsync(SendMailAsync会调用SendAsync)调用的，so，异步操作已经完全不受我们设置的DeliveryFormat参数控制了，UTF-8内容(如中文)转不转码完全看对方邮件服务器心情!!!
SmtpClient对象DeliveryFormat属性赋值为SmtpDeliveryFormat.SevenBit，要求邮件使用 7 位 ASCII 的传递格式，并且用异步方法来发送;本来Subject、附件文件名等里面的UTF-8内容(如中文)将会被转码;但如果邮件服务器EHLO返回了SMTPUTF8，那么SmtpClient对象将会将UTF-8内容不转码直接发送出去!导致发送出去的数据内容和预期的数据内容不一致!!!
同步方法Send不受此影响。
解决办法
SendMailCallback函数中的ServerSupportsEai应该换成统一的IsUnicodeSupported，Bug就解决。
受影响版本
.Net Framework 4.5 - 4.7.2(最新版)，估计是全系列
.Net Core 看最新版也是受此影响
一次.Net框架Bug的发现记录
DKIM签名功能写好后测试了很多个邮箱，都能通过验证。但隔一天测试却发现没有一个邮箱通过验证，并且下载下来的邮件源码body部分和本地额外保存的一份有很大出入，表现在邮件主题、附件文件名，本地是Base64编码，下载下来的是中文汉字。
首先发现问题的是outlook邮箱，他们家会告诉你DKIM签名是否正确，本地直接发送邮件没有一个通过签名验证的，但通过邮箱服务器发送却都是好的。对比直发和服务器发的邮件源码区别，发现邮箱服务器的没有中文，直发的里面中文的地方全是中文。
看样子中文部分有问题，然后试着把邮件里面的中文全部换成英文，发送，又可以了!想了一下昨天测试好像全部是英文，因为邮件内容写了一次基本上就不会改了。
到了这时候，感觉还以为是outlook服务器进行了什么处理，难道邮箱服务器发邮件用的协议和我们用Smtp协议发邮件的协议有出入?但并没有找到什么相关的资料。然后测试了QQ邮箱、网易yeah.net，并且抓了一下包看了一下，发现切换SmtpClient.DeliveryFormat参数，使用SevenBit(此值为默认值)(中文会被编码)QQ邮箱没问题，网易有问题;使用International(中文不编码)QQ邮箱有问题，网易反倒没问题。
抓包发现使用SevenBit时，中文部分给QQ邮箱发送的是Base64编码，给网易发送的是中文内容，本地保存的是Base64编码(和签名时使用到的邮件内容一致);使用International时正好相反。签名的数据和发送的数据不一致，导致了不管怎么改这个参数，都有一个是错的。
为什么会这样?查阅.Net源码，一路看编码部分，发现基本上每个涉及到字符编码、发送的地方都会传入allowUnicode参数，所有allowUnicode = SmtpClient.IsUnicodeSupported()，但有唯一的一处例外：
[此处忽略，见上文]
SendMailCallback是SmtpClient.SendAsync(SendMailAsync会调用SendAsync)调用的，so，异步操作已经完全不受我们设置的DeliveryFormat参数控制了，中文转不转码完全看对方邮件服务器心情!!!函数中的ServerSupportsEai应该换成统一的IsUnicodeSupported，Bug就解决。
但，我们没法去改这个地方，那么上Hook吧，把SmtpClient.ServerSupportsEaiHook一下，如果是SendMailCallback调用的就return IsUnicodeSupported()。
但，DotNetDetour库可以Hook String.Length属性，但没法HookSmtpClient.ServerSupportsEai属性，不知道啥原因。最后调试烦了放弃了。
结尾使用SmtpClient.Send没有这种问题，就把异步操作全部换成了同步，代码还少了不少。Bug修理完毕，给outlook、QQ、网易发英文、中文邮件都能通过DKIM签名验证。
联系客服
