企业官网建设流程全解析

常玩Unity引擎游戏的人，应该都经历过这种尴尬：游戏库里的冷门独立佳作，画面、玩法都戳中你，但界面和对话全是英文、日文或者韩文，啃起来实在费劲。等汉化组的大佬出手又不现实，小众游戏很可能根本没有汉化计划。XUnity.AutoTranslator就是用来解决这个问题的：它是一个运行在游戏进程内部的翻译插件，不需要改动游戏原文件，也不依赖官方支持，启动游戏后自动拦截并翻译屏幕上的文本。用它汉化一个Unity小游戏，从下载工具到真正看到中文界面，熟练的话确实能在五分钟左右跑通。

这篇文章我会从方案选择、安装配置一直写到离线词典和问题排查，把我实际用下来的经验、踩过的坑一并放进去。不管是刚接触游戏汉化的新玩家，还是想研究翻译管线原理的爱好者，照着这套流程走，大部分Unity引擎的游戏都能顺利啃下来。文章涉及的内容全部基于公开的通用技术，只讲技术实现思路，你可以放心跟着操作。

1. 为什么选XUnity.AutoTranslator：方案对比与底层原理

1.1 三种主流汉化方案，为什么我选注入式

说到汉化，大家最先想到的可能是汉化组发布的汉化补丁。这类补丁通常分两种思路：一种是直接修改游戏资源包，把文本文件解包、翻译、再封回去；另一种是外挂字幕式的翻译，用额外程序识别画面并覆盖显示。这两种方式在传统PC游戏里很成熟，但放到Unity游戏上有个尴尬：Unity的资源打包方式和传统游戏差异很大，不同项目的资源结构几乎没有统一标准。今天汉化A游戏需要拆AssetBundle，明天汉化B游戏又要解包Addressables，每个游戏都要定制一套解包封包流程，个人玩家折腾成本太高。

XUnity.AutoTranslator走的是第三条路：运行时注入翻译。它不碰游戏文件，而是在游戏启动后，从内存层面对文本进行拦截和替换。游戏本身该按什么逻辑运行还是按什么逻辑运行，翻译插件只是夹在“游戏要显示文字”和“文字被画到屏幕上”之间，做一个中转。

三种方案的区别我整理了一张表：

我在试过前两种之后，基本是稳定选第三种了。原因很现实：大部分个人汉化场景并不追求“发布一个完美汉化包”，只是想让游戏能舒服地玩下去。注入式方案把安装成本降到了最低，而且游戏本体文件没动过，Steam检查完整性也不会报错，退出插件就是原版，风险小很多。

1.2 XUnity.AutoTranslator的工作原理

要理解这个插件，得先简单说下Unity引擎的文本显示机制。Unity早期的主流脚本后端叫Mono，游戏里的UI文本、对话内容，最终都会从脚本层传到引擎层，再由底层绘图函数把字形画到屏幕上。XUnity.AutoTranslator做的事情，就是把那些负责“画文字”的函数入口拦下来，读取它要绘制的字符串，提交给翻译引擎翻译，再把译文交给原来的函数继续绘制。整个替换过程发生在内存里，游戏文件没有被修改，所以它被称为“注入式”工具。

插件内部有几个核心组件。首先是加载器，它负责把插件注入到游戏进程中，BepInEx就是其中最常用的加载器之一；其次是Hook层，负责拦截文本绘制相关的函数调用；然后是翻译引擎，负责把原文发送到翻译服务并取回译文；最后还有缓存机制，负责把翻译过的句子存到本地，避免下次遇到相同的文本再次请求翻译。

把原理弄明白之后，很多使用上的问题就能解释通了。比如为什么同一句话第二次出现时翻译很快，因为缓存命中了；为什么某些游戏里翻译生效但UI布局有点怪，因为译文长度和原文不同，而UI的排版是根据原文宽度计算的；为什么有的文本没被翻译，因为游戏可能用了特殊的文本渲染路径，插件默认的Hook没有覆盖到。这些细节在后面章节会逐一展开。

2. 环境准备与安装：拿到文件就能跑

2.1 下载前先确认：你的游戏能不能用

XUnity.AutoTranslator对目标游戏是有适配范围的，不是所有Unity游戏都能直接生效。动手之前，先花两分钟确认游戏类型，能避免后面白折腾。

