退而求其次解决.NET4.0发送邮件,附件名字过长会导致附件文件名乱码或后缀名变为.BIN

IDE:Visual Studio 2010[C#] + .NET 4.0框架
引用.NET 4.0框架的System.Net.Mail命名空间开发发送邮件[附件]
发现附件文件名长了,就会出现乱码问题
至于长到什么程度才会乱码,当时不得而知
百度一下,.net.mail 乱码,只有一条微软MSDN社区的网页标题与乱码的情况描述相吻合
标题为《.net framework4.0发送邮件,如果附件名字过长会导致附件乱码》,后来又找到一篇微软技术支持的知识库文章[http://support.microsoft.com/kb/2402064/en-us],看样子找到救星了
逐一对照我是否符合微软技术支持页描述的情形:
1.You run an application that is compiled for the Microsoft .NET Framework 4.---是的,我运行的应用程序被编译为 Microsoft.NET Framework 4。
2.The application calls the System.Net.SmtpClient class to send an email message and uses the Attachment class to attach files to a MailMessage object.---是的,应用程序调用System.Net.SmtpClient类发送一封电子邮件,且调用附件类把文件附加在MailMessage对象。
3.The attachment name contains non-ASCII characters and is longer than 41 UTF-8 encoded bytes.---附件文件名包含非 ASCII 字符,UTF-8编码且长度超过41个字节)。注:UTF-8编码下,1个汉字 = 3个字节。准备对该项进行测试,以确定我遇到的乱码问题是否与微软描述的这三种情形完全吻合。
于是,我对微软描述的这种情形作了进一步的测试[测试发送方:QQ邮箱、测试接收方:163邮箱]。测试结果发现,UTF-8编码下未超过41个字节的附件文件名,发送后发送方QQ邮箱[已发送]中就会正常显示附件文件名,接收方163邮箱[收件箱]中也会正常显示附件文件名;而UTF-8编码下超过41个字节的附件文件名,发送后发送方QQ邮箱[已发送]中的附件文件名就会显示乱码,接收方163邮箱[收件箱]中会将收到的附件文件名显示为“ATT0004.BIN、ATT0005.BIN”等字样,即解码不正确。将其下载下来把文件后缀名改成之前正确的后缀名,仍无法正常阅读其中的内容。
这三种情形与微软描述的三种情形完全吻合。这说明,微软已知晓该问题并认为该问题是.NET 4.0框架的一个BUG。
在微软关于该问题的知识库文章中,RESOLUTION中有修复该问题的Hotfix[Hotfix网页链接:https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=31723]。
下载后,XP下安装该Hotfix被微软告知该Hotfix不适用,安装未成功。想必是系统问题。想到,为了一个Hotfix,不至于重新安装操作系统。因.NET 4.0以下的几个框架也有System.Net.Mail命名空间,故退而求其次,下载安装了.NET 3.5框架,将该程序编译为.NET 3.5框架下的程序。这时,再次发送邮件后,发送方QQ邮箱[已发送]中的附件文件名均可正常显示,没有了乱码情况;而接收方163邮箱[收件箱]中也均可正常显示,不会显示为“ATT0004.BIN、ATT0005.BIN”等字样了。

当然了,如果系统没问题安装成功上述Hotfix,是最好不过的了。

退而求其次解决.NET4.0发送邮件,附件名字过长会导致附件文件名乱码或后缀名变为.BIN,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。