第一篇：关于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 类软件的判断和资源分类。