HTML无法防止特殊字符文件上传，accept属性仅提示性过滤，用户可绕过；前端JS应校验文件名后缀和路径，后端必须通过魔数、白名单MIME及内容解析进行最终校验。
HTML 本身无法防止上传带特殊字符的文件——浏览器允许任何合法文件名（包括空格、中文、emoji、括号、点号等）通过 <input type="file"> 提交，这是符合标准的行为。真正要拦的不是“特殊字符”，而是**恶意文件类型或构造异常的文件名**；前端能做的只是提示和初步过滤，所有关键校验必须落在后端。
accept 属性只影响文件选择框，不阻止提交
设置 accept=".jpg,.png" 或 accept="image/*" 后，用户在弹出的选择对话框里默认只看到匹配类型的文件，但：
• 用户可点击“全部文件”强行选中 shell.php.txt 或 malware.exe
• 文件名含 ../、:.exe、test<script>.html</script> 等仍能被选中并提交
• accept 对 fetch() + FormData 构造的上传完全无效
• 它不校验实际内容，report.pdf 可能是伪装的 PE 文件
前端校验文件名需提取扩展名并转小写
若需在提交前拦截明显异常的文件名（如双后缀、控制字符、路径遍历），应监听 change 事件，用 JavaScript 处理 file.name：
• 不要用 file.type 判断类型——它由浏览器根据扩展名或 MIME 推测，极易伪造
• 正确做法：用 file.name.toLowerCase().split('.').pop() 提取后缀，再比对白名单
• 要过滤掉空后缀、含 / \ : .. 的文件名，例如："payload.html%00.jpg" 或 "a/b/c.php"
• 注意：移动端可能返回空 file.name，需 fallback 到 file.webkitRelativePath 或直接放行并依赖后端
后端必须重做全部校验，且不能只信扩展名
前端任何检查都可被绕过，后端才是唯一可信防线：
• 检查原始文件名：剥离路径、标准化编码（如 UTF-8 Normalization），拒绝含 ../、空字节、控制字符的名称
• 校验文件头（Magic Bytes）：读取前几百字节，确认真实类型是否匹配扩展名（如 PNG 文件开头必须是 89 50 4E 47）
• 使用白名单 MIME 类型：只允许 image/jpeg、application/pdf 等，禁用 text/html、application/x-php
• 扫描病毒（尤其面向公众的上传服务）
• 存储时强制重命名：去掉原始文件名，用 UUID + 安全扩展名（如 abc123.jpg），存到非 Web 目录
立即学习“前端免费学习笔记（深入）”；
最容易被忽略的一点：即使文件名和 MIME 都“看起来安全”，攻击者仍可能上传一个合法图片，但在 EXIF 注释区嵌入 PHP 代码或 XSS payload——这类风险只能靠内容解析或沙箱检测覆盖，前端 accept 和简单后缀检查对此完全无感。