第一，看游戏是不是Unity引擎做的。Steam商店页、游戏启动画面、目录结构都能作为判断依据。Unity游戏的根目录下，通常会有一个以“游戏名_Data”命名的文件夹，里面放着globalgamemanagers、resources.assets等资源文件；有些游戏根目录还会有UnityCrashHandler64.exe这样的辅助程序。

第二，看游戏的脚本后端。老一些的Unity游戏默认使用Mono后端，这类游戏对XUnity.AutoTranslator支持最好。新一些的项目可能改用IL2CPP，把C#编译成C++再打包，文本渲染路径变了一截，插件的支持就会弱一些。简单判断方法是看游戏目录里有没有GameAssembly.dll，一般有这个文件就可能是IL2CPP；如果看到Mono目录或者MonoBleedingEdge这样的文件夹，基本就是Mono后端。IL2CPP游戏有一部分也能用，但功能会受限，比如对部分文本渲染方式的拦截可能不到位。

第三，确认游戏没有强反作弊系统。像一些竞技类游戏、带内核级反作弊的游戏，注入任何外部模块都可能触发风控。我的建议是，XUnity.AutoTranslator只用在单机游戏上，联机游戏尤其是有反作弊的联机游戏，不要折腾这个，既容易出问题，也不符合游戏规则。

2.2 两步安装：BepInEx与插件目录

确认游戏适用后，安装其实就两步。第一步下载BepInEx加载器，第二步把XUnity.AutoTranslator的插件文件放进加载器目录。

BepInEx是一个开源的游戏插件加载框架，名字拆开是“Beppy Unity Injector”，它在Unity游戏社区里使用非常广泛，音频替换、图形增强、玩法修改等各种插件都依赖它。XUnity.AutoTranslator也提供了基于BepInEx的分发包，所以我个人最推荐用这种方式安装。

具体的目录结构应该是这样：

游戏根目录/ ├─ 游戏可执行文件.exe ├─ 游戏名_Data/ ├─ BepInEx/ │ ├─ core/ │ ├─ plugins/ │ │ └─ XUnity.AutoTranslator/ │ │ ├─ AutoTranslatorConfig.ini │ │ ├─ Translation/ │ │ └─ ... │ ├─ config/ │ └─ LogOutput.log ├─ doorstop_config.ini └─ winhttp.dll

实际操作时，先把BepInEx压缩包解压到游戏根目录，再把XUnity.AutoTranslator的压缩包解压后放到BepInEx/plugins文件夹下。这里有个关键点：网上很多教程让人直接双击游戏主程序，其实第一次最好先从命令行或文件管理器直接启动，不要通过Steam启动器，避免启动器做文件校验时把新加的文件干掉。

首次启动游戏后，插件会创建两样东西：一个是AutoTranslatorConfig.ini配置文件，另一个是Translation文件夹。看到这两个东西生成，说明插件已经成功注入了。如果没生成，优先去BepInEx/LogOutput.log里看加载日志，后面问题排查章节会细说。

3. 核心配置：看懂配置文件，汉化就成功了一半

3.1 AutoTranslatorConfig.ini关键参数

插件的所有核心行为都被集中到AutoTranslatorConfig.ini这个文件里。第一次打开它，你会看到很多配置项，英文又长，容易让人头疼。但其实真正要动的就那么几个，我把我常用的配置贴出来，并逐一说明。

[General] Language=zh-CN FallbackLanguage=zh-CN [Service] Endpoint=BingTranslate FallbackEndpoint=GoogleTranslateV2 MaxConcurrentTranslations=8 MaxCharactersPerTranslation=150 DelayBetweenTranslations=100 [Cache] UseCache=true [Behaviour] OverwriteTranslations=false DumpTranslation=false

先看[General]里的Language，这个决定目标语言，写zh-CN就是简体中文。有的版本也接受zhs或者SimplifiedChinese这种写法，认不准就看插件文档里的语言代码表，统一用小写短横线格式基本不会错。

