内码转换技术介绍

1、内码转换技术

一、基本概念

GB码全称是GB2312-80《信息交换用汉字编码字符集 基本集》，1980年发布，是中文信息处理的国家标准，在大陆及海外使用简体中文的地区（如新加坡等）是强制使用的唯一中文编码。P-Windows3.2和苹果OS就是以GB2312为基本汉字编码， Windows 95/98则以GBK为基本汉字编码、但兼容支持GB2312。GB码共收录6763个简体汉字、682个符号，其中汉字部分：一级字3755，以拼音排序，二级字3008，以偏旁排序。该标准的制定和应用为规范、推动中文信息化进程起了很大作用。1990年又制定了繁体字的编码标准GB12345-90《信息交换用汉字编码字符集 第一辅助集》，目的在于规范必须使用繁体字的各种场合，以及古籍整理等。该标准共收录6866个汉字（比GB2312多103个字，其它厂商的字库大多不包括这些字），纯繁体的字大概有2200余个。（2312集与12345集不是相交的。一个是简体，一个是繁体）

穞BIG5编

是目前台湾、香港地区普遍使用的一种繁体汉字的编码标准，包括440个符号，一级汉字5401个、二级汉字7652个，共计13060个汉字。Big-5 是一个双字节编码方案，其第一字节的值在 16 进制的 A0～FE 之间，第二字节在 40～7E 和 A1～FE 之间。因此，其第一字节的最高位是 1，第二字节的最高位则可能是 1，也可能是 0。

穞abGBK编码(Chinese Internal Code Specification)

GBK编码（俗称大字符集）是中国大陆制订的、等同于UCS的新的中文编码扩展国家标准。GBK工作小组于1995年10月，同年12月完成GBK规范。该编码标准兼容GB2312，共收录汉字21003个、符号883个，并提供1894个造字码位，简、繁体字融于一库。Windows95/98简体中文版的字库表层编码就采用的是GBK，通过GBK与UCS之间一一对应的码表与底层字库联系。其第一字节的值在 16 进制的 81～FE 之间，第二字节在 40～FE，除去xx7F一线。

穞abUnicode编码(Universal Multiple Octet Coded Character Set)

国际标准组织于1984年4月成立ISO/IEC JTC1/SC2/WG2工作组，针对各国文字、符号进行统一性编码。1991年美国跨国公司成立Unicode Consortium，并于1991年10月与WG2达成协议，采用同一编码字集。目前Unicode是采用16位编码体系，其字符集内容与ISO10646的BMP（Basic Multilingual Plane）相同。Unicode于1992年6月通过DIS（Draf International Standard），目前版本V2.0于1996公布，内容包含符号6811个，汉字20902个，韩文拼音11172个，造字区6400个，保留20249个，共计65534个。

二、一些注解

在此解释一下我们常见的一些汉字内码转换工具：

1、 最常见的是GB2Big5和Big52GB转换工具。这里的GB指是GB2312集。

2、 GBK简体兼容GB2312字符集及其编码。

不规范理解为GB就是GBK简体。

3、 繁

体不等同于Big5，在GBK集中也有繁体，GB12345集也有繁体。但这三者的汉字编码方式不同。Windows95/98/NT/2000（简体中）中使用的都是GBK字符集；繁体版使用的是Big5字符集，在简体版中无法正常显示Big5字符，繁体版无法显示GB字符。

4、 在IE中，进入Big5码网站（如：台湾网站），如果安装有Big5字符集支持，IE会将Big5网页转换成GBK繁体显示，没有则是乱码。IE以GBK繁体显示时，在网页中输入的汉字应当是GBK繁体，以Big5码显示时（乱码），要输入Big5码字符（输入乱码？ 先输入GBK简体----GB码，再使用小工具将其转换成Big5，拷贝，粘贴即可）。

5、 常见的小工具中，可将Big5转换成GBK繁体的不多，可将GBK简体繁体相互转换的也不多。其原因是，他们是将GB2312字符集与Big5字符集建立了对应关系。

三、内码转换原理及方法

内码转换：就是在不同字符集之间建立一种对应关系。

以GBK2Big5（简繁体都可）

如：让字，在GBK中编码是C8C3。如果我们将GBK码表中的字符变成Big5码格式，则C8C3位上的应该是攍och 让攠字的Big5码字符攠琵攠（琵字不是GBK中的琵，而是攠让攠字的Big5码汉字在GBK环境中显示结果）。这样我们读出要转换的文字，在GBK（已经转换成Big5格式）码表中找到它的位置，取出该位置上的字符，将原字符替换即可。

读写字符不是问题。关键是如何在码表文件中对该汉字进行定位和如何将纯GBK码表转换成Big5格式表示的GBK码表。

问题一、对汉字进行定位。

GBK 代码表（按代码顺序排列） 81-87 88-8F 90-97 98-9F A0-A7 A8-AF B0-B7 B8-BF

C0-C7 C8-CF D0-D7 D8-DF E0-E7 E8-EF F0-F7 F8-FE

81 0 1 2 3 4 5 6 7 8 9 A B C D E F

4 丂 丄 丅 丆 丏 丒 丗 丟 丠 両 丣 並 丩 丮 丯 丱

5 丳 丵 丷 丼 乀 乁 乂 乄 乆 乊 乑 乕 乗 乚 乛 乢

6 乣 乤 乥 乧 乨 乪 乫 乬 乭 乮 乯 乲 乴 乵 乶 乷

7 乸 乹 乺 乻 乼 乽 乿 亀 亁 亂 亃 亄 亅 亇 亊 　

8 亐 亖 亗 亙 亜 亝 亞 亣 亪 亯 亰 亱 亴 亶 亷 亸

9 亹 亼 亽 亾 仈 仌 仏 仐 仒 仚 仛 仜 仠 仢 仦 仧

A 仩 仭 仮 仯 仱 仴 仸 仹 仺 仼 仾 伀 伂 伃 伄 伅

B 伆 伇 伈 伋 伌 伒 伓 伔 伕 伖 伜 伝 伡 伣 伨 伩

C 伬 伭 伮 伱 伳 伵 伷 伹 伻 伾 伿 佀 佁 佂 佄 佅

