WML的基本情况(转)

Victor — Sat, 04 Jun 2005 08:23:00 GMT

用于WAP的标记语言就是WML（Wireless Markup Language）。
　　WML的语法跟XML一样，WML是XML的子集。
　　HTML、XML和WML的文件有很多相似之处，这样网页开发者在过去10年中所学的东西今天依然适用。
WML页面文件的后缀是 *.WML，就象HTML的 *.HTML后缀。
XML规定定义了一个规范的XML文件的规格。任何违反这个规定的WML文件会出错。WML文件通常使用XML解释器起来解释。

建立网页制作环境
　　WML文件本身就是文本文件，所以编辑不成问题，顺手的编辑器都可以用。
当然，由于目前的浏览器还都不能显示WML页面，而我们又不能总在手机上进行测试（速度太慢），所以需要模拟器。现在象NOKIA、ERICSSON、MOTOROLA等手机制造商都生产了相应的产品，你只要下载就行了。当然除了模拟器以外，还需要图形制作转换器（用来制作WAP格式的图形文件）、字符转码器（汉字<=>UNICODE）等等，本站工具及论坛页面均有说明。

WML文件结构
　　WML的页面通常叫做桌面（DECK），由一组互相链接的卡片（CARD）组成。当移动电话访问一个WML页面的时候，页面的所有CARD都会从WAP服务器下载到设备里。CARD之间的切换由电话内置的计算机处理，不需要再到服务器上取信息了。CARD里可以包含文本、标记、链接、输入控制、任务（TASK）、图像等等。CARD之间可以互相链接。

　　文档的实体包含在...标记中，文档里每个CARD又包含在...标记中，然后实际的文字段落则包含在

...

标记中。

简单例子：

　 "http://www.wapforum.org/DTD/wml_1.1.xml">

　

　Hello world!
　

显示结果如下：

------ HELLO ------

Hello World!

DECK里面各个组成部分的具体解释在本教程的其他部分有说明。

WML字符集
　　WML是XML的子集，继承了XML的字符集设置。WML文档缺省的字符集是UTF-8。
要显示中文，有两种办法。最简单的办法就是在文档头使用encoding，即把第一行改为：

　　然而令人丧气的是，这种方法有些手机和模拟器并不支持（将来会的），所以目前第2种方法更普遍：不改变字符集设置，但是在写中文的时候采用UNICODE代表中文字符，如：

通讯录

代表：

通讯录

WML元素：标记（Tag）和属性
　　WML的主要内容是文本，由于标记会降低与手持设备的通讯速度，所以WML标准里仅仅使用了很少一部分。用于表格和图像的的标记几乎都被排除了。

　　与XML一样，在WML语言中，所有元素都放在符号"<" 和 ">"中，并且包含一个开始标志、一个结束标志和一个内容标志，或者使用自身结束的控制标记。就象这样：

内容例如：

Hello World!

或
例如：
和

　　WML同样支持在标志中标出属性。属性是标志的附加信息，与元素的内容不一样，它并不在屏幕上显示出来。属性通常在元素的开始标志后指定。如上面最后一个例子。

　　由于WML是XML的一种应用，因此所有的WML标记和属性都是大小写敏感的（跟完全不同），而且所有的标记都必须正确地结束。WML要求属性的值必须放在双引号或单引号内。单引号可放在属性标志内或双引号内。字符亦可作为属性的值。

WML注释
　　XML支持这样的注释格式：

这些注释在浏览器中并不显示出来。
WML不支持嵌套元素注释。

链接（URL）
WML外部引用方式跟HTML相同

http://www.itsalon.net/index.wml 或
http://www.itsalon.net/index.wml#login

内部引用，如果next是当前DECK中的一个CARD时，可以用这种方式：

#next

提供链接功能的WML元素有2个：（参见任务）和（参见事件）。

CDATA
　　XML支持CDATA的概念，以显示不需要解释的文本。下面的例子使用CDATA元素在WML页面中显示WML命令文本。

] ]>

浏览器窗口将显示如下内容：

this is data

　　有了上面的基础，相信大家已经能够做不少事情了。现在我们来深入一下，看看如何提高性能和网络传输效率。首先，需要介绍一下http 1.1（RFC2616）的基础知识。当然，如果你已经很熟悉了，可以跳过第一部分。

一、HTTP 1.1的简要介绍
　　HTTP 1.1是一个基于文本的互联网实体信息交互主流协议，这里的实体可以是WAP兼容浏览器之类的用户终端，可以是WAP网关之类的代理服务器，也可以是Java servlet之类的源服务器程序。它们之间的交互信息就是两大类：客户端对服务器端的请求（request）和服务器端对客户端的响应（response）。一次完整的交互包括一个请求和对它的响应。

