Last night I was in full guabi^[1] mode in the dorm. There are too many things to complain about in this dorm’s hardware setup, so I will skip that for now.

I opened the Blog in Chrome and was reminiscing about Shadong Wangshi^[2]. Then I found that several older posts went straight to 404.

After some troubleshooting, the pattern became clear: every filename whose path contained Chinese characters returned 404, while pure English paths worked normally.

As a control group, the same pages were accessible on Cloudflare Pages. This was probably not my problem.

So I reported it in the WeChat group, and exactly 0 people responded.

Submitting a support ticket to the official customer service channel was the right move. After talking with technical support, I confirmed that this was a backend bug in EdgeOne and was expected to be fixed in the next version. The detailed release progress would be announced in the WeChat group.

Because the release cycle was uncertain, I did not plan to sit there and wait. I decided to make a temporary workaround first. This post records that migration and repair process.

Problem Background

My Blog build output is very simple:

Take the Langya Terrace post as an example. Its corresponding access path is https://vluv.space/琅琊台 or https://vluv.space/琅琊台/index.html.

A Interlude 🎞️

Earlier, after one EdgeOne update, every post returned 404 because EdgeOne no longer supported omitting index.html.

At that time I wrote an edgeone.json workaround, but the official hotfix arrived quickly. I thought everything was fine and deleted the config file.

I did not expect Chinese paths to break again this time, hh.

Migration Solution

The core migration logic has 3 steps:

1. Rename: translate every filename containing non-ASCII characters, such as Chinese, into pure English.
2. Configure redirects: configure 301 permanent redirects in edgeone.json so old links do not break.
3. Update Wiki Links: Obsidian users may use backlinks. After renaming files, the old wiki links stop working too, so they also need to be handled.

Doing this manually is tedious, but AI makes it efficient.

A Pitfall 🕳

EdgeOne Pages only supports ASCII characters in redirects.source, which means Chinese paths must be URL encoded (Percent Encoding) first. Otherwise, deployment validation fails:

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

Current LLMs are already good enough. Keeping the prompts here is probably more useful than leaving behind an outdated script.

**任务描述**基于 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?

Why go through all this trouble? Mainly because of these factors:

1. User experience: prevent indexed links from breaking, so users clicking in from search results will not see a 404.
2. SEO: if a large number of old links return 404 directly, search engines will gradually deindex the site. Abin’s SEO record is not exactly great.

It cost me some time that could have gone into pretending to write my thesis, but it also turned into another Blog post. I have discovered the conservation law of filler posts 🤓

Speaking of the thesis, I want to complain about Microsoft Word again, but I will hold that too, otherwise this post may get too long.

Postscript

2026.4.17: There Is a Second Stage? 🤯

I forgot that Twikoo comments also needed to be migrated. Steps:

1. Visit MongoDB Atlas.
2. Click Data Explorer.
3. After selecting the cluster that stores Twikoo data, click Connect.
4. Select the Twikoo comment table.
5. Execute queries for {url: { $regex: /[^\x00-\x7F]/ }} and {url:{$regex:'%'}}; the former finds URLs containing non-ASCII characters, while the latter filters Chinese URLs that have already been encoded.
6. Update the url and href fields in the documents.

🥲 Who would have thought I still had to play with regex in MongoDB? This migration really had all four words of “complexity, repetition, fatigue, and difficulty,” although future migrations at work will likely be far more troublesome than this.

If I still had AI quota, I could integrate the MongoDB MCP, enter a prompt, and let the LLM handle this repetitive work. I did a previous Twikoo migration that way, but after my internship ended, the free AI was gone too.

As for visit counts… I am too lazy to migrate them. Let them become numeric ghosts 🪦. I still have a thesis to pad out.