D 佇 佈 佉 佊 佋 佌 佒 佔 佖 佡 佢 佦 佨 佪 佫 佭

E 佮 佱 佲 併 佷 佸 佹 佺 佽 侀 侁 侂 侅 來 侇 侊

F 侌 侎 侐 侒 侓 侕 侖 侘 侙 侚 侜 侞 侟 価 侢 　

以上是按代码顺序排列GBK码表，共126个区，每区190个汉字。汉字位置的计算如下：

posit = (ch1 - 129) * 190 + (ch2 - 64) - (ch2/128);（第n 个汉字）

posit = posit * 2; （第n个字节）

第一个问题就算搞

定。

问题二、将GBK码表用Big5来表示。

我们可以利用现有的工具，如东

方快车3000，将GBK码表转换成Big5的格式。但实际中有问题，因为GBK较Big5的汉字要多，那么在GBK中有的字符，而Big5中没有的字符在转换中可能被删除，那上面后码表定位就不能用了。而且实际上几乎无法定位。不过我在网上找到了一个以Big5表示的GBK码表的文本（可能是官方的），字符一个不缺。

这个问题也搞定了。

同样我们可以进行

Big52GBKT（繁体），Big52GBKS（简体），GBKS2GBKT，GBKT2GBKS，GBK2BIG5的转化。这里给出Big5码表格式，和定位算法：

BIG-5 代码表 A0-A7 A8-AF B0-B7 B8-BF C0-C7 C8-CF

D0-D7 D8-DF E0-E7 E8-EF F0-F7 F8-FE

（已被转化成

GBK）B0 ０ １ ２ ３ ４ ５ ６ ７ ８ ９ Ａ Ｂ Ｃ Ｄ Ｅ Ｆ

４ 虔 蚊 蚪 蚓 蚤 蚩 蚌 蚣 蚜 衰 衷 袁 袂 衽 衹 記

５ 訐 討 訌 訕 訊 託 訓 訖 訏 訑 豈 豺 豹 財 貢 起

６ 躬 軒 軔 軏 辱 送 逆 迷 退 迺 迴 逃 追 逅 迸 邕

７ 郡 郝 郢 酒 配 酌 釘 針 釗 釜 釙 閃 院 陣 陡 　

Ａ 　 陛 陝 除 陘 陞 隻 飢 馬 骨 高 鬥 鬲 鬼 乾 偺

Ｂ 偽 停 假 偃 偌 做 偉 健 偶 偎 偕 偵 側 偷 偏 倏

Ｃ 偯 偭 兜 冕 凰 剪 副 勒 務 勘 動 匐 匏 匙 匿 區

Ｄ 匾 參 曼 商 啪 啦 啄 啞 啡 啃 啊 唱 啖 問 啕 唯

Ｅ 啤 唸 售 啜 唬 啣 唳 啁 啗 圈 國 圉 域 堅 堊 堆

Ｆ 埠 埤 基 堂 堵 執 培 夠 奢 娶 婁 婉 婦 婪 婀 　

定位方法：

if ((ch2 >= 64)&&(ch2 <= 126))

{

posit = (ch1 - 160) * 157 + (ch2 - 64);

posit = posit * 2 - 1;

}

else if ((ch2 >= 161)&&(ch2 <= 254))

{

posit = (ch1 - 160) * 157 + 62 + (ch2 - 160);

posit = posit * 2 - 1;

}

在这里给出GBK2Big5的C++Builder的程序：

fGBK2Big5 = fopen("pureGBK2Big5byOrder.txt", "rb");

unsigned long i,posit;//把gb码转换为gbkT

unsigned char ch1,ch2;

String sContext;

char chr;

sContext = Memo1->Lines->Text;

i=1;

while(i < sContext.Length())

{

ch1 = sContext[i];

ch2 = sContext[i+1];

if ((ch1 >= 129)&&(ch1 <= 254))

{

if (((ch2 >= 64)&&(ch2 < 127)) ||((ch2 > 127)&&(ch2 <= 254)))

{

posit = (ch1 - 129) * 190 + (ch2 - 64) - (ch2/128);

posit = posit * 2;

if ((posit > 23940*2) || (posit < 0))

{

i++;

continue;

}

fseek(fGBK2Big5, posit - ftell(fGBK2Big5), 1);

fread((void *)(&chr), sizeof(char), 1, fGBK2Big5);

sContext[i] = chr;

fread((void *)(&chr), sizeof(char), 1, fGBK2Big5);

sContext[i+1] = chr;

i +=2;

}

else

{

i++;

}

}

else

{

i++;

}

}

Memo1->Lines->Text=sContext;

2、JSP/Servlet 中的汉字编码问题

网上就 JSP/Servlet 中 DBCS 字符编码问题有许多优秀的文章和讨论，本文对它们作一些整理，并结合 IBM WebSphere Applica

tion Server 3.5（WAS）的解决方法作一些说明，希望它不是多余的。

内容：

问题的起源

GB2312-80，GBK，GB18030-2000 汉字字符集及 Encoding

中文转码时'?'、乱码的由来

JSP/Servlet 汉字编码问题及在 WAS 中的解决

办法

结束语

1. 问题的起源

每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展 ASCII码, 中国的 GB2312-80，日本的 JIS 等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为 SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了 LANG, Codepage 等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为 Locale 信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode。

现在大部分具有国际化特征的软件核心字符处理都是以 Unicode 为基础的，在软件运行时根据当时的 Locale/Lang/Codepage 设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现 Unicode 和本地字符集的相互转换，甚或以 Unicode 为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。

Java 语言内部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序无论是从/往文件系统以字符流读/写文件，还是往 URL 连接写 HTML 信息，或从 URL 连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。

从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode 和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。

2. GB2312-80，GBK，GB18030-2000 汉字字符集及 Encoding

其实解决 JAVA 程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需要了解现有的汉字编码和编码转换。

GB2312-80 是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和 9 区的符号。该字符集是几乎所有

的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是 0xa1-0xfe；汉字从 0xb0a1 开始，结束于 0xf7fe；

