中国联通CDMAWAP.业务开发规范.docx

中国联通CDMA WAP2.0业务
开发规范
（V3.0）

中国联合通信有限公司

2005年12月
目 录
1 概述 1
1.1 文档内容 1
1.2 适用范围 1
1.3 解释权及修订权 1
1.4 术语和缩略语 2
1.5 参考文献 2
2 WAP2.0技术说明 3
3 业务管理规定 4
3.1 Wap2.0业务申报注意事项 4
3.2 Wap2.0业务测试前相关要求 4
3.3 Wap2.0下载业务计费Url的申报方法 5
3.4 计费和价格 6
3.4.1 费用结构与收费模式 6

3.4.2 收费规则 6
3.4.3 价格原则 7
3.4.4 优惠规则 7
4 业务开发规范 8
4.1 业务访问和定制/退定流程 8
4.1.1 业务访问流程 8
4.1.2 用户订购和使用业务的流程 9
4.1.3 用户退定业务流程 11
4.2 页面开发规范 12
4.2.1 页面设计基本原则 12
4.2.2 页面效果规范 12
4.2.3 背景音乐规范 14
4.2.4 图标与图形规范 一五
4.2.5 CACHE规范 16
4.2.6 菜单规范 17
4.2.7 页面返回规范 17
4.2.8 文本显示规范 一八
4.2.9 用户输入规范 20
4.2.10 格式化输入规范 20
4.2.11 浏览器性能参考 21
4.2.12 MHTML格式页面 21
4.2.一三 终端适配 25
4.2.14 COOKIES规范 25
4.3 URL说明 26
4.4 业务返回规范 27
4.4.1 说明 27
4.4.2 适用范围 27
4.4.3 页面和软键(数字键)的返回规定 27
4.4.4 业务的“返回上级” 28
4.4.5 业务的“返回首页” 31
4.4.6 业务的返回“频道首页” 32
4.5 Wap Push规范 33
4.5.1 说明 33
4.5.2 点对点WAP PUSH 33
4.53 CP服务器发起的WAP PUSH 43
4.5.4 注意事项 51
4.6 业务实现要求 52
4.6.1 对WAP1.2的兼容 52
4.6.2 浏览类业务 57
4.6.3 下载类业务 59
4.6.4 PUSH类业务 67
4.7 用户手机号码和手机型号获取说明 71
4.8 编码和代码 72

1 概述
中国联通CDMA“互动视界”业务自开展以来，用户数增长迅速，用户使用的各类业务越来越丰富，目前提供的各类业务均是按照WAP1.2标准向用户提供的服务。
为了提供更好、功能更加强大的服务，中国联通建立了统一的WAP 2.0门户站点，与WAP1.2门户站点相结合，对用户提供各类服务，为了保证统一WAP 2.0业务，特制定了本业务规范。
1.1 文档内容
本规范内容包括WAP 2.0业务的技术说明，业务访问流程，计费和价格原则以及各类业务规范，并给出了相应的基本原则与例子。同时对于WAP1.2业务的兼容性和延续性作了相关说明。
1.2 适用范围
本规范适用于中国联通各级机构和CP/SP（内容/服务提供商）通过中国联通CDMA WAP2.0门户站点向用户提供各类WAP2.0服务。
1.3 解释权及修订权
本规范由中国联通制定、审核并发布，起草单位为中国联通增值业务部。
本规范将根据市场发展需要适时进行修改，其修改权和解释权属于中国联通增值业务部。

1.4 术语和缩略语
WAP: Wireless Application Protocol
SP: Service Provider,服务提供商
页面：每次请求，所得到的显示内容
频道：根据业务内容分类划分的区域，频道下为栏目列表
栏目：频道中的某一类服务，栏目下是业务列表
栏目标题：显示内容的页面顶端显示的内容标题
栏目名称：菜单栏目列表中指向内容链接或下一级菜单链接的栏目名
XML：extensible markup language, 扩展超文本标记语言, HTML的最新版本（v.4.1）是XHTML的基础。
XHTML MP: XHTML mobile profile, XHTML 移动描述。源于XHTML Basic并且从完整的XHTML 1.1中增加了在移动浏览器中有用的元素和属性。
WAP CSS：WAP cascading style sheets，是CSS的移动版本，他是CSS的一个子集，但不包括那些不适用于特别小的设备功能。
CP/SP：内容提供商/服务提供商
资费确认：用户确认收费规则，如包月、点击及收费金额资费确认

