10949人阅读
转自：&[转] Android短信中心设置方式 本着认真负责的态度, 重新测试了下, 下文子虚乌有, 真是吹死人不用偿命... 直接设置正常加号短信中心即可. &真是渣...-----------------------上海移动 pdu码:0105F0(未验证) &+0&上海联通pdu码: &4105F0&& & & & 短信中心:+0-------------------Android短信中心设置方式一觉醒来发现手机上不了网，收发不了短信，但是接听电话没问题，中午去公司跟几个同事一通折腾，拿来n个手机过来测试，别人的sim卡在我机器里面正常，我的卡在别人机器里面涛声依旧，搞了大半天终于决定试试能不能拨出电话，靠，丫提示我欠费！你大爷的，感情联通186手机欠费了仍然是可以接通的？另外，我上周才充了100块钱怎么这么快就没钱了？这些都不提，反正经过这么一通折腾，手机现在变成了只能收短信不能发短信的状态了，因为之前曾经在诺基亚的手机上重新设置过短信中心号。拨打10010要了个上海联通的短信中心号 +0，几经折腾，smsc 都报 update error。而且网上此类回复基本都是语焉不详或者压根就是过时。最后终于知道感情这玩意不能直接填上面那个中心号，需要转成PDU格式的。解决步骤：在拨号界面输入&*#*#4636#*#*，然后选择“手机信息”；在SMSC部分点刷新按钮的话会出现00，这表示短信中心号错误；进入；页面拖到 SMSC 部分，输入框中填入短信中心号，不同地区的号码是不同的（见图示1）；点击 covert，然后把右面输入框第二行开始的前18位号码填入手机（见图示2）；点击更新即可。 图示1:图示2:最后补充一句：Google这该死的Geek本质，你丫直接在更新那儿加个PDU转换能死啊？- EOF -全国短信中心号码 & 10:09:21&阅读559&评论0&&字号：大中小&北京移动 +0 北京联通 +0上海移动 +0 上海联通 +0天津移动 +0 天津联通 +0重庆移动 +0 重庆联通 +0黑龙江移动/联通短消息中心号码哈尔滨 +0 黑龙江联通 +0齐齐哈尔 +0&牡丹江、鸡西、七台河 +0&佳木斯、鹤岗、双鸭山 +0&绥化、伊春 +0&黑河、大兴安岭 +0&大庆 +0&辽宁移动/联通短消息中心号码沈阳 +0 辽宁 +0鞍山+0&本溪+0&锦州+0&阜新+0&铁岭+0&盘锦+0&大连+0&抚顺+0&丹东+0&营口+0&辽阳+0&朝阳+0&葫芦岛+0&内蒙古自治区移动/联通短消息中心号码呼和浩特 +0 内蒙古 +0河北移动/联通短消息中心号码石家庄 +0 河北 +0山西移动/联通短消息中心号码太原 +0 山西 +0大同 +0阳泉 +0&晋中 +0长治 +0晋城 +0&临汾 +0吕梁 +0&运城 +0忻州 +0朔州 +0&山东移动/联通短消息中心号码济南移动 +0 济南联通 +0青岛移动 +0 青岛联通 +0&淄博移动 +0 淄博联通 +0&德州移动 +0 德州联通 +0&烟台移动 +0 烟台联通 +0&潍坊移动 +0 潍坊联通 +0&济宁移动 +0 济宁联通 +0&泰安移动 +0 泰安联通 +0&临沂移动 +0 临沂联通 +0&东营移动 +0 东营联通 +0&威海移动 +0 威海联通 +0&莱芜移动 +0 莱芜联通 +0&聊城移动 +0 聊城联通 +0&菏泽菏泽联通 +0&枣庄枣庄联通 +0&滨洲滨州联通 +0&日照日照联通 +0江苏移动/联通短消息中心号码南京移动 +0 南京联通 +0镇江移动 +0 镇江联通 +0苏州移动 +0 苏州联通 +0南通移动 +0 南通联通 +0扬州移动 +0 扬州联通 +0盐城移动 +0 盐城联通 +0徐州移动 +0 徐州联通 +0淮阴移动 +0 淮安联通 +0连云港移动 +0 连云港联通+0常州移动 +0 常州联通 +0无锡移动 +0 无锡联通 +0泰州移动 +0 泰州联通 +0宿迁移动 +0 宿迁联通 +0浙江移动/联通短消息中心号码杭州移动 +0 杭州联通 +0湖州移动 +0 湖州联通 +0&嘉兴移动 +0 嘉兴联通 +0&宁波移动 +0&绍兴移动 +0 绍兴联通 +0&台州移动 +0 台州联通 +0温州移动 +0 温州联通 +0&丽水移动 +0 丽水联通 +0&金华移动 +0 金华联通 +0&衢州移动 +0 衢州联通 +0&舟山移动 +0 舟山联通 +0安徽移动/联通短消息中心号码合肥、巢湖、滁州、池州、六安、 +0 安徽联通 +0安庆、蚌埠、芜湖、马鞍山、铜陵、宣城、黄山 +0&阜阳、淮北、淮南、宿州 +0&广西移动 +0 广西联通 +0四*川移动 +0 四*川联通 +0海南移动短信中心的号码：+0&海南联通短信中心的号码：+0陕西 +0 西安　+0甘肃 +0 兰州　+0&宁夏 +0 银川　+0&江西 +0 南昌　+0&四*川 +0 成都　+0&新疆 +0 乌鲁木齐　+0贵州 +0 贵阳　+0&云南 +0 昆明　+0&西宁　+0河南移动/联通短消息中心号码郑州
河南联通 +0安阳 &新乡 许昌 &平顶山 &信阳 &南阳 &开封 &洛阳 商丘 &焦作 &鹤壁 &濮阳 &周口 &漯河 驻马店 &三门峡 &湖北移动/联通短消息中心号码武汉 +0 湖北 +0鄂州 +0&孝感 +0&黄冈 +0&黄石 +0咸宁 +0荆州 +0&宜昌 +0&恩施 +0&十堰 +0襄樊 +0&随州 +0江汉 +0广东移动/联通短消息中心号码广州（含番禺、从化、增城、花都）移动 +0 广州联通 +0江门 +0&韶关 +0&惠州 +0&梅州 +0汕头 +0&深圳移动 +0 深圳联通 +0珠海 +0&佛山（含南海） +0肇庆 +0&湛江 +0&汕尾 +0&阳江 +0&揭阳 +0茂名 +0&中山 +0&河源 +0&清远 +0&顺德 +0&云浮 +0&潮州 +0&东莞 +0&吉林移动/联通短消息中心号码长春 +0 吉林 +0吉林 +0&延吉 +0&四平 +0&通化 +0&白城 +0&辽源 +0&松源 +0&白山 +0&湖南移动/联通短消息中心号码长沙 +0 湖南 +0湘潭 +0&株洲 +0&衡阳 +0&郴州 +0&常德 +0&益阳 +0&娄底 +0&邵阳 +0&岳阳 +0&自治州 +0&张家界 +0&怀化 +0永州 +0&福建移动/联通短消息中心号码福州 +0 福州联通　+0厦门 +0 厦门联通 +0&宁德 +0&莆田 +0&泉州 +0漳州 +0&龙岩 +0&三明 +0&南平 +0&广西移动/联通短消息中心号码南宁 +0 南宁　+0&柳州 +0&桂林 +0&梧州 +0&玉林 +0&百色 +0&钦州 +0&河池 +0北海 +0&防城港 +0&香港流动 +&澳门电讯 + --------------------------&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：167969次
积分：2003
积分：2003
排名：第15377名
转载：86篇
评论：46条
(1)(1)(2)(2)(1)(3)(1)(1)(3)(13)(22)(16)(7)(1)(14)(4)(1)【转】WAP&PUSH解析（1）——SMS&PDU编码
WAP PUSH是封装在SMS PDU中的，所以要解析WAP PUSH，首先要先看SMS PDU编码，这是SMS / MMS /
WAP PUSH等业务的基础。WAP
PUSH是通过发送给终端的，所以本文主要看Delivery类型的PDU编码。另外，如果PDU要封装的内容过长，会接收到拆分过的多条SMS，本文对接收到的多条Concatenated
SMS的拼接也做了阐述。
一、单个SMS PDU的封装
下面是接收到的一个完整PDU：
a0236e3f0120601ae02056a&&
3362e82f646f776e2ed26733d38&&
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689&&
8be69cbae8af81e588b8e380&&
a0236e3f0120601ae02056a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
（注：因显示的原因，人为的进行了分行，其实这个包中间并没有换行）
PDU的封装并不是在所有的位置都有固定的涵义，它是逐个扫描的，解析完上一个字段，才知道接下来的含义，或者后面字段的长度。
1. 短信中心
&&&为08，所以接下来的8字节为短信中心内容&&
&&&91为国际号，加上’+’号；&&
&&&后面的号码编码规则为GSM&BCD：f0&&&&0&&
所以，得到短信中心号码：+0&&
为08，所以接下来的8字节为短信中心内容
91为国际号，加上’+’号；
后面的号码编码规则为GSM BCD：f0 && 0
所以，得到短信中心号码：+0
现在PDU扫描到了红色处（绿色部分已经扫描结束）：
0105f04408a2a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
2. FirstByte:
0x44&=&0100&0100&&
bit1.bit0:&mti&&
&&&&&&00&Delevery&&
&&&&&&01&Submit&&
&&&&&&10&Status&Report&&
bit7:&TP-Reply-Path&&
&&&&&&1&有&&
&&&&&&0&无&&
bit6:&指示是否有userdata&header&(UDH)&&
&&&&&&1&有&&
&&&&&&0&无&&
bit4.bit3:&TP-Validity-Period&(submit类型的PDU才有意义)&&
&&&&&&00:&len=0&&
&&&&&&10:&len=1&&
&&&&&&01/11:&len=7&&
bit1.bit0: mti
00 Delevery
10 Status Report
bit7: TP-Reply-Path
bit6: 指示是否有userdata header (UDH)
bit4.bit3: TP-Validity-Period (submit类型的PDU才有意义)
01/11: len=7
现在PDU扫描到了红色处（绿色部分已经扫描结束）：
08a0b01ae02056a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
3. 发送方地址（Originating address）
地址长度:&&&
&&长度Length&=&08&&&
&&得到地址占用的字节数（包含长度本身）:&2&+&(Length&+&1)&/&2&=&6&&
&&地址在08a&&
TOA:&0xA0&=&1010&0000&&
&&bit7:&必须为1&&
&&bit6...bit4:&ton&=&010&&
&&&&&&&000&TON_UNKNOWN(0)&&
&&&&&&&001&TON_INTERNATIONAL(1)&&
&&&&&&&010&TON_NATIONAL(2)&&
&&&&&&&011&TON_NETWORK(3)&&
&&&&&&&100&TON_SUBSCRIBER(4)&&
&&&&&&&101&TON_ALPHANUMERIC(5)&&
&&&&&&&110&TON_ABBREVIATED(6)&&
所以，发送方地址为:&&
&&&&&&&&&&
长度Length = 08
得到地址占用的字节数（包含长度本身）: 2 + (Length + 1) / 2 = 6
TOA: 0xA0 =
bit7: 必须为1
bit6...bit4: ton = 010
000 TON_UNKNOWN(0)
001 TON_INTERNATIONAL(1)
010 TON_NATIONAL(2)
011 TON_NETWORK(3)
100 TON_SUBSCRIBER(4)
101 TON_ALPHANUMERIC(5)
110 TON_ABBREVIATED(6)
所以，发送方地址为:
现在PDU扫描到了红色处（绿色部分已经扫描结束）：
a0010bae02056a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
4. TP-Protocol-Identifier(TP-PID)
&& TS 23.040 9.2.3.9
现在PDU扫描到了红色处（绿色部分已经扫描结束）：
a004236e0605040bae02056a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
5. TP-Data-Coding-Scheme
&(TS 23.038)
&&0x04&=&0000&0100&&
&&bit7:&如果此位为0&&
&&&&&&&&bit6:&automaticDeletion&&
&&&&&&&&bit5:&userDataCompressed&&
&&&&&&&&bit4:&hasMessageClass&&
&&&&&&&&if&(!userDataCompressed)&&//&bit5&&
&&&&&&&&&&&bit3...bit2:&&&
&&&&&&&&&&&&&00&ENCODING_7BIT&&
&&&&&&&&&&&&&10&ENCODING_16BIT&&
&&&&&&&&&&&&&01/11:&ENCODING_8BIT&&
&&bit7...bit4:&如果这四位为1111&&&
&&&&&&&&bit2:&&
&&&&&&&&&&0&ENCODING_7BIT&&
&&&&&&&&&&1&ENCODING_8BIT&&
&&Bit7...bit4:&如果这四位为1100,&1101&or&1110&&
&&&&&&&&1110&ENCODING_16BIT(UCS-2)&&
&&&&&&&&&ENCODING_7BIT&&
&&bit1...bit0:&如果有Class&&
&&&&&&&&00&CLASS_0&&
&&&&&&&&01&CLASS_1&&
&&&&&&&&10&CLASS_2&&
&&&&&&&&11&CLASS_3&&
所以，这个PDU包数据是8Bit编码，没有Class类型。&&
bit7: 如果此位为0
bit6: automaticDeletion
bit5: userDataCompressed
bit4: hasMessageClass
if (!userDataCompressed)
bit3...bit2:
00 ENCODING_7BIT
10 ENCODING_16BIT
01/11: ENCODING_8BIT
bit7...bit4: 如果这四位为1111
0 ENCODING_7BIT
1 ENCODING_8BIT
Bit7...bit4: 如果这四位为 or 1110
1110 ENCODING_16BIT(UCS-2)
ENCODING_7BIT
bit1...bit0: 如果有Class
00 CLASS_0
01 CLASS_1
10 CLASS_2
11 CLASS_3
所以，这个PDU包数据是8Bit编码，没有Class类型。
现在PDU扫描到了红色处（绿色部分已经扫描结束）： &
a0236e3f0120601ae02056a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
6.TP-Service-Centre-Time-Stamp
&& 短信中心下发的时间戳，这个编码和长度固定
&21&Year:&&&12&&
&60&Month:&&06&&
&92&Day:&&&&29&&
&90&Hour:&&&09&&
&25&Minute:&52&&
&12&Second:&21&&
&23&TimeZone&Byte&&
&&&时区同样高4bit在低位，低4bit在高位&&
&&&Bit3为时区+/-标志位&&
&&&计算的结果为1/4时区&&
&&&0x23&=&0010&0011&&
&&&&&&&Bit3:&sign&symbol&&
&&&&&&&&&0&+&&
&&&&&&&&&1&-&&
&&&&&&&0010&x011&-&&x011&0010&=&0011&0010&=&32&[quarter-hour]&&
&&&TimeZone:&+&32&/&4&=&+8&&
25 Minute: 52
12 Second: 21
23 TimeZone Byte
时区同样高4bit在低位，低4bit在高位
Bit3为时区+/-标志位
计算的结果为1/4时区
Bit3: sign symbol
-& x011 0010 =
= 32 [quarter-hour]
TimeZone: + 32 / 4 = +8
&& 所以，得到时间戳为：12-06-29 09:52:21 GMT+8
现在PDU扫描到了红色处（绿色部分已经扫描结束）：&&
a0236e3f056a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
7. UserDataHeader & UDH
UserDataLength:&长度包含UDH和UD,但不包含这个字节本身&&
&&0x6E&=&110&&
UserDataHeaderLength:&该长度不包含这个字节本身&&
&&0x06&=&6&&
UserDataHeader:&f0&&
&&UDH中可能有多段，所以要不断解析，直到UDH结束&&
&&UDH每段含义开头都有个id做标示，接下来是后面具体含义的数据的字节个数，然后才是具体数据&&
&&id&-&0x05&&
&&&&0x00&ELT_ID_CONCATENATED_8_BIT_REFERENCE&&
&&&&0x08&ELT_ID_CONCATENATED_16_BIT_REFERENCE&&
&&&&0x05&ELT_ID_APPLICATION_PORT_ADDRESSING_16_BIT&&
&&&&0x04&ELT_ID_APPLICATION_PORT_ADDRESSING_8_BIT&&
&&&&0x24&ELT_ID_NATIONAL_LANGUAGE_SINGLE_SHIFT&&
&&&&0x25&ELT_ID_NATIONAL_LANGUAGE_LOCKING_SHIFT&&
&&length:&4&&
&&dest&port:&0b84&-&&0x0B84&=&2948&&
&&&&&&2948&for&WAP_PUSH&&
&&src&port:&23f0&-&&0x23F0&&
UserDataLength: 长度包含UDH和UD,但不包含这个字节本身
0x6E = 110
UserDataHeaderLength: 该长度不包含这个字节本身
UserDataHeader: f0
UDH中可能有多段，所以要不断解析，直到UDH结束
UDH每段含义开头都有个id做标示，接下来是后面具体含义的数据的字节个数，然后才是具体数据
0x00 ELT_ID_CONCATENATED_8_BIT_REFERENCE
0x08 ELT_ID_CONCATENATED_16_BIT_REFERENCE
0x05 ELT_ID_APPLICATION_PORT_ADDRESSING_16_BIT
0x04 ELT_ID_APPLICATION_PORT_ADDRESSING_8_BIT
0x24 ELT_ID_NATIONAL_LANGUAGE_SINGLE_SHIFT
0x25 ELT_ID_NATIONAL_LANGUAGE_LOCKING_SHIFT
dest port: 0b84 -& 0x0B84 = 2948
2948 for WAP_PUSH
src port: 23f0 -& 0x23F0
&& PDU是用端口来识别具体业务的，比如这个PDU的目的端口是2948，就是WAP PUSH的PDU封装。
&& 另外，如果还是长SMS，UDH中还会有长SMS拼接所需要的信息，UDH中就有了多重的含义。
现在PDU扫描到了红色处（绿色部分已经扫描结束）：&&
a0236e3f0056a
3362e82f646f776e2ed26733d38
e68e8ce68fa1e882a1e5b882e58588e69cbaefbc8ce6aca2e8bf8ee4bdbfe794a8e689
8be69cbae8af81e588b8e380
现在， PDU封装的基本信息已经解析完毕，剩下的是UserData，也已经区分出具体的业务，可以交给具体业务模块去解析。
二、多条SMS PDU的封装
因为单条SMS长度的限制，一条长SMS的发送是拆分成多条SMS发送的，接收时也是多条接收，然后拼接。
下面实例是分两次接收到的一条长SMS的两个SMS PDU：
a08c0bf1790601
aecee636e2f662f736ae689bee69c8be58f8be3
e5a4a9e6b094e3be5b08fe8afb4e3be696b0e997bbe280a6e689
8be69cbae9a39ee4bfa1efbc8ce7ae80e58d95e4bda0e79a84ebbefbc81e8b5b6e5bfab
e4b88be8bd
a0220bf2bde4bd
93e9aa8ce6898be69cbae9a39ee4bfa1000101
UserDataHeader里有多SMS的信息，我们就从这里开始分析。
1. UDH之前部分
PDU[0]与PDU[1]的UDH之前的部分完全相同，与前面讲的单条SMS PDU的封装也相同，所以这里不再赘述这部分的解析。
2. UserDataHeader& UDH
UserDataLength:&&&
&&长度包含UDH和UD,但不包含这个字节本身&&
&&长度指的是本PDU中的长度&&
&&PDU[0]:&0x8C&=&140&&
&&PDU[1]:&0x22&=&34&&
UserDataHeaderLength:&该长度不包含这个字节本身&&
&&0x0B&=&11&&
UserDataHeader:&&
&&UDH中可能有多段，所以要不断解析，直到UDH结束&&
&&UDH每段含义开头都有个id做标示，接下来是后面具体含义的数据的字节个数，然后才是具体数据&&
&&PDU[0]:&f0&&&
&&PDU[1]:&f0&&&
&&id&-&0x05&&
&&&&0x00&ELT_ID_CONCATENATED_8_BIT_REFERENCE&&
&&&&0x08&ELT_ID_CONCATENATED_16_BIT_REFERENCE&&
&&&&0x05&ELT_ID_APPLICATION_PORT_ADDRESSING_16_BIT&&
&&&&0x04&ELT_ID_APPLICATION_PORT_ADDRESSING_8_BIT&&
&&&&0x24&ELT_ID_NATIONAL_LANGUAGE_SINGLE_SHIFT&&
&&&&0x25&ELT_ID_NATIONAL_LANGUAGE_LOCKING_SHIFT&&
&&length:&4&&
&&dest&port:&0b84&-&&0x0B84&=&2948&&
&&&&2948&PORT_WAP_PUSH&&
&&src&port:&23f0&-&&0x23F0&&&
&&这段说明这是WAP&PUSH的PDU封装&&
&&id&-&0x00&&
&&length:&03&&
&&ConcatRef.refNumber:&0B&&
&&ConcatRef.msgCount:&02&&
&&ConcatRef.seqNumber:&&
&&&&PDU[0]:&01&&
&&&&PDU[1]:&02&&
&&这段说明这是长SMS的分拆出来的PDU封装包：&&
&&&&refNumber标识是属于哪个长SMS，分拆出来的各个分拆包都有相同的refNumber&&
&&&&msgCount长SMS分拆出来的包的个数&&
&&&&seqNumber指示到达的该包在各个分拆包中的顺序：取值1..&msgCount&&
&&&&&&&&&&&&&因为分拆出来的包到达接收端的顺序不一定是按次序的，所以拼接时，要按照这个顺序。&&
UserDataLength:
长度包含UDH和UD,但不包含这个字节本身
长度指的是本PDU中的长度
PDU[0]: 0x8C = 140
PDU[1]: 0x22 = 34
UserDataHeaderLength: 该长度不包含这个字节本身
UserDataHeader:
UDH中可能有多段，所以要不断解析，直到UDH结束
UDH每段含义开头都有个id做标示，接下来是后面具体含义的数据的字节个数，然后才是具体数据
PDU[0]: f0
PDU[1]: f0
0x00 ELT_ID_CONCATENATED_8_BIT_REFERENCE
0x08 ELT_ID_CONCATENATED_16_BIT_REFERENCE
0x05 ELT_ID_APPLICATION_PORT_ADDRESSING_16_BIT
0x04 ELT_ID_APPLICATION_PORT_ADDRESSING_8_BIT
0x24 ELT_ID_NATIONAL_LANGUAGE_SINGLE_SHIFT
0x25 ELT_ID_NATIONAL_LANGUAGE_LOCKING_SHIFT
dest port: 0b84 -& 0x0B84 = 2948
2948 PORT_WAP_PUSH
src port: 23f0 -& 0x23F0
这段说明这是WAP PUSH的PDU封装
length: 03
ConcatRef.refNumber: 0B
ConcatRef.msgCount: 02
ConcatRef.seqNumber:
PDU[0]: 01
PDU[1]: 02
这段说明这是长SMS的分拆出来的PDU封装包：
refNumber标识是属于哪个长SMS，分拆出来的各个分拆包都有相同的refNumber
msgCount长SMS分拆出来的包的个数
seqNumber指示到达的该包在各个分拆包中的顺序：取值1.. msgCount
因为分拆出来的包到达接收端的顺序不一定是按次序的，所以拼接时，要按照这个顺序。
3. UserData
这是一条长SMS拆分出的两条，所以UserData要按seqNumber次序拼接起来。
<span STYLE="CoLor: #0bf04405a08c0bf01790601
aecee636e2f662f736ae689bee69c8be58f8be3
e5a4a9e6b094e3be5b08fe8afb4e3be696b0e997bbe280a6e689
8be69cbae9a39ee4bfa1efbc8ce7ae80e58d95e4bda0e79a84ebbefbc81e8b5b6e5bfab
e4b88be8bd
a0220bf02bde4bd
93e9aa8ce6898be69cbae9a39ee4bfa1000101
把PDU[0]和PDU[1]中的红色的UserData拼接起来，得到完整的UserData。
056acf662f736ae689bee69c8be5
8f8bee5a4a9e6b094ebe5b08fe8afb4ebe696b0e997bbe280
a6e6898be69cbae9a39ee4bfa1efbc8ce7ae80e58d95e4bda0e79a84ebbefbc81e8b5b6
e5bfabe4b88be8bdbde4bd93e9aa8ce6898be69cbae9a39ee4bfa1000101
至此，完整的UserData已经得到，在UDH中也已经区分出具体的业务，可以交给具体业务模块去解析。
三、小结&&&&&&&&&&&&
Delivery SMS PDU中可以解析出：Service
Centre（可无）、有无UDH、PDU类型的识别、发送方号码、TP-PID、编码格式、Class类型（可无）、时间戳、UDH（可无。含：UserData长度、UserDataHeader长度，可能有端口号或Concat信息，等）以及包含具体业务数据的UserData。
关于UserData中具体WAP
PUSH业务的封装格式，在后续文章《》和《》中解读。
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。