feat(gacha): 升级 UIGF 支持至 v4.2，新增千星奇域抽卡记录导入导出

[WindDrift]

背景

项目此前实现的是 UIGF v4.0。UIGF 标准已迭代两版：

• v4.1（2025-08）新增星铁联动跃迁卡池类型 21/22
• v4.2（2026-01）新增千星奇域区段 hk4e_ugc

其中 v4.1 的缺口是一处已存在的标注错误：StarRailGachaClient 的 QueryGachaTypes 早在 2025-07 就包含了 21/22，导出文件实际已是 v4.1 规格，但 info.version 仍写 v4.0——而 v4.0 的 hkrpg.gacha_type 枚举只允许 1/2/11/12。只要用户有联动池记录，导出的文件就无法通过它自己声明的 schema 校验。

改动

数据模型

• UIGF4File 新增 hk4e_ugc 区段，info.version 升至 v4.2
• 解除 UIGF4GachaArchive<T> 的 where T : GachaLogItem 约束（千星奇域记录类不继承 GachaLogItem，且该约束在类体内未被使用）
• 复用现有的 GenshinBeyondGachaItem——其 JSON 属性名与标准的 hk4e_ugc 字段已完全对齐，未新建 DTO

导入导出

• UIGFGachaService 新增千星奇域的档案枚举、导出、导入三条链路
• 千星奇域与原神本体共用 UID，通过 IsGenshinBeyond 标记在导出列表中独立成行，可单独勾选
• region / is_up 是标准未定义的扩展字段，随记录一并写出以保证 Starward 之间无损往返；标准未禁止额外字段，其他应用会自动忽略

UI

• 跃迁记录页浮窗：Json → UIGF v3.0，从 JSON 导入 → 从 UIGF v3.0 导入，UIGF v4.0 → UIGF v4.2 并以分割线隔开，明确两套互不兼容的导出逻辑
• 原神页面导出 UIGF v3.0 时，若当前 UID 存在千星奇域记录，弹窗告知该部分数据不会被导出，提供【继续】/【取消】，默认焦点在【取消】
• UIGF v4.2 窗口的导出/导入列表新增「档案类型」列

说明

• 千星奇域导入沿用现有校验风格：id/item_id/op_gacha_type/time/rank_type 缺失抛 UIGF4ImportException，item_name 缺失走软提示
• 本次仅补齐 Lang.resx 与 Lang.zh-CN.resx，其余语种交由 Crowdin 同步
• 标准中 hk4e_ugc 的 properties/required 被写在数组层级而非 items 内，对校验器实际失效——这是 UIGF 侧的 schema 书写问题，本实现按语义字段对齐，不依赖 schema.uigf.org 校验该区段

测试

• UI 更新

• UIGF v4.2 验证通过

本人无千星奇域抽卡记录，且原神早已退坑，待寻找有抽卡记录的 UID 进行千星奇域验证

代码由 Claude Opus 5 生成，本地验证通过，GitHub Action 构建通过。

[IiHuTao]

感觉UIGF v4.0改为UIGF v4.2就可以了，把上面的json统一改为UIGF3.0不够严谨，崩铁的是SRGF1.0，绝区零的什么都不是只能在Starward中导入导出
最后一次抽卡应该是要与时间对齐？这直接挤开了。

[IiHuTao]

千星奇域hk4e_ugc导出时lang为空，Starward中能导入导出，但导入其他软件时可能会由于lang缺失而出错

[WindDrift]

感觉UIGF v4.0改为UIGF v4.2就可以了，把上面的json统一改为UIGF3.0不够严谨，崩铁的是SRGF1.0，绝区零的什么都不是只能在Starward中导入导出

UIGF 3.0 支持原神和崩铁，不支持绝区零，但是 Starward 在导出绝区零时也会类似的按照 UIGF 3.0 的标准导出，为避免歧义，将更改崩铁的导出为 SRGF 1.0，绝区零的保持为 Json 不变。

左边绝区零右边崩铁

---

最后一次抽卡应该是要与时间对齐？这直接挤开了。

这可能和本来的排布有关，最后一次抽卡 并不和 时间(服务器时区) 在一起，倒像是单独的一行，本次 PR 并没有修改这一行，具体见下图；
对于您编辑前的评论删掉的 新增的档案类型一列似乎纯多余，图标已经足够分辨 ，由于新增了千星奇域导出，Starward 中没有千星奇域的图标，故使用原神图标代替，单独列出了一行以供选择是否导出千星奇域记录，为避免和原神本体冲突，所以加了 档案类型 一列，这也是 AI 提供的建议。

---

千星奇域hk4e_ugc导出时lang为空，Starward中能导入导出，但导入其他软件时可能会由于lang缺失而出错

