关于PowerBuilder中的字符集问题
关于PowerBuilder中的字符集问题
搞PB的人，很多对字符集编码这个东西不理解。即使看了网上的文章，还是不懂。比如https://blog.csdn.net/qq_28098067/article/details/53486032这篇文章，就是非常好的一篇介绍字符集的文章。大家可以先耐心看一下这篇文章。
本文不研究高深的字符集问题，仅仅就PowerBuilder里字符集使用问题，作一个简介。
在PB里的字符串处理，我们熟悉的就是 string。这个string 类型，对于不同版本，是有区别的，PB9.0及以下版本，它使用的是GB2312编码（也就是ASC码编码方案），对PB10及以上版本，它使用的是UNICODE 版本。对于存储字符串来说，这两者完全不兼容，需要做转换。
一、不同字符集的内存存储形态
下面举一个例子说明：
String ls_str = “国3a”
对于这个字符串，它在PB9及以下的内存里存储是这样的(十六进制形式)：
表一：
| B9 |
FA |
33 |
61 |
\0 |
|
对于这个字符串，它在PB10及以上的内存里存储是这样的(十六进制形式)：
表二：
| B9 |
\0 |
FA |
\0 |
33 |
\0 |
61 |
\0 |
\0 |
\0 |
|
|
(注意：\0表示asc码的0，即NULL)
我们看内存里，它的区别很显然：
- PB9里占用的内存只是PB10里占用的内存一半。
- PB9里以一个字节为一个长度，所以这个len(ls_str)结果为4，而PB10里len(ls_str)结果为3。而PB10里又增一个函数lenA(ls_str)它是按照PB9的方式来取，结果为4。
以上是内存里的保存形态，实际使用UNICODE时那么多\0不需要你处理，系统会自动处理好，给你放到 string 里面取用。
二、不同字符集的互相转换
那么 ，为什么PB9.0 -> PB10.0这样升级，改字符集呢？原因有：
- gb2312显示的字符个数比较少，不能显示冷僻字，尤其对东亚一些宽字节文字无法处理。
- 用mid函数，无法取到整体汉字， 在PB9里mid(ls_str,1,1)只能取到半个汉字，PB10里面mid(ls_str,1,1)就能取到“国”，如果要和PB9里一样取半个汉字，它也增加了一个函数，用midA(ls_str,1,1)。
以上是介绍了PB9和PB10不同的字符集问题，那么PB9里是否可以使用UNICODE，PB10里是否可以使用gb2312呢？答案是肯定可以的。不要忘了，我们还有个类型叫做blob，这个类型很简单，它不负责字符转换，只是保存内存里二进制原有形态。
Blob blb_data
PB9里blb_data = blob(ls_str)，这时候blb_data里的形态就是
表三：
| B9 |
FA |
33 |
61 |
\0 |
|
而在PB10里面blb_data = blob(ls_str)，这时候blb_data里的形态就是
表四：
| B9 |
\0 |
FA |
\0 |
33 |
\0 |
61 |
\0 |
\0 |
\0 |
|
|
而在PB10里面blb_data = blob(ls_str, EncodingANSI!)，这时候blb_data里的形态就是
表五：
| B9 |
FA |
33 |
61 |
\0 |
|
这时候与PB9的表一表三是一样的。
PB10里表二表四这样的数据转换成PB10的字符串，很简单：ls_str = string(blb_data)
PB10里表一表三这样的数据转换成PB10的字符串：
ls_str = string(blb_data,EncodingANSI!)
而在PB9里，要将 gb2312转成 UNICODE，要稍微麻烦点，得借助WINAPI函数MultiByteToWideChar。这个比较复杂一点，此处不缀述，解决方案，本文最后会给出。
三、UTF8字符集问题
UNICODE已经很好地解决了多种语言字符集在计算机上的显示和存储问题，但是，在这个网络时代，我们还要考虑到网络传输问题。
对比表一和表二，我们看出，表二占用的内存比表一多一倍，同理，传输也要多花费一倍的网络流量。这很不划算。UTF8就由此诞生。下表就是“国3a”在内存里的形态：
表六：
| E5 |
9A |
BD |
33 |
61 |
\0 |
|
|
|
|
|
|
从表六可以看出，作为单字节的“3a”存储与PB9里的gb2312是一样的，而“国”由存为3个字节。总数上比UNICODE少了6个字节。
UTF8字符集既解决了多语言宽字节字符集存储问题，也提高了网络传输的效费比。所以，网络传输中几乎都默认使用UTF8字符集传输。
四、windows操作系统对字符集的处理
在我们日常使用的windows操作系统中，它提供了一整套WINAPI用于处理字符串，遗憾的是它无法直接显示UTF8字符集，必须转换成gb2312或UNICODE才能正确显示。
对于gb2312和UNICODE编码，windows为我们提供了2套WINAPI函数。通常以A和W结尾。
例如：
在PB9里我们这样声明函数，注意 alias for “…..A” 和alias for “…..W”里的不同：
FUNCTION ulong PlaySound(string lpszName,ulong hModule,ulong dwFlags) LIBRARY "winmm.dll" ALIAS FOR "PlaySoundA"
在PB10里我们这样声明函数：
FUNCTION ulong PlaySound(string lpszName,ulong hModule,ulong dwFlags) LIBRARY "winmm.dll" ALIAS FOR "PlaySoundW"
实际上在winmm.dll这个函数中，widnows分别为我们提供了PlaySoundA和PlaySoundW这两个函数，分别用于处理不同字符集编码下的同一个功能，
这两种声明，PB会直接把自己的字符集变量传给WINAPI处理。
此处需要注意，在PB10以上版本中使用WINAPI，请不要使用声明带A的函数，而应使用带W的函数。
对于自己的一些DLL实现的功能，没有windows操作系统那么尽责尽力，往往只有char *这样的参数形式，这类函数声明，使用PB9的方式即可:
FUNCTION ulong MyFunc(string szName) LIBRARY "my.dll" alias for “MyFunc”
在PB10以上版本中要使用此DLL，需要声明为：
FUNCTION ulong MyFunc(string szName) LIBRARY "my.dll" alias for “MyFunc;ansi”
注意后面多了一个 “;ansi”，PB会自动在内部进行字符集转换。这种转换不是百分之百成功有用，遇过多次这种方式是有问题的。随着PB9以下版本的应用升级到PB10以上，相应的DLL最好也能把字符集编码升级成UNICODE，就象windows的WINAPI那样，搞2套函数实现。
五、关于PB开发中字符集转换的方案
实际开发中，我们经常遇到字符集转换问题，同样的代码，在PB9和PB10版本中，不能通用，很多应用由PB9升级后，虽然业务逻辑没问题，但自定义的加密解密算法、编码解码算法、老版本的DLL使用问题，都会导致升级失败，没有统一的字符集处理接口。
在我写的PB_Json_httpclient_crypto_ftp 这个库里（简称pbjson库），我对PB9和PB10的字符集转换做了统一接口。尤其是在处理UTF8的时候，2个函数ToUtf8 和 FromUtf8分别完成从string转到UTF8和从UTF8转成string，让你不用关心当前使用的是 gb2312 还是 unicode字符集，全部自动转换完成 ，确保pb9和pb10代码一致性。
同时pbjson库里还有大量工具对字符集进行了自动转换，例如httpclient 涉及到的WEB应用，uo_json涉及到接口应用等。
大自在（QQ：781770213）
2020、12、3