GBK 是 GB2312-80 的扩展，是向上兼容的。它包含了 20902 个汉字，其编码范围是 0x8140-0xfefe，

剔除高位 0x80 的字位。其所有字符都可以一对一映射到 Unicode 2.0，也就是说 JAVA 实际上提供了 GBK 字符集的支持。这是现阶段 Windows 和其它一些中文操作系统的缺省字符集，但并不是所有的国际化软件都支持该字符集，感觉是他们并不完全知道 GBK 是怎么回事。值得注意的是它不是国家标准，而只是规范。随着 GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。

GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。GBK2K 从根本上解决了字位不够，字形不足的问题。它有几个特点，

它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。

编码是变长的，其二字节部分与 GBK 兼容；四字节部分是扩充的字形、字位，其编码范围是首字节 0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39。

它的推广是分阶段的，首先要求实现的是能够完全映射到 Unicode 3.0 标准的所有字形。

它是国家标准，是强制性的。

现在还没有任何一个操作系统或软件实现了 GBK2K 的支持，这是现阶段和将来汉化的工作内容。

Unicode 的介绍......就免了吧。

JAVA 支持的encoding中与中文编程相关的有：(有几个在JDK文档中未列出) ASCII 7-bit, 同 ascii7

ISO8859-1 8-bit, 同 8859_1,ISO-8859-1,ISO_8859-1,latin1...

GB2312-80 同gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381, 1383, Cp1383, ISO2022CN,ISO2022CN_GB......

GBK (注意大小写),同MS936

UTF8 UTF-8

GB18030 (现在只有IBM JDK1.3.?有支持), 同Cp1392,1392

JAVA 语言采用Unicode处理字符. 但从另一个角度来说，在java程序中也可以采用非Unicode的转码，重要的是保证程序入口和出口的汉字信息不失真。如完全采用ISO-8859-1来处理汉字也能达到正确的结果。网络上流行的许多解决方法，都属于这种类型。为了不致引起混淆，本文不对这种方法作讨论。

3. 中文转码时'?'、乱码的由来

两个方向转换都有可能得到错误的结果：

Unicode-->Byte, 如果目标代码集不存在对应的代码，则得到的结果是0x3f.

如：

"\u00d6\u00ec\u00e9\u0046\u00bb\u00f9".getBytes("GBK") 的结果是 "?ìéF?ù", Hex 值是3fa8aca8a6463fa8b4.

仔细看一下上面的结果，你会发现\u00ec被转换为0xa8ac, \u00e9被转换为\xa8a6... 它的实际有效位变长了！ 这是因为GB23

12符号区中的一些符号被映射到一些公共的符号编码，由于这些符号出现在ISO-8859-1或其它一些SBCS字符集中，故它们在Unicode中编码比较靠前，有一些其有效位只有8位，和汉字的编码重叠(其实这种映射只是编码的映射，在显示时仔细不是一样的。Unicode 中的符号是单字节宽，汉字中的符号是双字节宽) . 在Unicode\u00a0--\u00ff 之间

这样的符号有20个。了解这个特征非常重要！由此就不难理解为什么JAVA编程中，汉字编码的错误结果中常常会出现一些乱码(其实是符号字符), 而不全是'?'字符, 就比如上面的例子。

Byte-->Unicode, 如果Byte标识的字符在源代码集不存在，则得到的结果是0xfffd.

如：

Byte ba[] = {(byte)0x81,(byte)0x40,(byte)0xb0,(byte)0xa1}; new String(ba,"gb2312");

结果是"?啊", hex 值是"\ufffd\u554a". 0x8140 是GBK字符，按GB2312转换表没有对应的值，取\ufffd. (请注意：在显示该uniCode时，因为没有对应的本地字符，所以也适用上一种情况，显示为一个"?".)

实际编程中，JSP/Servlet 程序得到错误的汉字信息，往往是这两个过程的叠加，有时甚至是两个过程叠加后反复作用的结果.

4. JSP/Servlet 汉字编码问题及在 WAS 中的解决办法

4.1 常见的 encoding 问题的现象

网上常出现的 JSP/Servlet encoding 问题一般都表现在 browser 或应用程序端，如:

浏览器中看到的 Jsp/Servlet 页面中的汉字怎么都成了 ’?’ ?

浏览器中看到的 Servlet 页面中的汉字怎么都成了乱码？

JAVA 应用程序界面中的汉字怎么都成了方块？

Jsp/Servlet 页面无法显示 GBK 汉字。

JSP 页面中内嵌在<%...%>,<%=...%>等Tag包含的 JAVA code 中的中文成了乱码，但页面的其它汉字是对的。

Jsp/Servlet 不能接收 form 提交的汉字。

JSP/Servlet 数据库读写无法获得正确的内容。

隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为 Java font 设置错误引起的）。解决类似的字符 encoding 问题，需要了解 Jsp/Servlet 的运行过程，检查可能出现问题的各个点。

4.2 JSP/Servlet web 编程时的 encoding 问题

运行于Java 应用服务器的 JSP/Servlet 为 Browser 提供 HTML 内容，其过程如下图所示：

其中有字符编码转换的地方有:

JSP 编译。Java 应用服务器将根据 JVM 的 file.encoding 值读取 JSP 源文件，编译生成 JAVA 源文件，再根据 file.encoding 值写回文件系统。如果当前系统语言支持 GBK，那么这时候不会出现 encoding 问题。如果是英文的系统，如 LANG 是 en_US 的 Linux, AIX 或 Solaris，则要将 JVM 的 file.encoding 值置成 GBK 。系统语言如果是 GB2312，则根据需要，确定要

不要设置 file.encoding，将 file.encoding 设为 GBK 可以解决潜在的 GBK 字符乱码问题

Java 需要被编译为 .class 才能在 JVM 中执行，这个过程存在与a.同样的 file.encoding 问题。从这里开始 servlet 和 jsp 的运行就类似了，只不过 Servlet 的编译不是自动进行的。对于JSP程序, 对产生的JAVA 中间文件的编译是自动进行的(在程序中直接调用sun.tools.javac.Main类). 因此如果在这一步出现问题的话, 也要检查encoding和OS的语言环境，或者

