短信开发

admin · 2012-08-26

1.1. 基本知识
短信开发指通过串口 at 命令驱动短信猫进行短信发送和接收操作。
在 java 中主要使用 javax.comm 包进行开发，
sun 公司网上地址： Java Communications API
使用工具： windows 自带超级终端

短信猫操作分为三种模式： block,pdu 和 Text
短信传送有三种编码： 7 位， 8 位， UniCode
at 命令 ,at 命令是驱动短信设备的标准工业命令，除了业界的标准之外，每个厂商可能会对其进行扩展，不过一般来说，标准命令应该够用，这次用的是西门子 tc35i ，有专门的 at 命令文档。

1.1.1. 相关文档
Gsm03.38 规范： Alphabets and language-specific information 着重介绍短信发送中对字符集的控制部分
Gsm03.40 规范： Technical realization of the Short Message Service (SMS) Point-to-Point (PP) 详细介绍各种不同短信的不同实现
Gsm07.05 规范： Use of Data Terminal Equipment - Data Circuit terminating;Equipment (DTE - DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) ，介绍 at 的一些控制命令。
Gsm07.07 规范：着重介绍 at 的短信相关命令，可以说是 at 的 sms 规范。
1.1.2. Block 模式
Block 模式基本已经被 pdu 模式取代，没有具体研究
1.1.3. Text 模式
Text 模式比较简单，但是支持的设备不是很全，而且对于中文似乎有些问题，在金笛的网站技术资料中似乎提到了一句不能实现中文。
AT ＋ CGMF=1<CR>
AT ＋ CGMS= “ 13605696031 ” ,129<CR>
>Hello World!<^Z>
1.1.4. Pdu 模式
pdu 编码主要包括两个主要的部分，一是 pdu 串的整体数据格式，分别因为发送信息串和接收信息串而有区别，二是 pdu 中文本部分的编码，分别因为字符集而不同。
我们也可以这样来理解这个 pdu 编码的格式， sms 相当于一个协议栈，最简单的协议栈：
根据 gsm03.40 规范， sms 协议包括以下几层：
1、 SM-AL ：应用层。这个部分就是数据部分。
2、 SM-TL ：传输层。我们可以清楚的看到这里描述了主要的短信内容，包括发送号码，接收号码，信息类型，编码，数据报长度等等，这也是我们编程主要要面对的问题。
3、 SM-RL ：中继层。这个指的是短信在网关之间中继需要的协议。
4、 SM-LL: 链路层。
从上述描述中我们可以清楚的看到，我们编程主要集中于传输层。

PDU 串的用户信息 (TP-UD) 段最大容量是 140 字节，所以在这三种编码方式下，可以发送的短消息的最大字符数分别是 160 、 140 和 70 。这里，将一个英文字母、一个汉字和一个数据字节都视为一个字符。

1.2. SMS 用户数据的编码方法
1.2.1. 英文 7 位编码
图片不能正确显示
这是 gsm 的默认编码方式
由于这样的移位，我们可以看到我们能发的最多英文字符等于： 140*8/7 = 160 。
1.2.2. 数据 8 位编码
8-bit 编码通常用于发送数据消息，比如图片和铃声等；
1.2.3. 中文 pdu 编码
发送中文时，必须用 UCS2 （ utf-16 ）进行编码，最多可以发 140/2 ＝ 70 个汉字。
UniCode 编码转换也比较简单，以中文为例，一个中文字符是两个字节，直接对高位字节和低位字节进行十六进制转换就可以了。如“欢迎”， UniCode 编码是 6B22 8FCE ，这同时也就是转换的结果，如果发送的串中有英文字符，那么在前面补全 00 ，以保证一个字符对应两个字节。
1.2.4. Wap-push 中的中文编码
做 wap-push 短信的时候有些问题了，开始的时候也按照 Unicode 编码处理，总是失败，后来才发现，有个编码字段设为了 uft-8 ，所以在这种情况下，还是可以出现其他编码方式的。