计费：根据用户确认的收费策略，作计费处理，计算本次使用服务的费用
1.5 参考文献
《中国联通CDMA WAP业务规范》
《中国联通CDMA WAP平台接口规范》
《中国联通CDMA PUSH业务规范》
2 WAP2.0技术说明
与WAP 1.2相比，WAP 2.0主要采用的技术：
l XHTMLMP。采用XHTMLMP来扩展XHTML的基本用户简介，并能够按需要增加其他语言元素。
l TCP/IP传送协议移动简本。WAP 2.0 将推动业界为无线链路开发TCP移动简本，能与目前Internet上运行的通用TCP互操作。
l 移动友好技术：包括XHTML的简本; 层叠样式表（CSS）移动简本; 用户个性喜好和设备能力介绍等。

与WAP 1.2相比，WAP 2.0主要体现在：
l 采用最新的Internet标准和协议，能优化网络带宽的利用以及基于数据包的全球无线网络的连接。
l 能对已有的WAP内容、应用和业务提供可管理的向后兼容性。
l WAP 2.0XHTML MP，并支持WAP 1.x内容的WML。这些标记语言在发挥其独特优点的同时，为移动设备提供合适的内容业务。
l 支持对WML 1.0的完全向后兼容。WML 2.0在WML 1.0增加了向后兼容的具体特性后对XHTML MP的扩展，可实现从WML 1.0到XHTML MP的名称、属性的转换。
l 支持的图片格式有：GIF，JPEG，PNG，BMP、WBMP等。
l 按照WAP2.0标准化组织提出的标准开发规范进行页面开发，例如：支持XHTML的简本，层叠样式表（CSS）移动简本多媒体信息服务（MMS），WAP Push等
l 支持语言：支持内容标记语言、WWW Consortium（W3C）以XML（extensible markup language）为基础规定的兼容HTML的“XHTML Basic”，和CSS（cascading style sheets）样式单。
l 支持协议：因特网标准的TCP/IP。
详细WAP2.0技术说明，请访问：xxopenmobilealliancex/。
3 业务管理规定
3.1 Wap2.0业务申报注意事项
1. SP提交的业务必须严格按照WAP业务开发规范和《页面开发规范》（4.2）进行开发，必须根据对页面（如大小在20K以下）、图片（如，页面小图片不超过8个）、铃声（如，铃音必须有试听）、背景音（选择项，但如果采用，则背景音必须有开启关闭的快捷方式）、快捷键、返回、速度等要求严格执行。
2. 在SP已分配的测试区首位新增“WAP20业务区”，在业务接入前，均需将WAP2.0业务URL加入到测试区。
3. 控制每个SP业务的上线数量，原则上一个栏目一个SP只能上线一个业务（可包含两个（含两个）以下子业务），申报业务时注意内容整合。SP应严格按照联通WAP2.0频道规划中规定的数量进行申报。
4. SP提交的WAP2.0业务名称必须积极健康，长度不超过四个汉字。
5. 要求每个业务必须提供“免费试用区”，因此，申报/调整业务的确认或计费Url不能包含或等于入口Url。
6. 对于提供给2.0手机使用的按次或包天下载业务，CP需单独提交业务资源所在路径的Url作为2.0按次或包天下载计费Url。具体填写位置详见工单。
3.2 Wap2.0业务测试前相关要求
1. 必须严格按照《WAP20业务开发规范》和《WAP20页面开发规范》的要求进行业务开发，并且业务开发前根据《Wap2.0门户架构》的设置要求，考虑新业务锁定的目标人群，确定所属频道。
2. 在业务开发中必须考虑申报业务所在频道或栏目的容量，原则上一个栏目一个SP只能接入一个业务（可包含两个（含两个）以下子业务）。所以在业务开发中一定要注意业务的整合和资源的合理使用。联通在业务审核时将不计算SP在某一栏目下已接入业务的数量，请SP自己做好业务数量的核对工作，以避免测试通过后业务无法上线。
3. SP的业务在评审通过后，提交测试前必须增加业务内容数量、提高内容质量，否则将不予以测试。务必保证在提交测试前将业务的数量扩充到同类WAP1.2的上线业务的60％，上线后不低于80％。
4. SP在提交业务申请前务必详细阅读《WAP2.0业务申报注意事项》(3.1)。
5. SP新提交业务从uni-wise网站上进行申请，业务处不再接收申请。SP在提交申请通过后，应提供《WAP2.0业务申报表》，提供URL等相关信息。
3.3 Wap2.0下载业务计费Url的申报方法
l WAP2.0下载类业务的计费URL下载业务的申报方法
（1） 下载类业务，不管是包月、按次、按天计费，计费URL都必须是业务资源所在的路径。例如：某CP提供的“图片下载”业务，所有的图片都放在 “xdownload.cooxx/test/picture/”目录下，那么该业务的计费URL应该为“xdownload.cooxx/test/”，也就是说，该业务中准备用来下载的资源必须处于计费URL的目录下
（2） 为了不违反“不同业务计费URL不能重复或包含”的原则可得，对于下载类业务，不同业务的下载资源不能存放于同一路径，否则相关业务的计费URL就会存在重复或包含。
3.4 计费和价格
对于本章节内容，与WAP1.2业务规范一致。