将内嵌在JSP JAVA Code 中的静态汉字转为 Unicode, 要么静态文本输出不要放在 JAVA code 中。 对于Servlet, javac 编译时手工指定-encoding 参数就可以了。

Servlet 需要将 HTML 页面内容转换为 browser 可接受的 encoding 内容发送出去。依赖于各 JAVA App Server 的实现方式，有的将查询 Browser 的 accept-charset 和 accept-language 参数或以其它猜的方式确定 encoding 值，有的则不管。因此采用固定encoding 也许是最好的解决方法。对于中文网页，可在 JSP 或 Servlet 中设置 contentType="text/html; charset=GB2312"；如果页面中有GBK字符，则设置为contentType="text/html; charset=GBK"，由于IE 和 Netscape对GBK的支持程度不一样，作这种设置时需要测试一下。

因为16位 JAVA char在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的和servlet运行过程中得到的）是期望的内码，可以用 PrintWriter out=res.getWriter() 取代 ServletOutputStream out=res.getOutputStream(). PrinterWriter 将根据contentType中指定的charset作转换 (ContentType需在此之前指定！); 也可以用OutputStreamWriter封装 ServletOutputStream 类并用write(String)输出汉字字符串。

对于 JSP，JAVA Application Server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。

这是解释 URL 字符 encoding 问题。如果通过 get/post 方式从 browser 返回的参数值中包含汉字信息， servlet 将无法得到正确的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析参数时根本没有考虑 browser 的语言设置，而是将得到的值按 byte 方式解析。这是网上讨论得最多的 encoding 问题。因为这是设计缺陷，只能以 bin 方式重新解析得到的字符串；或者以 hack HttpUtils 类的方式解决。参考文章 2 均有介绍，不过最好将其中的中文 encoding GB2312、 CP1381 都改为 GBK，否则遇到 GBK 汉字时，还是会有问题。

Servlet API 2.3 提供一个新的函数 HttpServeletRequest.setCharacterEncoding 用于在调用 request.getParameter(“param_name”) 前指定应用程序希望的 encoding，这将有助于彻底解决这个问题。

4.3 IBM Websphere Application Server 中的解决方法

WebSphere Application Server 对标准的 Servlet API 2.x

作了扩展，提供较好的多语言支持。运行在中文的操作系统中，可以不作任何设置就可以很好地处理汉字。下面的说明只是对WAS是运行在英文的系统中，或者需要有GBK支持时有效。

上述c,d情况，WAS 都要查询 Browser 的语言设置，在缺省状况下， zh, zh-cn 等均被映射为 JAVA encoding CP1381（注意： CP1381 只是等同于 GB2312 的一个 codepage，没有 GBK 支持）。这样做我想是因为无法确认 Browser 运行的操作系统是支持GB2312, 还是 GBK，所以取其小。但是实际的应用系统还是要求页面

中出现 GBK 汉字，最著名的是朱总理名字中的“镕"(rong2 ，0xe946，\u9555)，所以有时还是需要将 Encoding/Charset 指定为 GBK。当然 WAS 中变更缺省的 encoding 没有上面说的那么麻烦，针对 a,b，参考文章 5，在 Application Server 的命令行参数中指定 -Dfile.encoding=GBK 即可； 针对 d，在 Application Server 的命令行参数中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情况下可以不再指定charset。

上面列出的问题中还有一个关于Tag<%...%>,<%=...%>中的 JAVA 代码里包含的静态文本未能正确显示的问题，在WAS中的解决方法是除了设置正确的file.encoding, 还需要以相同方法设置-Duser.language=zh -Duser.region=CN。这与JAVA locale的设置有关。

4.4 数据库读写时的 encoding 问题

JSP/Servlet 编程中经常出现 encoding 问题的另一个地方是读写数据库中的数据。

流行的关系数据库系统都支持数据库 encoding，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有 encoding 转换。 对于中文数据，数据库字符编码的设置应当保证数据的完整性. GB2312，GBK，UTF-8 等都是可选的数据库 encoding；也可以选择 ISO8859-1 (8-bit)，那么应用程序在写数据之前须将 16Bit 的一个汉字或 Unicode 拆分成两个 8-bit 的字符，读数据之后则需将两个字节合并起来，同时还要判别其中的 SBCS 字符。没有充分利用数据库 encoding 的作用，反而增加了编程的复杂度，ISO8859-1不是推荐的数据库 encoding。JSP/Servlet编程时，可以先用数据库管理系统提供的管理功能检查其中的中文数据是否正确。

然后应当注意的是读出来的数据的 encoding，JAVA 程序中一般得到的是 Unicode。写数据时则相反。

4.5 定位问题时常用的技巧

定位中文encoding问题通常采用最笨的也是最有效的办法——在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字符串的内码，你可以发现什么时候中文字符被转换成Unicode，什么时候Unic

ode被转回中文内码，什么时候一个中文字成了两个 Unicode 字符，什么时候中文字符串被转成了一串问号，什么时候中文字符串的高位被截掉了……

取用合适的样本字符串也有助于区分问题的类型。如：”aa啊aa丂aa” 等中英相间、GB、GBK特征字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，可以尝试着增加连续的英文字母长度）。

5. 结束语

其实 JSP/Servlet 的中文encoding 并没有想像的那么复杂，虽然定位和解决问题没有定规，各种运行环境也各不尽然，但后面的原理是一样

的。了解字符集的知识是解决字符问题的基础。不过，随着中文字符集的变化，不仅仅是 java 编程，中文信息处理中的问题还是会存在一段时间的。

3、Delphi下汉字输入法的编程及使用

许多Windows应用程序的中西文录入界面中，中西文的录入需要反复切换汉字输入法，这样使用起来非常麻烦，下面来介绍一种比较简便的解决方法。本文的程序设计环境为Delphi Client/Server Suit Ver 3.0（以下简称Delphi 3.0）和中文Windows 95。

　　1．Delphi下的Imename、Imemode属性

