关于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)

我们看内存里,它的区别很显然:

  1. PB9里占用的内存只是PB10里占用的内存一半。
  2. PB9里以一个字节为一个长度,所以这个len(ls_str)结果为4,而PB10里len(ls_str)结果为3。而PB10里又增一个函数lenA(ls_str)它是按照PB9的方式来取,结果为4。

以上是内存里的保存形态,实际使用UNICODE时那么多\0不需要你处理,系统会自动处理好,给你放到 string 里面取用。

 

二、不同字符集的互相转换

那么 ,为什么PB9.0 -> PB10.0这样升级,改字符集呢?原因有:

  1. gb2312显示的字符个数比较少,不能显示冷僻字,尤其对东亚一些宽字节文字无法处理。
  2. 用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

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页