Greasy Fork镜像

标题含有zwj类型的emoji在下载后文件名会分解成独立的emoji

浏览器的默认行为，特殊字符可能导致兼容性/安全问题，所以连字符zwj会被替换为_。脚本中使用远程下载貌似可以支持零宽连字符。

下面是gpt的回答

回答1：

你的文件名里用了 ZWJ（Zero Width Joiner，零宽连字符） 来把 👨 和 🚀 组合成 👨‍🚀。

在 HTML/JS 里 👨‍🚀 确实是一个单独的 emoji。

但是 Windows 文件系统（NTFS）对某些 Unicode 控制字符（如 ZWJ）不完全支持，Chrome 在调用系统保存文件时，会把这个字符「安全化」——结果就是把 👨‍🚀 拆成了 👨🚀。

所以你看到的 我的文件-👨🚀.txt 就是这种情况。

回答2：

那为何我保存的时候在文件名输入框中手动输入👨‍🚀 又生效呢？

ChatGPT 说：

这个问题很关键 👍 你发现：

• 代码里设置 download 属性 → Chrome 会把 👨‍🚀 转成 👨_🚀。
• 你手动输入文件名时 → 👨‍🚀 就能正常保存。

看似矛盾，其实原因在于 谁来做校验：

---

1. 你手动输入时

• Windows 的文件系统（NTFS）本身并不禁止大多数 emoji（甚至含 ZWJ 的合成符号）。
• 所以当你输入 👨‍🚀 并点保存时，Chrome 不会修改，直接交给系统保存 → 系统接受 → 成功。

---

2. JavaScript 设置 a.download 时

• Chrome 内部有一层「安全过滤」，会检查文件名里是否有控制字符或特殊符号。
• ZWJ (\u200D) 属于 控制类字符，Chrome 认为它可能导致兼容性/安全问题。
• 所以 Chrome 在把 download 的 filename 传给系统之前，会替换掉不安全字符。
• 替换策略就是把 ZWJ → _，导致 👨‍🚀 变成 👨_🚀。

也就是说： 👉 手动输入是 你绕过了 Chrome 的过滤，直接交给 Windows； 👉 代码触发下载时，Chrome 先帮你「清洗」了一遍。

---

3. 这其实是 Chrome 的「特意行为」

我查过 Chromium 的 bug 记录（记得之前有人提过类似问题）：

• Chrome 在处理 download 属性时，会走一个 sanitizeFilename 的流程。
• 这个流程会去掉/替换掉它认为「不安全」的 Unicode 字符，比如：
  • ZWJ (U+200D)
  • RTL/LTR 标记符 (U+200E / U+200F)
  • 一些控制字符

---

✅ 总结：

• 手动输入成功：因为系统本身支持，没被 Chrome 拦。
• JS 触发失败：因为 Chrome 自己做了「预防性过滤」。