　　在Delphi 3.0中的Tedit、Tmemo、TmaskEdit等编辑元件在应用程序中经常使用，这三种元件都具有ImeName、ImeMode属性。其中ImeName属性是输入法名称，在对象观察器中对应一个包括当前系统中所有汉字输入法的下拉组合框；ImeMode属性是输入法模式，在对象观察器中也对应一个下拉组合框，组合框中包含imClose、imOpen、imChinese、imDontCare、imSAlpha、imAlpha六项内容。

　　imClose 表示输入法处于关闭状态；

　　ImOpen 表示输入法处于打开状态；

　　ImChinese 表示处于中文输入法状态；

　　ImDontCare 表示若输入法处于关闭状态则打开最近一次使用过的输入法；

　　ImSAlpha 表示输入处于半角状态；

　　ImAlpha 表示输入处于全角状态。

　　2．Delphi下汉字输入法的编程

　　在Delphi 3.0中，中西文录入界面中涉及到的输入元件都具有ImeName、ImeMode属性。在设计录入界面表单时，对其中每一个元件的这两种属性赋值，系统就可以在元件获得焦点时自动打开或关闭所设定的汉字输入法。但是对于用户来说，这种编程方法一点灵活性也没有。若系统所设定的输入法不是用户所喜欢的，那么只好再通过Windows 95的输入法选择器重新选择。其实，通过在Form下放置一个标签及一个下拉组合框的方法就可以灵活地解决这个问题了。本文示例的Form中共放置了四个Label、两个Edit、一个ComboBox、一个Memo及一个Button，下面对这个示例作个说

明。

　　(1)在Delphi中选择File | New Application菜单项生成一个新的应用程序，设定新窗体Form1的属性为：

　　Caption=输入法编程示例；

　　(2)在Form1中添加标签Label1、Label2、Label3及编辑框Edit1、Edit2、Memo1，设定其属性为：

　　Label1.Caption=中文输入编辑框

　　Label1.Font.Size=12

　　Label2.Caption= 西文输入编辑框

　　Label2.Font.Size=12

　　Label3.Caption= 中文多行文本编辑器

　　Label3.Font.Size=12

　　Edit1.ImeMode=ImOpen

　　Edit2.ImeMode=ImDontCare（缺省值）

　　Memo1.ImeMode=ImOpen

　　编程时，一般把输入西文或以西文为主的元件

的ImeMode属性设为缺省值；而把输入中文或以中文为主的元件的ImeMode属性设为ImOpen；ImeName属性值则在程序运行时由用户设定。这个方法的灵活性就在于此。另外，还需要把Edit1.Text、Edit2.Text、Memo1.Lines的值设为空。

　　(3)在Form1中添加一个标签Label4，设定其属性为：

　　Caption = 选择最喜欢的输入法

　　Font.Size=12

　　Font.Color=红色

　　(4)在Form1中添加一个下拉组合框ComboBox1，在对象观察器Object Inpector中选择Events选项卡，双击OnDropDown，对此事件进行编程，其代码如下：

　　ComboBox1.Items.CommaText:=Screen.Imes.CommaText;

　　上面这个语句可以将中文Windows 95中安装的汉字输入法添加到下拉组合框中，它巧妙地运用了TScreen类的Imes特性，而Imes特性本身又是一个Tstring类，其属性Commatext包含了Windows 95已安装的汉字输入法，可以将其直接赋值给ComboBox1的相应属性。如果直接编辑ComboBox1的属性Items来添加汉字输入法名称，则会在应用程序发布时，因用户机器汉字输入法的不确定性造成应用程序的不通用性。

　　在对象观察器中双击OnExit事件，对此事件进行编程，代码如下：

　　Edit1.ImeName:=ComboBox1.Text;

　　Memo1.ImeName:=ComboBox1.Text;

　　(5)在Form1中添加一个命令按钮Button1，设置其属性为：

　　Caption=退出

　　Font.Size=12

　　双击此命令按钮，对Click事件进行编程，代码如下：

　　Close；

　　至此，整个示例的程序设计过程就完成了，保存此应用程序及表单，再进行编译、运行。

　　3．汉字输入法的使用

　　首先在下拉组合框中选择你所喜欢的汉字输入法，将光标移到中文输入编辑框中就会发现所选的汉字输入法已自动出现在屏幕上；再将光标移到西文输入编辑框中，汉字输入法就会自动关闭；如果将光标移到中文多行文本编辑框中，则已选中汉字输入法又自动出现了。

　　从上

面的程序中可以得出，在应用程序的录入界面中，设置一个选择输入法的下拉组合框，并让其控制录入界面中所有可输入项的ImeName属性，既可以做到在中西文录入过程中不必进行录入法的来回切换，还可以做到让用户选择自己最喜欢的汉字输入法，而且这样的录入界面对于用户来说也是非常友好、方便、快捷的。PCC

必须用'标识符，但直接用'会出错

tdataset.filter:='somebodyname='+chr(39)+'李*'+chr(39)

4、VB中字符串中文的问题

字串中文的问题，起於vb的字串是使用UniCode，而我们一般是使用Ascii Code。

这差别在何处呢？UniCode的每个字元长度是2个byte，而Ascii是一个byte，如果说，我将们将VB的字串写入

档案，有时会有意想不到的结果。例如：

Text1.Text = "这是一个abc" len5 = Len(str5)

如果我们的Access资料库有一栏位的长度是10个Byte，所以我们在TextBox中设定MaxLength = 10，但是上面的例子得到的len5是7，而不是我们认为的11，因为不管是中文或英文，vb一律以UniCode来存，所以str5的长度是7个"字元"，而text1最大的长度限制是10，7没有超过10，故使用者仍可输入，但存档时，11个byte超过10个byte，所以会有错。

可是或许有人发现，使用RS232来传资料时，另一端主机是Ascii编码的机器，在vb中我们若使用String来传，一样可以通啊，其实那是vb在传送与接收data时，会做转换，使我们的程式设计较方便，但如果传的资料是Binary时，就头大啦。例如说，以字串的方式来传送资料，当想传Ascii 大於128时，常有些问题，因为ASC(Chr(129))=0，使我们不能用Chr()的指令来放资料。(事实上，您可以使用ChrW(129)来存资料，和使用AscW()来取得值，加个W代表是Word的运算)，这时候，就只有使用Byte Array来做了。1.UniCode转成ByteAryDim byteAry() As Byte Dim str5 As String Dim i As Long str5 = "这abc"

