input[type="file"]不处理文件名编码，中文名上传失败需后端从content-disposition的filename*字段按rfc 5987解析并解码，web服务器、框架、代码三者缺一不可。
input[type="file"] 本身不处理文件名编码，中文名上传失败通常不是前端能单方面解决的问题——后端接收逻辑、HTTP 协议限制、Web 服务器配置三者共同决定是否能正确还原原始中文文件名。
为什么 input[type="file"] 选了中文名，后端却收到乱码或问号
浏览器在提交表单时，对 filename 字段的编码行为不统一：
- Chrome / Edge（基于 Chromium）：默认用 UTF-8 编码文件名，并在
Content-Disposition头中添加filename*=UTF-8''...形式（RFC 5987），这是标准且可解析的 - Safari（macOS/iOS）：部分版本仍用系统默认编码（如 macOS 的 UTF-8，但旧版可能 fallback 到 Latin-1），且不一定发
filename* - Firefox：行为较接近 Chrome，但低版本存在兼容性问题
- 关键点：
filename（无星号）字段永远是 ASCII 安全的，浏览器会把它强制转成乱码或截断；真正承载中文的是filename*字段，后端必须主动读取它
后端必须检查的三个地方
即使前端 form 写对了，后端漏掉任一环节都会导致中文名丢失：
- Web 服务器（Nginx/Apache）不能过滤或重写
Content-Disposition头——尤其 Nginx 默认会 strip 非 ASCII header，需确认没配underscores_in_headers on;或类似干扰规则 - 应用框架是否解析
filename*：Express +multer默认支持；Python Flask +werkzeug2.0+ 支持；PHP$_FILES数组**完全不提供filename*解析**，必须手动从原始请求头里提取并解码 - 后端代码是否调用了正确的解码函数：不能直接用
urldecode()或utf8_decode()；RFC 5987 要求先提取filename*=charset'lang'value中的value，再按指定charset（通常是UTF-8）做 percent-decode。例如 Node.js 中可用decodeURIComponent(escape(value))（注意双层转义），Python 中用urllib.parse.unquote(value, encoding=charset)
form 和 input 本身要怎么写
不需要特殊属性，但有硬性前提：
- HTML 文件自身必须是 UTF-8（无 BOM），且声明
<meta charset="UTF-8">在最开头 -
form标签**不要**加accept-charset——这个属性对文件上传无效，且可能干扰其他字段编码 - 确保整个请求走 HTTP POST（不是 GET），且
enctype是"multipart/form-data"（这是默认值，显式写上更稳妥） - 示例最小可行结构：
最常被忽略的细节：开发环境 vs 生产环境差异
本地测试时容易“恰好正常”，上线就崩，原因往往是：
- 本地用
file://直接打开 HTML：此时没有 HTTP 协议栈，filename*根本不会生成，所有浏览器都 fallback 到乱码 —— 必须通过http://localhost启服务测试 - 后端部署在反向代理后（如 Nginx → Node.js）：Nginx 默认不透传原始 header，需在 location 块中加
proxy_pass_request_headers on;，否则filename*被吃掉 - CDN 或 WAF（如 Cloudflare）：某些配置会清洗 multipart 请求头，需确认其是否保留
Content-Disposition
真正卡住人的从来不是“怎么让浏览器发中文名”，而是后端有没有能力从一堆兼容性补丁里稳定提取出那个 filename*=UTF-8''%E4%BD%A0%E5%A5%BD.txt 字段，并正确 decode 成 你好.txt —— 这个环节一旦出错，前端再怎么写都白搭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