[Service]这一组是重中之重。Endpoint是翻译引擎，插件的设计思路是通过统一的接口对接各种翻译服务，你可以在这里切换不同的端点。我实测下来，BingTranslate对中文的支持比较稳定，响应速度也理想，适合作为默认选择。FallbackEndpoint是备用引擎，当第一个引擎请求失败时，插件会自动切换过去。同时还可以调整MaxConcurrentTranslations（最大并发翻译数）和DelayBetweenTranslations（每次请求之间的间隔毫秒数）。这两个参数要配合着调：并发数调太高，容易被翻译服务限流；间隔调太短，同样可能被限流。我在个人使用中一般并发8、间隔100毫秒，稳定性和速度比较均衡。如果你网络环境对某些公共接口响应慢，可以试着把并发降下来，再把间隔稍微调大，优先保证不超时。

[Cache]里的UseCache建议永远保持true。这是个本地缓存开关，开启后每条译文都会存到本地，同一句话第二次遇到时直接读缓存，不用再请求翻译服务，对速度和成本都是巨大优化。

[Behaviour]里有两个容易混淆的开关。OverwriteTranslations控制是否允许覆盖已有翻译，默认false表示“如果离线词典里已经有译文，就不再用在线翻译”。DumpTranslation是文本转储开关，后面进阶章节会单独讲，平时保持false就好。

3.2 字体替换：解决汉字变成“口口口”

第一次跑通翻译的人，十有八九会碰到一个经典问题：游戏里文字确实变成了中文，但所有字符都显示成方框或者“口口口”。这不是翻译失败，翻译其实成功了，只是游戏默认字体里根本没有中文字形。

Unity游戏的字体会被打包进资源文件里，不同游戏自带字体的字符集差异很大。英文游戏的自带字体往往只包含拉丁字母、数字和符号，你把中文塞进去，引擎找不到对应的字形，就只能画一个方块占位。解决办法是让插件强制替换游戏使用的字体文件。具体步骤：下载一个包含简体中文的字体文件，比如思源黑体、NotoSansCJK等开源字体，把字体文件命名为Font.ttf，放到游戏根目录，然后在配置文件里把[Behaviour]区域的OverrideFont设置成Font.ttf。重启游戏后，插件就会在绘制文本前把默认字体换成这个字体文件。

字体替换这块有几个坑需要提一下。第一，字体文件体积别太大，中文字体本身动辄十几兆，如果游戏里要频繁切换字体样式，可能造成加载卡顿。第二，思源黑体这类字体有多种字重，如果只提供常规字重，游戏里加粗文字可能会渲染异常，你可以把加粗变体也一并放进目录并用OverrideFontBold指定。第三，替换字体后，原来英文UI的排版宽度会发生变化，中文单字本身占宽更多，有些按钮或对话框可能出现文字顶到边缘的情况，这个属于Unity版面适配问题，通常不影响使用，介意的话只能靠离线词典把长文本改短一些。

4. 5分钟实操流程：从解压到跑通

4.1 完整操作步骤与验证方法

理论知识过了一遍，现在走一遍完整实操。我以我最近处理的一款Unity单机游戏为例，把每一步拆开来说。

第一步，备份。把游戏根目录下的存档文件夹整体复制一份，同时如果游戏在Steam上有云存档，先确认云存档同步完成。备份存档是为了防止插件在极少数情况下导致崩溃，存档面前无小事。

第二步，下载并解压BepInEx。从BepInEx的GitHub Release页面找到对应游戏架构的发行版，Windows平台一般下载x64版本即可。把压缩包解压到游戏根目录，解压后应出现BepInEx文件夹、winhttp.dll、doorstop_config.ini等文件。这一步做完，先别急着装翻译插件，直接启动一次游戏再退出，让BepInEx把它的基础目录结构生成完整。

第三步，解压XUnity.AutoTranslator。从插件的GitHub Release页面下载与BepInEx对应的版本，解压后把内含的XUnity.AutoTranslator文件夹整个放到BepInEx/plugins目录下。

第四步，配置。启动游戏，插件会生成默认配置文件。退出游戏，打开AutoTranslatorConfig.ini，把Language改成zh-CN，Endpoint改成BingTranslate，缓存保持开启，先把字体替换关掉，其他保持默认。这一步的核心理念是“先跑通再优化”，不要一上来就改一堆参数，否则出了问题很难判断是哪一处配置引起的。