byteAry = str5 For i = LBound(byteAry) To UBound(byteAry)

Debug.Print byteAry(i) '得 25 144 97 0 98 0 99 0 Next i

Debug.Print Len(str5), LenB(str5) '得4 8

所以了，可看出UniCode 的特性，程式应改一下，使用Strconv()来转换 Dim byteAry() As Byte

Dim str5 As String Dim i As Long str5 = "这abc"

byteAry = StrConv(str5, vbFromUnicode)

For i = LBound(byteAry) To UBound(byteAry)

Debug.Print byteAry(i) '得 25 144 97 98 99 Next i

Debug.Print LenB(StrConv(str5, vbFromUnicode)) '得5

2.ByteAry转回UniCode 使用Strconv()转换 Dim byteAry(10) as Byte Dim Str5 as String

byteAry(0) = 25 byteAry(1) = 144 byteAry(2) = 97 byteAry(3) = 98

byteAry(4) = 99 Str5 = StrConv(byteAry, vbUniCode)3.一些有用的函式SubStr() 中文化取子字串，相对Mid()

Strlen() 中文化字串长

度，相对Len()

StrLeft() 中文化取左字串，相对Left()

StrRight() 中文化取右字串，相对Right()

isChinese() Check某个字是否中文字

Public Function SubStr(ByVal tstr As String, start As Integer, Optional leng As Variant) As String

Dim tmpstr As String

If IsMissing(leng) Then

tmpstr = StrConv(MidB(StrConv(tstr, vbFromUnicode), start), vbUnicode)

Else

tmpstr = StrConv(MidB(StrConv(tstr, vbFromUnicode), start, leng), vbUnicode)

End If

SubStr = tmpstr

End Function

Public Function Strlen(ByVal tstr As String) As Integer

Strlen = LenB(StrConv(tstr, vbFromUnicode))

End Function

Public Function StrLeft(ByVal str5 As String, ByVal len5 As Long) As String

Dim tmpstr As String

tmpstr = StrConv(str5, vbFromUnicode)

tmpstr = LeftB(tmpstr, len5)

StrLeft = StrConv(tmpstr, vbUnicode)

End Function

Public Function StrRight(ByVal str5 As String, ByVal len5 As Long) As String

Dim tmpstr

As String

tmpstr = StrConv(str5, vbFromUnicode)

tmpstr = RightB(tmpstr, len5)

StrLeft = StrConv(tmpstr, vbUnicode)

End Function

Public Function isChinese(ByVal asciiv As Integer) As Boolean

If Len(Hex$(asciiv)) > 2 Then

isChinese = True

Else

isChinese = False

End If

End Function

5、动态汉化Windows技术的分析

四通利方(RichWin)、中文之星(CStar)是大家广为熟知的汉化Windows产品,"陷阱"技术即动态修改Windows代码,一直是其对外宣称的过人技术。本文从Windows的模块调用机制与重定位概念着手,介绍了"陷阱"技术的实现,并给出了采用"陷阱"技术动态修改Windows代码的示例源程序。

一、发现了什么?

笔者多年来一直从事Windows下的软件开发工作,经历了Windows 2.0 、 3.0 、3.1 ,直至Windows 95、NT的成长过程,也遍历了长青窗口、长城窗口、DBWin、CStar、RichWin等多个Windows汉化产品。从现在看来,影响最大也最为成功的,当推四通利方的RichWin;此外,中文之星CStar与RichWin师出一门,其核心技术自然也差不多。其对外宣传采用独特的"陷阱" 技术即动态修改Windows代码,一直是笔者感兴趣的地方。

EXEHDR是Microsoft Visual C++开发工具中很有用的一个程序,它可以检查NE(New-Exe cutable)格式文件,用它来分析RichWin的WSENGINE.DLL或CStar的CHINESE.DLL,就会发现与众不同的两点(以CStar 1.20为例):

C:\CSTAR>exehdr chinese.dll /v..................................6 type offset target BASE 060a seg 2 offset 0000 PTR 047e imp GDI.GETCHARABCWIDTHS PTR 059b imp GDI.ENUMFONTFAMILIES PTR 0451 imp DISPLAY.14 ( EXTTEXTOUT ) PTR 0415 imp KEYBOARD.4 ( TOASCII ) PTR 04ba imp KEYBOARD.5 ( ANSITOOEM ) PTR 04c9 imp KEYBOARD.6 ( OEMTOANSI ) PTR 04d8 imp KEYBOARD.134( ANSITOOEMBUFF ) PTR 05f5 imp USER.430 ( LSTRCMP ) PTR 04e7 imp KEYBOARD.135( OEMTOANSIBUFF ) PTR 0514 imp USER.431 ( ANSIUPPER ) PTR 0523 imp USER.432 ( AN

SILOWER ) PTR 05aa imp GDI.56 ( CREATEFONT ) PTR 056e imp USER.433 ( ISCHARALPHA ) PTR 05b9 imp GDI.57 ( CREATEFONTINDIRECT ) PTR 057d imp USER.434 ( ISCHARALPHANUMERIC ) PTR 049c imp USER.179 ( GETSYSTEMMETRICS ) PTR 0550 imp USER.435 ( ISCHARUPPER ) PTR 055f imp USER.436 ( ISCHARLOWER ) PTR 0532 imp USER.437 ( ANSIUPPERBUFF ) PTR 0541 imp USER.438 ( ANSILOWERBUFF ) PTR 05c8 imp GDI.69 ( DELETEOBJECT ) PTR 058c imp GDI.70 ( ENUMFONTS ) PTR 04ab imp KERNEL.ISDBCSLEADBYTE PTR 05d7 imp GDI.82 ( GETOBJECT ) PTR 048d imp KERNEL.74 ( OPENFILE ) PTR 0460 imp GDI.91 ( GETTEXTEXTENT ) PTR 05e6 imp GDI.92 ( GETTEXTFACE ) PTR 046f imp GDI.350 ( GETCHARWIDTH ) PTR 0442 imp GDI.351 ( EXTTEXTOUT ) PTR 0604 imp USER.471 ( LSTRCMPI ) PTR 04f6 imp USER.472 ( ANSINEXT ) PTR 0505 imp USER.473 ( ANSIPREV ) PTR 0424 imp USER.108 ( GETMESSAGE ) PTR 0433 imp USER.109 ( PEEKMESSAGE )35 relocations

