入門：WML的基本情況概述

　　用於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之間可以互相連結。

　　文檔的實體包含在<wml>...</wml>標記中，文檔裡每個CARD又包含在<card>...</card>標記中，然後實際的文欄位落則包含在<p>...</p>標記中。

簡單例子：

<?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" 　 "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card id="HELLO" title="HELLO"> 　<p> 　Hello world! 　</p> </card> </wml>

顯示結果如下：

------ HELLO ------ Hello World!

DECK裡面各個組成部分的具體解釋在本教程的其他部分有說明。

WML字元集
　　WML是XML的子集，繼承了XML的字元集設定。WML文檔預設的字元集是UTF-8。
要顯示中文，有兩種辦法。最簡單的辦法就是在文檔頭使用encoding，即把第一行改為：

<?xml version="1.0" encoding="gb2312"?>

　　然而令人喪氣的是，這種方法有些手機和模擬器並不支援（將來會的），所以目前第2種方法更普遍：不改變字元集設定，但是在寫中文的時候採用UNICODE代表中文字元，如：

<b>通讯录</b>

代表：

通訊錄

WML元素：標記（Tag）和屬性
　　WML的主要內容是文本，由於標記會降低與手持功能的通訊速度，所以WML標準裡僅僅使用了很少一部分。用於表格和映像的的標記幾乎都被排除了。

　　與XML一樣，在WML語言中，所有元素都放在符號"<" 和 ">"中，並且包含一個開始標誌、一個結束標誌和一個內容標誌，或者使用自身結束的控制標記。就象這樣：

<tag>內容</tag> 例如：<p>Hello World!</p> 或 <tag/> 例如：<br/> 和 <go href="#done"/>

　　WML同樣支援在標誌中標出屬性。屬性是標誌的附加資訊，與元素的內容不一樣，它並不在螢幕上顯示出來。屬性通常在元素的開始標誌後指定。如上面最後一個例子。

　　由於WML是XML的一種應用，因此所有的WML標記和屬性都是大小寫敏感的（<wml>跟<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個：<go>（參見任務）和<anchor>（參見事件）。

CDATA
　　XML支援CDATA的概念，以顯示不需要解釋的文本。下面的例子使用CDATA元素在WML頁面中顯示WML命令文本。

<! [CDATA [ <card name="bogus"><p&gtthis is data</p></card> ] ]>

瀏覽器視窗將顯示如下內容：

<card name="bogus"><p>this is data</p></card>

　　有了上面的基礎，相信大家已經能夠做不少事情了。現在我們來深入一下，看看如何提高效能和網路傳輸效率。首先，需要介紹一下http 1.1（RFC2616）的基礎知識。當然，如果你已經很熟悉了，可以跳過第一部分。

一、HTTP 1.1的簡要介紹
　　HTTP 1.1是一個基於文本的互連網實體資訊互動主流協議，這裡的實體可以是WAP相容瀏覽器之類的使用者終端，可以是WAP網關之類的Proxy 伺服器，也可以是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

<?xml version=”1.0”>
<!<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN”
“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訊息頭通常用來屏蔽一個裝置的預設緩衝行為。他們在訊息鏈中傳遞時必須直接穿過所有的Proxy 伺服器和網關而不被改變。

　　* Cache-Control: no-cache。設定這個選項的URL不能被緩衝，包括使用者終端和所有處於內容伺服器和使用者終端之間的其他伺服器；
　　* Cache-Control: max-age=<second>。定義URL儲存在裝置緩衝中的最長時間。時間到了以後，這個實體會從緩衝中清除；
　　* Expired:<date> 。指定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-個項目的曆史堆棧。當使用者按下由<go>或其他轉向指令的定義的前行（forward）連結時，URL被推（push）入堆棧。如果按下由<prev>定義的後退（backward）連結，URL被彈（pop）出。

　　一般情況下，所有的前行連結都會被驗證，而後退連結則不會，因為它已經在cache裡了。可是我們有時候還是希望當使用者按下後退鍵時依然能夠得到最新的資料。如果終端總是不予驗證的話，那使用者只好找到主菜單再重新進入那個頁面。

　　幸運的是，我們用Cache-Control：must-revalidate就可以強迫使用者終端在使用者按back時對URL進行驗證。當然，進行驗證並不是說該頁面會立刻重新讀取，而是根據他是否到期來決定。如果沒有到期，驗證的結果仍然是顯示緩衝中的頁面。

　　如果你需要每次back都重新讀取頁面，用Cache-Control：must-revalidate, no-cache可以實現。另外，把 no-cache換成max-age=300就可以在back時對已緩衝了300秒的頁面進行重新整理。

四、HTTP頭與meta元素
　　到這裡，大家已經知道HTTP訊息頭的在WAP頁面的作用了。不過要在WML文檔裡設定這些訊息頭，就要用到meta元素，它只能出現在WML文檔<head>段裡。下面是幾個訊息頭和它們的表示形式：
　　Expires: Mon, 10 Jan 2000 00:00:00 GMT
　　Cache-Control: max-age=300
　　Cache-Control: no-cache

　　<meta http-equive="Expires" content=" Mon, 10 Jan 2000 00:00:00 GMT"/>
　　<meta http-equive="Cache-Control" content="max-age=300"/>
　　<meta http-equive="Cache-Control" content="no-cache"/>

　　當網關在WML文檔中掃描到元素時，就會把它們轉換成WSP等效的HTTP訊息頭，然後使用者終端就可以據此對緩衝進行控制了。