1.3. 短信报头分析
1.3.1. 短信类型
详细请参考 gsm 0438 规范和 gsm0440 规范，里面有详细的关于各种短消息类型的描述。
在 sms 中到底支持多少种类型的短信，短信类型由什么进行控制，这是我们在这里需要着重介绍的问题。
在传输层来分，一共有六大短信类型： SMS-DELIVER ， SMS-DELIVER-REPORT ， SMS-SUBMIT
， SMS-SUBMIT-REPORT ， SMS-STATUS-REPORT ， SMS-COMMAND ，这六种短信类型，由短信中心地址后的第一个字节的最低两位控制。
bit1 bit0 Message type
0 0 SMS-DELIVER (in the direction SC to MS)
0 0 SMS-DELIVER REPORT (in the direction MS to SC)
1 0 SMS-STATUS-REPORT (in the direction SC to MS)
1 0 SMS-COMMAND (in the direction MS to SC)
0 1 SMS-SUBMIT (in the direction MS to SC)
0 1 SMS-SUBMIT-REPORT (in the direction SC to MS)
1 1 Reserved

也就是说，每个短信在短信中心地址之后的第一个字节的最低两位是至关重要的。他决定了如何读这条短信（结合是发送的，还是接收的）
1.3.2. 地址编码
短信发送中都会涉及到短信地址的问题，他们的编码规则是一致的 , 简单来说就是 BCD8421码编码。
如： 08 91 683108501505F 0 ，
08 ：地址长度，（号码类型 + 号码长度） /2 的十六进制表示
91 ：号码类型
683108501505F 0 ：号码，实际号码应为： 8613805515500 ，号码处理方法为 , 如果为 +86 开始 , 将 + 号去掉 , 然后判断是否为偶数 , 不是在末尾补 F, 然后将奇数位和偶数位互换
1.3.3. TP-DCS( 数据编码格式 )
这个字节比较特殊，表明整个短信的字符编码，数据内容等信息。详细说明参考 gsm03.38 规范。
1.3.4. 第一个字节
Pdu 编码的第一个字节比较有意思，这个字节会根据六种不同的短信按位有不同的意思，拿句专业一点的话来说，叫 bitmask. 用图来大概描述一下，详细参考 gsm0340 的 9.2.3 段。

位数 MSG_Deliever MSG_SUBMIT
7 TP_RP （回复地址） TP_RP
6 TP_UDHI （数据报头） TP_UDHI
5 TP_SRI （需要回复） TP_SRR （请求回复）
4 TP_VPF( 时间格式 )
3
2 TP_MMS （多条短信标志， 1 为无， 0 为有） TP_RD( 拒绝重复标志 )
1 ， 0 TP_MTI （短信类型） TP_MTI
常见值 04 ，正常收到， 44 ，有报头短信 11 ，正常发送， 51 ，有报头短信

1.3.5. TP-PID （协议标识）
在这个里面还有一个字节比较特殊，就是协议标识。
一般都是 00 ，表示点到点的标准短信。
1.3.6. 超长短信
参考 gsm0340 的 9.2.3 .24TP_UD 部分，这个部分中间的一种情况就是描述超长短信的处理。
长短信关键涉及一个数据报头的问题，数据报头由“长度”和多个“数据元素”组成。
1.3.7. Wap-push 短信
WAP 的推送协议中定义了服务指示（ SI ： Service Indication ）和服务加载（ SL ： Service Load ）两项服务，以给用户和网络运营者更多的选择。服务指示是将新信息的指示和相关的通用资源标识符（ URI ）推送给用户，由用户选择是立即处理信息还是以后处理。服务加载是将一项服务的 URI 推送给用户，然后客户端自动地使用 PULL 技术根据该 URI 启动服务。两种服务的区别在于用户是否介入推送信息的处理过程。 SL 对推送信息的处理对用户来说是透明的，而 SI 则在指示用户的同时，请用户对随后的处理做出选择。
PUSH 可以将某一站点或某一业务的链接通过短信发送到支持 WAP PUSH 功能的手机上，这样用户只需要阅读这条短信，打开短信中的链接，就可以直接访问业务了。因此， WAP PUSH 实现了短信和 WAP 业务的结合，节省了用户寻找业务的时间，方便用户直接找到并使用自己喜欢的业务。
Wap-push 短信的核心不同之处就在于：
1、含有数据报头，也就是 TP_UDHI 位为 1 ，一般来说 pdu 的第一个字节发送时为 51 ，接收时为 44 。
2、 TP_DSC 字节不同，一般为 F5 ，表明字符集为 8 位，短信类型为 Class 1; 详细解释参看 gsm03.38 的第四章。
1.4. 编码示例
1.4.1. 发送信息的 PDU 串：
用手机写一条短信息，发送手机号码为 13605696031 ，信息内容为“ Hello World! ”。通过执行 AT ＋ CMGL=2 可以读出此条信息。