3.4.1 费用结构与收费模式
中国联通WAP2.0业务的计费均由中国联通进行，费用包括基础通信费和信息服务费。
1. 基础通信费通信费解释
：用户使用中国联通无线通信网络发生的费用，由中国联通制定收费标准，并由中国联通向用户收取。
2. 信息服务费信息费解释
：用户使用SP提供的应用服务而发生的费用，由提供服务的SP制定标准，并由中国联通代SP向用户收取。

3.4.2 收费规则
中国联通WAP平台对于SP提供的WAP2.0业务，支持如下几种信息费计费方法：

1. 免费业务:指用户免费使用SP提供的该项业务
2. 收费:SP对于一个业务可以同时选择多个计费方式收费方式
，如下：
l 按点击计费：按点击计费是用户在使用某CP申请并提供的某项业务时，再申请的地址之下的页面中每点击一次该服务计一次费，如：点击一条新闻计0.1元。
l 按天计费：按照天为单位进行收费，CP就某业务整体进行收费，用户在一天内使用该业务收取一次特定价格的费用，多次进出和重复使用不重复计费。用户当天不使用此业务，不收取费用。
l 包月计费：包月计费是指一次性收取一定费用，在计费月中用户定制某包月服务时，系统一次性收取业务全月费用，用户本自然月内多次使用不重复计费，如果用户不退定，则在后续月初自动的一次性收取全月费用。
3.4.3 价格原则
中国联通WAP2.0业务的信息费由SP指定。但为了规范市场，保证SP公平竞争，SP制定信息服务费的价格应遵循信息服务费不能低于成本价的原则。

3.4.4 优惠规则
为了更好的推广业务，中国联通WAP平台对于SP提供的WAP2.0业务，支持如下几种信息费优惠方法：
1. 对每一个新的用户给予固定时间长度（可设定）的免费试用：在优惠开始和结束日期之内定制该业务，免费使用一段时间。免费试用时长由SP制定。
2. 对每一个新的用户给予固定时间次数（可设定）的免费试用：在优惠开始和结束日期之内定制该业务，免费使用设定的次数。免费试用次数由SP制定。
3. 在固定日期内对所有用户免费使用：SP需要制定免费开始日期和结束日期。
4. 在固定日期内对所有用户按折扣优惠：在优惠开始和结束日期之内，按照业务的原定价格的某一个百分比进行计费。SP需要制定免费开始日期和结束日期，以及百分比。设定的优惠价格（小于正常的收费价格）进行优惠。CP/SP可以申请优惠开始和结束日期，以及优惠价格
5. 在固定日期内对所有用户以特定优惠价格优惠：在优惠开始和结束日期之内，按照低于业务的原定价格的某一个特定优惠价格进行计费。SP需要制定免费开始日期和结束日期，以及优惠价格。
6. 优惠套餐优惠：指把某一个SP的几项业务捆绑在一起向用户销售的策略，用户定制优惠套餐后，在每月缴纳一定费用（如用户每月缴纳25元），就可以使用此SP的优惠套餐中的全部业务。
4 业务开发规范
4.1 业务访问和定制/退定流程
对于本章节内容，与WAP1.2业务一致。
4.1.1 业务访问流程
WAP2.0业务的用户访问流程与WAP1.2业务访问流程类似，参见下图：

（1） 用户使用移动终端一键上网请求访问WAP门户首页，WAP平台对用户请求处理后，返回WAP门户首页。在WAP门户中，存在链接指向SP服务器。
（2） 用户点击WAP门户中的链接，请求访问SP服务器中的业务，该请求发送给WAP平台的计费处理系统。

