[UIAF] 讨论 v1.2 ：扩展为多游戏成就交换格式，并支持绝区零与崩坏：星穹铁道

[Guest-Liang]

自己搓了个绝区零的成就导出 Guest-Liang/ZZZAchievementExporter，本来想pr一下添加到UIGF-org的，不过翻了一下目前针对成就记录导出的UIAF还只有原神一个，故提出此提案

Note: 部分内容由AI生成，并经过本人人工核对

现行 UIAF v1.1 面向原神成就，根对象只有一份 info + list。 UIAF 或许可以参考UIGF v4.2 的一级游戏键名，在后续版本中以 hk4e、nap 区分不同游戏，并加入绝区零成就支持。或许说不定还有崩坏：星穹铁道呢

正式样本

在我的3.0账号样本ZZZae-full-20260724-142544 - 副本.json中：

• 完整成就子树共有 683 条服务端记录；
• 其中 642 条具有完成证据，与游戏界面显示的完成数一致；
• 另外 41 条没有完成时间和完成标志；

各字段组合如下：

原始 varint 字段	数量	当前可确认的含义
{1,3,4}	635	已完成
{1,3,4,5}	7	已完成，另有语义尚未正式确认的字段 5
{1}	35	只有成就 ID，没有完成或非零进度证据
{1,2}	6	未完成，并具有非零进度

目前的字段判断为：

字段号	观察	当前结论
1	每条记录都有，值与公开成就元数据 ID 对应	成就 ID
2	只在 6 条未完成记录出现，值分别与成就描述中的累计进度吻合	很大概率为当前进度 current
3	只在 642 条完成记录出现，值为合理 Unix 秒	完成时间，Unix 秒
4	只在 642 条完成记录出现，值恒为 1	完成标志
5	只在 7 条完成记录出现，值与部分计数/最高值类条件有关	很可能是实际计数、最大值或累计值

字段 2 的证据相当好：

• “累计喂食 3 次”的未完成记录，字段 2 为 1；
  

• “累计 9 次通关”的未完成记录，字段 2 为 3；
  

• “回复 10 条帖子”的未完成记录，字段 2 为 7；
  

字段 5 的几个样本则包括：

• 累计登录 365 天，字段 5 为 751；（后来又登录了几天，和导出不是同一天）
  

• 持有不少于 50 枚鸣徽，字段 5 为 73；
  

• 累计获得 2000 积分，字段 5 为 3077；
  

• 单次伤害超过 1000000，字段 5 为 573692416；
  

• 总得分达到 30000，字段 5 为 40000。
  

互斥成就的实际表现

zzz.liyin.space 当前通过MultipleChoice.json维护互斥成就组，并在导入一条已完成分支后，将同组其他分支推导为“已选其他”。
相关状态处理可参考achievement.js。

当前 MultipleChoice.json 定义了 6 个互斥组，共 14 个分支 ID。与样本快照交叉检查后：

• 其中 4 个组已经选择并完成一个分支；
• 每个已选择的组在服务端快照中只出现完成的那个 ID；
• 同组未选择分支完全不在 683 条记录中；
• 另外 2 个尚未选择的组，其全部分支 ID 都不在快照中；
• 对原始完整响应的 raw body 进行对应 ID 的 varint 搜索，也没有发现这些缺失分支在 body 其他位置出现。

因此，目前没有发现服务端直接返回的“已选其他”状态数字。互斥状态需要：

已完成的成就 ID
  + 当期成就元数据中的互斥组关系
  = 已选择分支及同组“已选其他”分支

这与 zzz.liyin.space 的纯导入行为一致：交换文件只提供已完成的分支，Liyin 根据自己的互斥组元数据自动把其他分支标记为“已选其他”。

建议增加 UIGF 的一级游戏键名