(括号内为笔者加上的对应Windows API函数。)

第一,在数据段中,发现了重定位信息。

第二,这些重定位信息

提示的函数,全都与文字显示输出和键盘、字符串有关。也就是说汉化Windows,必须修改这些函数。

在这非常特殊的地方,隐藏着什么呢?毋庸置疑,这与众不同的两点,对打开"陷阱"技术之门而言,不是金钥匙,也是敲门砖。

二、Windows的模块调用机制与重定位概念

为了深入探究"陷阱"技术,我们先来介绍Windows的模块调用机制。

Windows的运行分实模式、标准模式和增强模式三种,虽然这几种模式各不相同,但其核心模块的调用关系却是完全一致的,见图一。

主要的三个模块,有如下的关系:

·KERNEL是Windows系统内核,它不依赖其它模块。

·GDI是Windows图形设备接口模块,它依赖于KERNEL模块。

·USER是Windows用户接口服务模块,它依赖于KERNEL、GDI模块及设备驱动程序等所有模块。

这三个模块,实际上就是Windows的三个动态链接库。KERNEL有三种系统存在形式:Kern el.exe(实模式)、Krnl286.exe(标准模式)、Krnl386.exe(386增强模式);GDI模块是Gdi.ex e;USER模块是User.exe。虽然文件名都以EXE为扩展名,但它们实际都是动态链接库。

<图片>

图1 Windows的模块调用机制

同时,几乎所有的API函数都隐藏在这三个模块中。用EXEHDR对这三个模块分析,就可列出一大堆大家所熟悉的Windows API函数。

以GDI模块为例,运行结果如下:

C:\WINDOWS\SYSTEM＞exehdr gdi.exe Exports: rd seg offset name ............ 351 1 923e EXTTEXTOUT exported, shared data 56 3 19e1 CREATEFONT exported, shared data ............

至此,读者已能从Windows纷繁复杂的系统中理出一些头续来。下面,再引入一个重要概念——重定位。

一个Windows执行程序对调用API函数或对其它动态库的调用,在程序装入内存前,都是一些不

能定位的动态链接;当程序调入内存时,这些远调用都需要重新定位,重新定位的依据就是重定位表。在Windows执行程序(包括动态库)的每个段后面,通常都跟有这样一个重定位表。重定位包含调用函数所在模块、函数序列号以及定位在模块中的位置。

例如,用EXEHDR /v 分析CHINESE.DLL得到:

6 type offset target .......... PTR 0442 imp GDI.351 ..........

就表明,在本段的0442H偏移处,调用了GDI的第351号函数。如果在0442H处是0000:FFFF ,表示本段内仅此一处调用了GDI.351函数;否则,表明了本段内还有一处调用此函数,调用的位置就是0442H处所指向的内容,实际上重定位表只含有引用位置的链表的链头。那么,GDI. 351是一个什么函数呢?用EXEHDR对GDI.EXE作一分析,就可得出,在GDI的出口(Export)函数中,第351号是ExtTextOut。

这样,我们在EXEHDR这一简单而非常有用的工具帮助下,已经在Windows的浩瀚海洋中畅游了一会,下面让我们继续深入下去。

三、动态汉化Windows原理

我们知道,

传统的汉化Windows的方法,是要直接修改Windows的显示、输入、打印等模块代码,或用DDK直接开发"中文设备"驱动模块。这样不仅工作量大,而且,系统的完备性很难保证,性能上也有很多限制(早期的长青窗口就是如此),所以只有从内核上修改Windows核心代码才是最彻底的办法。

从Windows的模块调用机制,我们可以看到,Windows实际上是由包括在KERNEL、GDI、US ER等几个模块中的众多函数支撑的。那么,修改其中涉及语言文字处理的函数,使之能适应中文需要,不就能达到汉化目的了吗?

因而,我们可以得出这样的结论:在自己的模块中重新编写涉及文字显示、输入的多个函数,然后,将Windows中对这些函数的引用,改向到自己的这些模块中来。修改哪些函数才能完成汉化,这需要深入分析Windows的内部结构,但CHINESE.DLL已明确无误地告诉了我们,在其数据段的重定位表中列出的引用函数,正是CStar修改了的Windows函数!为了验证这一思路, 我们利用RichWin作一核实。

用EXEHDR分析GDI.EXE,得出ExtTextOut函数在GDI的第一代码段6139H偏移处(不同版本的Windows其所在代码段和偏移可能不一样)。然后,用HelpWalk(也是Microsoft Visual C+ +开发工具中的一个)检查GDI的Code1段,6139H处前5个字节是 B8 FF 05 45 55,经过运行Ri chWin 4.3 for Internet后,再查看同样的地方,已改为 EA 08 08 8F 3D。其实反汇编就知道,这5个字节就是 Jmp 3D8F:0808,而句柄为0x3D8F的模块,用HelpWalk能观察正是RichWin 的WSENGINE.DLL的第一代码段( 模块名为TEXTMAN)。而偏移0808H处 B8 B7 3D 45 55 8B E C 1E,正是一个函数起始的地方,这实际上就是RichWin所重改写的ExtTextOut函数。退出Ri chWin后,再用

HelpWalk观察GDI的Code1代码段,一切又恢复正常!这与前面的分析结论完全吻合!那么,下一个关键点就是如何动态修改Windows的函数代码,也就是汉化Windows的核心——"陷阱"技术。

四、"陷阱"技术

讨论"陷阱"技术,还要回到前面的两个发现。发现之二,已能解释为修改的Windows函数,而发现之一却仍是一个迷。

数据段存放的是变量及常量等内容,如果这里面包含有重定位信息,那么,必定要在变量说明中将函数指针赋给一个FARPROC类型的变量,于是,在变量说明中写下:

