# 如何读懂反编译进度报告

Author: DecompHub
Updated: 2026-10-10
Language: zh-Hans
Canonical: https://decomphub.com/zh-cn/guides/understanding-decompilation-progress

百分比只有结合测量内容、目标构建和测量时间才有意义。DecompHub 会保留指标名称、范围和来源链接。没有可靠测量时，进度保持未知；未知不等于 0%。

## 代码匹配与正常运行回答不同问题

匹配反编译的目标，是让重建的源码生成与指定原始构建一致的机器码。编译器和构建设置同样重要。[decomp.me FAQ](https://www.decomp.me/faq)解释了函数级 scratch 比较；一个 scratch 的结果不能直接代表整款游戏的进度。

兼容替代品则追求行为复现。例如，[ScummVM 替换游戏可执行程序，并使用原有游戏数据](https://docs.scummvm.org/en/latest/help/faq.html)。支持某款游戏不等于机器码匹配率。移植、重新实现和硬件研究即使没有匹配报告，也有价值。

## 先看分母

函数、字节、文件、符号和已识别资源是不同单位。**假设**某项目匹配了 1,000 个函数中的 900 个，按函数数量是 90%。如果剩余函数占一半代码字节，就不是按字节计算的 90%。这只是算术示例，不是目录中某个项目的真实数据。

阅读进度条时检查：

- 指标是匹配代码、已反编译代码、已识别资源，还是发布者另行定义的量？
- 数值是比例还是数量？如果是数量，来源是否真的提供总数？
- 范围是整个可执行文件、库、地区版本、平台，还是部分文件？
- 能否打开提供测量结果的原始报告？

[objdiff](https://github.com/encounter/objdiff)支持目标文件比较和进度信息生成。但项目使用这个工具，并不能说明它具体采用了什么设置或分母。

## 不要混合版本与指标

某个地区版或调试版完成，并不证明其他版本也完成。[Ocarina of Time](https://github.com/zeldaret/oot)明确说明了支持版本和构建目标选择。

代码匹配与资源识别也是独立任务。前者完成，不代表全部纹理、声音和数据结构都已理解。除非发布者明确规定综合指标，否则不要自行平均成“总完成度”。

## 区分日期来源

**报告日期**由测量结果的发布者提供。**观测日期**是 DecompHub 读取来源的时间。刚刚读取的页面可能包含旧测量。仓库元数据更新时间或条目编辑时间，也不能证明进度报告是新的。

[数据文档（英文）](/data)说明了导出字段。引用时应一起记录项目、指标、范围、来源 URL 和对应日期。

未知可能意味着没有兼容报告、来源不可用、无法确定范围，或尚未采集到有效资料。超过 100%、分母变化、互相冲突的徽章，都需要进一步核实。不要悄悄截断数值，也不要把未知替换成零或 GitHub Star 数。

[浏览已有测量的项目](https://app.decomphub.com/zh-cn/explore?progress=in-progress)，打开来源后再比较。若条目有误，可通过举报功能提供需要核查的具体上游证据。