当在 D2007 中编译的相同源代码生成带有正确命名为原始文件名的附件的电子邮件时，为什么我的 D2009 exe 会生成带有名为 ATTnnnnn.DAT 的附件的电子邮件？
我正在使用 D2007 和 D2009 附带的相应 Indy 库。附件中没有原始文件名会阻止用户双击附件打开它（通常附件是 Excel 电子表格）。
注意：代码是相同的——只是编译器和 Indy 库有所不同。D2009 exe发送的附件可以保存并重命名为zzzz.xls，然后正确打开-即电子邮件和附件正确通过-只是电子邮件附件文件名混乱。
有人建议附件标题已损坏。印地被破坏了吗？要复制的代码是可以在许多网站上找到的标准代码，但如果需要，我可以发布。提前谢谢。
我发现了问题 - 请参阅 adug.com.au 邮件列表了解解决方案的详细信息，但总的来说 - D2009 附带的 Indy 版本（版本 10.2.5）在 IdMessageClient.pas 中有 2 个错误单元在附件部分处理中设置 name= 和 filename= 的两行（一行是内存中的 1222，另一行是前几行；对不起，我现在在家；我今晚在工作中修好了东西）。缺少这些分号会导致附件标题格式错误，Outlook 会为附件生成自己的名称。
修复方法是在输出 name= 或 filename= 标记之前输出一个分号 ( ; )。然后印地需要重建。
我比较了 Indy (10.1.5) 的 D2007 版本，可以看到它总是将分号放在 Content-Type 行的末尾，从而避免了 D2009 包含的版本中出现的问题。
我建议更新到当前的 Tiburon 快照 ( http://indy.fulgan.com/ZIP )。Indy 版本现在是 10.5.7。
恐怕您可能只需要追溯到 indy 代码。Indy 过去有很多错误，所以这可能是原因。如果您跟踪，您应该很快就会找到它。
是否设置了 IdAttachment.Filename 属性？有可能在 Indy 版本之间他们改变了 Filename 的工作方式。
理查德的建议对我有用。我比较了正确附件的消息来源和 Indy 的消息来源。将分号放在 Content-type 和 Content-disposition 后面（确实在第 1220 行左右，它可以工作。谢谢理查德！