一、从一个汉化目录说起：被低估的工程问题

社区中常见的“汉化游戏目录”，表面上只是一份“编号 + 游戏名 + 汉化进度 + 汉化团队”的列表，本质上却是一个小型资产管理系统的输出界面。当条目规模达到数百甚至上千条时，会自然暴露出一连串工程问题：

• 同一款作品存在多个区域版本与修订版本，补丁往往只对特定基 ROM 有效，如何准确标注适用范围？
• 汉化进度从 0.1 到 1.0 不等，不同团队的进度口径如何统一？
• 补丁命名风格各异，如何让使用者一眼判断“能不能用、怎么用”？
• 目录本身如何被检索、统计与增量更新？

这些问题决定了汉化目录的维护成本，也决定了汉化成果能否被正确使用。下文先讲清汉化本身的技术流程，再回到目录管理，给出可落地的元数据设计。

二、汉化工程的总体流程

一个典型的汉化项目可以拆解为八个阶段：

1. 资源解析与解包：识别 ROM 或打包资源的组织格式，抽出文本、字库、图片等数据块；
2. 文本定位与导出：结合码表与指针表，把二进制文本转成可编辑文本；
3. 翻译与校对：统一术语表、统一文风，多轮审校；
4. 文本回填：重新分配存储空间、重建指针；
5. 字库制作：制作点阵字模并建立编码映射；
6. 图形资源处理：重绘标题画面、菜单、图标等“含字图片”；
7. 封装与补丁：生成差量补丁并附校验信息；
8. 测试与发布：全流程回归后发布。

这八个阶段并非严格串行。字库与文本回填往往相互牵制：字库区能容纳多少字模，决定了译文的用词空间；译文的长度又反过来影响对话框排版。经验上，先做小规模“垂直切片”（一两段对话完整跑通提取、翻译、回填、渲染），再批量铺开，可以大幅降低返工率。

三、文本提取：码表与指针表

3.1 字符编码与码表

老游戏通常不使用通用编码，而是“字模编号 → 字符图形”的自定义映射。提取文本前需要先整理出这份映射，即俗称的码表。部分平台的作品直接采用日文标准编码（如 Shift-JIS），此时可借助标准映射转换；但仍有大量作品使用私有编码，需要人工比对字模逐个确认。

码表片段示例：

00=<{end}>
01=<{line}>
20=A
21=B
A1=你
A2=好

3.2 指针表与文本定位

文本区中每段对话的存储位置并不连续，程序通过指针表检索。汉化改动文本长度后，所有后续偏移都会失效，因此要么按定长回填，要么扩容文本区并全量重写指针。导出文本的伪代码如下：

# 伪代码：依据指针表批量导出文本
TEXT_BASE = 0x08000000        # 文本区基址（示例值，因平台内存映射而异）
PTR_START = 0x00100000        # 指针表起始偏移（示例值）
count = read_u16(PTR_COUNT_ADDR)
for i in range(count):
    ptr = read_u32(PTR_START + i * 4)   # 多数掌机平台为小端序
    off = ptr - TEXT_BASE
    raw = read_bytes_until(off, terminator=0x00)
    print(decode(raw, charmap))

两个实践要点：其一，先验证指针算法——有些平台使用“基址 + 三字节偏移”的复合形式，直接按四字节整数解析会得到错位文本；其二，导出时保留控制符原文，避免翻译阶段误删导致回填后渲染异常。

四、字库与文本渲染

4.1 点阵字库与编码空间

• 字模格式：常见 1bpp/2bpp/4bpp 的 tile 排列，需注意行扫描顺序与字节序，弄错会得到“花屏”字模；
• 编码空间：GB2312 收录汉字 6763 个，其中一级常用字 3755 个。若原字库区只够存放一两千个字模，就必须做字集子集化——统计全部译文用字，只嵌入实际出现的字，并重建“文字 → 编号”映射；
• 编码宽度：子集化后若总字数不超过单字节编码空间（256 个），可沿用单字节编码，文本区无需扩容；超出则需引入双字节编码或扩页机制，并同步修改读写逻辑。

4.2 变宽字体与对话框排版

早期作品多用等宽点阵字，中文全角字符恰好适配；若原版使用变宽字体（VWF），则需要实现中英文混排的宽度度量与断行。文本超长会导致溢出、遮挡甚至程序崩溃，常见对策包括：压缩措辞、在合适位置手工插入换行标记，或重写排版函数以支持自动换行。