FARPROC FarProcFunc=ExtTextOut;

果然,在自己程序的数据段中也有了重定位信息。这样,当程序调入内存时,变量FarPro cFunc已是函数ExtTextOut的地址了。

要直接修改代码段的内容,还遇到一个难题,就是代码段是不可改写的。这时,需要用到一个未公开的Windows函数AllocCStoDSAlias,取得与代码段有相同基址的可写数据段别名, 其函数声明为:

WORD FAR PASCAL AllocCStoDSAlias(WORD code_sel);

参数是代码段的句柄,返回值是可写数据段别名句柄。

Windo

ws中函数地址是32位,高字节是其模块的内存句柄,低字节是函数在模块内的偏移。将得到的可写数据段别名句柄锁定,再将函数偏移处的5个字节保留下来,然后将其改为转向替代函数(用 EA Jmp):

*(lpStr+wOffset) =0xEA;

四通利方(RichWin)、中文之星(CStar)是大家广为熟知的汉化Windows产品,"陷阱"技术即动态修改Windows代码,一直是其对外宣称的过人技术。本文从Windows的模块调用机制与重定位概念着手,介绍了"陷阱"技术的实现,并给出了采用"陷阱"技术动态修改Windows代码的示例源程序。

//源程序 relocate.c#include ＜WINDOWS.H＞#include ＜dos.h＞BOOL WINAPI MyExtTextOut(HDC hDC, int x, int y, UINT nInt1, const RECTFAR*lpRect,LPCSTR lpStr, UINT nInt2, int FAR* lpInt);WORD FAR PASCAL AllocCStoDSAlias(WORD code_sel);typedef struct tagFUNC{FARPROC lpFarProcReplace; //替代函数地址FARPROC lpFarProcWindows; //Windows函数地址BYTE bOld; //保存原函数第一字节LONG lOld; //保存原函数接后的四字节长值}FUNC;FUNC Func={MyExtTextOut,ExtTextOut};//Windows主函数int PASCAL WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow){HANDLE hMemCode; //代码段句柄WORD hMemData; //相同基址的可写数据段别名WORD wOffset; //函数偏移LPSTR lpStr;LPLONG lpLong;char lpNotice[96];hMemCode=HIWORD((LONG) Func.lpFarProcWindows );wOffset=LOWORD((LONG) Func.lpFarProcWindows );wsprintf(lpNotice,"函数所在模块句柄 0x%4xH,偏移 0x%4xH",hMemCode,wOffset); MessageBox(NULL,lpNotice,"提示",MB_OK); //取与代码段有相同基址的可写数据段别名 hMemData=AllocCStoDSAlias(

hMemCode); lpStr=GlobalLock(hMemData); lpLong=(lpStr+wOffset+1 ); //保存原函数要替换的头几个字节Func.bOld=*(lpStr+wOffset);Func.lOld=*lpLong;*(lpStr+wOffset)=0xEA;*lpLong=Func.lpFarProcReplace;GlobalUnlock(hMemData);MessageBox(NULL,"改为自己的函数","提示",MB_OK);//将保留的内容改回来hMemData=AllocCStoDSAlias(hMemCode);lpStr=GlobalLock(hMemData);lpLong=(lpStr+wOffset+1 );*(lpStr+wOffset)=Func.bOld;*lpLong=Func.lOld;GlobalUnlock(hMemData);MessageBox(NULL,"改回原Windows函数","提示",MB_OK);return 1;}//自己的替代函数BOOL WINAPI MyExtTextOut(HDC hDC, int x, int y, UINT nInt1, const RECT FAR* lpRect, LPCSTR lpStr, UINT nInt2, int FAR* lpInt){BYTE NameDot[96]={ 0x09, 0x00, 0xfd, 0x08, 0x09, 0x08, 0x09, 0x10, 0x09, 0x20, 0x79, 0x40, 0x41, 0x04, 0x47, 0xfe, 0x41, 0x40, 0x79, 0x40, 0x09, 0x20, 0x09, 0x20, 0x09, 0x10, 0x09, 0x4e, 0x51, 0x84, 0x21, 0x00, 0x02, 0x00, 0x01, 0x04, 0xff, 0xfe, 0x00, 0x00, 0x1f, 0xf0, 0x10, 0x10, 0x10, 0x10, 0x1f, 0xf0, 0x00, 0x00, 0x7f, 0xfc, 0x40, 0x04, 0x4f, 0xe4, 0x48, 0x24, 0x48, 0x24, 0x4f, 0xe4, 0x40, 0x0c, 0x10, 0x80, 0x10, 0xfc, 0x10, 0x88, 0x11, 0x50, 0x56, 0x20, 0x54, 0xd8, 0x57, 0x06, 0x54, 0x20, 0x55, 0xfc, 0x54, 0x20, 0x55, 0xfc, 0x5c, 0x20, 0x67, 0xfe, 0x00, 0x20, 0x00, 0x20, 0x00, 0x20};HBITMAP hBitmap,hOldBitmap;

HDC hMemDC; BYTE far *lpDot; int i; for ( i=0;i＜3;i++ ){lpDot=(LPSTR)NameDot+i*32;hMemDC=CreateCompatibleDC(hDC);hBitmap=CreateBitmap(16,16,1,1,lpDot);SetBitmapBits(hBitmap,32L,lpDot);hOldBitmap=SelectObject(hMemDC,hBitmap);BitBlt(hDC,x+i*16,y,16,16,hMemDC,0,0,SRCCOPY);DeleteDC(hMemDC);DeleteObject(hBitmap);}return TRUE;}//模块定义文件 relocate.defNAME RELOCATEEXETYPE WINDOWSCODE PRELOAD MOVEABLE DISCARDABLEDATA PRELOAD MOVEABLE MULTIPLEHEAPSIZE 1024EXPORTS

五、结束语

本文从原理上分析了称为"陷阱"技术的动态汉化Windows方法,介绍了将任一Windows函数调用改向到自己指定函数处的通用方法,这种方法可以拓展到其它应用中,如多语种显示、不同内码制式的切换显示等。