EdgeOne Pages中文路径 404 故障排查与迁移实践

昨晚宿舍挂壁^[1]，关于这间宿舍的硬件条件，槽点实在太多，这里先不讲。

Chrome 中打开 Blog， 回忆《沙东往事》^[2]。发现好几篇旧文直接 404。

经过一番排查后发现了规律：凡是路径中包含中文字符的文件名，访问时全部 404；而纯英文路径则表现完全正常。

作为对照组，Cloudflare Pages 上都是可正常访问的。大概率不是我的问题。

于是在微信交流群里反馈了该情况，获得了 0 个人的搭理。

找官网客服提交工单才是正确姿势。经过与技术支持的沟通，确认这是 EdgeOne 后端的一个 Bug，预计会在下一个版本中修复。具体的发版修复进度会在微信群通知。

考虑到发版周期不确定，我不打算原地等死，决定先搞个权宜之计（Workaround）。以下是对此次迁移修复过程的记录。

问题背景

我的 Blog 构建产物结构非常简单：

以琅琊台 这篇文章为例，对应的访问路径就是，https://vluv.space/琅琊台 或https://vluv.space/琅琊台/index.html

A Interlude 🎞️

更早之前，EdgeOne 某次更新后，所有文章都 404，因为它不再支持省略 index.html。

当时我写了个 edgeone.json 做 workaround，不过官方很快就释出了 hotfix，我以为万事大吉就把配置文件删了

不曾想，这次中文路径又翻车了，hh

Migration Solution

迁移的核心逻辑分为 3 步：

1. 重命名：将所有包含非 ASCII（中文）的文件名翻译成纯英文。
2. 配置重定向：在 edgeone.json 中配置 301 永久重定向，确保旧链接不失效。
3. 更新 Wiki Link: Obsidian 用户可能会使用双链，修改文件名之后原先的双链就失效了，也要进行处理

虽然手动操作很麻烦，但借助 AI 可以高效完成。

A Pitfall 🕳

EdgeOne Pages 的 redirects.source 仅支持 ASCII 字符，这意味着中文路径必须先进行 URL 编码（Percent Encoding），否则部署校验会报错：

17:22:23.099> Start validating the configuration file:17:22:23.105error in root.redirects.[0].source: char match error17:22:23.105error in root.redirects.[1].source: char match error17:22:23.106error in root.redirects.[2].source: char match error17:22:23.106error in root.redirects.[3].source: char match error

Prompts

现在 LLM 的能力都不错，直接备份 Prompt 想必比一个 outdated 的脚本更实用

**任务描述**  基于 EdgeOne Pages 的 edgeone.json 规范（redirects.source 仅支持 ASCII），完成以下任务：**子任务一：生成路径映射文件**  将所有包含非 ASCII 字符的旧文件名翻译为英文，生成 JSON 映射：  { "旧文件名": "new-english-path" }**子任务二：生成 edgeone.json**  基于映射文件，输出符合格式的 edgeone.json：codeJSON```{  "redirects": [    {      "source": "/%E4%B8%AD%E6%96%87",       "destination": "/new-english-path/",      "statusCode": 301    }  ]}```注：source 必须经过 URL 编码。

@filename_translation_map.json 查找 @blog/ 目录下有无[[old_file_name存在，如果有，替换成 [[new_file_name

Why Bother?

为什么费这个劲呢，主要是考量下面几点因素：

1. 用户体验：防止已收录的链接失效，确保从搜索结果点击进来的用户不会看到 404。
2. SEO：如果大量旧链接直接 404，站点会被搜索引擎逐步降权（Deindex），阿宾的 SEO 成绩并不理想

耽误一些水毕设论文的时间，不过又水了一篇 Blog，我发现了水文守恒定律 🤓

聊到毕设，又想吐槽 Microsoft Word 了，也先不讲了，恐怕篇幅过长。