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