第五步，重新启动游戏，进入任意有文本的场景。正常情况下，几秒钟后英文/日文原文会陆续变成中文。如果你玩的是日文游戏，还会发现文本出现顺序是先原文后译文，这是因为翻译请求需要一点网络往返时间。此时打开BepInEx/LogOutput.log，能看到插件输出的翻译日志，包括正在翻译的文本、请求的端点、耗时等信息，这些日志后面排查问题特别有用。

第六步，验证缓存。玩一小段后退出游戏，打开插件的Translation目录，应该能看到按语言划分的缓存文件夹，里面已经有刚才翻译过的文本记录。能走到这一步，说明整个管线已经通了。

4.2 为什么有时要等好几秒才出中文

很多人在第五步会被“等待时间”吓住，怀疑插件是不是卡死了。其实首次运行的前几秒，插件做的事比看起来多得多。它要向翻译服务发送一段段文本，等待响应，再把译文回填到游戏界面。如果游戏同一个画面里塞了几十段文本，而配置里的并发数又比较保守，队列消化需要时间，体感就是“翻得慢”。

我自己有一个经验参数组合：玩剧情密集的游戏，内容量大、句子短、重复多，我会把并发调到10到12，间隔调到100毫秒，这样一屏多文本也能快速消化；玩文本量小的游戏，比如操作菜单为主的，并发保持默认就足够了。但要注意，并发不是越高越好，我试过把它调到30，结果某个翻译端点直接开始返回限流错误，翻译质量没变差，但日志里全是一串一串的错误，反而不如之前稳定。

缓存是另一个被低估的加速器。第一次进游戏时翻译慢，第二次进同一个场景，几乎瞬间就出中文，这就是缓存命中的效果。经验是别频繁清理缓存目录，缓存文件夹哪怕积累到几万条记录也不用太担心，文本文件本身占不了太多空间。但反过来，如果你怀疑某些翻译内容已经在缓存里变成“错误翻译”了，那就要找到对应词条手动修改或者删除，而不是清空整个缓存。

5. 进阶玩法：离线词典、文本转储与Mod翻译

5.1 离线词典与自定义词条：让专有名词不再“乱翻”

在线翻译能解决大部分通用句子的翻译，但游戏里的人名、地名、专属术语，在线翻译往往翻得莫名其妙。比如奇幻游戏里的城市名，很可能被直译成一句没有意义的词组。这时候离线词典就是你的控制开关。

插件的Translation文件夹下，会有一个与目标语言对应的子文件夹，把自定义词条放进里面就可以。支持的格式很直观，每行一条，等号左边是原文，右边是译文：

Alduin=奥杜因 Whiterun=白漫城 The Elder Scrolls V: Skyrim=上古卷轴5：天际

这个机制的优先级很有意思：离线词典里已有的词条，会直接覆盖在线翻译的结果。利用这一点，我可以先把高频的人名、地名、道具名全部写进词典，保证游戏里这些专有名词从头到尾保持统一。游戏更新后文本变了，离线词典文件还在，只需要补充新出现的词条即可。

更进阶的用法是配合正则表达式。词典文件支持按正则规则匹配批量替换，比如把所有的“HP Potion”批量映射成“生命药水”，甚至可以根据上下文做条件替换。这个功能对文本量很大的RPG特别有用，但正则规则复杂，新手建议先从精确匹配的“原文=译文”开始用，跑稳了再学批量规则。

5.2 文本转储：把游戏文本抽出来整理

如果你想追求比机器翻译更好的阅读体验，文本转储功能值得研究。把配置文件里的DumpTranslation临时改成true，插件在翻译的同时，会不断把游戏中实际出现的原文追加记录到一个文本文件里。

这个功能的价值在于，你可以得到一个带上下文的完整文本清单。收集到一定量后，把文本导出，用表格软件打开，手动修改不清楚的翻译，改完再以离线词典的形式放回插件。这样操作下来，同一个游戏内部出现的专有名词、语气词、习惯用语，都能做到全局统一，而不是掉进在线翻译“上一句和下一句翻法都对不上”的坑里。

整套流程其实就是个人汉化的精简版：机器初翻、人工精修、词典回填。规模肯定比不上汉化组几千条文本的工程，但对一个体量中等的单机游戏来说，这个工作流完全可行。我经常在周末挑一个文本量不大的短篇游戏，花半天时间挑重点对话润色一遍，玩起来的感觉完全不同。