很抱歉我并没有千星奇域抽卡记录，故暂时无法测试，如果您愿意提供自其他项目导出的，含有千星奇域抽卡记录的 UIGF 4.2 文件，将不胜感激。
根据 uigf.org 的信息，提瓦特指南 和 胡桃重制版 支持基于 UIGF 4.2 的千星奇域抽卡记录导出。

[WindDrift]

已完成更改 WindDrift@444bcba 。

1. 导出格式命名一刀切

感觉UIGF v4.0改为UIGF v4.2就可以了，把上面的json统一改为UIGF3.0不够严谨，崩铁的是SRGF1.0，绝区零的什么都不是只能在Starward中导入导出

修复：按 CurrentGameBiz 动态取名——原神 UIGF v3.0、星铁 SRGF v1.0、绝区零 JSON。新增 LegacyFormatName / LegacyImportText 两个属性在 OnNavigatedTo 中赋值，本地化键改为参数化的 GachaLogPage_ImportFrom0（从 {0} 导入），三种情况共用一条翻译。

2. 千星奇域 lang 写出空字符串

千星奇域hk4e_ugc导出时lang为空，Starward中能导入导出，但导入其他软件时可能会由于lang缺失而出错

原因：Starward 没有存千星奇域的语言（GenshinBeyondGachaItem 无该字段，数据库表也无该列），原先直接写了 lang: ""。而标准虽未把 lang 列入 required，却给了 15 个值的 enum，空字符串不是合法成员——等于主动写出一个非法值，比省略更糟。

修复：UIGF4GachaArchive.Lang 改为可空并加 JsonIgnoreCondition.WhenWritingNull；千星奇域按「同 UID 的原神本体记录 → AppConfig.GachaLanguage → 省略」三级推导，取到的值过 LanguageUtil.FilterLanguage 归一（其输出恰好就是那 15 个 enum 值，且会把 zh-hk 归到 zh-tw，避开 enum 不含 zh-hk 的坑）。原有三个游戏同样的 ?? "" 隐患一并改为空值即省略。

3.「最后一次抽卡」标签错位

最后一次抽卡应该是要与时间对齐？这直接挤开了。

原因：该标签是独立一行，靠硬编码 Margin="296" 对齐到「时间(服务器时区)」列（92+100+12+80+12=296）。本次新增了 140px 的「档案类型」列，后续各列整体右移 152px，标签仍停在 296，落到了档案类型列中间。

修复：Margin 改为 448（92+100+12+140+12+80+12），重新对齐到时间列起点，导出和导入两个页签都改。

[IiHuTao]

UIGF 3.0 支持原神和崩铁，不支持绝区零，但是 Starward 在导出绝区零时也会类似的按照 UIGF 3.0 的标准导出，为避免歧义，将更改崩铁的导出为 SRGF 1.0，绝区零的保持为 Json 不变。

UIGF 3.0只支持原神，崩铁是独立的SRGF 1.0

删掉新增的档案类型一列似乎纯多余，图标已经足够分辨

是因为克隆下来拿自己数据看了后发现多了千星奇域，所以删了
如果可以建议新增千星奇域图标以作区分，如千星奇域官号头像

https://bbs-static.miyoushe.com/static/2025/08/27/7c8615e5b688e21cf38c1513b1065d52_744698744296376266.jpg

最后一次抽卡并不和时间(服务器时区) 在一起

原来排布更像刻意对齐，是不是要看老大怎么想，所以我加了个问号表示不确定

导入导出的功能上暂未其他发现问题

[IiHuTao]

档案类型应该对应一致如原神，原神千星奇域，崩坏：星穹铁道，绝区零
祈愿，颂愿，跃迁，调频

此外档案类型一列本地化还应考虑文本宽度，如英语(Miliastra Wonderland Ode)、俄语等明显超出列宽

[IiHuTao]

或者说档案名称一列直接复用现有的祈愿记录，千星奇域颂愿，跃迁记录，调频记录的命名

[WindDrift]

已完成更改 WindDrift@5642018 。

档案类型应该对应一致如原神，原神千星奇域，崩坏：星穹铁道，绝区零
祈愿，颂愿，跃迁，调频
或者说档案名称一列直接复用现有的祈愿记录，千星奇域颂愿，跃迁记录，调频记录的命名

• 复用现有本地化文本，将原神、千星奇域、崩铁和绝区零分别显示为祈愿记录、千星奇域颂愿、跃迁记录和调频记录。
• 保持档案顺序为原神、千星奇域、崩铁、绝区零。

此外档案类型一列本地化还应考虑文本宽度，如英语(Miliastra Wonderland Ode)、俄语等明显超出列宽

• 加宽档案类型列，并同步调整导入和导出列表布局。
• 重新对齐“最后一次抽卡”表头与时间列。