RuneTranslate 现已支持翻译 YU-RIS 视觉小说

RuneTranslate 现在又读懂了一个长期挡在同人汉化者面前的引擎：YU-RIS，这是 raiL-soft 出品的 Windows 脚本引擎，数百款日本同人及商业视觉小说都基于它制作。如果你曾经打开某款 YU-RIS 游戏的文件夹，看到一个塞满 .ypf 封包的 pac/ 目录和一个里面没有任何可读内容的 ysbin.ypf，然后就放弃了——那正是这个引擎。RuneTranslate 现在能识别它，用纯 TypeScript 打开这些封包，从已编译的脚本中读出对白，并导出一份游戏可自行加载的翻译副本。这是 RuneTranslate 支持的最新引擎。

这是一个全新的引擎，先说实话：YU-RIS 支持刚刚做好，尚未在大量真实游戏上验证。所以首先——如果你把 RuneTranslate 指向某款 YU-RIS 游戏，它没能识别、无法打开，或导出的东西游戏加载不了，请告诉我们。具体怎么反馈，文末会讲。

YU-RIS 引擎究竟是什么

YU-RIS（有时写作 ゆーりす）是 raiL-soft 出品的一款日本视觉小说脚本引擎。一款成品 YU-RIS 游戏由一个 Windows .exe 加上一组 .ypf 封包档案组成——通常放在 pac/ 文件夹里——其中存放着美术、音频和脚本。剧本本身是已编译的：开发者编写的可读脚本会被构建成一种名为 YSTB 的二进制格式，以 .ybn 文件的形式存放在 ysbin.ypf 内（内部路径类似 ysbin/yst00000.ybn）。正是这种「已编译剧本封装在打包档案里」的组合，让这个引擎庞大的作品库一直无缘于普通的机器翻译工具。

为什么 YU-RIS 游戏一直这么难翻译

与 Ren'Py 这类以源码驱动的引擎相比，YU-RIS 把文本藏在了好几层之后：

• 一切都在 `.ypf` 封包里。 脚本并非松散地放在磁盘上——它们被打包进 YU-RIS 自有的 .ypf 容器，文件名经过混淆、条目用 zlib 压缩。没有能读取该格式的工具，压根就没有东西可编辑。
• 剧本是编译过的，不是文本。 .ybn 不是能用记事本打开的脚本——它是一个二进制 YSTB 容器，分为四个区段（指令流、参数描述符表、字符串表和行号）。真正的日文位于字符串表中，由描述符引用。
• 脚本经过 XOR 加密。 每个 YSTB 脚本的四个数据区段都用一个 4 字节密钥打乱。你必须先恢复该密钥，任何文本才可读——而且密钥因游戏而异。
• 并非每个字符串都是对白。 字符串表里还存有变量名、资源路径和脚本逻辑用来比较的表达式操作数。一不小心翻译了其中之一，游戏流程就会悄无声息地出错。

综合结果是：即便是能流畅阅读日文的人，也得先解开一个专有档案，再解析一个已编译的二进制文件，再破解 XOR，再把对白从引擎的内部字符串中区分出来——这一切都要在翻译第一行之前完成。这些活儿，RuneTranslate 现在替你做了。

RuneTranslate 现在能做什么

RuneTranslate 把 YU-RIS 当作一等公民引擎对待，整条流水线都用纯 TypeScript 处理——无需外部工具、无需 Python 附属程序、无需安装任何东西：

• 直接读取 `.ypf` 封包。 它自行打开档案、解压条目并恢复被混淆的文件名——不需要 GARbro 或另外的解包器。已经自己把游戏解包了？松散的 ysbin/ 文件夹（内含 .ybn 脚本）同样能被识别。
• 解析已编译的 `YSTB` 脚本并破解加密。 它自动从参数描述符表中恢复每个脚本的 4 字节 XOR 密钥，解码 Shift-JIS 字符串表，并在编辑器中按脚本文件分组列出每一行日文。
• 能分辨对白与机制。 变量名、资源路径和表达式操作数会显示出来，但默认排除——以红色的选择性加入行呈现——这样你就绝不会误翻一个剧情逻辑用来比较的字符串。
• 保留内嵌的控制码。 消息文本中穿插的反斜杠码（换行、颜色、注音）和方括号标签，会在内容送达翻译提供方之前用数字占位符遮蔽，导出时再原样还原。
• 导出无需重新打包。 导出时它会重建每个翻译后的脚本——调整字符串表偏移量，让更长或更短的译文都能容纳，并重新应用同一个 XOR 密钥——然后把 .ybn 以松散文件的形式写到它在档案中的原始路径上。YU-RIS 运行时会优先选用松散文件，而非 .ypf 里打包的同一路径，于是游戏就直接读取你的译文。完全不重新打包。（这与我们的 Kirikiri 补丁流程和 Artemis 支持采用的松散文件覆盖方式相同。）

