[Gal汉化入门教程]#3.1 编码&范围校验修改演示
本节主要是让大家熟悉一下调试器的使用，了解编码和编码校验范围是什么，试着汉化一个简单的Gal游戏看看。
#0x0 瞄一眼目录
首先我们拿出今天的实验对象
みくの夏休み
来看看她的游戏目录
首先我们可以注意到找个游戏并没有封包，这也是我选择这个游戏的原因之一。
然后我们看标了
1
的部分，是三个文件夹，里面是一些图片和音频，这里就不展示了
看到
2
这是游戏是脚本部分，里面包括了控制游戏音频播放和背景以及文本的代码
编码方式为Shift-jis，且没进行任何修改，直接就是纯文本。
看到
3
这里，nscmake2.exe应该是游戏开发的时候用的，这个我们可以不看
nscr.exe是游戏的主程序部分，编码的读取，文本读取，整个游戏引擎的框架就封装在里面
nsogg2.dll和nspng.dll 我们看名字可以猜测是和ogg png解码有关系。
#0x1 打开游戏看看
双击nscr.exe，打开游戏
再点击，はじめる 进入游戏剧情
进入游戏后我们发现，第一段文本和我们刚刚打开的00.txt里的内容是对应的
并且没乱码，说明游戏内指定了Shift-jis读取
好了，我们可以点右上角的x关掉游戏了
但是这个时候就蹦出来了个乱码的提示
点yes就可以关掉游戏了，这个部分的文本我们可以推测一般不是在那几个.txt文件里
因为刚刚里面的文本都已经正确解析了，当然也有可能就是了。
这个时候我们一般是推测位于exe里，这个我们后面会具体分析
#0x2 写一点中文进去测试
编辑这部分，上一节已经讲过了，这里就不多说了
想看操作的可以看视频，还没懂的回去看上一节
首先先把这个文件复制一份出来，以免你改废了。
然后开始编辑，这里有两种方案，
第一种是，你每一句都翻译出来，或填别的中文也可以
只要整出一堆中文出来，方便我们测试就行
第二种是，我们把日文部分用GBK的编码方式塞回去，
注意千万不要以为塞回去还是日文就觉得编码什么都没变
，
这里我们是已经把日文编码转换到中文编码了，也就是说对应的十六进制也变了。
我这就两种方法都用一下，方便演示。
修改好后保存，提示我错误
注意41行，是日文，有个〜符号，这个符号GBK下没有，
我们可以替换为 ~ 但是这个符号貌似和游戏内的脚本符号有冲突，
~ 这个符号后面的字符都会无法识别，建议放弃这个符号
当然你这写 ~ 这个符号是可以正常保存的，但是游戏内会识别错误。
我们直接把它删了，就正常保存了
注意下一这个乱码后的 丂 这个是一个空格
现在打开游戏看看
不仅中文乱码了，日文也乱码了，其实刚刚塞进去的日文也是中文编码的
再看看我们没修改过的部分
正常显示
#0x3
修改编码
把nscr.exe拖入OD
按下Ctrl+N 并选中弹出的窗口，输入createfonta 右键在函数上切换断点。
OK，断点下完了，我们来打开游戏
按F9
打开游戏后选中 はじめる 开始游戏
然后游戏就卡住了
我们看OD的右下角的框，非常经典的 CreateFontA 的结构，来到它的返回处
我们看到这个汇编代码 push 0x80，对应的就是我们右下角的 charset=128
80是128的十六进制表示
80对应的就是Shift-jis编码读取
86对应的就是GBK编码读取
这个时候我们只要把80改成86即可
修改完了我们保存
运行保存后的exe
现在是不是就显示正常了
但是我们继续往下点，原来没修改过的部分Shift-jis编码的文本就乱码了
这里我就要强调一点了，如果你是汉化的话，
后面有一部分你没汉化，但是要发布，遇到这种情况，
就要把日文部分文本用GBK编码回去，不然人家玩到你没翻译部分就是这样一坨乱码。
我们现在来滑一下鼠标滚轮，你会发现，backlog部分乱码了
但是这乱码是我们修改的地方乱了，我们没修的地方没乱
其实backlog部分也有个 CreateFontA 的 charset 要改
我们把修改过exe拉入OD，还是对 CreateFontA 下断点
卡住后我们按F9让游戏正常运行，直到翻页
正常运行后我们在游戏内滑，滑轮，呼出backlog界面
结果游戏就卡住了
(注意一下游戏必须翻到第二页才能用滚轮打开backlog）
再次观察这个 CreateFontA 的结构，发现 charset 还是128也就是80
我们刚刚明明改了啊？
为什么呢？
其实这个 CreateFontA 的位置不止一处，你仔细观察地址，和之前的是不一样的
我们再次把80改为86后保存
其实这个游戏有4处 CreateFontA 的charset=128的，我们已经改了两处了，还有两处呢？
其实还有一处在文本显示的地方，就是我们第一次修改游戏的80的地方
另外一处在backlog的地方
你连续按F9观察返回处80的地址，你会发现有两个不同的地址
不过另外两处作用我也不太清楚，改了和不改都没什么区别，大家可以自己去看看。
最好可以改一下，可能是游戏某些选项的。
#0x4 编码校验范围
这个游戏比较奇葩，虽然有经典的日文编码校验范围的代码，但是并没有启用
所以我们直接写中文也没有任何问题
我们直接搜索常量9F就能找到
有好几处
由于这个游戏并没有实际用到，所以没办法演示
如果大家遇到有校验范围的游戏
搜索常量9F或或A0就可以定位到
给这些常量对应的汇编代码下断点，如果断下来说明游戏就用到了
这样我们就可以修改对应部分的范围
这么修改呢?
通常我们是把图上的9F改成FE，FC改成FE
有的时候也需要把81改成A0，E0改成A0
这个边界比较麻烦，后续讲到一些需要修改边界的引擎会继续讲。
文末也会贴几个链接，有兴趣的可以去看看
#0x5 字体
相信大家也注意到了，这个字体确实有点丑
那么如何修改游戏内的字体呢？
我们回看之前断 CreateFontA 的截图
有个 FaceName = "俵俽 僑僔僢僋" 的玩意
俵俽 僑僔僢僋 这个是乱码的日文编码，正确解码应该是 ＭＳ ゴシック
这是一个日文常见的字体名
回看我们前面几次断在 CreateFontA 的截图也可以发现，
这个玩意的前面的地址始终是 19C9C4
这个时候我们可以直接在exe里搜索
把之前修改过的exe拉入winhex
选中搜索十六进制字符串
输入 826C827220835383
就是这玩意对应日文编码的十六进制字符串
只输入前面一部分即可，完全输入也可以。
winhex 按F3搜索下一个结果
这个时候你发现，居然有4个搜索结果
那我们应该换修改哪一个呢？
其实，没必要纠结，全部换掉即可，如果出问题，我们再一个个换，只有4个也不麻烦
选中这个替换十六进制字符串
我们要把 ＭＳ ゴシック 换成 黑体，注意这个 黑体 要GBK编码对应的十六进制
从十六进制的角度，我们就是把
826C827220835383568362834E
换成
BADACCE5
还记得我们之前说过的吗？要保存长度一致
所以我们正确的替换方法应该是
826C827220835383568362834E
换成
BADACCE5000000000000000000
然后另存为
打开游戏看看
我们发现字体还是没变啊？
这是为什么呢？
其实一般的Gal游戏引擎都会在运行的时候生成一个配置文件，里面会写入字体的信息
因为我们之前已经运行过游戏了，游戏生成的配置文件写的还是那个日文字体
这个时候我们需要删除游戏的存档，也就是配置文件，
这种情况常见于KRKR引擎和CS2引擎，
把这个配置文件删了后再次运行
这样就完成了。
#0x5
菜单的汉化
游戏内的文本我们总算是处理完成了，但是这个游戏菜单的文本我们要怎么去处理呢?
我们先看第一个框，这个框里的文本是我们很常见的，处理方法也很标准
我们需要一个叫 ResourceHacker 的软件，用它打开exe
比如我们修改一个文本，修改好后点那个绿色的箭头，之后再另存为。
效果就有了
还有一些游戏弹窗的内容，在那个Dialog里
里面可以修改字体大小，字体，文本，有兴趣可以自己去看看
至于那个 2 部分呢，其实就是一张图片而已
直接去修图就可以了，当然有些时候一些引擎也可能是会在脚本里写。
#0x6 其它部分的汉化
说了这么多，其实还是有一些部分文本的汉化我们没说到，
比如最开始那个，关闭游戏的提示框
我们先转区运行游戏
得到这个原来的日文是
終了しますか
我们把这段话转换为日文编码的十六进制
8F4997B982B582DC82B782A9
我们在winhex里搜索这个十六进制字符串
可以得到唯一的结果
现在我们只要修改这个就可以了
我们还是用十六进制字符串替换的方法来修改
8F4997B982B582DC82B782A9
替换为
BDE1CAF8D3CECFB700000000
BDE1CAF8D3CECFB7是中文编码的 结束游戏
好了保存运行看看
OK，完成了，别的地方也是同一个道理，只要你找不到的就可以试着转换为十六进制字符串在exe里面搜索一下看看。
说了这么多，我们也算是把这个游戏汉化的程序部分完全做完了
这边贴几个参考链接有兴趣的可以去看看
https://www.iteye.com/blog/shera-409666
https://bbs.pediy.com/thread-260061.htm
https://blog.csdn.net/madonghyu/article/details/103572482
https://blog.csdn.net/luozhuang/article/details/3260235