指南 / 故障排除

将 .mrpack 转换为普通整合包 zip——以及为什么解压工具会失败

.mrpack 是一份清单，而不是模组压缩包。解压它只会得到一个 JSON 文件，没有任何 jar。下面说明它内部到底有什么，以及转换器必须做哪些事，转换器必须核对清单里的 sha512 校验值，否则可能混入被篡改或损坏的 jar 文件。

2026-07-09

把一个 .mrpack 重命名为 .zip 再打开，你会发现里面几乎什么都没有：一个 modrinth.index.json，也许还有个 overrides/ 文件夹。模组不见了。这不是文件损坏——而是这个格式本来就该长这样。

里面有什么

modrinth.index.json     the manifest: name, version, loader, and a list of downloads
overrides/              config files, resource packs, anything not on Modrinth

清单中的每个条目长这样：

{
  "path": "mods/sodium.jar",
  "hashes": { "sha1": "…", "sha512": "…" },
  "downloads": ["https://cdn.modrinth.com/data/…/sodium.jar"],
  "fileSize": 812345
}

整合包携带的是引用，不是文件。这就是为什么一个装了 40 个模组的整合包只有 200 KB，也是为什么所有通用解压工具都会“失败”——根本没有东西可解压。

转换必须做的事

1. 读取 modrinth.index.json。
2. 从每个条目的 CDN URL 下载文件。
3. 用清单里的 sha512 校验每个文件。跳过这一步，损坏或被掉包的 jar 就会混进整合包。
4. 把每个文件放到它对应的 path。
5. 把 overrides/，以及 client-overrides/ 或 server-overrides/ 覆盖上去——覆盖内容优先，这正是它们存在的意义。
6. 把结果打包成 zip。

第 3 步是转换器们悄悄跳过的那一步。哈希不匹配意味着下载被截断，或者文件已被改动；硬装上去，整合包会在加载时崩溃，而报错还指向错误的模组。

为什么要转换

• 不认识 mrpack 的启动器。 ATLauncher、MultiMC 和手动安装都需要一个装满 jar 的文件夹。
• 服务端。 服务器托管商几乎从不接受 .mrpack；他们要的是 mods 文件夹。
• 离线安装。 转换之后，整合包不再需要 CDN。

env 字段决定客户端还是服务端

每个文件都带有：

"env": { "client": "required", "server": "unsupported" }

服务端整合包必须跳过所有在服务端标记为 unsupported 的内容——主要是光影、小地图和 HUD 模组。把完整的客户端 mods 文件夹直接拷到服务器上，通常就是启动时崩溃、报错里还提到某个渲染类的原因。

反过来转换

从文件夹构建 .mrpack 是反向操作，有一个坑：任何未托管在 Modrinth、GitHub 或 GitLab 上的模组都不能作为清单条目——而 Modrinth 本身对已发布的整合包也只接受自家 CDN。这类模组必须放进 overrides/mods/，这会让整合包变大，但能保证它正常工作。悄悄丢掉这些模组，得到的整合包会安装得很顺利，内容却是缺的。

在 MRPACK 转 ZIP 转换器 中把 .mrpack 转换成客户端或服务端 ZIP，带哈希校验并处理好 env 的区分。

资源包压缩工具 →