如何汉化软件中的字符串.docx

第一篇：关于ASCII字符串 一、ASCII字符串的定义和简介 ASCII字符串-在汉化界里，把在一个程序中不能使用资源方式来提取的,但是在运行时会显示出来的提示信息称为ASCII字符串(一般称为ASCII码)。在汉化软件过程中，ASCII字符串的汉化一直是最麻烦和最容易出错的地方，这是由于ASCII字符串一般都分布在程序中的代码段或数据段里，不属于资源部分，不能使用标准的资源提取工具提取出来。由于程序执行代码也在代码段里，并且字符串往往并不是集中固定在某一个地方，所以很难分辨是否为需要翻译的字符串。 ASCII字符串一般划分为C语言字符串和Pascal语言字符串： 1、C语言字符串指的是在字符串前后都有一个ASCII码为“00”的字符来与其它代码区分开来（图1）： 如：00 69 73 6B 2E 00（disk） 。C语言字符串主要出现在程序的数据段部分。一般用C语言编写的程序（注：典型的是用VC+来编写的程序）最多C语言字符串。由于C语字符串在数据段里往往会集中一处，所以查找起来比较方便。 2、Pascal语言字符串只有用Pascal语言来编写的程序才有（注：Delphi就是使用Object Pascal语言）。是指字符串后面不但有至少一个ASCII值为“00”的字符分开，且在字符串第一个字符前三个字符都是 00，在前第四个字符是该字符串的长度标识符，前第五、六、七，八个字符是ASCII码值为“FF”的字符，如：FF FF FF FF 02 00 00 00 C4 E3（图2）。 有这么多的特点，判断是否为ASCII字符串比起C语言字符串容易多了，不过由于Pascal语字符串分布在整个代码段里，所以查找起来就比较难了。 二、汉化时遇到的问题 由于ASCII字符串在代码段或数据段中，所以汉化ASCII字符串有其的特殊性: 一、要保证程序的运行，就不能增加程序文件的大小，也就是不能直接增加ASCII字符串的长度，否则程序就会出错而不能正常运行。 二、难以判断是否为可翻译或需要翻译的字符串。 鉴于ASCII字符串的特殊性，所以目前汉化ASCII字符串时，绝大多数都是使用十六进制编辑器来手动修改，不但汉化需要的时间长，并且很容易出错，一个字-烦！ 三、ASCII字符串提取工具的介绍和分析 难道就没有一个程序可以用来自动提取ASCII码吗？当然有了，但是目前汉化界的所有ASCII码提取工具都是基于一种提取方法，使用的判断条件大都是：字符串全是字母或数字，字符串前后都有值为00的字符，字符串要有一定的长度，高级一点的提取工具会设置不提取包含某些字符的字符串(这样可以除去一部份不需要翻译的字符，如WIN32API函数，但有时反而不提取不到应该提取的 ASCII字符串)，更高级的提取工具可以判断字符串是否为英文单词，并且可以设置要提取的字符串中包含英文单词的数量，提取的范围固定在代码段和数据段里（这样提取出来的字符相对准确，可以除去WIN32API函数以及一些代码。是所有判断方法中准确性最高的一种，但是编写程序的难度大，提取速度慢，因为要有一个英文库，所以此类的提取工具很少）。在提取时，如果满足所有提取条件的字符串，就提取出来。虽然这样，但结果还是只有很少的汉化高手使用，原因是提取效果还是差强人意。以及最重要的是不能增加字符串长度。 四、如何增加ASCII字符串的长度 要是按修改资源的方法来增加字符串长度是不行的，因为那样虽然增加了字符串的长度，但是文件长度也增加了，也就是代码或数据的位置改变了。那么，程序运行时就会产手错误，而使汉化告败。可见，增加字符串的长度，是首先要保证程序可以正常运行，所以不修改程序的长度，而是修在程序内部利用一些空余的位置来放罢新增的字符，由于语言字符串和Pascal语言字符串不同，所以把增加字符串的技巧分为四章，第一章写的一般情况下增加语言字符串的长度，第二章是写在比较特殊的情况下使用的技巧，第三章是增加Pascal语言字符串的长度的技巧，第四章则是在比较特殊的情况下使用的方法，在看完四章后，相信你汉化软件时，对 ASCII字符串一定能更完美地汉化，而不是以前的“是”或“否”了。 五、要了解的知识 在这里，我将介绍一下增加ASCII字符串长度的主要原理，以及将使用一个辅助计算的小工具：代码转达换器。在WIN32程序中，显示一个提示信息都是通过调用 API来完成的，调用的时候，会先把字符串在内存中的偏移地址移到一个寄存器中，然后调用API函数，而API函数根据偏移地址找到字符串在内存中的位置。我们在调试一个程序时就可看到（图3）： 这是用在调试DELPHI程序时的一个函数MessageDlg，由上面我们可以看到，字符串在内存中的地址是固定的，其地址在编译时就已经以代码的形式存放到文件中，那么我们可不可以通过修改这个偏移代码来使其显示另一个字符串呢？事实证明是可以的，这就是汉化 ASCII字符串的出路了，我们可以通过修改它来使我们可以自由地增加字符串长度，而又可以使程序可以正常运行。 由于程序在载入时有一个基地址，程序载入时，是在基地址开始加载的，所以载入后字符串在内存的位置与在文件中的位置不同，我们可以表示为：字符串在内存中的地址=字符串在文件中的偏移+基地址。可见，我们只需要知道基地址就可以计算出调用偏移代码（注：意思是程序调用字符串时的偏移代码）了。但是基地址是不是固定的，数值是多少呢？通过查看了数十个软件，基地址并不是固定的，使用VC或DELPHI编译的程序各有一个比较固定的基地址，这是由编译器来确定的，VC的基地址是400000H，而DELPHI则是400C00H，现在我们只需要把字符串在内存中的偏移加上基地址就可以知道调用偏移代码了，但是由上图可以看出，这与在文件中的代码并不同，如在内存中的地址为“00442F00”，则在程序中用代码“002F4400”表示，这是把内存地址经过位移后的代码，这就要用代码转换器来计算了。 六、关于代码转换器 代码转换器就是为了便于在调用偏移代码和字符串偏移之间转换之用（图 4），只要把字符串在文件中的偏移（十进制在十进制输入框中输入，十六进制在十六进制输入框中输入）输入到代码转换器中，代码转换器就可以在调用代码框显示出调用偏移代码： 你也可以把调用偏移代码在调用代码输入框中输入，这样就会在十进制和十六进制输入框里分别计算出字符串在文件中的偏移，DELPHI程序选择框是由于VC和DELPHI的基地址不同，计算的基数也就不同，所以如果你计算的是DELPHI程序，就选取这个选择，否则就不用理了。十进制输入框与十六进制输入框纯是数制转换，只有调用代码输入框是不同的数值，在各个输入框按下回车就会自动清除各个输入框的数字，可以进行新的计算，该软件可到汉化新世纪下载兵家云：“知己知彼，百战不殆”。这句话同样也适用于我们进行汉化工作。当我们在进行汉化之前，根据不同是资源类型针对性地采用不同的汉化工具，往往可以达到事半功倍的效果。在这一部分中，我们要了解的就是软件的几种常见资源格式。由于我并非专业程序员，因此，对各种资源的格式仅从汉化者的角度出发，同时也是按照汉化界的习惯说法进行说明，有错误之处，还请各位高手指点。-就目前而言，常见的应用程序大都使用 Visual C+（今后简称为VC）、Borland Delphi（今后简称为Delphi）和 Visual Basic（今后简称为VB）这三种语言之一进行编写，由于目前对 VC 和 Delphi 编写的软件的汉化技术较为完善，而 VB 的汉化实际上正处于起步阶段，因此，我们在进行说明的时候，把 VB 资源与其他两类分开，单独讲述。同时，在进行资源判断的时候，我们需要用到以下两个工具软件：ExeScope 和 FileInfo。这两个工具可以在我主页的汉化工具栏目中找到最新版本的下载，或到汉化新世纪下载。-ExeScope 是一个备受汉化人推崇的资源编辑器，在后续章节中，我们会逐步了解它强大的功能。你甚至可以完全使用它来进行软件的手动汉化，只是这样一来，汉化软件相对就累多了。想当年，我就用它一点点“啃”了几个软件，真够累人的。下面我们就结合 2xExplorer 和 PowerArchiver 2000 两个软件来说明利用它判断资源的方法。-首先，我们判断出这两个软件的主文件分别是 2xExplorer 和 Powerarc.exe，别告诉我你不知道如何判断主文件哦。接着，我们用 ExeScope 分别打开这两个文件，如下图所示： 图一 图二 -大家可以看到，在图一当中，资源部分包括位图、菜单、对话框、字串表、快捷键列表、光标、图标、版本、对话框数据、工具栏等类型的资源。一般情况下，标准的VC软件就包括这些类型的资源，在这当中，需要我们汉化的资源往往就在菜单、对话框和字串表里面，而在大部分的软件中，版本这一部分通常也包含少量可汉化的信息。至于其中的对话框数据部分，通常是一些对话框的下拉列表选项的资源，其中也包含一些需要汉化的资源。当然，并非所有的程序都包含所有类型的资源的。-我们再看图二，在其资源部分除了在 VC 中能够找到的对话框、字串表、版本等资源外，多了一种叫 RC 数据的资源。其实，这就是标准的 Delphi 程序的资源形式。在 RC 数据当中，基本包括了程序运行当中出现的菜单、对话框等等资源，这种格式的资源，通常称为窗体或表单，其中需要我们汉化的主要有 Caption、Hint、Strings、Filter 这几部分。Caption 通常是菜单项、按钮文字等；Hint 通常是鼠标提示或状态栏提示内容、Strings 通常是一些较长的屏幕字符或其他的下拉列表等选项、Filter 通常是文件过滤器。-通过 ExeScope 查看到的这两种资源的不同情况，我们基本能够判断出 VC 和 Delphi 这两种类型的软件。而在 ExeScope 中能看到的资源，我们通常称之为标准资源。-在实际汉化过程中，往往在我们汉化完所有的标准资源后，程序运行时还会出现一些英文信息，而且，在所有的标准资源中也找不到这些信息。这又是为什么呢？通常，我们认为是程序员在编程当中把部分信息包含在执行代码中，而并非使用标准资源格式。在汉化界，我们称之为 ASCII 资源。这一部分资源基本上在所有的资源编辑工具中都无法查看或修改。这一部分的汉化，也是最容易出现由于汉化而影响软件功能的“过度汉化”现象的地方。但是，要实现完美汉化，这也是关键所在。由于这种资源的特点，其汉化方法在很大程度上依赖一些 HEX（16 进制）编辑软件。有关这一部分的汉化，我们在后续章节中再进行叙述。 -介绍完 VC 和 Delphi 的常规判断方法和资源类别后，我们下面要讨论的是 VB 类软件的判断和资源分类。在通常情况下，当我们用 ExeScope 打开 VB 类软件的时候，我们是看不到那么多类似 VC 或 Delphi 类软件的标准资源的，通常只包括图标和版本这两种标准资源。但是，并非所有看不到标准资源的文件都是 VB 类软件，有些 VC 或 Delphi 类的文件中，由于资源并不在我们所打开的文件中，也会出现看不到资源的情况。此时，我们可以通过查看文件中的“导入”部分来进行判断，如图三所示。这是用 ExeScope 打开 VoptMe 5.10 的主文件 VoptMe.exe 之后看到的情况。我们可以在“导入”部分中看到有“MSVBVM50.DLL”这一部分。的确，这就是判断软件是用 VB 编写的依据之一。就 VoptME 而言，我们可以确定它是用 VB 5.0 编写的，而在有些软件中，我们看到的可能是“MSVBVM60.DLL”，这应该是用 VB 6.0 编写的。当然，在实际操作过程中，我也碰到过用 VB 编写的软件中还包含有字串表这种形式的资源，由于我对VB的资源格式并不十分了解，我也无法肯定 VB 软件具体还会包括什么类型的资源。通过前面所提到的“导入”部分，我们基本上可以判断 VB 类别的软件了。 图三 -判断出 VB 类软件后，我们进一步要了解的是 VB 类资源的形式，由于 VB 类软件一直是汉化界的一个难点，所以，这里所阐述的情况可能并不十分完整，我也只能就目前所了解的情况做个说明。-就目前所掌握的情况，我们认为 VB 类软件基本包括 ASCII 类和 Unicode 类字符这两种资源。其中，ASCII 类主要出现在软件的表单中，体现在操作界面上的就是软件的菜单和对话框部分。这一部分的汉化，与 VC 或 Delphi 类 ASCII 资源的汉化方法有共通之处，但也有它自己的特点，我们在今后再详细加以说明。而 Unicode 部分，主要是软件的各种消息和出错信息部分，就这一部分的汉化，也已经有了较好的工具可以完成。-到此，我们已经基本了解了利用 ExeScope 判断软件类别的方法和其资源的特点。但是，我们这里所说的只是可汉化资源的常见类别，实际上，由于程序员编写软件的风格各异，有时候，一些资源还以其他各种不同的形式出现，比如位图、文本、RTF、HTML 等形式。而这各种不同形式的资源，其存在的方式可能有不同的情况，有的以独立文件的形式出现，有的却是在可执行文件或DLL文件中以特定类别的形式出现。在此，我们也无法逐一