AT ＋ CMGL=2 { 读未发短信息 }
＋ CMGL: 1,2,,24 {1 表示信息个数， 2 表示未发信息， 24 表示信息总容量 }
08 91 683108501505F0 11 00 0B 81 3106656930F1 0000FF 0B E8329BFD06DDDF723619
OK

下面分析这条信息：
08 短信息中心地址长度。（短信息中心号码类型 + 短信息中心号码长度 /2 的十六进制表示）
91 短信息中心号码类型， 91 是 TON/NPI 。 TON/NPI 遵守 International/E.164 标准，指在号码前需加‘＋’号 ; 此外还可有其他数值，但 91 最常用。
683108501505F 0 短信息中心号码，是所使用的服务中心地址。由于位置上略有处理，实际号码应为： 8613805515500( 字母 F 意指长度减 1), 这是作者所在地 GSM 短信息中心的号码。 ( 号码处理方法为 , 如果为 +86 开始 , 将 + 号去掉 , 然后判断是否为偶数 , 不是在末尾补 F, 然后将奇数位和偶数位互换 )
11 文件头字节 (header byte, 是一种 bitmask) 。这里 11 指正常地发送短信息。
00 信息参考号。（ TP-MR ）
0D 被叫号码长度。被叫号码长度的十六进制表示。
81 被叫号码类型。
3106656930F 1 被叫号码，也经过了移位处理，实际号码为 13605696031 。
00 协议标识 (TP-PID), 是普通 GSM 类型，点到点方式
00 用户信息编码方式 (TP-DCS) , 7-bit 编码（ 08 ： UCS2 编码）
FF 有效期 (TP-VP), 短信的有效时间
0B 短信息长度
E8329BFD06DDDF723619 短信息内容“ Hello World! ”。

1.4.2. 接受信息的 PDU 串
读取以上发送出来的短信，可以收到如下信息 , 接受到来自 13600554267 的“欢迎“ PDU 串为： 0891683108503705F0040D91683106504562F7000830507001021500046B228FCE 。而接受到的“欢迎“ PDU 串为：
0891683108503705F0040D91683106504562F70000305070010201000AE8329BFD4697D9EC37 。对以上的 PDU 串分析如下表：

段含义说明
08 SMSC 地址信息的长度共 8 个八位字节 ( 包括 91)
91 SMSC 地址格式 (TON/NPI) 用国际格式号码 ( 在前面加 ‘+’)
683108503705F 0 SMSC 地址 8613800573500 ，补 ‘F’ 凑成偶数个
04 基本参数 (TP-MTI/MMS/RP) 接收，无更多消息，有回复地址，如果为 00 ，就没有以下关于回复地址的三个段
0D 回复地址数字个数共 13 个十进制数 ( 不包括 91 和 ‘F’)
91 回复地址格式 (TON/NPI) 用国际格式号码 ( 在前面加 ‘+’)
683106504562F 7 回复地址 (TP-RA) 8613600554267 ，补 ‘F’ 凑成偶数个
00 协议标识 (TP-PID) 是普通 GSM 类型，点到点方式
08 用户信息编码方式 (TP-DCS) UCS2 编码（即中文）
30507001021500 时间戳 (TP-SCTS) 2003-3-12 08:36:45 +8 时区
04 用户信息长度 (TP-UDL) 实际长度 4 个字节
6B228FCE 用户信息 (TP-UD) “ 欢迎 !”

1.4.3. 超长短信
所谓超长短信不同的地方无非就是数据报文需要有个拼接的过程，这个详细可以参考 gsm03.40 的 9.2.3 .24.1 段。下面是个例子，表明的是短信的第一条和第二条。
第一条
0891683108100005F0 SMSC 地址
44 有协议头标志
0D91683118216553F6 回复地址
0008 TP-PID ， TP-DCS
60403011142423 时间戳 (TP-SCTS)
8C 用户信息长度 (TP-UDL)
05 协议头的长度
00 标志这是个分拆短信
03 分拆数据元素的长度
39 唯一标志（用于把两条短信合并）
02 一共两条
01 这是第一条
4E8C96F64E005B9A4
F1A597D597D597D76
8465F 665F 665F 695F 4
4E0D597D597D597D7684
60254F1A4E8654754F604
E5F4E0D898157284E006
B21751F76EE8FDB665A
70B954275417662F4E00
4E2A4E1C5F20897F6211
4E0D662F62117231597D
4E86541754758BBE7F6E
597D597D554A51765B83
662F554A5475547554754
F607684547562A4 数据内容

