从其它平台迁移而来
闲来无事,又开始扒拉起Delphi的源码,这次发现一个比较有意思的函数StringCodePage
,作用是返回传入字符串的CodePage
。至于什么是CodePage
,暂且认为是字符编码吧。
先测试一把:
|
|
来看下是怎么实现的:
|
|
原来字符串首地址逆向偏移12个字节所存放的Word
型数据就是该字符串的CodePage
信息。注释里出现了一个StrRec
,看一下是何方神圣:
|
|
两个Word
两个Integer
刚好12B
,那就看下所有字节吧:
|
|
查一下各个字符的编码备用:123abc
的ASCII码就不必说了;中
的GBK编码D6D0
,Unicode编码4E2D
,UTF-8编码E4B8AD
;国
的GBK编码B9FA
,Unicode编码56FD
,UTF-8编码E59BBD
。
先看s1
,codePage:A8 03
,elemSize:01 00
,refCnt:01 00 00 00
,length:0A 00 00 00
,字符串内容:31 32 33 61 62 63 D6 D0 B9 FA
。
字符串内容比较好理解,与具体编码也都一一对上了,但是其它的又是怎么回事呢?用PWord
和PInteger
去取的话又是没问题的啊!其实是编译器大端
、小端
的问题,至于大小端问题这里不讨论,知道这里用的是小端
就可以了。
按小端
来解析s1
,codePage:03 A8
=936,elemSize:00 01
=1,refCnt:00 00 00 01
=1,length:00 00 00 0A
=10。
s2
就比较头大了,前8个字节总是变来变去,length:00 00 00 10
=16,字符串内容按小端
来解析也是没问题的。
其中有这样一段代码:
|
|
意思是说求WideString
的长度时,windows平台下还需要右移一位,其实就是除以2
。
s3
,codePage:FD E9
=65001,elemSize:00 01
=1,refCnt:00 00 00 01
=1,length:00 00 00 0C
=12,字符串内容与UTF-8编码一致。
s4
按小端
来解析,codePage:04 B0
=1200,elemSize:00 02
=2,refCnt:00 00 00 01
=1,length:00 00 00 08
=8,字符串内容UCS-2LE编码一致。
这里发现一个重大问题:WideString
和UnicodeString
虽然在内容上一样,但具体实现却是不同的。
|
|
结果如图,不多解释了。