摘要：本文详细记录了 RealLive 游戏引擎的汉化全过程。首先介绍了引擎的文件结构（SEEN.TXT 脚本、.pak/.dat 资源）与编码限制（仅支持 Shift-JIS）。汉化流程分为三个主要阶段：1）使用 SExtractor 等工具拆包提取文本；2）利用 AI 翻译并重新封包；3）通过 IDA Pro 逆向修改主程序，关键修改包括：调整 MultiByteToWideChar 的代码页参数、将 CreateFontA 的字符集改为 GB2312_CHARSET（0x86），以及将双字节字符判断逻辑从 cmp al, 0A0h 改为 cmp al, 0FEh 以适配 GBK 编码范围。文章还总结了调试中遇到的乱码、API 定位困难等问题及解决方案。

1. 概述

记录一下自己对 RealLive 游戏的汉化过程。RealLive 是 VisualArt’s 早期广泛使用的游戏引擎。

引擎特征

• 文件结构： 核心脚本文件通常打包为 SEEN.TXT，资源文件常封装为 .pak 或 .dat 格式。
• 编码限制： 引擎底层逻辑默认且固定支持日文 Shift-JIS 编码。直接替换或导入 GBK/GB2312 等中文编码文本会导致乱码。汉化的核心步骤在于修改主程序（.exe）的反汇编代码，调整字符判定和渲染逻辑。

---

2. 工具与知识储备

使用的工具

• 文本/代码编辑器： Notepad++、VS Code
• 资源处理工具： SExtractor（用于解包和封包）
• 反汇编工具： IDA Pro（用于分析和修改可执行文件）
• 翻译工具： AI 辅助翻译工具

涉及的技术知识

• 字符编码： Shift-JIS 与 GB2312/GBK 编码原理。
• 字符判定逻辑： 计算机底层区分单字节字符与双字节字符（如中日文字符）的前导字节判断机制。
• 逆向分析： Windows API 调用追踪（如 MultiByteToWideChar、CreateFontA）及基本汇编指令修改。

---

3. 汉化执行步骤

3.1 拆包与文本提取

1. 拆解文件： 使用相关工具拆解游戏目录下的封包文件，定位并提取脚本文件。参考：解包封包教程。
2. 提取文本： 过滤脚本中的控制符和系统指令，提取纯对白文本用于翻译。参考：提取文本教程。

3.2 翻译与文本导入

1. 翻译： 运用 AI 工具将提取出的日文文本翻译为中文。
2. 导入与封包： 将中文文本按原结构导回脚本文件，并重新打包替换原资源文件。参考：翻译和导入文本教程。

3.3 主程序编码修改与测试

直接运行导入中文文本的游戏会在对话环节卡死。使用 Locale Emulator 转区运行可避开卡死，但文本显示为日文乱码。需使用 IDA Pro 对主程序进行逆向修改。

分析与修改一：MultiByteToWideChar API

• 定位： 在 IDA 中通过交叉引用查找 MultiByteToWideChar 调用。
  
• 现象： 查看对应汇编代码，发现调用参数 CodePage 被静态赋值为 0。
• 原理解析： MultiByteToWideChar 负责将多字节字符串转换为宽字符。参数 0 代表 CP_ACP（系统默认 ANSI 代码页）。在 Locale Emulator 环境下，CP_ACP 被设定为 932（Shift-JIS）。程序以此参数解析导入的 GBK 中文文本，造成字符映射错误与乱码。

分析与修改二：CreateFontA API

• 定位： 查找 CreateFontA 调用。
  
• 现象： iCharSet 参数被静态赋值为 1，即 DEFAULT_CHARSET。
  
• 修改操作： 将该参数对应的汇编指令修改为压入 0FFFFFF86h。在 Windows 字体标准中，0x86（十进制 134）代表 GB2312_CHARSET。此修改强制引擎按中文字符集标准渲染字体。

分析与修改三：双字节字符判断逻辑修复

完成上述修改后进行测试，文本出现汉字乱码以及连续的 ????? 符号。此现象由引擎底层对双字节字符的判定逻辑引起。

• 原理解析：

  • Shift-JIS 的双字节前导字符范围为 0x81-0x9F 及 0xE0-0xFC。引擎中判断前导字符的条件通常写为 cmp al, 0A0h，即遇到小于 0xA0 的特定字符即判断为双字节字符。
  • GBK 的前导字符范围为 0x81-0xFE，包含大量大于或等于 0xA0 的字节。引擎读取到这些字节时，将其误判为单字节字符并截断，导致显示错误及问号。
    

• 修改操作： 根据相关资料，在十六进制视图中搜索特征字节串 A0 72，将相关用于比较的指令 cmp xx, 0A0h 全局修改为 cmp xx, 0FEh，以适配 GBK 编码的读取范围。
  

• 最终测试： 完成前导字节范围的扩大修改后，汉化文本可正常显示。

---

4. 调试记录

• 问题 1：使用 Locale Emulator 出现乱码
  • 表现： 游戏跳过卡死报错，但中文文本显示为日文乱码（图 7）。
  • 原因： 模拟器强行将系统语言环境置为日文，导致 CodePage 参数使用 Shift-JIS 规则解析 GBK 数据，仅解决了执行异常，未解决编码不匹配问题。
• 问题 2：API 参数定位困难
  • 表现： 不同版本或不同游戏的内存地址偏移量不同，无法直接使用网上的静态内存地址。
  • 解决方法： 在 IDA Pro 中利用函数的交叉引用（Xrefs）功能，通过寄存器操作向上回溯以确认各 API 调用的参数入栈位置。
• 问题 3：字体修改后出现 ????? 乱码
  • 表现： 将 iCharSet 更改为 134 后，文字呈现乱码及问号串。
  • 原因： 虽然解决了字体字符集问题，但引擎本身的字符截断逻辑依然为 Shift-JIS 标准。大于 0xA0 的 GBK 前导字节被当作单字节处理，使得双字节结构被破坏。

---

5. 总结

RealLive 引擎游戏汉化的完整流程不仅需要处理资源层的拆包、文本提取和替换，还需对可执行文件进行逆向修改。关键的系统层修改包括：处理 MultiByteToWideChar 的代码页解析逻辑、修改 CreateFontA 的字体字符集参数（改为 0x86），以及扩大底层指令中对双字节前导字符的判定范围（0A0h 修改为 0FEh）。完成上述步骤即可解决该引擎不支持中文编码的问题。