|
楼主 |
发表于 2012-6-11 18:34
|
显示全部楼层
本帖最后由 pollyster 于 2012-6-11 18:44 编辑
h9 J$ o, k0 I2 i+ F# csnowmonkey 发表于 2012-6-11 15:28
# y$ r7 R, O$ t; p你还是没有搞清楚我的观点。我的意思是,在上层应用处理短信内容的时候,对于字符串内出现的0,有可能会截 ...
+ v5 s! K7 A! ^+ D/ u1 i2 ?" w3 x
不知是我没表达清楚,还是你没理解清楚,我再明确说明一次,我说的不会遇到零就截断,而是靠长度变量来结尾,指的正是接收方手机上的应用程序,不是指的底层,更不是指cdma协议,应用程序的编写也是有规范的啊,比如cdma网络传来的字串,应用程序是按C的方式处理呢?还是去读网络传来的长度变量来结尾呢?应用程序也有这两个选择啊,至少我测试的三种手机的应用程序清一色地选择了第二种方法,没有遇0截断啊,如果iphone和android上面的应用程序(注意是应用程序不是底层)也是选择的第二种方法,难道不能合理怀疑在应用程序的编写中,尤其是短信等字串处理问题中,所有手机商的应用程序编写都遵循相同规范吗?再重复一便,我这里指的标准或规范是应用程序的编写规范,与底层毫无关系,与cdma协议更无关系,之所以提到cdma只是因为长度数据的来源是cdma网络而已。
" E1 D. o j( d" Q, M pixi中有两个核,一个核跑linux,另个核跑amss,对于linux来说,amss就像是一个外设,具体来说是个modem,最早通过向一个虚拟的串口发at命令来通信,就像pc机上的拨号modem那样,pixi上的两核除了at命令,还有更新的通讯方式,你可以认为是非at格式的命令,而且不是通过虚拟串口来通讯的。现在短信从libTelephonyInterfaceLayer通过发命令传到了amss,这个命令中只包含了一个长度,在复制命令中的短信内容的时候,是按这个长度来复制的,这个长度是字节数还是字符数呢?amss处理命令的模块认为它既是字节数又是字符数,因为整个系统在美国使用,采用ascii码,决定复制长度的时候,它不会去理睬cdma发送编码(就是你说的4),因为这个4本来是不该出现的,在美国用的手机发ascii码,怎么会出现4呢?这个4是你通过修改libTelephonyInterfaceLayer让它意外出现的,amss命令处理模块不管,还按ascii那样来处理。但问题是pixi的基带发往cdma网络的模块不是这样的,它懂得要通过cdma发送编码来确定字节数和字符数的关系,它是个国际化的模块,也就是说这两个功能模块在国际化方面进度不一致,也没必要一致,因为是用在ascii国家。至于为什么不一致,也许根本就是分立的硬件,发送部分对amss又是个硬件modem设备,这样可以卖到中国,只要把一个模块换掉不用换发送模块就行了,也许只是两个部门进度整合不一致,由于不影响美国使用就没有在这个版本中让它们一致,我们外人不能肯定不一致的原因。但是能回答你的疑惑,老的650的fw为什么可以呢? 因为这两个模块进度一致了,比如都不懂国际化,就只需提供字节数就行了,尽管字节数会被cdma网络曲解,但是在发送方不会缓冲溢出,不会发送时带上发送方的信息,当然接收方有可能溢出,但没有泄密问题。如果进度一致是都懂国际化,那就更不用说了。老产品比新产品国际化得更好这并不是什么奇怪的事。而且pixi的amss也可能不是新旧的问题,只是其中一个模块采用ascii模块而已,因为只用在美国。而新amss就不这么分了,统一为国际化模块。所以两个模块一个懂一个不懂国际化,就造成如果人为指定utf16(ucs2)编码的时候,一个会处理一个不会处理的错误,在pixi上就是带尾巴。新的amss除了发送编码,还加了数据编码,数据编码告诉amss你发过来的数据怎么算长度,而发送编码告诉cdma网络你用哪种编码。其实有时间看汇编的话,有两种改法,一种是在amss上找到向基带准备数据的部分,把长度减半就行了。另一种是找到amss复制libTelephonyInterfaceLayer传来短信的部分,把长度加倍,然后再在libTelephonyInterfaceLayer写0xb9,0xba的长度栏位时减半就一切正确了。 |
|