处理非英文文件名时。
问题是我的程序无法保证这些目录和文件名是英文的，如果某些使用日文，中文字符的文件名会显示某些字符，如'？'。
任何人都可以建议我需要访问非英文文件名
答案 0 :(得分：3)
问题是我的程序无法保证这些目录和文件名是英文的。如果文件名使用日语，则中文字符 将显示某些字符，如“？”。
问题显然是“它”使用错误的字符集来显示文件名。解决方案取决于“it”是您的程序（通过GUI），某些其他应用程序，命令shell /终端模拟器还是用户的Web浏览器。如果您可以提供更多信息，也许我可以提供一些建议。
但将角色转换为下划线很可能是一个糟糕的解决方案。它容易导致文件名冲突，并且那些中文/日文/等字符最有可能对创建文件的人有意义。
顺便说一句，“英文”字母的正确用语是拉丁语。
修改
对于您的用例，您不要使用与提供的文件名有任何关系的文件名来存储PDF文件。我建议您尝试使用由（例如）currentTimeInMillis()生成的拉丁数字和字母组成的文件名来解决问题。如果失败了，那么你真正的问题根本就与文件名无关。
编辑2
你问的是声明
if (fileName.startsWith("=?iso-8859"))
这似乎是试图以MIME encoded-word格式取消文件名;见RFC 2047 Section 2
首先，我认为代码可能是不必要的。 javadoc不是特定的，但我认为Part.getFilename()方法应该处理文件名的解码。
其次，如果解码是必要的，那么你会以错误的方式解决它。 charset之后的东西不能简单地被视为文件名的值。看看RFC。
第三，如果您需要，您应该使用相关的MimeUtility方法来解码“word”令牌...就像文件名一样。
第四，ISO-8859-1不适合非拉丁字符集中的字符。
最后，检查您尝试解码的电子邮件的原始电子邮件标头，并查找开始的标题行
Content-Disposition: attachment; filename=...
如果文件名看起来像“=？iso-8859-1？...”，并且文件名应该包含japanese / chinese / etc字符，则问题出在构建该文件的客户端（或其他）中电子邮件。字符集必须是“utf-8”或其他多字节字符集之一。
答案 1 :(得分：2)
Java本身使用Unicode - 您不需要替换特殊字符，因为Unicode 没有特殊字符 - 每个代码点都被平等对待。你的replaceSpChars()可能是罪魁祸首。