Eden 稳定版和 nightly 的存档为什么对不上: 用户档案 ID 与 UID 字节逆序

Sun, 20 Sep 2026 10:00:00 +0000

我把 Eden 的主力版本从稳定版换成了 nightly。它和稳定版包名不同, 可以直接共存, 游戏也都能正常打开。但进去之后, 之前所有的存档一个都读不到, 每个游戏都像第一次玩。我第一反应是 nightly 把数据目录清了, 或者存档被覆盖了, 赶紧去翻文件。

文件都在。少的不是存档, 是 nightly 去错了地方找。

两个构建共用游戏, 但不共用用户档案

Eden 把 Switch 的存档放在数据目录的 nand/user/save/ 下。这条路径不是只有一层, 它的结构大致是 nand/user/save/0000000000000000/<用户档案ID>/<TitleID>/, 中间那层是用户档案。稳定版和 nightly 是两个独立安装的应用, 各自的数据目录分开, 更关键的是: nightly 首次启动时会自己生成一个新的用户档案 ID, 和稳定版那个没有任何关系。

我这边稳定版的活动档案是 D2AE7D815565D5C93F432C7C74A7DD6A, nightly 自动生成的是 173CB8FB1F16348366B4CABB88A445D9。存档文件都在 nightly 的数据目录里(从稳定版拷过来之后), 但 nightly 只会去它自己那个活动档案目录里找游戏存档, 于是看不到。

存档目录名从哪来

那个看起来像随机十六进制串的档案目录名, 其实不是随机的。日志里能观察到, 它来自用户档案的 UID, 并且是 UID 的字节逆序排列——同一段身份数据, 换个字节序就成了目录名。两个构建只要各自生成了新 UID, 目录名就必然不同, 这也是为什么换构建、甚至 nightly 自己重新初始化之后, 存档会"对不上"。理解了这一点, 就不会再把它当成文件损坏。

为什么直接拷存档会失效

最容易踩的坑是: 把稳定版的 save/ 整个拷到 nightly 的 save/, 以为就完事了。结果 nightly 里依然读不到。原因是稳定版拷贝过去的目录名是 D2AE7D..., 而 nightly 的活动档案是 173CB8FB..., 内容进了库, 但没进 nightly 真正会查的那个抽屉。所以迁移必须做两段覆盖: 先把稳定版的存档根整体带过来, 再把稳定版活动档案里的内容, 再拷进 nightly 的活动档案目录。

从 emuMMC 里提取 Switch 存档: 非标准 AES-XTS、FAT32 与 DISF 的实现

Wed, 16 Sep 2026 10:00:00 +0000

那台破解过的 Switch 已经不在我手上了, 只剩一张 512GB 的 SD 卡。我想做的事很具体: 把当年玩出来的游戏存档救出来, 导进 Android 上的 Eden(一个 yuzu 分支), 接着玩下去。

我第一反应是插上读卡器去翻 Nintendo/save/。里面确实有存档, 但只有两个, 文件名是 8000000000000000 和 8000000000000124, 都是 NAX0 加密的系统存档, 和游戏进度无关。整张卡能看到的目录翻了一遍, 找不到任何一处像游戏存档。这个结果很反直觉: 存档明明是这台机器产生的, 怎么会不在卡上。

任天堂的说法是, 游戏存档只存在主机的内部存储 eMMC 里, 不能复制到 microSD; SD 卡上只有游戏本体、更新、DLC、截图和系统存档。那破解机的存档在哪——emuMMC。

存档不在 SD 卡表面, 而在 emuMMC 镜像里