第二条
0891683108100005F0 SMSC 地址
44 有协议头标志
0D91683118216553F6 回复地址
0008 TP-PID ， TP-DCS
60403011145423 时间戳 (TP-SCTS)
26 用户信息长度 (TP-UDL)
05 协议头的长度
00 标志这是个分拆短信
03 分拆数据元素的长度
39 唯一标志（用于把两条短信合并）
02 一共两条
02 这是第二条
81EA4ECE524D5C317761
7740542754755475007A0
07A006C0076006C006F0
07A 数据

1.4.4. Wap-push 短信
发送的 pdu ，关于 wap-push 短信中间的 wbxml 该如何转变和编码，请参考 WAP Service Indication 规范。
0891683108100005F0 SMSC 地址
51 有协议头标志
00 TP_MR 消息基准值
0D91683118216553F6 回复地址
00 TP-PID
F5 TP-DCS
A7 有效期 TP-VP
85 用户信息长度（ TP-UDL ）
0B WAP PUSH 头部的总长度
05 协议头的长度
00 标志这是个分拆短信
03 分拆数据元素的长度
03 唯一标志（用于把两条短信合并）
01 一共一条
01 这是第一条
05040B8423F0 表示接下来是一个 WAP PUSH
29060603AE81EA8DCA WSP
02 标记位
05 -//WAPFORUM//DTD SI 1.0//EN
6A UTF-8
00 标记开始
45 <si>
C6 <indication
08 <action=signal-high>
0C href="http://
03 字符串开始
3231312e3133362e31353
32e33302f776170707573
682f70757368496e64657
82e6a73703f7075736849
643d3035303531313134
313630353231 URL
00 URL 字符串结束
01 >
03 内容描述字符串开始
E8AFB7E782B9E587BB
E4BBA5E4B88BE993B
EE68EA5E88EB7E58F
96E5BDA9E4BFA1E5
8685E5AEB9 内容描述字符串
00 内容描述字符串结束
01 </si>
01 </indication>