日文 → 英文是最佳组合，但你可以翻译成 30 多种语言中的任意一种——西班牙文、法文、德文、葡萄牙文、俄文、中文、意大利文、土耳其文、越南文等等。

你需要准备什么

• Windows 版 RuneTranslate——免费；所有引擎和翻译提供方都已解锁（免费档只限制速度，不限制功能）。
• 一个 YU-RIS 游戏文件夹。也就是包含游戏 yu-ris.exe 及其 .ypf 封包的目录（通常在 pac/ 子文件夹里，脚本位于 ysbin.ypf 中）。
• 一种目标语言——英文、西班牙文、法文、德文、葡萄牙文、俄文、中文、意大利文、土耳其文、越南文，以及另外 20 多种。
• 一个翻译提供方。免费的 Google Translate 开箱即用；DeepL 有免费额度；OpenAI、Anthropic、本地模型（Ollama / LM Studio）以及任何兼容 OpenAI 的 API 则需自备密钥。YU-RIS 游戏对白很多，所以 LLM（OpenAI / Anthropic）或 DeepL 通常读起来最自然。

第 1 步：打开游戏文件夹

启动 RuneTranslate，点击新建项目，把它指向 YU-RIS 游戏目录。引擎检测会自动运行——当它看到 .ypf 封包（或一个内含 .ybn 脚本的松散 ysbin/ 文件夹）时，就会把该项目识别为 YU-RIS。你的原始游戏文件夹绝不会被修改。

第 2 步：脚本是怎样被读取的

RuneTranslate 打开 .ypf 封包，从 ysbin.ypf 中取出已编译的 YSTB 脚本，恢复每个脚本的 XOR 密钥，并解码 Shift-JIS 字符串表——在编辑器中按文件分组列出每一行日文。引擎的内部字符串（变量名、资源路径、表达式操作数）会显示出来但默认排除，内嵌的控制码则用数字占位符遮蔽，以免翻译提供方把它们弄乱。

第 3 步：翻译

选择一个翻译提供方并运行。对于视觉小说，LLM（OpenAI / Anthropic）最擅长把握角色的语气和口吻，DeepL 处理旁白快速而干净，免费的 Google Translate 则适合短小的菜单字符串和选项。请提前为你的角色阵容和反复出现的术语建立术语表，让人名在整部游戏里呈现一致——参见术语表 101。完成后，用 AI 精修器做一次可选的处理，它会结合上下文重读每一行，收紧机器翻译常留下的生硬、直译的措辞。

第 4 步：导出即可运行的副本

点击导出。RuneTranslate 会写出一份翻译后的游戏副本，把每个重建的 .ybn 以松散文件的形式放在它的原始档案路径上，与未改动的 .ypf 封包并排存放。完全不重新打包——YU-RIS 会优先加载松散脚本，而非打包的原件，于是游戏就直接读取你的译文。运行它，游戏便以你的目标语言呈现。

已知限制

• YU-RIS 的字符串是 Shift-JIS（cp932）。 英文以及其他能用 cp932 表示的目标语言可以干净地导出。含有 cp932 之外字符的目标语言——扩展西里尔文、韩文、繁体中文——需要对游戏字体/编码做修改，而这尚未自动化。
• 松散文件覆盖是预期的加载路径，在大多数 YU-RIS 游戏上它都能奏效，因为引擎会优先选用松散脚本而非打包副本。对于极少数不遵守这一点的作品，导出可能需要调整——这正是我们仍在确认的真实游戏行为。
• 烧录进图片美术里的文字——以位图绘制的标题画面或菜单按钮——是像素，而非脚本文本。对此请参见图片文字翻译。
• 档案和脚本的确切变体可能因版本而异。请务必在你的具体副本上验证。

它是全新的——遇到问题请告诉我们

值得直白地再说一遍：YU-RIS 支持是新加入的功能，尚未在大量真实游戏上测试过。.ypf 读取器、YSTB 解析器和密钥恢复都已实现并通过单元测试，但这个引擎积累了多年、因工作室而异的差异，我们并未全部见识过。所以，如果你把 RuneTranslate 指向某款 YU-RIS 游戏，它没能识别、打不开档案、什么都提取不到，或导出的东西游戏加载不了，请到我们的 Discord 反馈——游戏名称以及它的封装方式，正是最能帮助我们尽快加固支持的信息。

下载 RuneTranslate，把它指向那款你一直想读的 YU-RIS 视觉小说，试一试。想了解我们如何处理另一款基于档案的视觉小说引擎，接着阅读 Artemis 教程。