所有的请求和响应都采用[RFC822]中定义的标准互联网消息格式，框架如下：
　　* 消息定义
　　* 没有或多个消息头
　　* CRLF（空行回车）
　　* 可选的消息本体
　　其中消息定义不分指定了发送消息的类型。请求和响应都可以包含多个消息头，用来进一步或者重新定义用户终端和服务器之间的交互。CRLF仅仅用来将信息定义和消息本体分开。

1、请求
　　在消息定义部分可以这样定义请求：请求类型 URL HTTP/1.1
其中请求类型可以是下面的一种：
　　①. OPTION：返回请求者和相应者之间可以使用的通信选项，主要用来检测服务器处理能力；
　　②. GET：获得以URL标示的文件内容或者程序执行结果。服务器根据文件名后缀判断服务内容，比如该URL是静态文本还是一个程序；
　　③. HEAD：除了不返回响应的信息本体以外，得到的是跟GET一样的信息。一般用来测试链接的有效性、可达性和近期修改；
　　④. POST：把消息本体中的消息发送到一个URL或者其他类似的服务器端定义行为。通常用来提交一个HTML表单或者一些数据操作活动；
　　⑤. PUT：把消息本体中的消息发送到一个URL，跟POST类似，但不常用；
　　⑥. DELETE：删除URL指定的资源；
　　⑦. TRACE：调用一个远程应用层请求消息回路。发出这个消息的用户终端除了收到原来的消息内容以外，还得到消息在Internet上的传送路径。
　　最常用的请求类型--也是我们在处理WAP应用时最关心的--是GET和POST。假设有一个WML文档，我们用UP的浏览器去浏览的话，就会向服务器发出如下GET请求：
GET www.itsalon.com/wap/index.wml HTTP/1.1
accept-charset: UTF-8
accept-language: ch
accept: text/vnd.wap.wml, */*, image/bmp, text/html
user-agent: UP.Browser/3.1-UPG1 UP.Link/3.2
host: www.itsalon.net
……
其中粗体的部分是HTTP消息头，这里我们忽略了一些与我们关系不大的消息头。
accept-charset: 用户终端支持的字符集
accept-language: 用户终端目前使用的语言
accept: 用户终端可以接受的MIME文件类型
user-agent: 用户终端供应商提供的终端描述信息
host: 请求信息发送到的域名

2、响应
　　响应的消息定义部分一般是这样的：HTTP/1.1 状态码状态描述在[RFC2616]中定义了近40种不同的状态码（分成5组）。其中最常见的是3个：
200 OK
401 Unauthorized
404 Not Found

继续上面那个例子，如果该URL合法的话，服务器的响应会是这样的：
HTTP/1.1 200 OK
Server: www/5.0
Date: Fri, 26 Oct 2000 12:15:23 GMT
Connection: Keep-Alive
Content-Length: 1211
Content_Type: text/vnd.wap.wml
Last-Modified: Mon, 22 Oct 2000 18:19:24 GMT

“http://www.wapforum.org/DTD/wml_1.1.xml”>

……
其它内容
……

　　这个响应信息里包括了响应的数字代码和文本描述，然后是一组消息头。在一个换行符以后就是消息本体，在这里，消息本体就是www.itsalon.net/index.wml的源代码。
Server: 发出响应的服务器
Date: 响应发出的时间
Connection: 指示用户终端保持连接
Content-Length: 响应信息的长度，从DECK的第一个"<"字符开始计算
Content_Type: 响应的MIME类型
Last-Modified: 响应中DECK的最后修改时间

　　当用户终端接收到响应以后，会对其状态信息和消息头进行解码，然后决定对响应做出什么样的动作。如果收到OK响应，一般会把消息本体里的内容显示在屏幕上。对于桌面终端，通常是HTML，对于WAP浏览器，则是WML。

　　HTTP是一种很烦琐的协议。即使是简单没有任何数据的请求和响应都要产生数百字节的消息。WAP通过WAP网关来解决这个问题。WAP网关一个很重要的功能就是把所有的HTTP1.1消息转换成无线任务协议（Wireless Session Protocol, WSP）的消息格式。这种格式是压缩的二进制协议，兼容HTTP1.1。它能解析所有的请求和响应消息，并转换成最精简的BIT序列。

到这里我们已经介绍了HTTP1.1的主要内容。当然HTTP1.1还有很多复杂的内容，但是在这里并不打算多讲，如果你有兴趣，可以去相关网站查找它的资料。作者只想大家知道一点：用户终端和服务器之间还有比GET和POST请求更多的互动消息，它们一样有请求和响应消息头，并且可以包含一些信号来影响WAP应用程序的执行和性能。这正是提高WAP运行效率的秘密所在。

二、缓存（Caching）
　　根据[RFC2616]的定义，缓存是："程序中响应消息的本地储存区以及控制这些消息储存、重新获取和删除的子系统。缓存保存可以缓存的响应消息以便降低将来的响应时间和网络带宽消耗，同样也适用于请求消息。"

　　由于WAP信道带宽的限制，我们在编写WAP应用的时候都希望最大限度地减少消息的传送量。要做到这一点，就要尽量地使用缓存，经常地从缓存中获得以前的消息。幸运的是目前大多数WAP设备都有一定级别的缓存，在默认情况下，会尝试最大化的缓存。几乎所有指向URL的响应都会被缓存下来。

　　当WAP用户终端缓存一个响应的时候，会保存几乎所有的信息：URL、响应文本、消息头以及其他可以验证响应的内容（参看下一节"验证和历史堆栈"）。每个被缓存的项目都可以根据它的URL组成部分（域名、路径、协议、参数、端口等等）唯一的识别。

　　有两种HTTP消息头可以让你控制WML的DECK缓存，对我们最重要的是Cache-Control消息头。它能够直接通过请求/响应链来控制所有的缓存实体。所有的缓存机制都必须遵守这些消息头的定义。Cach-Control消息头通常用来屏蔽一个设备的默认缓存行为。他们在消息链中传递时必须直接穿过所有的代理服务器和网关而不被改变。

　　* Cache-Control: no-cache。设定这个选项的URL不能被缓存，包括用户终端和所有处于内容服务器和用户终端之间的其他服务器；
　　* Cache-Control: max-age=。定义URL保存在设备缓存中的最长时间。时间到了以后，这个实体会从缓存中清除；
　　* Expired: 。指定URL在缓存中存放的最后日期期限。[RFC1123]定义了日期的格式，通常是这样的：Expires: Sun, 29 October 2000 17:30:47 GMT

在写一个WAP应用的时候，你要先假设用户终端会尽量最大化缓存以便使向内容服务器获取信息的动作减少到最少。下面做些解释：

1、永久缓存URL
WAP用户终端通常会尽量长地在它的缓存中保存存取过的URL，这个"尽量长"在Phone.com浏览器中的定义是大约30天。不过，也许你会想把一个URL的缓存时间尽量延长，比如你公司的LOGO，这样每次打开页面的时间就会减少。用下面两种方法能够很简单地实现：

　　* 指定一个离现在很远的过期日，比如：Expires: Tue, 01 Jan 2002 00:00:00 GMT；
　　* 指定一个很大的缓存时间，如：Cache-Control: max-age=3153600。这个例子可以让URL缓存一年。用户终端允许的最大整数是2,147,483,647，所以你可以让一个URL保存超过68年之久。当然，到那个时候，你的手机早就那报废了。

2、指定对URL的缓存时间
　　通常的情况是对一个URL你只需要缓存一段时间。比如股票报价系统，网页可能需要5分钟更新一次，那么你只要在DECK的HEAD部分指定Cache-Control: max-age=300就行了。如果用户在5分钟以内再次检索该页面，看到的还是缓存里的网页。如果在5分钟以后，就会到服务器上获取最新的数据。

　　另外一种控制缓存时间的方法是使用前面提到过的Expires，不过这种方法只能告诉用户终端：只要过了指定时间，无论什么时候访问页面都要刷新。如果你下次要控制时间，只能改变Expires里的时间值。

3、禁止对URL的缓存
　　对于快速变化的内容，一般都会希望每次都得到最新的数据。所以这个时候要完全禁止对相关网页的缓存。方法有三种：
　　* 设定Cache-Control: no-cache；
　　* 设定最大缓存时间为0，Cache-Control: max-age=0；
　　* 设定缓存到期日为一个早就过去的日期，Expires: Mon, 1 Jan 1990 00:00:00 GMT。

实际上，后两种不是最好的选择。首先这样会多占用终端的处理时间，因为当碰到这个DECK时，终端需要计算一下过期时间。其次，这样会多占用一些字节，而且在表达上也不够清楚。

三、验证（validation）和历史堆栈（History Stack）
　　在HTTP1.1中对缓存进一步提出了验证的概念。验证的目的就是检验缓存项目是否在有效期内。由于历史堆栈的存在，WAP终端上的验证过程变得有点复杂。

　　WAP标准规定所有的WAP设备都至少要有可以容纳10-个项目的历史堆栈。当用户按下由或其他转向指令的定义的前行（forward）链接时，URL被推（push）入堆栈。如果按下由定义的后退（backward）链接，URL被弹（pop）出。

　　一般情况下，所有的前行链接都会被验证，而后退链接则不会，因为它已经在cache里了。可是我们有时候还是希望当用户按下后退键时依然能够得到最新的数据。如果终端总是不予验证的话，那用户只好找到主菜单再重新进入那个页面。

　　幸运的是，我们用Cache-Control：must-revalidate就可以强迫用户终端在用户按back时对URL进行验证。当然，进行验证并不是说该页面会立刻重新读取，而是根据他是否过期来决定。如果没有过期，验证的结果仍然是显示缓存中的页面。

　　如果你需要每次back都重新读取页面，用Cache-Control：must-revalidate, no-ca