【汉化资料】论内核和外挂汉化

shane007

转自某汉化论坛      
+ M$ {3 C! E- V9 Q* Rhttp://hunking.game.topzj.com/thread-26420-1-1.html
6 M5 _! G$ e# E
2 g4 n! d4 L0 h6 ~. D  j: L; `+ F! _
2 X, e+ s8 Q  Z' J' O8 f1 w7 F      首先，我觉得不少人对内核和外挂汉化，都有一种概念性的误解，认为汉化文件是很明显放在外面的就叫做外挂汉化，覆盖英文原文件的或者藏在游戏某个很深子目录的就叫做内核汉化，呵呵，这种定义法未免有些过于儿戏。拿我们团队的通常做法为例，一般都是把所有汉化资源放入HunKing中，然后这个文件夹独立放在游戏根目录下，与英文原文件互不干扰，我觉得这可能就是很多人认为我们的汉化是外挂式汉化的原因，因为的的确确，这个汉化包是“挂”在其他游戏文件外面的。但是不知道抱有这种概念的人有没有想过，我们既然能把它单独做成一个文件夹，那么直接拿出来覆盖英文文件是不是更容易，退一万步说，即便非要放到一个单独文件夹内，我们把这个文件夹藏到游戏随便那个四五级子目录里面让别人很难发现，似乎也不是难事吧，不就是更换下路径么，那么是不是这样一来，外挂式汉化就变成内核汉化了，或者说想外挂就外挂想内核就内核，看最后准备以什么形式发布了。那所谓外挂和内核的区别岂不是成了一个笑话，有什么可值得区分的，无非就是文件路径不同而已。
/ v* p' I, v4 K4 B+ J6 [
      汉化交流空间其实外挂和内核汉化的区别不在于文件存在形式，而在于中文显示机制的实现方式。具体因为牵涉到太多的技术内容怕说不清，我举一个简单例子吧，好比做糕点需要模具，把面倒在模具里烘烤就成了糕点。英文游戏本身的显示机制相当于一个圆形的成型模具，那么作出来的都是圆形糕点--显示英文字符。现在要让游戏显示中文字符，也就是作出个方形糕点来，怎么办，那此时就有两种思路：

- p- i9 l6 D; B; U第一种，拿起凿子把这个模具形状改了，把圆形凿成方形，然后把面倒进去，出来的不就是方形糕点了么。在汉化中，这种思路就可以叫做内核汉化，因为需要首先分析游戏内核的显示机制，彻底搞清楚它的显示方式后修改对应代码，才能令其显示中文，好比上面说的是个模具改型的过程，这种方式改变了游戏内核的显示机制，所以被叫做内核汉化。

! W/ o& R- ?- x第二种思路，也可以不改模具，而在糕点生产线最后加一个方形框子。所有造出来的圆形糕点被那个方框一挤，被强制挤成了方形，呵呵。对应到汉化技术中，这种思路就是外挂汉化，无论游戏本身的显示机制如何，最终这些字符总要通过显卡显示出来吧，那就直接在这里截取字符转换处理。外挂这个词其实很形象，因为这个工作方式的确是没有触及游戏内核的工作方式（糕点模具还是圆的），只是在最后显示过程中处理（生产线末端加挂方框）。
: y! E+ N4 s! i5 Z
内核和外挂的区别，关键在于你怎么把这个糕点做成圆形（显示机制），而不在于你做好以后把圆形糕点到底放在那个箱子里（安装路径）。一个内核汉化包，别说放在单独文件夹里了，哪怕直接塞到C盘根目录或者其他什么匪夷所思的地方，它也仍然是个内核汉化包，当然我想也没有什么人会把文件路径做得这么奇怪，除非是有意跟用户开玩笑了，呵呵。

& @/ [0 ]* |2 V: L& b! ^当然了上面都是举例，我没有什么食品加工经验对糕点生产不了解，可能这个例子有些荒谬，而且汉化具体技术实现过程中各种问题比糕点这个复杂得多，大家也不必过分深究，重要的是明白这两种思路的基本区别就好。相比之下，内核汉化比较花时间，因为对待每个游戏都要深入分析它的显示机制，不同游戏的显示机制不可能完全相同，有时候甚至差别非常大，所以这个分析过程会很花时间，但是一旦琢磨透了那个机制，改写代码后中文字符显示效率也比较高（圆形糕点一次成型）。外挂汉化呢，基本不怎么需要分析游戏内核，可以说任何游戏拿过来就能显示中文，但有个问题就是，这个外挂处理的过程会比较占用资源，如果文字量很大的游戏，一下子要进行那么多文本处理和判断，游戏会变得很慢（方框来不及挤压过多糕点），搞不好游戏会整个被卡死，这也就是你上面说的“外挂式汉化包都会把游戏拖得很慢”，的确会有这个问题存在，但不是绝对的，要看游戏文本量多大，另外要看这个外挂模块的执行效率，如果代码写得非常出色，运行游戏不会太慢的。
; {6 r1 Z$ c. k& ^9 L
基本就是这样了，其实我个人建议，这些内核外挂思路都是属于汉化者本身考虑的问题，对于玩家来说，大可不必追究这个汉化到底是内核还是外挂，因为没有意义。玩家应该关心的是这个汉化包加载后，游戏速度如何，汉化本身是不是完整，文字翻译是不是通顺典雅，汉化后的游戏有没有理解障碍，我觉得这才是切乎玩家利益的问题。至于汉化包本身是怎么做出来的，跟玩家没有丝毫关系，谁也犯不上每吃一碗饭还要先想想这个大米是人工播种还是机器播种的，呵呵，完全没意义的事情。汉化这个东西，千条万绪归结到一个道理，就是最后看在游戏中的表现，不论白猫黑猫要抓住耗子才算数吧，片面强调某个中间环节的优劣是没有意思的，而且这两种技术方式我也说了各有优劣，对文字量比较大的游戏比如战略或策略游戏，内核汉化能够保证中文版游戏运行速度不会太慢，而且对中文字符的显示支持会很完美（因为修改了显示机制）。而对于没什么文字的游戏，比如FPS或者动作游戏来说，外挂汉化能够提高制作汉化包的速度，不怎么需要分析游戏内核拿过来就能做，只要翻译文本就行，由于文字量小，最终也不会减慢多少游戏速度，对于希望先睹为快的玩家同样也是福音。
8 q2 ?  b* A+ g9 @+ M
       关于我们团队自己的汉化包，到目前为止我们做的每一个汉化都是内核汉化，还没有发布过外挂式汉化作品，不过这是因为我们做的游戏基本都集中于历史题材的战略或策略游戏，文字量都很大，上百万字翻译量的项目都算中小型项目，这种题材选择范围注定了我们很苦命，每次都要很辛苦地去分析内核，呵呵。尽管目前情况如此，不排除以后我们也会用外挂汉化，如果某天我们也做到了动作或者射击游戏，游戏本身根本就没几个字，那也就犯不上花精力分析内核了，直接加一个模块处理中文字符就行，所以也不排除做出外挂汉化包这个可能。一般来说，我们对技术问题采取实用主义，能逮住耗子就是好猫。技术本身没有优劣可言，任何一种技术的存在都有其合理性，关键看使用者如何妥善运用，我们也没有必要规定自己必须以某种方式做汉化，这样无异于划地自囚。
- g1 \  x& r3 M: ~  k1 C
, F( g" v1 y( i, o6 n7 K      至于采用HunKing文件夹放置汉化资源的形式，其实我们是特意做成这样独立形式的，因为这样可以不改变英文游戏文件，玩家可以随便自由选择用中文版还是英文版，执行hunking中的中文exe进入就是中文版，执行根目录下的英文exe那就是英文版，有的玩家喜欢双语切换着玩，呵呵，这样就会很方便，而且这种方式要卸载汉化非常容易，把那个HunKing文件夹直接删除就行了，没有任何其他麻烦。从用户反馈来看，这个方式还是很受欢迎的，因为结构很简单还可以自由切换语种。而且我们自己调试和修正汉化包也很方便，发现某个地方有问题可以随时退出后切换成英文版，看看原版游戏这里是不是本身就有错误。如果采用了覆盖英文原有文件的方式，那么就要来回备份文件很麻烦，汉化后期测试中经常一天要修改上百处地方，要每次都这么备份覆盖，修正人员累也累死了，还非常容易忙中出错。此外还有些出于游戏原版著作权问题上的考虑，不太想对原版文件进行什么改动，免得被人说成不尊重游戏制作公司。总之采取什么方式放置汉化资源，那都是很小的枝节问题，所谓内核和外挂汉化不是根据这个文件放置路径进行区分的。