导出输出位置

每次导出产生两个文件：一个未压缩的 .json 和一个包含它的 .zip。两者都留在原地，json 不会被删除。

路径推导

RecipeExporter.getSaveFile(String ext)：

String dateTime = ZonedDateTime.now(ZoneId.of("UTC"))
    .format(DateTimeFormatter.ofPattern("uuuu-MM-dd_HH-mm-ss"));
File file = new File(
    RecipeExporterMod.clientConfigDir.getParent() + "/RecEx-Records/" + dateTime + ext);
环节 值 来源
clientConfigDir <存档根>/config FMLPreInitializationEvent.getModConfigurationDirectory()
.getParent() <存档根> 去掉 config 一级
目录 RecEx-Records（相对拼接，无 OS 分隔符处理） 硬编码字符串
时间戳 uuuu-MM-dd_HH-mm-ss，UTC ZoneId.of("UTC") 显式指定
扩展名 .json（zip 由 replace(".json", ".zip") 派生） 硬编码

最终路径：

<存档根>/RecEx-Records/2026-02-06_19-50-00.json
<存档根>/RecEx-Records/2026-02-06_19-50-00.zip

.getParent() 这一跳依赖 Forge 把 getModConfigurationDirectory() 定义为 <gamedir>/config；README.md 也明确写着 “The exported files will be stored in RecEx-Records/, at the root of the minecraft instance.”

时间戳格式的两个细节

  • 模式用的是 uuuu（proleptic year，公元纪年）而非 yyyy（year-of-era）。在当前年代两者输出一致，uuuu 在负数年份下不会出错。
  • 时区硬编码为 UTC，不是系统时区。所以文件名里的时间与玩家本地时间可能相差若干小时，且不随系统时区变化。

时间戳精度为秒。同一秒内触发两次导出会算出同一个文件名：getSaveFile 里 if (!file.exists()) 判断为真跳过的分支不执行，随后 new FileWriter(saveFile) 以截断模式覆盖同名 json。

目录创建

getSaveFile 只在 !file.exists() 时执行 file.getParentFile().mkdirs() 与 file.createNewFile()，即首次导出时才创建 RecEx-Records/。目录不存在不会报错。

压缩

saveData 写完 json 后，用 zip4j 打同名 zip：

参数 值
库 net.lingala.zip4j:zip4j:2.3.1（shadowImplementation，打进 jar）
压缩方法 CompressionMethod.DEFLATE
压缩级别 CompressionLevel.FASTEST
内容 上面那个 json 文件（zipFile.addFile(saveFile, ...)）

压缩失败只打 Recipe compression may have failed! 警告——json 依然有效可用，zip 可以缺失。

另一个被创建但从不写入的目录

RecipeExporterMod.preInit 还会创建 <存档根>/config/RecEx：

clientConfigDir = e.getModConfigurationDirectory();
modConfigDir = new File(clientConfigDir.getPath() + "/RecEx");
if (!modConfigDir.exists()) { modConfigDir.mkdirs(); }

modConfigDir 字段在全仓库只被赋值、没有任何读取点（grep -rn "modConfigDir" src/main/java 只有声明与这一次赋值）。所以该目录会出现在磁盘上，但永远是空的——本 mod 没有任何配置文件。配置项情况见 导出 JSON 格式 的说明。

相关条目