2012-08-26	#1 (permalink)
admin 论坛管理员注册日期: 2009-06-30 帖子: 861	短信开发 1.1. 基本知识短信开发指通过串口 at 命令驱动短信猫进行短信发送和接收操作。在 java 中主要使用 javax.comm 包进行开发， sun 公司网上地址： Java Communications API 使用工具： windows 自带超级终端短信猫操作分为三种模式： block,pdu 和 Text 短信传送有三种编码： 7 位， 8 位， UniCode at 命令 ,at 命令是驱动短信设备的标准工业命令，除了业界的标准之外，每个厂商可能会对其进行扩展，不过一般来说，标准命令应该够用，这次用的是西门子 tc35i ，有专门的 at 命令文档。 1.1.1. 相关文档 Gsm03.38 规范： Alphabets and language-specific information 着重介绍短信发送中对字符集的控制部分 Gsm03.40 规范： Technical realization of the Short Message Service (SMS) Point-to-Point (PP) 详细介绍各种不同短信的不同实现 Gsm07.05 规范： Use of Data Terminal Equipment - Data Circuit terminating;Equipment (DTE - DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS) ，介绍 at 的一些控制命令。 Gsm07.07 规范：着重介绍 at 的短信相关命令，可以说是 at 的 sms 规范。 1.1.2. Block 模式 Block 模式基本已经被 pdu 模式取代，没有具体研究 1.1.3. Text 模式 Text 模式比较简单，但是支持的设备不是很全，而且对于中文似乎有些问题，在金笛的网站技术资料中似乎提到了一句不能实现中文。 AT ＋ CGMF=1<CR> AT ＋ CGMS= “ 13605696031 ” ,129<CR> >Hello World!<^Z> 1.1.4. Pdu 模式 pdu 编码主要包括两个主要的部分，一是 pdu 串的整体数据格式，分别因为发送信息串和接收信息串而有区别，二是 pdu 中文本部分的编码，分别因为字符集而不同。我们也可以这样来理解这个 pdu 编码的格式， sms 相当于一个协议栈，最简单的协议栈：根据 gsm03.40 规范， sms 协议包括以下几层： 1、 SM-AL ：应用层。这个部分就是数据部分。 2、 SM-TL ：传输层。我们可以清楚的看到这里描述了主要的短信内容，包括发送号码，接收号码，信息类型，编码，数据报长度等等，这也是我们编程主要要面对的问题。 3、 SM-RL ：中继层。这个指的是短信在网关之间中继需要的协议。 4、 SM-LL: 链路层。从上述描述中我们可以清楚的看到，我们编程主要集中于传输层。 PDU 串的用户信息 (TP-UD) 段最大容量是 140 字节，所以在这三种编码方式下，可以发送的短消息的最大字符数分别是 160 、 140 和 70 。这里，将一个英文字母、一个汉字和一个数据字节都视为一个字符。 1.2. SMS 用户数据的编码方法 1.2.1. 英文 7 位编码图片不能正确显示这是 gsm 的默认编码方式由于这样的移位，我们可以看到我们能发的最多英文字符等于： 140*8/7 = 160 。 1.2.2. 数据 8 位编码 8-bit 编码通常用于发送数据消息，比如图片和铃声等； 1.2.3. 中文 pdu 编码发送中文时，必须用 UCS2 （ utf-16 ）进行编码，最多可以发 140/2 ＝ 70 个汉字。 UniCode 编码转换也比较简单，以中文为例，一个中文字符是两个字节，直接对高位字节和低位字节进行十六进制转换就可以了。如“欢迎”， UniCode 编码是 6B22 8FCE ，这同时也就是转换的结果，如果发送的串中有英文字符，那么在前面补全 00 ，以保证一个字符对应两个字节。 1.2.4. Wap-push 中的中文编码做 wap-push 短信的时候有些问题了，开始的时候也按照 Unicode 编码处理，总是失败，后来才发现，有个编码字段设为了 uft-8 ，所以在这种情况下，还是可以出现其他编码方式的。 1.3. 短信报头分析 1.3.1. 短信类型详细请参考 gsm 0438 规范和 gsm0440 规范，里面有详细的关于各种短消息类型的描述。在 sms 中到底支持多少种类型的短信，短信类型由什么进行控制，这是我们在这里需要着重介绍的问题。在传输层来分，一共有六大短信类型： SMS-DELIVER ， SMS-DELIVER-REPORT ， SMS-SUBMIT ， SMS-SUBMIT-REPORT ， SMS-STATUS-REPORT ， SMS-COMMAND ，这六种短信类型，由短信中心地址后的第一个字节的最低两位控制。 bit1 bit0 Message type 0 0 SMS-DELIVER (in the direction SC to MS) 0 0 SMS-DELIVER REPORT (in the direction MS to SC) 1 0 SMS-STATUS-REPORT (in the direction SC to MS) 1 0 SMS-COMMAND (in the direction MS to SC) 0 1 SMS-SUBMIT (in the direction MS to SC) 0 1 SMS-SUBMIT-REPORT (in the direction SC to MS) 1 1 Reserved 也就是说，每个短信在短信中心地址之后的第一个字节的最低两位是至关重要的。他决定了如何读这条短信（结合是发送的，还是接收的） 1.3.2. 地址编码短信发送中都会涉及到短信地址的问题，他们的编码规则是一致的 , 简单来说就是 BCD8421码编码。如： 08 91 683108501505F 0 ， 08 ：地址长度，（号码类型 + 号码长度） /2 的十六进制表示 91 ：号码类型 683108501505F 0 ：号码，实际号码应为： 8613805515500 ，号码处理方法为 , 如果为 +86 开始 , 将 + 号去掉 , 然后判断是否为偶数 , 不是在末尾补 F, 然后将奇数位和偶数位互换 1.3.3. TP-DCS( 数据编码格式 ) 这个字节比较特殊，表明整个短信的字符编码，数据内容等信息。详细说明参考 gsm03.38 规范。 1.3.4. 第一个字节 Pdu 编码的第一个字节比较有意思，这个字节会根据六种不同的短信按位有不同的意思，拿句专业一点的话来说，叫 bitmask. 用图来大概描述一下，详细参考 gsm0340 的 9.2.3 段。位数 MSG_Deliever MSG_SUBMIT 7 TP_RP （回复地址） TP_RP 6 TP_UDHI （数据报头） TP_UDHI 5 TP_SRI （需要回复） TP_SRR （请求回复） 4 TP_VPF( 时间格式 ) 3 2 TP_MMS （多条短信标志， 1 为无， 0 为有） TP_RD( 拒绝重复标志 ) 1 ， 0 TP_MTI （短信类型） TP_MTI 常见值 04 ，正常收到， 44 ，有报头短信 11 ，正常发送， 51 ，有报头短信 1.3.5. TP-PID （协议标识）在这个里面还有一个字节比较特殊，就是协议标识。一般都是 00 ，表示点到点的标准短信。 1.3.6. 超长短信参考 gsm0340 的 9.2.3 .24TP_UD 部分，这个部分中间的一种情况就是描述超长短信的处理。长短信关键涉及一个数据报头的问题，数据报头由“长度”和多个“数据元素”组成。 1.3.7. Wap-push 短信 WAP 的推送协议中定义了服务指示（ SI ： Service Indication ）和服务加载（ SL ： Service Load ）两项服务，以给用户和网络运营者更多的选择。服务指示是将新信息的指示和相关的通用资源标识符（ URI ）推送给用户，由用户选择是立即处理信息还是以后处理。服务加载是将一项服务的 URI 推送给用户，然后客户端自动地使用 PULL 技术根据该 URI 启动服务。两种服务的区别在于用户是否介入推送信息的处理过程。 SL 对推送信息的处理对用户来说是透明的，而 SI 则在指示用户的同时，请用户对随后的处理做出选择。 PUSH 可以将某一站点或某一业务的链接通过短信发送到支持 WAP PUSH 功能的手机上，这样用户只需要阅读这条短信，打开短信中的链接，就可以直接访问业务了。因此， WAP PUSH 实现了短信和 WAP 业务的结合，节省了用户寻找业务的时间，方便用户直接找到并使用自己喜欢的业务。 Wap-push 短信的核心不同之处就在于： 1、含有数据报头，也就是 TP_UDHI 位为 1 ，一般来说 pdu 的第一个字节发送时为 51 ，接收时为 44 。 2、 TP_DSC 字节不同，一般为 F5 ，表明字符集为 8 位，短信类型为 Class 1; 详细解释参看 gsm03.38 的第四章。 1.4. 编码示例 1.4.1. 发送信息的 PDU 串：用手机写一条短信息，发送手机号码为 13605696031 ，信息内容为“ Hello World! ”。通过执行 AT ＋ CMGL=2 可以读出此条信息。 AT ＋ CMGL=2 { 读未发短信息 } ＋ CMGL: 1,2,,24 {1 表示信息个数， 2 表示未发信息， 24 表示信息总容量 } 08 91 683108501505F0 11 00 0B 81 3106656930F1 0000FF 0B E8329BFD06DDDF723619 OK 下面分析这条信息： 08 短信息中心地址长度。（短信息中心号码类型 + 短信息中心号码长度 /2 的十六进制表示） 91 短信息中心号码类型， 91 是 TON/NPI 。 TON/NPI 遵守 International/E.164 标准，指在号码前需加‘＋’号 ; 此外还可有其他数值，但 91 最常用。 683108501505F 0 短信息中心号码，是所使用的服务中心地址。由于位置上略有处理，实际号码应为： 8613805515500( 字母 F 意指长度减 1), 这是作者所在地 GSM 短信息中心的号码。 ( 号码处理方法为 , 如果为 +86 开始 , 将 + 号去掉 , 然后判断是否为偶数 , 不是在末尾补 F, 然后将奇数位和偶数位互换 ) 11 文件头字节 (header byte, 是一种 bitmask) 。这里 11 指正常地发送短信息。 00 信息参考号。（ TP-MR ） 0D 被叫号码长度。被叫号码长度的十六进制表示。 81 被叫号码类型。 3106656930F 1 被叫号码，也经过了移位处理，实际号码为 13605696031 。 00 协议标识 (TP-PID), 是普通 GSM 类型，点到点方式 00 用户信息编码方式 (TP-DCS) , 7-bit 编码（ 08 ： UCS2 编码） FF 有效期 (TP-VP), 短信的有效时间 0B 短信息长度 E8329BFD06DDDF723619 短信息内容“ Hello World! ”。 1.4.2. 接受信息的 PDU 串读取以上发送出来的短信，可以收到如下信息 , 接受到来自 13600554267 的“欢迎“ PDU 串为： 0891683108503705F0040D91683106504562F7000830507001021500046B228FCE 。而接受到的“欢迎“ PDU 串为： 0891683108503705F0040D91683106504562F70000305070010201000AE8329BFD4697D9EC37 。对以上的 PDU 串分析如下表：段含义说明 08 SMSC 地址信息的长度共 8 个八位字节 ( 包括 91) 91 SMSC 地址格式 (TON/NPI) 用国际格式号码 ( 在前面加 ‘+’) 683108503705F 0 SMSC 地址 8613800573500 ，补 ‘F’ 凑成偶数个 04 基本参数 (TP-MTI/MMS/RP) 接收，无更多消息，有回复地址，如果为 00 ，就没有以下关于回复地址的三个段 0D 回复地址数字个数共 13 个十进制数 ( 不包括 91 和 ‘F’) 91 回复地址格式 (TON/NPI) 用国际格式号码 ( 在前面加 ‘+’) 683106504562F 7 回复地址 (TP-RA) 8613600554267 ，补 ‘F’ 凑成偶数个 00 协议标识 (TP-PID) 是普通 GSM 类型，点到点方式 08 用户信息编码方式 (TP-DCS) UCS2 编码（即中文） 30507001021500 时间戳 (TP-SCTS) 2003-3-12 08:36:45 +8 时区 04 用户信息长度 (TP-UDL) 实际长度 4 个字节 6B228FCE 用户信息 (TP-UD) “ 欢迎 !” 1.4.3. 超长短信所谓超长短信不同的地方无非就是数据报文需要有个拼接的过程，这个详细可以参考 gsm03.40 的 9.2.3 .24.1 段。下面是个例子，表明的是短信的第一条和第二条。第一条 0891683108100005F0 SMSC 地址 44 有协议头标志 0D91683118216553F6 回复地址 0008 TP-PID ， TP-DCS 60403011142423 时间戳 (TP-SCTS) 8C 用户信息长度 (TP-UDL) 05 协议头的长度 00 标志这是个分拆短信 03 分拆数据元素的长度 39 唯一标志（用于把两条短信合并） 02 一共两条 01 这是第一条 4E8C96F64E005B9A4 F1A597D597D597D76 8465F 665F 665F 695F 4 4E0D597D597D597D7684 60254F1A4E8654754F604 E5F4E0D898157284E006 B21751F76EE8FDB665A 70B954275417662F4E00 4E2A4E1C5F20897F6211 4E0D662F62117231597D 4E86541754758BBE7F6E 597D597D554A51765B83 662F554A5475547554754 F607684547562A4 数据内容第二条 0891683108100005F0 SMSC 地址 44 有协议头标志 0D91683118216553F6 回复地址 0008 TP-PID ， TP-DCS 60403011145423 时间戳 (TP-SCTS) 26 用户信息长度 (TP-UDL) 05 协议头的长度 00 标志这是个分拆短信 03 分拆数据元素的长度 39 唯一标志（用于把两条短信合并） 02 一共两条 02 这是第二条 81EA4ECE524D5C317761 7740542754755475007A0 07A006C0076006C006F0 07A 数据 1.4.4. Wap-push 短信发送的 pdu ，关于 wap-push 短信中间的 wbxml 该如何转变和编码，请参考 WAP Service Indication 规范。 0891683108100005F0 SMSC 地址 51 有协议头标志 00 TP_MR 消息基准值 0D91683118216553F6 回复地址 00 TP-PID F5 TP-DCS A7 有效期 TP-VP 85 用户信息长度（ TP-UDL ） 0B WAP PUSH 头部的总长度 05 协议头的长度 00 标志这是个分拆短信 03 分拆数据元素的长度 03 唯一标志（用于把两条短信合并） 01 一共一条 01 这是第一条 05040B8423F0 表示接下来是一个 WAP PUSH 29060603AE81EA8DCA WSP 02 标记位 05 -//WAPFORUM//DTD SI 1.0//EN 6A UTF-8 00 标记开始 45 <si> C6 <indication 08 <action=signal-high> 0C href="http:// 03 字符串开始 3231312e3133362e31353 32e33302f776170707573 682f70757368496e64657 82e6a73703f7075736849 643d3035303531313134 313630353231 URL 00 URL 字符串结束 01 > 03 内容描述字符串开始 E8AFB7E782B9E587BB E4BBA5E4B88BE993B EE68EA5E88EB7E58F 96E5BDA9E4BFA1E5 8685E5AEB9 内容描述字符串 00 内容描述字符串结束 01 </si> 01 </indication> __________________ 让世界倾听我们的笛声

当前查看此主题的会员: 1 (0 位会员和 1 位游客)