UIGF v4.2 使用 hk4e、hkrpg、nap 等一级字段区分游戏。它的各游戏字段实际是账号数组，每个元素带 uid、timezone 和 list，因此 UIGF 同时支持同一文件中的多游戏和多账号。
UIAF v1.1 当前没有 UID，ZZZae 目前的成就导出也暂时没有提取 UID。建议先用 UIGF 的“按游戏键名读取”思路：

type UIAFv1.2 = {
  info: {
    export_timestamp: number
    export_app: string
    export_app_version?: string
    uiaf_version: "v1.2"
  }

  hk4e?: {
    list: Hk4eAchievement[]
  }

  nap?: {
    list: NapAchievement[]
  }
}

这样，一个只支持原神的工具只读取 hk4e，一个只支持绝区零的工具只读取nap，同时支持两款游戏的工具可以在同一文件中读写两者。

各游戏共享基础记录结构，并分别定义状态语义

目前原神与绝区零的成就记录都可以使用相同的基础字段：

type Achievement<TStatus extends number> = {
  id: number
  current: number
  status: TStatus
  timestamp: number
}

hk4e

原神可以完整保留 UIAF v1.1 的现有记录语义：

type Hk4eAchievement = Achievement<0 | 1 | 2 | 3>

nap

基于当前绝区零正式服样本：

type NapAchievement = Achievement<0 | 1 | 2>

建议的状态语义为：

0 = INVALID
1 = UNFINISHED
2 = FINISHED

绝区零的转换规则可以是：

• 原始字段 1 → id；
• 原始字段 3 → 完成 timestamp；
• 原始字段 4 为 1，或具有可信完成时间 → status = 2；
• 只有 ID 或具有非零进度但未完成 → status = 1；【分支成就也可以理解为完成不了的成就，UNFINISHED语义上应该也没问题】
• 完成时间未知 → 沿用 UIAF v1.1 的 253402271999（9999-12-31 23:59:59）哨兵；
• 字段 5 存在 → current = 字段 5，否则字段 2 存在 → current = 字段 2，否则 → current = 0

[ky3-git]

大大大大肘子😭

[Lightczx]

@HolographicHat 有原始字段么

[HolographicHat]

@HolographicHat 有原始字段么

无
（有旧版本dump.cs可供参考）

[Guest-Liang]

昨天Tibo按按钮了，故继续添加了HSR成就的相关分析
这下SRAF有救了

依旧https://github.com/Guest-Liang/HSRAchievementExporter

崩坏：星穹铁道正式样本

在我的 4.4 账号完整成就快照HSRae-achievements-20260729-042750.json中：

• GetQuestDataScRsp 是同时包含主线、支线、日常和成就等任务的混合 Quest 快照，从其中筛出的 4xxxxxx 成就记录共有 1887 条；
• 其中 1869 条与当期 AchievementInfo.json 中的成就 ID 完全对应；
• 另外 18 条为元数据中不存在的内部或未知 ID；
• 服务端状态统计只出现了 1、2、3，没有观察到其他状态数字；
• 最新快照中有 1543 条正式成就具有完成时间，其余 326 条正式成就没有完成时间。

字段组合

原始 varint 字段	数量	正式 ID	当前观察
{1,2,14,15}	1543	1543	状态为 3，具有进度和可信完成时间
{14,15}	298	292	状态为 1，没有非零进度或完成时间；另有 6 条未知 ID
{1,14,15}	46	34	34 条正式记录状态为 1；12 条未知 ID 状态为 2

字段 3 使用 protobuf wire type 2 单独编码为 packed varint 数组，不计入上表的 varint 字段组合。

当前字段判断

字段号	观察	当前结论
1	已完成记录全部具有；部分未完成记录的值与成就累计进度吻合	当前进度 current
2	所有已完成正式记录都具有，均为合理 Unix 秒；领奖前后保持不变	完成时间 timestamp
3	packed repeated uint32；多组样本保存已命中过的不同角色或配置键	去重/累计不同条件的辅助记录数组
14	值与正式成就元数据 ID 对应	成就 ID
15	正式样本只出现 1/2/3，且已取得未完成、完成未领取、领取后的连续样本	成就状态统计值

