RuneTranslate 现已支持翻译 NScripter / ONScripter 视觉小说
RuneTranslate 现已可将 NScripter 和 ONScripter 视觉小说翻译成英语及 30 多种语言——解码经 XOR-0x84 混淆的 nscript.dat,处理 Shift-JIS / CP932 文本以及以拉丁字母开头的行会被解析器误判的陷阱,并翻译烙印在标题画面、菜单和按钮里的日文。指向游戏文件夹、自动识别、翻译、导出一份可直接运行的副本。新增功能——遇到无法加载的游戏请反馈给我们。
RuneTranslate 现在能读懂日本视觉小说中最古老的方言之一:NScripter 及其开源孪生兄弟 ONScripter。如果你一直想翻译一部经典的同人视觉小说——那种以一堆晦涩的 .dat 文件和 Shift-JIS 脚本打包的作品——那么这正是历史上最难手工撬开、也最常被机器翻译工具跳过的引擎家族。如今 RuneTranslate 能识别它、读取脚本文本,甚至翻译绘制在标题画面和菜单按钮上的日文。
这是一个新增的引擎,所以在一切开始之前:如果你把 RuneTranslate 指向一款 NScripter / ONScripter 游戏,而它无法加载或无法识别,请告诉我们。文末会详细说明。
NScripter 和 ONScripter 究竟是什么
NScripter 是由高橋直樹编写的 Windows 视觉小说脚本引擎,大约从 1999 年开发到 2018 年(它的最后一个修订版 3.10.102 的日期是 2018 年 2 月,尽管实质性的功能开发在 2000 年代初之后就大幅放缓了)。它从未开源,但其许可证允许免版税的个人和商业使用,再加上内置的归档打包器和一门强大、以底层著称的脚本语言,这使它在鼎盛时期成为日本使用最广泛的视觉小说引擎之一。像 Nekonekosoft 这样的商业工作室几乎完全依赖它,同人圈也对它青睐有加。
ONScripter 是一个独立的、单独的项目:由一位名为 Ogapee 的程序员于 2002 年发起的、对 NScripter 运行时的开源(GPL)重新实现。它基于 SDL 构建,力求与 NScripter 游戏即插即用地兼容,但它能运行在 NScripter 从未涉足的平台上——Linux、macOS、BSD、Android 等等。由于它开源且可修改,英语本地化社区将其采纳为发行已翻译 NScripter 游戏的事实标准引擎,一系列分支为它加入了西方语言支持:Chendo 于 2004 年的单字节字符补丁、Haeleth 用于比例 Unicode 字体的 ONScripter-EN(ONS-EN)和 Ponscripter*、Uncle Mion 后期的维护,以及 insani 为现代构建重新激活的分支。
所以简而言之:NScripter 是这些游戏最初赖以创作的封闭式 Windows 引擎;ONScripter(以及 ONS-EN / Ponscripter)则是粉丝译者实际用来运行其翻译版本的开源跨平台运行时。RuneTranslate 从游戏的脚本和素材入手,因此两大阵营的作品它都能覆盖。
为什么这些游戏一直如此难以翻译
与 Ren'Py 或 Kirikiri 这类现代引擎相比,NScripter / ONScripter 遍布那个引擎年代的怪癖。其中有四点尤其让手工译者和粗糙的机器翻译工具都撞上了墙:
- Shift-JIS / CP932 编码。 老旧的脚本和数据文件采用 Shift-JIS(微软的变体 CP932)编码,这是古老的日文双字节编码。解码错误就会得到乱码;粗心地重新编码,某些旧运行时会损坏内存并崩溃。译者必须正确地识别并让 CP932 完整往返——现代的原生脚本可以是 UTF-8,但那些老作品是 CP932。
- 经 XOR-0x84 混淆的 `nscript.dat`。 编译后的脚本通常存放在
nscript.dat(在 Ponscripter 中则是pscript.dat)中,其中每个字节都与常量字节0x84做了异或。这不是加密——文档明确指出它不提供任何安全性,只是防止意外剧透——但你也不能直接用文本编辑器打开它。你必须解开 XOR,编辑其中的 Shift-JIS 文本,再在写回时重新施加 XOR。(游戏也可能改为附带明文的0.txt/.u脚本,或放在.nsa/.sar归档里的脚本。) - 烙进图像美术里的文字。 标题画面、菜单和按钮往往是预先渲染好的位图——NScripter 甚至要求部分美术必须是 BMP——所以上面的日文是像素,而不是字符串。字符串提取器碰不到它们。
- 微妙的那一点:以拉丁字母开头的行会被重新解析为命令。 NScripter 的解析器让每一行都以命令模式开始。过去这样很安全,因为引擎只接受双字节日文,所以任何显示出来的行都毫无疑义地是文本。可一旦你引入单字节英文,一行以拉丁字母开头就与脚本命令一模一样,引擎便会试图执行它——从而弄坏游戏。社区的修复方法是一个保留的文本标记(旧版 ONScripter 中的反引号 `
`;Ponscripter 后来改用^`),它会强制本行余下部分进入文本模式。把日文粗暴地查找替换为英文,会产生引擎误读为命令的行。
正是这最后一个陷阱,才让早期的粉丝项目(Gin'iro、Mizuiro)不得不改用双字节拉丁字符——原版 NScripter 根本不接受单字节输入——也正因如此,一个不理解该引擎的通用翻译器只会把脚本弄成砖头。
RuneTranslate 现在能做什么
RuneTranslate 把 NScripter / ONScripter 当作一等公民引擎来对待,并同时处理这个问题的两个半边:
- 脚本文本。 它读取游戏的脚本——一份松散的明文文件(
0.txt之类)或一份经 XOR0x84混淆的nscript.dat——解码 Shift-JIS / CP932 对白,在编辑器中列出每一行可翻译的文本,并在导出时以引擎所期望的形式写回脚本,当原始.dat使用了 XOR0x84混淆时重新施加它。它还会自动应用单字节文本标记,这样你翻译的英文就不会被误读为命令。(一个只存在于.nsa/.sar归档内、在游戏根目录没有松散副本的脚本,目前还读不了——见下方的限制。) - 烙进图像里的文字。 标题画面、菜单和按钮上的日文——是像素而非字符串——由 RuneTranslate 的图像文字翻译来处理:框选文字、识别它们、用你自己的翻译服务商翻译,再把结果重新烙回去,让游戏改为加载你翻译后的美术。
日译英是最佳场景——这款引擎整部粉丝翻译史都是围绕它展开的,而在老旧的 Shift-JIS 脚本上,非拉丁的目标语言会受限于引擎字体能渲染的范围——但你可以选定 30 多种语言中的任意一种。
你需要准备什么
- Windows 版 RuneTranslate——免费,所有引擎和服务商全部解锁。
- 一个 NScripter 或 ONScripter 游戏文件夹。这是包含游戏
.exe(或一个 ONScripter 二进制文件)以及其脚本和素材的目录——通常有nscript.dat、一份松散的0.txt,以及一个或多个.nsa/.sar归档。 - 一种目标语言——英语、西班牙语、法语、德语、葡萄牙语、俄语、中文、意大利语、土耳其语、越南语,以及另外 20 多种。
- 一个翻译服务商。免费的 Google Translate 开箱即用;DeepL 有免费额度;OpenAI、Anthropic、本地模型(Ollama / LM Studio)以及任何兼容 OpenAI 的 API 都需自备密钥。这些游戏对白繁多且对语气敏感,所以 LLM(OpenAI / Anthropic)或 DeepL 通常读起来最自然。
第 1 步:打开游戏文件夹
启动 RuneTranslate,点击新建项目,将其指向 NScripter / ONScripter 游戏目录。引擎识别会自动运行——当它看到 nscript.dat、一份松散的 0.txt 脚本,或引擎的 .nsa 归档时,就会把该项目识别为 NScripter / ONScripter。你原始的游戏文件夹绝不会被改动。
第 2 步:脚本是如何被读取的
RuneTranslate 会读取游戏在其根目录中松散附带的脚本,并替你解码:
- 经混淆的 `nscript.dat`——对
0x84解开 XOR 并按 Shift-JIS 读取,这样你就无需单独运行一遍nsdec。 - 松散的明文脚本(
0.txt之类)——直接读取。 - 归档中的图像——从游戏的
.nsa/.sar归档中取出,供下方的图像文字步骤使用。(脚本本身是从上面所述的根目录松散文件中读取的;仅打包在归档内的脚本目前还读不了。)
对白和显示文本会在编辑器中按文件分组列出。引擎标记和命令记号会在任何内容到达服务商之前被数字占位符遮蔽,然后在输出时还原——单字节文本标记也会在需要之处被应用,这样引擎就不会把你翻译好的英文行误认为命令。
第 3 步:翻译
选择一个服务商并运行。对于视觉小说,LLM(OpenAI / Anthropic)最擅长还原角色的声线与语气,DeepL 处理旁白快速而干净,而免费的 Google Translate 应付简短的菜单字符串绰绰有余。事先为你的角色阵容和反复出现的术语建立词汇表,好让人名在整部游戏中呈现得一模一样——见词汇表入门 101。完成之后,用 AI 精修器进行一遍可选的处理,它会结合上下文重读每一行,收紧机器翻译往往留下的那种生硬、直译的措辞。
第 4 步:翻译图像中的文字
由于 NScripter 的界面有太多是预渲染的美术,这一步在这里比在大多数引擎上都更重要。在项目中打开一张标题或菜单图像,围绕每一块日文拖出一个方框,识别它,用你翻译对白时相同的服务商来翻译它,导出时 RuneTranslate 会把译文重新烙回图像,并将其作为松散文件写入导出的副本,让引擎加载你翻译后的美术、覆盖归档中的原图。(你原始的游戏文件夹保持不动;经 SPB 压缩的美术和少数冷门的图像变体仍在加固中——若发现任何看着不对的地方请反馈。)完整演练:图像文字翻译。
第 5 步:导出一份可直接运行的副本
点击导出。RuneTranslate 会写出一份翻译后的游戏副本——脚本被重新编码为 Shift-JIS / CP932,若原始 .dat 使用了 XOR 0x84 则重新混淆,作为一份松散脚本写出,引擎会以它覆盖任何归档中的副本,同时附带写在旁边的任何松散的翻译图像。运行游戏,它便会以你的目标语言呈现,无论你是在原版 NScripter 运行时上启动它,还是在 ONScripter / ONScripter-EN 上。
已知限制
- XOR-0x84 混淆已受支持,但采用真正的自定义加密(而非标准混淆)保护的游戏可能无法打开。
- 一个只打包在
.nsa/.sar归档内、游戏根目录没有松散nscript.dat/0.txt的脚本,目前尚不能提取——大多数游戏都会松散附带脚本,但少数不会。 - 图像文字翻译能触及绘制在菜单、标题和按钮上的日文,但经 SPB 压缩的美术和高度风格化的 logo 美术可能仍需手动修饰。
- 确切的引擎可能因发行版本而异——一些通常与 NScripter 关联的作品(例如 When They Cry 系列的部分作品)是基于 NScripter 构建的,并常通过 ONScripter 运行,但某些 Steam / 主机复刻版有时会被重新改造。请务必在你自己的那份拷贝上核实。
它全新登场——告诉我们哪里出了问题
这个引擎是新加入的,还未经历千锤百炼。NScripter / ONScripter 有几十年的变体、分支和各工作室的独有癖性,我们并未见识全。所以如果你把 RuneTranslate 指向一款 NScripter 或 ONScripter 游戏,而它无法识别、无法加载,或导出了运行时打不开的东西,请反馈给我们——游戏的名称以及它的打包方式(松散的 0.txt、nscript.dat、.nsa 归档)正是最能帮我们尽快加固它的信息。
下载 RuneTranslate,把它指向那部你一直想读的经典视觉小说,试一试。想了解一款更现代的视觉小说引擎,接着阅读 Ren'Py 演练。