（3） WAP平台对用户的请求进行认证和鉴权处理后，如果认证和鉴权通过，则WAP平台转发请求给SP服务器。
（4） SP服务器处理用户请求，并返回响应给WAP平台系统。
（5） WAP平台系统返回响应给用户，同时根据SP服务器响应结果对用户进行计费处理。

说明：对用户的计费均由中国联通CDMA WAP平台处理。
4.1.2 用户订购和使用业务的流程
1． 用户使用一个未定制业务的流程

（1） 用户使用移动终端发送业务使用请求给WAP平台。
（2） WAP平台判断用户是否已经定制了此业务，如果未定制此业务，WAP平台弹出业务订购页面，并返回给到用户终端。
（3） 用户选择业务收费规则，并确认订购。
（4） WAP平台成功处理用户定制请求后，把用户请求发送给SP服务器。
（5） SP服务器返回响应给WAP平台。
（6） WAP平台返回响应给用户终端。
（7） 同时WAP平台将用户定制信息传送给SP业务服务器。
2． 用户使用一个已定制业务的流程

（1） 用户使用移动终端发送业务使用请求。
（2） 由WAP平台判断用户是否已经定制了此业务。
（3） WAP平台验证用户已经定制的业务，则将请求转发给SP业务服务器。
（4） SP服务器端返回请求给WAP平台。
（5） WAP平台返回请求给用户终端。

4.1.3 用户退定业务流程

（1） 用户使用移动终端或者登录中国联通统一WEB界面，对已定制的业务进行退定操作。
（2） WAP平台成功处理业务退定操作后，将用户退定业务信息传送到SP业务服务器。
4.2 页面开发规范
4.2.1 页面设计基本原则
1. 由于手机终端具有屏幕狭小、输入受限等特点，同时移动互联网速度较慢，因此CP/SP业务设计本着引导与方便用户使用原则而开展。
2. CP/SP所开发业务既要较快让用户进入与使用，又要方便用户出来使用其它栏目或者CP/SP业务。用户进入后无法通过链接返回首页的业务视为重大错误。
3. 浏览类与信息类业务要求各CP/SP要有功能与风格基本一致的界面
4.2.2 页面效果规范
页面的效果应把握“提高访问速度的前提下，提高页面浏览流量、提高页面视觉冲击效果”的原则：
1. 单页面图片与文字总和的整体容量应控制在20k以下，普通页面的全部展现时间应保证小于4s，多图形页面的全部展现时间应保证小于6s（包括页面内置对象）。
2. 对于业务入口页面，在保证速度的前提下，应尽可能做得丰富一些，增强用户的视觉感受；对于第二级和第三级及其以下的页面，可以稍微简化页面的效果，但是不允许出现纯文本的页面。
3. 对于使用图片的页面，应该设置与图片主色调相近的背景色，在用户触发页面的下载后，应保证用户通过迅速见到出现的背景色而能感受到下载已经进行绝对不能在下载进行中向用户展现白屏。
4. 如果使用表格的嵌套，嵌套的层数应该少于2层。
5. CSS应该定义到每一个文件，不能单独做成一个文件，应使用页面内包含。
6. 对于背景的图片，建议使用小图片的平铺方式，可以大大提高下载速度，平铺应该优先考虑双模手机170cm像素的屏宽。否则将会出现明显的接缝痕迹，示例如下:
未考虑双模手机平铺效果：

建议平铺效果：

7. Html Body下的子TAG中的内容应尽量少，尽量少定义全局，应分散到多个子TAG中，TAG禁止相互嵌套，代码示例:
pacing="0" cellpadding="0">
table>DI格式。
2. 为了满足用户在不同场景中的需要， 页面中应该设置明显的可以开启或关闭背景音的操作方式。
3. 背景音乐的请求代码应该放在图片的请求代码的后面，以保证下载速度和用户感受，示例代码如下：
推荐的写法：

fkdgjkldgjklfjdksgjkdl
gjklfdjgkldjf

ody>

不推荐的写法：

fkdgjkldgjklfjdksgjkdl
gjklfdjgkldjf