字段 1 的进度证据包括：

• “开启 400 次二相乐园战利品”，字段 1 为 359；
  
• “收集 26 张银河战力党卡牌”，字段 1 为 18；
  
• “击败 800 次凝滞虚影”，字段 1 为 670。
  

字段 3 的 packed 数组样本

当前 1887 条记录中只有 6 条包含字段 3：

成就 ID	成就	字段 1	字段 3	liyin元数据v4.4.0
4054309	废墟的遗赠	5	[405034,405035,406034,407014,407015]	AchievementInfo.json#L12455-L12464
4073406	十万个冷知识	4	[1209,1220,1221,1310]	AchievementInfo.json#L17286-L17300
4074704	致翁法罗斯	2	[1407,1413]	AchievementInfo.json#L18545-L18559
4082602	茶浓于水	字段 1 缺失	[19840]	AchievementInfo.json#L19705-L19719
4082603	罗浮老饕	字段 1 缺失	[20397]	AchievementInfo.json#L19720-L19734
4082801	在世界中心呼唤我	8	[1001,1208,1222,1225,1303,1308,1310,1409]	AchievementInfo.json#L19902-L19916

其中多组数值可直接对应角色 ID：

• 4054309 的六位数值结合成就描述，很可能是已购买的配方/配置键。
• 4073406 的 4 个值对应彦卿、飞霄、云璃、流萤；
• 4074704 的 2 个值对应遐蝶、长夜月；
• 4082801 的 8 个值对应三月七·存护、符玄、灵砂、忘归人、阮·梅、黄泉、流萤、风堇。
• 4082602 茶浓于水 和 4082603 罗浮老饕 比较特殊：原始字段 1 实际缺失，但字段 3 分别保存 19840、20397。如果把它们当作 Unix epoch 起算的天数，分别对应 2024-04-27 和 2025-11-05，很像“上一次有效饮用日期”或连续天数状态键。我打算等会上号喝一次，看看是否有变动。

这几组可核对样本的字段 1 恰好等于字段 3 数组长度，符合“保存已经命中过的不同条件键并据此累计进度”的解释。4054309 的值结合描述很可能是配方或配置 ID。两个连续饮用成就的单值可能是日期或内部状态键，但样本不足以给出更具体的字段名称。

字段 3 与完成或领奖状态无关：它只出现在 6 条未完成记录中，本次完成和领奖的记录均没有字段 3。交换格式也不需要它，因此可以只在完整原始备份中保留。

状态值的三次受控样本

---

点击展开详细分析过程

三次快照分别为：

1. 初始快照；
2. 明确完成 5 个正式成就但不领取奖励后的快照；
3. 领取这 5 个成就奖励，并在两次快照之间另完成且领取 1 个成就后的快照。

快照	正式状态 1	正式状态 2	正式状态 3	有完成时间的正式成就
初始	332	0	1537	1537
完成 5 个但未领取	327	5	1537	1542
领取 5 个并新增完成 1 个	326	0	1543	1543

第二次快照中新完成的 5 条正式记录全部发生：

status: 1 → 2
progress: 缺失/0 → 1
finish_timestamp: 缺失 → 合理 Unix 秒

第三次快照中，这 5 条记录又全部发生：

status: 2 → 3
progress: 保持 1
finish_timestamp: 逐条保持不变

这 5 个 ID 为：

4035410
4035413
4055413
4055417
4085401

两次导出之间另完成的 4055412 在导出前已经领取，因此直接表现为：

status: 1 → 3
progress: 缺失/0 → 1
finish_timestamp: 缺失 → 1785267712

---

正式成就状态语义已经由前后差分确认：

状态值	正式成就语义	完成时间
1	未完成（UNFINISHED）	无
2	已完成但奖励未领取（FINISHED）	有
3	奖励已领取（POINT_TAKEN）	有，且与状态 2 时相同

