![具有长非 ASCII 文件名的 mutt 附件设置为“noname”](https://linux22.com/image/185414/%E5%85%B7%E6%9C%89%E9%95%BF%E9%9D%9E%20ASCII%20%E6%96%87%E4%BB%B6%E5%90%8D%E7%9A%84%20mutt%20%E9%99%84%E4%BB%B6%E8%AE%BE%E7%BD%AE%E4%B8%BA%E2%80%9Cnoname%E2%80%9D.png)
当我附加带有俄语名称的文件时,收件人收到了带有名称的附件noname
。我添加set rfc2047_parameters = yes
到 .muttrc,它开始适用于简单的文件名,例如Решение.doc
和тест тест.txt
。但是,当我附加一个具有长文件名的文件时:(Электронный документ, полученный из внешней системы.pdf
该文件仍然有效并且可以通过 Gmail 网络界面附加),它仍然noname
以从 mutt 发送时的文件名形式给出。
可以修复吗?
更新:区域设置结果:
$ locale
LANG=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
答案1
我相信这是旧版本中的一个已知错误mutt
,已于 2019 年 5 月修复提交 6898c083。这意味着该修复应该包含在 1.12.1 版本中。
我无法使用版本 2.0.3(撰写本文时的当前版本)重现您的问题,因此我假设该修复仍然有效。
问题是mutt
截断了长名称附件的文件名。对于多字节字符串,截断未正确完成,文件名的最后一个字符编码错误。当用户的电子邮件客户端注意到附件文件名的编码不正确时,它会用字符串 替换该名称noname
。
在 1.12.1 版本之后,您应该能够使用最多 255 个字符的文件名。