-- 作者:wangxinxin
-- 發(fā)布時間:2010-12-6 11:12:37
-- WAP頁面及技術(shù)規(guī)范FAQ
因為手機內(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”>
|