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,布布扣,bubuko.com