五、图形资源与“含字图片”

标题画面、菜单项、教程插图往往把文字直接“画”进了图片。处理思路：

1. 理解 tile 排列与调色板结构，把图形还原为可编辑位图；
2. 在原图基础上修字而非整图重绘，尽量保留原版构图与字体骨架，维持视觉一致性；
3. 警惕调色板共享：同一场景多张图共用调色板时，改动一处颜色可能波及整个画面。

六、控制符与脚本逻辑

游戏文本中大量控制符承担换行、变色、等待按键、插入变量等功能。应建立控制符的白名单与转义规则：

• 导出时转成可读标记，如 <line>、<color:2>、<wait>；
• 回填时校验标记合法性，遇到未知控制符一律报错而非静默跳过；
• 变量类控制符（如玩家名字、物品数量）涉及参数宽度，需确认其取值范围，避免翻译后参数越界。

七、补丁封装与分发策略

合规基线是：不传播原 ROM，只分发差量补丁，由使用者自备合法获取的基 ROM。工程要点包括：

• 基 ROM 校验：用 CRC32、SHA-1 等校验和锁定适用版本，打补丁程序在校验不符时给出明确错误提示，而不是产出损坏文件；
• 差量补丁：只记录与基 ROM 的差异而非全量数据，体积小、传播成本低；
• 版本语义化：主版本号对应“内容全部翻译完成”，次版本号对应“修复错漏字、更新译文”，避免“最终版完全版”式的模糊命名。

校验脚本示例：

import zlib, hashlib
def fingerprint(path):
    data = open(path, "rb").read()
    return {
        "crc32": format(zlib.crc32(data) & 0xFFFFFFFF, "08X"),
        "sha1": hashlib.sha1(data).hexdigest(),
    }

八、汉化资源目录的元数据设计

回到目录本身。一份可持续维护的汉化目录，核心在于把每条记录结构化。推荐最小元数据模型如下：

{
  "id": "CH-0012",
  "title": "示例作品",
  "platform": "掌机平台",
  "region": "JP",
  "base_rom": { "crc32": "1A2B3C4D", "sha1": "..." },
  "patch": { "version": "1.2.0", "format": "差量补丁", "size_kb": 2048 },
  "localization": {
    "team": "某汉化团队",
    "language": "zh-Hans",
    "progress": 1.0,
    "status": "released",
    "updated": "2026-03-24"
  },
  "notes": "需先升级至修订版基 ROM"
}

字段设计原则：

• id 全局唯一且稳定，不因改名而变化；
• base_rom 的校验和是判断“能不能用”的第一依据；
• progress 使用 0～1 的数值而非文字描述，便于排序与统计；
• status 区分 released / beta / wip / abandoned 等状态，避免“挖坑”信息被淹没。

目录的托管与检索可以完全基于通用云能力搭建：对象存储存放补丁与截图，静态页面或轻量服务渲染目录，配合搜索、日志服务与监控告警保障可用性。例如采用“对象存储 + 内容分发网络”托管目录页面，再以通用检索能力实现按标题、平台、进度筛选——这类能力各家云平台（包括百度智能云）均以通用类目形式提供，无需绑定特定实现。

九、质量保障与自动化

• 导入/导出幂等性：同一文本两次导出结果应完全一致，回填后再次导出应能还原译文；
• 溢出检测：回填后遍历全部对话，模拟渲染宽度，自动标记超长文本；
• 截图回归：对关键场景自动截图并与基线比对，尽早发现花屏、错位；
• 术语一致性：用术语表做差异检查，防止同一名词前后译法不一；
• 持续集成：把“导出 → 占位翻译 → 人工翻译 → 回填 → 生成补丁”接入流水线，每次译文提交自动产出可测试的补丁包。

十、版权与社区协作

• 汉化补丁属于衍生作品，发布前应确认权利边界：不分发 ROM、保留原作者署名、明确声明仅供学习交流；
• 多人协作时用版本库管理译文与码表；码表变更必须走评审，因为一处改动可能影响全部文本；
• 停更项目应归档完整工程（码表、脚本、译文、构建脚本），避免“只有补丁、没有源文件”的技术断代。

十一、总结

汉化目录只是冰山露出水面的一角，水面之下是文本编码、指针重定位、字库工程、差量补丁与元数据管理的一整套流程。把每个环节工具化、把每条记录结构化，汉化成果才能长期可用、可检索、可追溯——这既是技术问题，也是社区协作的治理问题。