因為手機內(nèi)置的微瀏覽器各手機廠家并沒有統(tǒng)一.存在大量的標準差異和技術(shù)差異.會導(dǎo)致通過手機對WAP的訪問的成功率降低.為規(guī)范和統(tǒng)一SP的頁面.保證其符合基本的技術(shù)規(guī)范.特回答以下問題.
什么是WML？
A:答：是WIRELESS MARKUP LANGUAGE（無線標識語言）的簡稱，是WAP規(guī)范的一部分，類似于編寫網(wǎng)頁HTML語言；它是XML基礎(chǔ)上的標識語言，用于界定文字的格式、表現(xiàn)方式，屏幕的層次（‘deck’），和頁與頁（‘card’）之間的超鏈接。
現(xiàn)在支持的WML版本?
答:分為兩種. 非OPENWAVE和OPENWAVE.其規(guī)范分別是WAP 1.1和WAP 1.3,可以在WAP 論壇上查到相應(yīng)的WML版本
WML與XML有何不同？
答：XML語言由W3C制定的META語言，是為特定應(yīng)用程序加入其它語言的一系列規(guī)則。XML不直接加密內(nèi)容，而由XML規(guī)定的特定標識語言進行加密。WML完全遵循XML規(guī)則，是無線應(yīng)用的一種特定語言，因此是XML其中一種應(yīng)用。
WML語言分不分大小寫？
答:分大小寫，WAP 1.1版用小寫標識符
頁面應(yīng)該采用何種DTD版本?
答:分兩種
WAP 1.1 (非OPENWAVE)
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
WAP 1.3 (OPENWAVE)
<!DOCTYPE wml PUBLIC "-//OPENWAVE.COM//DTD WML 1.3//EN"
"http://www.openwave.com/dtd/wml13.dtd">
現(xiàn)在WAP的頁面大小可以多大?
答:不同的電話各不同，作為原則，應(yīng)盡量編輯頁面使之不超過1397字節(jié).這非常重要.請注意
現(xiàn)在WAP的每一頁的選項可以有多少?
答:由于WAP –GW的限制,OPEN WAVE的頁面最好控制每頁8個連接.非OPENWAVE可以有11個連接.
每一個連接的連接地址可以多長?
答:由于一些老的手機對連接地址的長度有限制.建議連接的長度在70個字節(jié)以內(nèi).
為什么一定對手機的按鍵進行控制?
答:做為一個服務(wù)商,必須在每個頁面控制用戶的訪問行為.為手機的回退等按鍵是可以使用WML強行指定的.如果可以.請指定.
返回夢網(wǎng)首頁的方式?
答:在你自己的頁面最下端統(tǒng)一加入以下代碼:
<anchor> <go > </go>返回夢網(wǎng)首頁</anchor>,剩下的事情會由WTBS來處理.它會將你的這個地址替換成一個標準的返回夢網(wǎng)的地址.如:
<go />
現(xiàn)在支持的中文編碼?
答:現(xiàn)在只支持UTF8編碼.并要求在WEB SERVER輸出的 HTTP HEAD信息中包含以下內(nèi)容:content-type: text/vnd.wap.wml;charset=UTF-8.
或者在頁面的<HEAD></HEAD>字段中加入:
<meta http-equiv="content-type" c/>
我怎么實現(xiàn)對頁面在手機和WAP GW上的CACHE控制
答:嘗試在頁面的<HEAD></HEAD>中加入以下信息:
<head>
<meta http-equiv="Cache-Control" c forua="true" />
<meta http-equiv="Cache-Control" c forua="true"/>
<meta http-equiv="Cache-Control" c forua="true" />
</head>
WAP SERVICE 應(yīng)該采用何種MIME?
WAP 1.1, 服務(wù)器端加入以下MIME類型：
Associated Extension MIME Type
wml text/vnd.wap.wml
wmlc application/vnd.wap.wmlc
wbmp image/vnd.wap.wbmp
wmlsc application/vnd.wap.wmlscriptc
wmls text/vnd.wap.wmlscript
wsc application/vnd.wap/wmlscriptc
頁面之間的參數(shù)傳遞如何處理?
答:如果可能.盡量不要使用POST直接傳遞參數(shù).建議通過
HTTP://WAP.TEST.COM的方式通過URL傳遞參數(shù).
WML SCRIPT支持嗎?
答:支持.但建議盡量不要使用以上方法.會導(dǎo)致計費可能不完整.
系統(tǒng)現(xiàn)在支持的計費方式?
答:現(xiàn)在支持包月和按次兩種方式,像鈴聲和圖片類業(yè)務(wù)最好按次.角色扮演類游戲最好按包月方式和用戶結(jié)算.
WAP FORUM是什么？
答:WAP FORUM是由多個會員組成的行業(yè)協(xié)會。它制定了WAP的標準。其主要目標為聯(lián)合無線通信行業(yè)的各個不同領(lǐng)域的公司，保證產(chǎn)品的兼容性和行業(yè)的發(fā)展。WAP FORUM會員代表了占世界移動電話市場九成以上的制造商、覆蓋用戶超過一億人數(shù)的營運商、主要的基礎(chǔ)設(shè)施供應(yīng)商，以及為無線通信行業(yè)提供解決方案的軟件開發(fā)人員和組織。 請參http://www.wapforum.org/
SP的首頁訪問頁面取不到規(guī)范里面指定的各參數(shù)
在這種情況下，大多錯誤是判斷變量大小寫出錯造成的，因為變量是大小寫敏感的；MISC向SP傳回去的變量名為：
MISC_SessionID
MISC_ServiceID
對于MISC_SessionID和MISC_ServiceID，MISC的傳遞方式是通過URL參數(shù)直接傳遞；所以SP的程序應(yīng)該使用GET方式進行讀取
Provision 接口部分
無法正確讀取MISC發(fā)過來的XML包內(nèi)容；
往往是SP的接口程序在處理HTTP POST包內(nèi)容的時候出錯；如何讀取包內(nèi)容的代碼，可參照不同語言的DEMO程序。
SP應(yīng)該正確安裝XML的SDK包，可以使用相關(guān)的SDK進行XML分析；不同語言有不同的SDK包；例如，asp需要安裝msxml 3.0以上版本；c語言的sdk版本可以免費在網(wǎng)絡(luò)上下載。
在程序調(diào)試中可以將取到的內(nèi)容先存入到Log文件中，這樣錯誤就很容易定位。
MISC系統(tǒng)無法判斷SP程序返回的內(nèi)容；
可能是因為SP接口程序容錯性差，程序運行出錯，返回了系統(tǒng)的出錯頁面，而非指定的XML格式。
或者接口程序返回了XML格式包；但是因為XML對語法要求很高，經(jīng)常會誤筆寫錯了某個元素造成的；
因此，最好可以參照DEMO進行Copy& Paste，減少誤操作產(chǎn)生的錯誤。
部分Provision操作失敗；
可能會MISC和SP之間的數(shù)據(jù)不同步或者SP的程序邏輯錯誤；
數(shù)據(jù)不同步往往也會造成上述錯誤信息；例如，在SP中已經(jīng)用此用戶的訂購信息而在MISC中沒有，則會在訂購時，SP判斷數(shù)據(jù)庫中已經(jīng)有訂購信息，返回操作失敗信息；在這種情況下，互相確定SP和MISC之間的數(shù)據(jù)狀況，可以先同時做個數(shù)據(jù)初始化操作。
SP的程序邏輯錯誤造成上述錯誤信息；例如，必要只有被暫停后的服務(wù)才能被重新啟動；否則應(yīng)該返還出錯信息。
調(diào)試過程中，可讓局方的測試人員配合一起進行。
SSO接口部分
MISC系統(tǒng)沒有反應(yīng)，沒有應(yīng)答；
原因可能如下：
SSO URL出錯；
因為MISC的SSO處理程序是個js的腳本文件，不要誤寫成.jsp文件了。
SSOIP鑒權(quán)沒有通過；
MISC需要對SP發(fā)起SSO的接口程序作IP鑒權(quán)；因此需要跟MISC運維人員確定IP是否配置正確了。
SP的SSO程序的通信協(xié)議部分出錯；
MISC和SP之間的SSO通信是使用標準的Http協(xié)議通信；SP的SSO程序使用POST方式發(fā)送到指定的URL上；如果POST的數(shù)據(jù)不對，則系統(tǒng)會返回一個404的提示信息，而非表明此程序不存在。
SP程序應(yīng)注意在讀取MISC返回SSO應(yīng)答包的時候采用連續(xù)讀取的方式，將所有的包全部讀下后，斷開連接。
MISC返回內(nèi)容格式錯誤；
可能是XML包格式不對造成的；SSO的XML包格式程序部分可參考MISC發(fā)布的DEMO程序。往往XML的格式語法要求特別高，很容易出錯，可以直接拷貝DEMO中的XML格式部分。
MISC返回SessionID過期的錯誤；
如果SP保持的SessionID超過了它的缺省有效時間短，則MISC系統(tǒng)將無法解析SessionID；在這種情況下，SP的接口程序應(yīng)該導(dǎo)航用戶到首頁進行重新登錄。
MISC返回SessionID或者ServiceID或者SPID或者SP_Passwd有誤信息；
如果上述參數(shù)的格式有一個不對的話，均會造成返回失敗信息。
SPID是SP的企業(yè)代碼，9開頭的6位數(shù)字串；
SP_Passwd是鑒權(quán)SP使用的；上述兩個參數(shù)均需要與MISC運維人員確定；
SessionID和ServiceID是通過在頁面GET變量讀取。
SSO一般只返回MID，不返回用戶的手機號信息。根據(jù)SP的特別要求可以開放返回用戶的手機號信息
注意SessionID、ServiceID、MID都不是整數(shù)類型，而只是數(shù)字串，因此SSO的接口程序應(yīng)該將上述變量類型其設(shè)置成字符串的類型。
我應(yīng)該怎么設(shè)計我的接口程序流程部分？
SP的信息源的程序可以按照以下的流程進行：
SP的頁面程序讀取MISC系統(tǒng)發(fā)過了的參數(shù)；
程序從數(shù)據(jù)庫中查看是否有SessionID和ServiceID的解析紀錄？
如有，則比較其Sumtime是不是超過了Timeout時間；如果沒有，則可以通過訪問權(quán)限控制系統(tǒng)控制是否讓這個用戶訪問這個頁面；否則繼續(xù)由程序向MISC發(fā)起SSO請求；取回SessionID的解析成MID；并將上述相關(guān)的解析關(guān)系存入到數(shù)據(jù)庫中；并讓訪問權(quán)限控制系統(tǒng)根據(jù)MID來控制是否讓這個用戶訪問這個頁面。
SP的程序在每個事務(wù)的最后頁面才發(fā)起ECHO請求；例如，用戶注冊填寫流程的最后一個頁面來發(fā)起ECHO；在查詢請求的最后一個頁面來發(fā)起ECHO；在游戲的最后一個頁面來發(fā)起ECHO請求等。
SP的頁面不能正常顯示，但是使用瀏覽器直接訪問其站點則顯示正常。
此項出錯信息是SP接入中遇到最多的錯誤，往往錯誤信息是以“SPID error,……”；其錯誤原因比較復(fù)雜，但是大體如下：
返回頁面的http頭里沒有加上charset=utf-8的標志。
如果SP返回的頁面沒有指定UTF8編碼格式，則往往頁面返回會出現(xiàn)亂碼。
在每個連接前沒有使用絕對路徑。
如果在每個連接前沒有使用絕對路徑，則WTBS無法對這個地址進行解析，點擊后會出錯。
頁面中的鏈接過多。
因為WTBS在每個從SP返回的頁面要進行過濾，在每個頁面前加入100個左右的字符；如果鏈接數(shù)過多的話，在添加的冗余字符過多，造成頁面通過手機通過WAP Gateway無法訪問。
“返回夢網(wǎng)”按鈕指定的鏈接不對。
對于"返回夢網(wǎng)"的鏈接不得使用<a >或者<go >以外的方式。
SSO/ECHO的時延過長。
WAP Gateway對WAP服務(wù)器返回的時延要求比較嚴格；如果在指定的timeout時間（一般為3-5秒）內(nèi)沒有返回，則會返回網(wǎng)關(guān)錯誤信息；因此如果SP的信息源服務(wù)器跟MISC的WTBS服務(wù)器之間網(wǎng)絡(luò)狀況不好，并且MISC的負載過重都會造成每步的時延；每步的時延累加會造成整個時延過長。
WML頁面沒有嚴格遵循XML格式。
WTBS將對每個返回的WML頁面進行解包；因為頁面分析是嚴格按照XML的語法進行的，如果頁面沒有嚴格按照XML語法，則分析就會出錯；但是因為瀏覽器可以支持非標準的XML語法，所以造成有些頁面通過WTBS不能訪問，但是用瀏覽器就可以訪問。
WML頁面是否有&nbps;。
在舊版本的WTBS中，如果SP的頁面中如果有&nbps;空格，則會分析出錯，是個bug。
href指向的鏈接中的？之后的參數(shù)帶著/，則WTBS在這種鏈接下增加過濾參數(shù)會出錯。
在舊版本的WTBS中會出錯。
附件1
對HTTP 1.1和CACHE控制的介紹.
一、HTTP 1.1的簡要介紹
HTTP 1.1是一個基于文本的互聯(lián)網(wǎng)實體信息交互主流協(xié)議，這里的實體可以是WAP兼容瀏覽器之類的用戶終端，可以是WAP網(wǎng)關(guān)之類的代理服務(wù)器，也可以是Java servlet之類的源服務(wù)器程序。它們之間的交互信息就是兩大類：客戶端對服務(wù)器端的請求（request）和服務(wù)器端對客戶端的響應(yīng)（response）。一次完整的交互包括一個請求和對它的響應(yīng)。
所有的請求和響應(yīng)都采用[RFC822]中定義的標準互聯(lián)網(wǎng)消息格式，框架如下：
* 消息定義
* 沒有或多個消息頭
* CRLF（空行回車）
* 可選的消息本體
其中消息定義不分指定了發(fā)送消息的類型。請求和響應(yīng)都可以包含多個消息頭，用來進一步或者重新定義用戶終端和服務(wù)器之間的交互。CRLF僅僅用來將信息定義和消息本體分開。
1、 請求
在消息定義部分可以這樣定義請求： 請求類型 URL HTTP/1.1
其中請求類型可以是下面的一種：
①. OPTION：返回請求者和相應(yīng)者之間可以使用的通信選項，主要用來檢測服務(wù)器處理能力；
②. GET：獲得以URL標示的文件內(nèi)容或者程序執(zhí)行結(jié)果。服務(wù)器根據(jù)文件名后綴判斷服務(wù)內(nèi)容，比如該URL是靜態(tài)文本還是一個程序；
③. HEAD：除了不返回響應(yīng)的信息本體以外，得到的是跟GET一樣的信息。一般用來測試鏈接的有效性、可達性和近期修改；
④. POST：把消息本體中的消息發(fā)送到一個URL或者其他類似的服務(wù)器端定義行為。通常用來提交一個HTML表單或者一些數(shù)據(jù)操作活動；
⑤. PUT：把消息本體中的消息發(fā)送到一個URL，跟POST類似，但不常用；
⑥. DELETE：刪除URL指定的資源；
⑦. TRACE：調(diào)用一個遠程應(yīng)用層請求消息回路。發(fā)出這個消息的用戶終端除了收到原來的消息內(nèi)容以外，還得到消息在Internet上的傳送路徑。
最常用的請求類型--也是我們在處理WAP應(yīng)用時最關(guān)心的--是GET和POST。假設(shè)有一個WML文檔，我們用UP的瀏覽器去瀏覽的話，就會向服務(wù)器發(fā)出如下GET請求：
GET www.wap86.com/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.wap86.net
……
其中粗體的部分是HTTP消息頭，這里我們忽略了一些與我們關(guān)系不大的消息頭。
accept-charset: 用戶終端支持的字符集
accept-language: 用戶終端目前使用的語言
accept: 用戶終端可以接受的MIME文件類型
user-agent: 用戶終端供應(yīng)商提供的終端描述信息
host: 請求信息發(fā)送到的域名
2、 響應(yīng)
響應(yīng)的消息定義部分一般是這樣的：HTTP/1.1 狀態(tài)碼 狀態(tài)描述 在[RFC2616]中定義了近40種不同的狀態(tài)碼（分成5組）。其中最常見的是3個：
200 OK
401 Unauthorized
404 Not Found
繼續(xù)上面那個例子，如果該URL合法的話，服務(wù)器的響應(yīng)會是這樣的：
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”>