18 个元数据外 ID 的状态始终为 6 条 1 和 12 条 2，并且全部没有完成时间。它们不进入 Liyin 或 UIAF，只保留在用于分析的完整原始备份中。实现完成判定时也应继续要求合法完成时间，不能仅凭未知内部记录的状态 2 判定完成。

4.4 空文本但实际可达成的正式 ID （像fate联动的成就）

目前 Liyin AchievementInfo.json 中，4035408～4035413 共 6 条记录具有完整 ID、系列、稀有度、显示类型和版本字段，但标题与描述均为空：

• SeriesID = 3
• Rarity = Mid
• ShowType = ShowAfterFinish
• Version = 4.4

游戏内这些成就实际可以达成，服务端快照中也存在对应记录。本次已实际观察到：

• 4035410：未完成 1 → 完成未领取 2 → 领取后 3；
• 4035413：未完成 1 → 完成未领取 2 → 领取后 3；
  两条记录都有可信完成时间，且领奖前后时间保持不变。

因此更可能是当期成就文本元数据没有更新完整，而不是 ID 无效。

星穹铁道互斥成就的实际表现

liyin.space 当前通过 MultipleChoice.json 维护星铁互斥成就组。

当期文件定义了：

• 50 个互斥组；
• 共 113 个正式分支成就 ID；
• 理论上每组最多完成一个分支。

与 4.4 服务端快照交叉检查后：

• 113 个分支 ID 全部出现在服务端快照中；
• 44 个已经选择的组均表现为一个分支状态 3，同组其他分支状态 1；
• 6 个尚未选择的组，其全部分支状态均为 1；
• 113 个互斥分支中没有状态 2；
• 因此服务端没有直接使用状态 2 表达 Liyin 的“已选其他”。

Liyin 显示的最大可完成数量为 1806，正好满足 1869 - (113 - 50) = 1806，也就是从 1869 个正式成就中，扣除互斥组内不可能同时完成的 63 个额外分支。

因此星铁的互斥状态应当与绝区零一样由消费端推导：

已完成分支 ID + 当期 MultipleChoice.json = 同组“已选其他”分支

尤其需要注意：

• Liyin 的 status = 2 表示“已选其他”；
• UIAF 的 status = 2 表示 FINISHED；
• 两种格式的数字 2 语义不同，不能直接转换；
• HSRae 生成 Liyin 文件时只提供正式且已完成的分支，Liyin 再根据自己的互斥组元数据推导其他分支

hkrpg

基于星铁 4.4 正式样本，建议增加：

type HkrpgAchievement = Achievement<1 | 2 | 3>

状态语义沿用 UIAF：

1 = UNFINISHED
2 = FINISHED
3 = POINT_TAKEN

星铁转换规则建议为：

• 原始字段 14 → id；
• 原始字段 1 → current，字段缺失时为 0；
• 原始字段 15 的 1/2/3 分别直接映射为 UIAF 1/2/3；
• 状态缺失、超出 1/2/3 或 ID 不在正式元数据中时，不写入 UIAF；
• 原始字段 2 → timestamp；
• 完成时间缺失时，沿用 UIAF v1.1 的 253402271999 哨兵；
• 字段 3 是内部辅助记录数组，不写入当前 UIAF 成就结构；
• 不把 Liyin 的“已选其他”状态写成 UIAF FINISHED；
• 互斥分支关系由消费端结合 MultipleChoice.json 推导。

建议的账号结构为：

hkrpg?: {
  uid: number
  list: HkrpgAchievement[]
}

[Lightczx]

@xytoki FYI

[Lightczx]

因为现在整个米家相关的开发社区都十分的疲软，如果提了新标准其实可以自家的App先做上，形成事实标准，后面有兼容问题了再慢慢调整就行了

当然变得这么疲软我认为 某务部 功不可没🤣

[Guest-Liang]

懂你意思