减小字体
增大字体- ·上一篇编程：CMPP DELIVER
- ·下一篇编程：对于开发SMS初学者的，经常用到的几个函数。
移动业务代码规范方案
一、代码规范方案
一、名词规范
IOD方式：用户通过“－》【信息】－》【写信息】－》【发送】－》特服号” 发送的点播请求。适用于普通SIM卡和STK卡用户。
STK方式：用户通过“－》【移动梦网】－》【各项菜单】－》【发送】－》特服号” 发送的点播请求。适用于拥有STK业务便利卡的用户。
MO：用户终端发起的源请求。包括IOD和STK两种方式。 习惯称PULL业务。
MT：由服务端下发的目标请求。没有用户终端发起的上行请求，一般由服务提供商WEB网站发起。 习惯称PUSH业务。
二、编码规范
业务代码表示业务类别，由内容/应用服务提供商自己制定，由字母组成，长度最大为10位。
业务代码采用容易记忆、便于输入的编码方法。
原则一：基本遵照中文拼音进行缩写。构成方式为：
取每个音节的首字母；大类别缩写在前，小类别缩写在后。 如焦点新闻=新闻（XW）+焦点（JD）=XWJD
原则二：通用缩写优先。如NBA、USA
原则三：某些用户熟知、点播率高的业务，可以从大类中提出，单独定义。如甲A排名的功能代码可以直接为JAPM。
原则四：对于维持时间相对比较短的阶段性内容，例如：世界杯足球赛，或者无法对其进行归类的内容，直接遵照读法缩写。
原则五：所有编码全部采用大写。
（1）对内容进行系统化分类。
应对所提供服务按内容进行分类并尽量使结构合理，条理清晰。
例：
（2）通用信息编码方法：
时间：年年月月日日，如 2000年12月18日 即20001218
国家：可使用英文或拼音全拼 ，如：中国 即CHINA或ZHONGGUO
城市：国内城市使用拼音缩写，如北京 即BJ，国外城市使用英文，如 巴黎 即PARIS 。
注：当国内城市的缩写有重复时，点播回复内容应包括所有重复城市内容。如“陕西”和“山西”的拼音缩写均为“shx”，当用户查询天气预报“TQ SHX”，则将陕西和山西的天气预报同时发给用户。
三、针对三种接口编码规范
需要SP在开办业务的时候就为这（PUSH、STK、IOD）三个接口做考虑。集团公司征求多方意见，对编码进行规范如下：
IOD接口：用户上行点播使用，采取用户熟悉好记的编码规则。
PUSH接口：没有用户上行请求，完全由SP服务端发起的请求，业务代码加字头“-”。
STK接口：用户通过STK卡上行点播，在卡里将业务代码加字头“+”。
SP在向接入地移动公司报编码时，需要慎重考虑此项业务是否有可能支持三种接口的某一种或者某几种，然后填入相应的业务代码。
SP收到网关下来的业务代码，判断出请求是来自IOD还是STK，根据请求来源，下发给网关的业务代码同样需要给请求来源保持一致。
例如：网站主动PUSH下去的焦点新闻为：-XWJD。
响应用户IOD请求的焦点新闻为： XWJD.
响应用户STK请求的焦点新闻为：+XWJ
二、大类代码规范
三、SP业务代码规范补充方案
1、大类业务统一编码，即业务代码的前两位。
2、具体业务代码各SP先自行制定，移动公司汇总，原则上不同SP的相同业务名称的业务代码必须统一，移动公司作为协调方协助各SP编写具体业务代码。
3、上行点播代码兼容业务代码，手机定制类业务统一定制、取消代码如下：“X空格D”是定制，“X空格Q”是取消，其中X代表某个具体的业务代码。在业务代码的基础上，各家公司可以根据实际情况自行编写方便用户使用的上行点播代码。具体要求如下：
1） 用户已经在用的上行点播代码继续使用；
2） 规范后的业务代码也可以当上行点播代码使用；
3） 用户直接使用大类代码点播时必须有反馈，比如用户点播“XW”，可以回馈帮助信息，或者默认为国内新闻。
4、以后出现不能纳入上述大类代码的业务种类，先入为主。
5、按照梦网业务实现方式，将业务分为三类：PUSH、IOD和STK，对三类业务进行区分编码，原则如下：
1）IOD接口：用户上行点播使用，采取用户熟悉好记的编码规则。
2）PUSH接口：没有用户上行请求，完全由SP服务端发起的请求，业务代码加字头“-”。
3）STK接口：用户通过STK卡上行点播，在卡里将业务代码加字头“+”。
SP在向接入地移动公司报编码时，需要慎重考虑此项业务是否有可能支持三种接口的某一种或者某几种，然后按下表格式填入相应的业务代码。
6、一般业务最多分三级，每级子类最好用两个大写字母表示，遇特殊情况具体考虑。
一、名词规范
IOD方式：用户通过“－》【信息】－》【写信息】－》【发送】－》特服号” 发送的点播请求。适用于普通SIM卡和STK卡用户。
STK方式：用户通过“－》【移动梦网】－》【各项菜单】－》【发送】－》特服号” 发送的点播请求。适用于拥有STK业务便利卡的用户。
MO：用户终端发起的源请求。包括IOD和STK两种方式。 习惯称PULL业务。
MT：由服务端下发的目标请求。没有用户终端发起的上行请求，一般由服务提供商WEB网站发起。 习惯称PUSH业务。
二、编码规范
业务代码表示业务类别，由内容/应用服务提供商自己制定，由字母组成，长度最大为10位。
业务代码采用容易记忆、便于输入的编码方法。
原则一：基本遵照中文拼音进行缩写。构成方式为：
取每个音节的首字母；大类别缩写在前，小类别缩写在后。 如焦点新闻=新闻（XW）+焦点（JD）=XWJD
原则二：通用缩写优先。如NBA、USA
原则三：某些用户熟知、点播率高的业务，可以从大类中提出，单独定义。如甲A排名的功能代码可以直接为JAPM。
原则四：对于维持时间相对比较短的阶段性内容，例如：世界杯足球赛，或者无法对其进行归类的内容，直接遵照读法缩写。
原则五：所有编码全部采用大写。
（1）对内容进行系统化分类。
应对所提供服务按内容进行分类并尽量使结构合理，条理清晰。
体育 TY |
新闻 XW |
国际 XWGJ |
国内 XWGN |
娱乐 XWYL |
财经 XWCJ |
足球 TYZQ |
篮球 TYLQ |
网球 TYWQ |
（2）通用信息编码方法：
时间：年年月月日日，如 2000年12月18日 即20001218
国家：可使用英文或拼音全拼 ，如：中国 即CHINA或ZHONGGUO
城市：国内城市使用拼音缩写，如北京 即BJ，国外城市使用英文，如 巴黎 即PARIS 。
注：当国内城市的缩写有重复时，点播回复内容应包括所有重复城市内容。如“陕西”和“山西”的拼音缩写均为“shx”，当用户查询天气预报“TQ SHX”，则将陕西和山西的天气预报同时发给用户。
三、针对三种接口编码规范
需要SP在开办业务的时候就为这（PUSH、STK、IOD）三个接口做考虑。集团公司征求多方意见，对编码进行规范如下：
产品类别 | 产品名称 | IOD | PUSH | STK | ||||||
业务代码 | 价格 | 返回条数 | 业务代码 | 价格 | 发送频率 | 业务代码 | 价格 | 返回条数 | ||
新闻 | ||||||||||
焦点新闻 | XWJD | 0.30元/次 | 2条 | -XWJD | 8元/月 | 2条/日 | +XWJD | 0.30元/次 | 2条 |
IOD接口：用户上行点播使用，采取用户熟悉好记的编码规则。
PUSH接口：没有用户上行请求，完全由SP服务端发起的请求，业务代码加字头“-”。
STK接口：用户通过STK卡上行点播，在卡里将业务代码加字头“+”。
SP在向接入地移动公司报编码时，需要慎重考虑此项业务是否有可能支持三种接口的某一种或者某几种，然后填入相应的业务代码。
SP收到网关下来的业务代码，判断出请求是来自IOD还是STK，根据请求来源，下发给网关的业务代码同样需要给请求来源保持一致。
例如：网站主动PUSH下去的焦点新闻为：-XWJD。
响应用户IOD请求的焦点新闻为： XWJD.
响应用户STK请求的焦点新闻为：+XWJ
二、大类代码规范
信息类 | 通信类 | 娱乐类 | 商务类 | 特殊服务类 | ||||||||||
类别 | 代码 | 包含内容 | 类别 | 代码 | 包含内容 | 类别 | 代码 | 包含内容 | 类别 | 代码 | 包含内容 | 类别 | 代码 | 包含内容 |
新闻 | XW | 邮件 | YJ | 邮件提醒、收发 | 图片 | TP | 股票 | GP | 位置服务 | WZ | ||||
天气 | TQ | 统一信息 | UM | 铃声 | LS | 彩票 | CP | 字典 | ZD | 翻译 | ||||
考试 | KS | 聊天 | LT | 言语 | YY | 外汇 | WH | 帮助 | BZ | 注册密码、帮助信息 | ||||
交通 | JT | 航班、火车、轮船等 | 游戏 | YX | 期货 | QH | ||||||||
防伪 | FW | 易程 | YC | 星座、运程 | 税务 | SW | ||||||||
行业信息 | HY | 人才服务、服装信息 | 休闲娱乐 | XX | 笑话、幽默 | 交易类通知 | TZ | 订票、帐号等通知 | ||||||
体育 | TY | 赛况、竞猜 | 秘书 | MS | 日程、名片 | |||||||||
生活 | SH | 打折 | ||||||||||||
文化 | WE | 语言 | ||||||||||||
三、SP业务代码规范补充方案
1、大类业务统一编码，即业务代码的前两位。
信息类 | 通信类 | 娱乐类 | 商务类 | 特殊服务类 | |||||
新闻 | XW | 邮件 | YJ | 图片 | TP | 股票 | GP | 位置服务 | WZ |
天气 | TQ | 统一信息 | UM | 铃声 | LS | 彩票 | CP | 字典 | ZD |
考试 | KS | 聊天 | LT | 言语 | YY | 外汇 | WH | 帮助 | BZ |
交通 | JT | 短信邮差 | DXYC | 游戏 | YX | 期货 | QH | ||
防伪 | FW | 易程 | YC | 税务 | SW | ||||
行业信息 | HY | 笑话等休闲娱乐 | XX | 交易类通知 | TZ | ||||
体育 | TY | 秘书 | MS | ||||||
生活 | SH | ||||||||
文化 | WE | ||||||||
2、具体业务代码各SP先自行制定，移动公司汇总，原则上不同SP的相同业务名称的业务代码必须统一，移动公司作为协调方协助各SP编写具体业务代码。
3、上行点播代码兼容业务代码，手机定制类业务统一定制、取消代码如下：“X空格D”是定制，“X空格Q”是取消，其中X代表某个具体的业务代码。在业务代码的基础上，各家公司可以根据实际情况自行编写方便用户使用的上行点播代码。具体要求如下：
1） 用户已经在用的上行点播代码继续使用；
2） 规范后的业务代码也可以当上行点播代码使用；
3） 用户直接使用大类代码点播时必须有反馈，比如用户点播“XW”，可以回馈帮助信息，或者默认为国内新闻。
4、以后出现不能纳入上述大类代码的业务种类，先入为主。
5、按照梦网业务实现方式，将业务分为三类：PUSH、IOD和STK，对三类业务进行区分编码，原则如下：
1）IOD接口：用户上行点播使用，采取用户熟悉好记的编码规则。
2）PUSH接口：没有用户上行请求，完全由SP服务端发起的请求，业务代码加字头“-”。
3）STK接口：用户通过STK卡上行点播，在卡里将业务代码加字头“+”。
SP在向接入地移动公司报编码时，需要慎重考虑此项业务是否有可能支持三种接口的某一种或者某几种，然后按下表格式填入相应的业务代码。
产品类别 | 产品名称 | IOD | PUSH | STK | ||||||
业务代码 | 价格 | 返回条数 | 业务代码 | 价格 | 发送频率 | 业务代码 | 价格 | 返回条数 | ||
新闻 | ||||||||||
焦点新闻 | XWJD | 0.30元/次 | 2条 | -XWJD | 8元/月 | 2条/日 | +XWJD | 0.30元/次 | 2条 |
6、一般业务最多分三级，每级子类最好用两个大写字母表示，遇特殊情况具体考虑。