5.3 Mod文本与游戏外的扩展场景

XUnity.AutoTranslator还有一个常被忽视的能力：支持翻译Mod新增的文本。很多Unity游戏以Modding著称，Mod会往游戏里添加新的物品、任务、对话。这些Mod文本同样走Unity引擎的文本管线，只要Mod作者没有用特殊的不受拦截的方式绘制文字，插件都能一并翻出来。配置里面跟Mod相关的开关，建议保持默认开启，对原版文本不会有影响，但能覆盖到Mod场景。

说到游戏外，我也用这套工具做过几次Unity原型开发时的调试。当时项目的界面文案只有英文，给客户演示时想临时改成中文，重新打包成本高，直接用XUnity.AutoTranslator注入一次，十分钟就把演示版本的中文界面跑通了。这类用法在个人开发、测试、演示场景里非常实用，相当于把翻译插件用成了“运行期资源替换工具”。

6. 常见问题与排查技巧实录

6.1 高频问题速查表

这几年用下来，XUnity.AutoTranslator相关的问题基本集中在下面几个方向。我整理成一张速查表，遇到问题先对号入座。

这个表解决八成问题没问题。那剩下两成，基本要靠日志定位了。

6.2 排查思路与独家技巧

排查XUnity.AutoTranslator问题的第一步永远是看日志。BepInEx/LogOutput.log记录了插件的加载过程、配置解析结果、每条文本的翻译请求和错误原因。有一次我自己折腾一个老游戏，装完插件完全没反应，第一反应就去翻日志，结果发现插件根本没有被加载，原因是BepInEx版本太老，插件要求的加载接口不存在。换新版本BepInEx后一次通过。这个案例说明，日志永远是最可靠的突破口。

排查的第二个建议是“做减法”。配置项先全部还原成默认，插件也只保留XUnity.AutoTranslator这一个，其他功能插件全部移出plugins文件夹，然后在默认配置下测试。如果默认配置能翻，再一项一项把自定义配置加回去，哪一步出问题，就是哪一项的锅。我见过有人一上来就开十几个插件，结果翻译不生效，最后发现是内存修改类插件和翻译插件的Hook函数互相覆盖了。这个问题不用“减法”，翻一天日志都不一定能找到。

第三个技巧是关于请求参数的。很多人为了让句子翻译完整，把MaxCharactersPerTranslation调得很大，其实没必要。翻译服务对单条文本长度通常有上限，而且长文本翻译耗时长、失败率高。游戏里那些长句，插件会智能分段处理，你只要保持参数在合理范围就行。我记得有一次想翻一个特别长的剧情文本，反而让翻译卡住，后来把单条长度上限调小，句子被拆成多段，反而顺利出译文了。

还有一点容易被忽视：插件不会主动重翻已经缓存的句子。如果你更新了词典，但游戏里那句话还是显示旧的翻译，多半是旧译文还在缓存里。解决办法有两个，要么在词典更新后手动删除对应缓存文件，要么在配置文件里打开OverwriteTranslations开关，让词典覆盖缓存。这里我推荐用前者，因为OverwriteTranslations打开会让所有在线翻译结果也覆盖词典词条，反而可能把精心修改的词条冲掉。

最后分享两个实用经验

第一，一开始装的时候，尽量把“先跑通核心流程”当目标。先别管字体、别管词典、别管Mod，先把翻译验证出来，再逐步叠加工序。很多人第一步就栽在“字体替换+词典+翻译+Mod”同时上，出了问题根本不知道从哪儿排查。我的习惯是先默认配置跑通，成功后再加字体，能正常显示中文了再加词典，每一步都有明确验证点，整个流程会顺很多。

第二，用好缓存目录这个“金矿”。有些游戏你玩到后期，缓存里已经积累了几千条词条，这其实是自己用脚投票生成的一部“游戏术语词典”。我把每个游戏的Translation缓存目录单独备份，同一个系列的游戏之间可以互相复用。比如玩过一代再玩二代，一代缓存里的那些人名、地名，把文件挪过去直接就能命中，二代需要重新翻译的新词条少了一大截，整个汉化过程快到飞起。这个用法不需要什么高深技术，但绝对能让你在朋友面前显得很专业。