4.2.4 图标与图形规范
1. 为了保证页面的整体下载时间，建议单页面图片的容量应该控制在一五k以内。
2. 图片下载必须提供图片预览功能，预览时显示文字应为“生成预览中…”， 预览图片应为80x80像素，大小应控制在6K以内，以保证预览生成的速度在3秒以内。正式下载的图片应尽量保证容量较大，图像清晰。建议下载图片大小在25K左右， 预览页面效果如图：

圣诞老人 1256字节
下载

返回上级* 联通首页#

生成预览中…

圣诞老人 1256字节
下载

返回上级* 联通首页#

3. WAP浏览器对于不同格式的图片解码速度是不同的，根据测试值得出（OPENWAVE浏览器），解码速度BMP保证图片质量的基础上，最好选择GIF和PNG格式的图片，并且应经过PHOTOSHOP压缩。
4. 由于使用小图标会增加Http请求的个数从而影响页面的整体下载速度，所以不推荐在栏目列表中使用较多的小图标，建议使用特殊符号或者数字符号代替小图标，可以很大程度上提高浏览速度；如果必须使用，则每页使用小图标的个数不应超过8个，且单个图标大小应在500byte以内。

4.2.5 CACHE规范
1. 为加快用户浏览页面显示速度，业务入口页面，以及公共性和架构类的页面应使用CACHE，其他页面不应使用CACHE。
2. 不要将时效性很强的内容（如新闻、股票信息等）留在CACHE中。
3. 天气信息、交通信息等特定内容在CACHE中的有效时间为6小时。
4. 对动态信息要强制更新。
4.2.6 菜单规范
1. 菜单项按业务的重要性的顺序来排列，用户最可能选择的业务排在前面。
2. 菜单项应遵循的排列格式：在保证美观的基础上，如果菜单一列显示，文本部分左对齐，图片菜单部分中间对齐；如果分列显示，文本部分左对齐，图片菜单项要尽量与屏幕宽度相同，如果不能相同，则要保证中间对齐。
3. 菜单项应尽量避免使用小图标。。
4. 建议使用数字快捷键作为菜单选择手段，但是菜单选项应该使用明显的标识提示用户使用数字快捷键，菜单选项多于9个时，定义“0”键表示进入下一页，定义“*”键表示返回上级；定义“#”键表示返回首页。对于不支持字符触发的终端，“返回上级”和“联通首页”应采用小图标和文字链接，可以通过方向键选择。
5. 菜单尽量不要小图标（Icon）和数字快捷键同时使用，因为这样，对于大部分终端，会造成菜单文字的换行，影响界面的美观。
6. 如果需要在一个菜单项上执行多个操作，可以通过弹出式菜单实现。

4.2.7 页面返回规范
用户经常使用手机中的返回按键（通常就是删除按键）返回或退出，因此，返回连接对一个业务的成功是十分关键的，要倍加关注，对返回连接设计好的业务，将会显著地提高用户的使用次数。
1. 在所有业务的页面底部必须有一个“联通首页#”和“返回上级的链接(注意必须在链接的文字后提供“#”和“*”作为明显的标识提示用户)；“返回首页”的链接为：xwap.uni-wisex，页面效果如图：
（个人图片)（图片下载）
（铃声下载）（屏保动画）
（音乐动画）(背景图片)

返回上级* 联通首页#

返回上级：指返回SP的应用菜单
联通首页：指返回互动视界的首页
2. 如果上一个页面是重定向页面，则“返回上级”应跳过重定向页面。
3. 为了便于用户的使用，在有些情况下，允许返回上级功能不直接返回上一个页面，而是将用户带到最方便使用业务的页面。
例：用户在使用铃声搜索或者单词翻译的业务时，当输入的要搜索的铃声或者翻译的单词，然后进入确认页面，点击确认后，当没有找到时出现的提示页面中的返回，不是返回到确认页面，而是返回到重新输入页面；

