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