RomM项目中的iOS Safari下载文件名编码问题解析

在RomM 3.8.1版本中，用户报告了一个关于iOS设备上通过Safari浏览器下载ROM文件时出现的文件名编码问题。本文将深入分析这一问题的技术背景、解决方案及其实现原理。

问题现象

当用户在iOS设备上通过Safari浏览器下载包含空格或括号等特殊字符的文件名时，下载的文件名会保留URL编码形式（如%20代表空格，%28代表左括号等）。而在桌面浏览器上，同样的下载操作却能正确显示解码后的文件名。

例如，文件"Advance Wars (USA) (Rev 1).zip"在桌面浏览器下载时显示正常，但在iOS Safari上却显示为"Advance%20Wars%20%28USA%29%20%28Rev%201%29.zip"。

技术背景分析

这一问题源于HTTP协议中Content-Disposition头部的处理方式差异。Content-Disposition头部用于指定如何处理响应内容，当值为"attachment"时表示应作为附件下载，并可指定文件名。

传统上，文件名直接放在Content-Disposition头部的filename参数中。然而，当文件名包含非ASCII字符或特殊字符时，不同浏览器对编码的处理方式存在差异：

1. 现代浏览器通常能正确处理URL编码的文件名
2. iOS Safari等浏览器会保留编码形式而不自动解码
3. 某些浏览器对特殊字符集的支持有限

解决方案

经过技术分析，开发团队采用了符合RFC 6266标准的解决方案：同时提供两种文件名指定方式：

1. 传统的filename参数作为向后兼容
2. 新增filename*参数支持UTF-8编码

具体实现是在后端响应中添加如下格式的Content-Disposition头部：

Content-Disposition: attachment; filename*=UTF-8''encoded_filename; filename="fallback_filename"

这种双重指定方式确保了：

• 支持新标准的浏览器会优先使用UTF-8解码的filename*
• 旧版浏览器会回退到传统的filename参数
• 特殊字符在不同平台都能正确显示

实现细节

在RomM的后端代码中，这一修改主要涉及rom.py文件中的文件下载响应部分。开发团队将原来的简单引用：

"Content-Disposition": f'attachment; filename="{quote(file.file_name)}"'

升级为符合RFC标准的双重引用格式：

"Content-Disposition": f'attachment; filename*=UTF-8\'\'{quote(file.file_name)}; filename="{quote(file.file_name)}"'

这一改动虽然简单，但有效解决了跨平台文件名显示不一致的问题，同时保持了对各种字符集的良好支持。

兼容性测试

在解决方案实施后，团队进行了全面的兼容性测试：

1. iOS Safari：正确显示解码后的文件名
2. iOS Firefox：同样基于WebKit内核，问题得到解决
3. iOS Chrome：原本就能正确处理，不受影响
4. 桌面浏览器：保持原有良好表现
5. 非ASCII字符文件名：如日文文件名也能正确显示

版本更新

此修复已包含在RomM 3.8.2版本中发布。用户升级后即可在所有平台上获得一致的文件名显示体验。

这一问题的解决展示了RomM团队对跨平台兼容性的重视，也体现了HTTP标准在解决实际问题中的重要性。通过遵循RFC标准而非针对特定浏览器做特殊处理，确保了解决方案的长期稳定性和广泛适用性。