4.2.8 文本显示规范
1. 一个CARD中显示500-600个字符，即300汉字以内。
2. 当需要显示的内容超过范围时，在底部提供一个“下一页”连接，但在每个栏目下，传送给用户的内容最好不要超过3页。
3. 将超出一行的内容分行显示，但主菜单及子栏目标题则应尽量将文字压缩为一行。如：“少女系列三十一”此标题字符过长，可将其压缩为“少女系列31”。
4. 所有文本左对齐。
5. 每段文字的首字需要保证对应的文字缩进。
6. 浏览图片和新闻等内容时，应提供明示下一主题或内容的连接说明，用于用户直接转到下一个主题或内容，比如“下一张”、“下一条”等，而不要仅仅显示“下一页”，以免造成用户的混淆。
7. 所有提示性文字应使用统一的简体中文，避免出现英文与中文混合的内容，如“Loading…请稍后”，应为“正在下载中…请稍后”。
8. 菜单中的各项要按照一定的逻辑顺序来排列，如按照类型、时间、字母顺序等。如果没有逻辑顺序，就按优先级排列，将最可能选择的排在最前面，将最新更新的部分放在最前面，并加入“NEW”字样。
9. 新闻类栏目要在新闻标题的后面显示新闻发布的日期及出处。如图：
1. 中国队大胜香港队……。(2004。11。一八，摘自XX时报)
2. 央视招标突破50亿……。(2004。11。一八，摘自XX晚报报)
3. 北京警方成功破获多起抢劫案……。(2004.11.一八，摘自XX时报)
下一页

返回上级* 联通首页#

10. 当用户阅读文本时，应能主动预读取下一页文本到手机的CACHE中，加快用户阅读的切换速度。
比如：

e=”Page2”>

不要用*进行掩盖，在手机上明文显示即可。
7. 使用MAXLENGTH参数来限制用户输入密码的长度，避免用户出错。
4.2.10 格式化输入规范
格式化输入主要包括输入日期、信用卡号码等具有固定格式的内容。
1. 对所有格式化输入都必须表明输入格式，如输入如期时可以表示为：MM/YYYY见下 例：
2. 对输入的类型进行强制匹配，该输入数字的地方，不能输入字母。
3. 可以通过MAXLENGTH参数限制输入的字符数。
4. 对确定的内容进行预制， 如输入日期时可以表示为20xx，只让用户输入后两位数字就可以。
5. 对可确定用户输入的文字功能实现自动切换，如需用户输入密码时应自动切换为“数字功能”，要求用户输入Email地址时，应自动切换为“英文”等。
4.2.11 浏览器性能参考
1. 目前浏览器并发请求能力无法启用，浏览器一次只能发送1个请求，因此建议CP/SP建议控制页面中Http link数目。
2. 页面中http link请求的顺序是按照编写的顺序产生的，建议CP/SP对于较大的对象应尽量放在后面。
3. 页面编码应采用utf-8， 可减少proxy或终端的转化。
4.2.12 MHTML格式页面
4.2.12.1 概述
鉴于4.2.11章节中提到的手机浏览器单连接同步发送请求的特性，减少同一页面中请求数量可以有效的加快页面翻转速度MHTML格式页面恰恰可以满足如上需求。
目前Openwave 6.X版本的浏览器已经被普遍的应用在Wap2.0终端上，该版本手机浏览器可以支持Multipart/related MIME Type。由于MHTML格式页面对于“多图”页面能够显著提供页面翻转速度，因此，对于由页面下载速度缓慢而严重影响用户感知、用户体验的页面，我们建议采用MHTML格式页面进行打包，将多个请求转换为一个请求，缩短由于手机浏览器的局限而导致页面翻转较长的耗时。
4.2.12.2 实现原理
网页打包技术是一种基于HTTP的传输扩展协议，可以参考互联网标准协议RFC2557《MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)》，通过在传输过程中实现页面和页面内嵌对象的整合编码技术，实现一次连接可以传输完整页面及页面内嵌对象的技术标准。本协议是对RFC2557在WAP传输上的修正，针对无线网络的特性，去掉了冗余数据，结合CDMA1x的高速数据通道实现无缝高效传输。
传统的WAP页面传输过程：
1. 向服务器发送请求，请求页面文件(WML或XHTML)。
2. 显示初步页面。
3. 浏览器针对页面进行分析，得到页面内嵌对象（如图片，铃声）的URL。
4. 继续发送对页面内嵌对象请求。
5. 显示完整页面。
服务器
手机

页面元素文件
XHTML文件
多次请求/应答
一次请求/应答

WML/XHTML格式页面传输示意图
服务器
手机
打包技术页面传输过程：
1. 向服务器发送页面请求，传输整个MHTML页面文件。
2. 对打包文件解码，显示完整页面。
手机
服务器
MHTML文件
一次请求/应答

MHTML技术传输示意图
4.2.12.3 简单实现过程
4.2.12.3.1 将网页转成Multipart格式
1. 使用IE打开某业务入口页面。
2. 在菜单中选择另存为。
3. 在对话框内选择保存类型为[WEB档案，单一文件]。
4. 选择编码为UTF-8,文件名为test.mht，确定保存。
5. 在菜单中选择另存为。
6. 在对话框内选择保存类型为[网页，html格式]。
7. 文件名为test. html，确定保存。
8. 使用文本编辑器打开test.mht。
9. 去掉前的16行（前16行为IE自行添加的冗余信息）。
10. 增加以下内容：
<%x page contentType="multipart/related;type=\"text/html\";boundary=\"----=_NextPart_000_0003_01C54672.B1702520\""%>
------=_NextPart_000_0003_01C54672.B1702520
Content-Type: text/html;charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: page

4.2.12.3.2 将页面元素转成Base64格式
接前一章节：
1. 查找图片文件的URL位置。
2. 修改为本地路径。
3. 去掉最后一行的标识------=_NextPart_000_0000_01C54B57.43303D40-（对于不同情况，黄色背景部分可能略有不同）。
4. 在文件尾部加上以下内容（假设该测试页面只内嵌了2个对象）：
------=_NextPart_000_0003_01C54672.B1702520
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Location: a.gif

------=_NextPart_000_0003_01C54672.B1702520
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Location: b.gif

------=_NextPart_0000003_01C54672.B1702520--

5. 在test.files文件夹中找出图片文件并使用BASE64进行编码，获得纯文本字符串，或参照以下步骤使用outlook对图片进行编码。
a) 打开outlook,新建一个邮件
b) 在附件中选择以上的图片文件
c) 发送邮件
d) 在邮件发送箱中找到该邮件
e) 查看邮件属性里的详细信息
f) 选择编号好的图片文件内容
4.2.12.3.3 整合为MHTML文件
1. 在test.mht中粘贴对内嵌对象进行BASE64编码后的纯文本字符串。如，
------=_NextPart_000_0003_01C54672.B1702520
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Location: a.gif
此处粘贴a.gif进行BASE64编码后的纯文本字符串
------=_NextPart_000_0003_01C54672.B1702520
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Location: b.gif
此处粘贴b.gif进行BASE64编码后的纯文本字符串
------=_NextPart_000_0003_01C54672.B1702520--

2. 将test.mht另存为test.jsp。
3. 部署到应用服务器。
4. 进行测试。
4.2.12.4 应用范围
如4.2.12.1章节要求，对于由页面下载速度缓慢而严重影响用户感知、用户体验的页面，我们建议采用MHTML格式页面进行打包。
以下举例说明建议采用MHTML格式进行开发的现网业务页面（灰色涂抹部分为尚未下载完成的图片说明，顾及影响，此处以灰色进行涂抹）。

以上页面效果严重影响用户感知、用户体验，因此，对于此类业务页面，我们建议以MHTML格式进行开发。
4.2.13 终端适配
1. 由于终端支持的选择性的，相同设计的页面在不同的终端上有着不同的表现形式，因此，请CP/SP在开发时注意通过终端适配，识别不同的终端并根据其不同的能力属性来推送适配的页面。
2. 由于终端CPU性能的影响，一些终端在解码时CPU资源占用严重，影响浏览速度，这类终端不适合图片内容较多的页面的展现， CP/SP应单独对这类终端进行适配。
4.2.14 COOKIES规范
鉴于终端浏览器可以设置不支持Cookie，因此，对于需要保存会话关系的WAP 2.0应用程序，应通过URL重写（URL Rewriting）的方式来保存会话关系，即将用户的会话信息保存在URL中，当用户点击链接时送回服务器端来保持用户的会话关系。

4.3 URL说明三个URL解释

对于本章节内容，与WAP1.2业务一致。

SP在中国联通WAP门户中提供一个WAP2.0业务时，需遵循中国联通WAP平台基于URL计费（信息费）的原则，对于接入的任何收费业务需要提供如下几类URL：
参数名称
参数举例
用途描述
入口URL
xwap.demox/wap/index.jsp
业务的入口URL，唯一的一个
计费URL
xwap.demox/wap/content/fee1/
xwap.demox/wap/content/fee2/
如果用户访问的URL包含此URL，WAP平台进行计费处理。关于我们      便捷服务       自信AI       AI导航        抽奖活动©2010-2026 宁波自信网络信息技术有限公司  版权所有客服电话：[phone]  投诉电话：[phone]浙公网安备33021202000488号   浙ICP备2021020529号-1  |  浙B2-20240490  关注我们 ：