國立中山大學

國立中山大學

在WAP上之E-mail收發實作

國立中山大學計算機與網路中心

作業組王呈聖

第1章簡介	1
1.1 背景	1
1.2 WAP	1
1.3 E-mail與使用者介面	2
第2章相關的準備工作	3
2.1 軟硬體環境	3
2.2 架設WAP伺服器	3
2.3 資料庫	5
2.4 SESSION	6
第3章、收發E-mail	8
3.1 使用者登入/登出	8
3.2 收信	10
3.3 發信	16
3.4 通訊錄	18
第4章、使用者設定介面	19
第5章、結論與未來的工作	22
參考書目	23

附錄A 完整原始碼
附錄B 使用者說明手冊
附錄C 管理者說明手冊

圖表目錄

圖1 網路架構	3
圖2 IIS中的MIME類型設定(一)	4
圖3 IIS中的MIME類型設定(二)	5
圖4 資料庫結構	6
圖5 Web使用者設定介面	19
圖6 可供設定的服務	20
圖7 “我的郵件”的設定畫面	20
圖8 設定郵件帳號	21

表1 與WML內容有關的MIME類型	4

本篇報告說明如何在WAP上實作一個完整的E-mail收發系統，其中包括WAP伺服器的架設，利用POP3協定收信，利用SMTP協定寄信，使用者介面設計，以及伺服器與資料庫的管理。

行動通訊與網際網路的結合，使得行動電話和PDA不再只是單純的通訊工具和個人秘書工具。藉由輕巧易於攜帶的特性，讓人們可以隨時隨地獲得最新資訊與進行交易。目前的行動通訊工具仍有不少限制，如記憶體、CPU、螢幕大小，使得行動通訊的服務走向短、快、準的特性。

日本NTT DoCoMo公司的i-Mode服務於1999年2月上市，在一年多的時間內就成長到六百萬人。根據日本通信總和研究所針對i-Mode用戶所做的調查報告，使用電話、郵件與瀏覽網站的比例分別為39%、38%與22.5%，大約是4：4：2。使用i-Mode的理由中，使用E-mail的比例高達82.4%，其次才是打電話77.4%。（電子時報2000/5/09）

雖然i-Mode不是使用WAP的技術，但是可以從中瞭解到無線上網的魅力，更瞭解到在各種應用中，E-mail是相當重要的部分。於是我們打算在WAP上實作E-mail的收發，讓手機與PDA成為另一種形式的溝通工具。

WAP(Wireless Application Protocol)主要是把在網際網路上的資料內容，傳遞到行動電話或其他無線裝置的一種開放式標準協定。簡單來說，WAP簡化了Internet的標準，配合行動通訊與無線網路的特性，以WML(Wireless Markup Language)的語言格式，將訊息傳遞到移動式裝置上。

WAP是由Erisson、Nokia、Motorola以及Phone.com等業者所組成的WAP forum所提出的標準，可以與大部分的通訊網路相容，包括GSM、PDC、CDPD、CDMA、DECT等通訊技術。WAP的程式模式與WWW的程式模式類似，對程式發展人員來說，可以加速學習的過程，而且許多現有的工具都可以互相引用（如Web Server、XML工具）。而WAP的應用程式內容格式與WWW的內容格式類似，內容的傳輸方式也是使用WWW通訊協定的部分標準。換言之，現有的WWW應用程式只需作少部分的修改，就可以套用到WAP上了。

WAP的運作模式，首先由用戶端提出要求，經由無線網路傳輸到Gateway進行解碼，再傳送到有線網路上的伺服器。伺服器處理要求後，將回應傳送到Gateway，資料就被編碼傳回用戶端。所以Gateway所扮演的角色，就是無線網路與有線網路之間資料格式的轉換，使得應用程式能獨立於通訊網路。

E-mail的服務，不外乎是收信與發信，再配合通訊錄與郵件管理的功能，就可以滿足大部分人的使用習慣了。傳統處理E-mail的方式是使用郵件軟體（如Windows上的Outlook或UNIX上的elm），使用者必須在有安裝特定程式的主機上使用。目前WWW上也有網站提供這類的服務，使用者只要有Browser，就可以連上Web Server來處理電子郵件，不用藉助郵件軟體，將收發E-mail的動作交給Web Server來完成。

然而無論選擇哪一種，使用者都必須找到一部電腦上網。如果要突破這個限制，行動電話和PDA就是目前最好的選擇。所以我們要做的，是把在WWW上已經發展成熟的技術，配合無線網路的特性，移植到WAP上。使E-mail的收發不受特定軟體和地點的限制，隨時隨地都可以接受和傳送各類訊息，大大增加電子郵件的及時性和方便性。

接下來必須考慮現實問題，一般WAP裝置的電力來源大多是靠電池供應，因此使用時間並不會很長，所以必須節省電力的使用，也就是盡量減少資料的傳遞量和連線時間，使用較大的頻寬，就意味著使用的時間較短。另外在使用者的感覺上，會利用行動裝置上網大多是有迫切的需要，再加上它們的螢幕通常很小，所以傳遞的訊息應該要盡量簡潔而快速。

這與WWW上的環境完全不同，如何將個人電腦的大螢幕搬到行動電話上，是使用者介面上的難題。大量的圖片與選單勢必要被捨棄，絢爛的聲光效果更是遙不可及，只能用最簡潔的文字和簡單的圖形跟使用者溝通。於是最後我們讓使用者設定介面回到WWW的世界，讓使用者用最方便的方式進行各種繁瑣的設定，而不侷限於小按鍵與小螢幕上。當用行動裝置使用我們的服務時，則只傳送已經篩選整理過的資料，讓使用者能快速掌握他所需要的訊息。

軟體部分：作業系統採用Windows 2000 Server，並使用其內建的IIS5做Web Server。CGI採用PHP，資料庫則是採用MySQL。PHP與MySQL原本是在Linux上發展，於是有跨平台和免費的優點，同時也比同類型的ASP與MS SQL Server或是Oracle輕巧多了。另外PHP在4.0的版本之後支援Session，這對我們是一個很重要的功能。

硬體部分：一部個人電腦，能安裝Windows 2000 Server即可勝任，而且當然要連接上網路，才能作為伺服器。另外準備了30GB的硬碟，作為資料庫的空間。

資料庫用PhpMyAdmin這隻Web介面的程式來管理，是用PHP寫成的MySQL管理程式，功能簡單但已符合我們的需要，而且她的Web介面非常適合遠端管理，也可用來測試PHP與MySQL的連線。

測試的環境使用兩個Windows上的模擬器：UP Simulator與M3Gate。實際上也有兩支手機作測試用：Motorola Accompli A6188太極(內建Phone.com的Browser)，以及OKWAP i3698（內建其自行開發的Browser），都具有WAP上網與中文顯示的能力。

在架設伺服器之前，先說明整個架構，知道我們的伺服器需要哪些能力。由手機到郵件伺服器的網路架構如下圖所示：

手機利用WAP連接到電信業者提供的Gateway，便轉為HTTP與我們的WAP Server溝通，Server依據使用者的要求，再對郵件伺服器發出收信(用POP3)或發信(用SMTP)的要求，最後將結果傳回手機。所以Server的主要工作，就是能接受手機來的要求，並且能進一步與Mail Server溝通。

由於WAP經過Gateway就轉換成HTTP，在網路上的傳輸方式與一般的網頁相同。所以我們直接在Web server中設定MIME類型，使它認識WAP的各種格式，並且給予適當的回應，就可以接受手機來的要求，變成WAP伺服器了。

以簡單的WML文件為例，當伺服器被要求附檔名為 .wml 的檔案時，就會回應檔案類型為text/vnd.wap.wml，並且告訴使用者這是一個”簡單的WML文件”。手機上的瀏覽器收到正確的回應，就知道如何將收到的內容顯示出來。[8]

以下是IIS的MIME類型設定方式，假設已經在IIS中先設定好一個WEB站台：

至於PHP與MySQL的安裝與設定，在取得它們的win32版本後，參考其中的安裝說明就可以順利安裝。

在提供各種服務之前，我們必須先確認使用者的身分，也就是要求他們登入。這樣做的好處是方便管理，可以確定user的身分，進而提供一些個人化的服務，像是常用的郵件伺服器，或是通訊錄等等。至於一些比較隱密的資料，像是成績和行事曆，則是需要加以保護，不能讓每個人都隨意存取。當然也可以用來留下一些紀錄，不過IIS已經有log的功能了，所以我們並未對此再作加強。

面對眾多的帳號和資料，勢必要建立資料庫來存取。然而在建立資料庫之前，要先規劃資料存放的方式，應該要有哪些table，以及它們之間要如何關聯。這必須要考慮到存取的效率、管理方便、資料存放的完整性，同時最好能配合系統的特性。

登入的部分獨立出來，成為一個資料庫，只有一個table專門存放所有的帳號和密碼。而每個user有自己專屬的資料庫，其中有不同的table存放各種服務的資料，例如mail table存郵件帳號，address table存通訊錄。

會這樣規劃的原因，和資料庫系統MySQL有很大的關係。因為MySQL將每一個資料庫存成一個資料夾，當我們建立一個user A的資料庫，硬碟裡就多了一個叫做user A的資料夾。如此一來，設定新的帳號非常方便，只需要在帳號資料庫中加入新的帳號密碼，再把一個預設帳號的資料夾複製成新的帳號資料夾就可以了。

然而這樣做的缺點，就是要新增其他的服務時，必須修改每一個user的資料庫。不過我們提供的服務大致固定了，所以這種情形發生的機會很少，而且應該有很多解決方法。

所以當有一個user發出登入的request時，我們先比對帳號資料庫中的帳號密碼，如果正確，就可以開啟該帳號的資料庫，再依使用的服務來選擇不同的table。如此一個user同時間只需開啟一個資料庫的一個table，而且不會用到其他的資料庫。所以對系統的負擔很小，也比較有效率。對user而言，就可以很快得到回應，進而節省連線的費用。

一個user的登入是持續有效的，必須使他接下來的request都擁有該user的權限，直到他登出為止。從server的角度來看，就必須要辨識目前的request是來自哪一個user。起初我們嘗試去擷取來源IP，結果得到的卻經常是proxy或gateway的IP，根本就無從分辨。cookie也不適用，因為WAP browser不支援，我們也不可能在手機上面開檔案。

最後我們用了session才解決這個問題。Session利用user傳送過來的session ID來延續變數，並且將資料儲存在server端，這對空間極小的手機可說是唯一的選擇。

每當server收到一個PHP script (.php)的request，就會呼叫PHP的直譯器來執行該script，再把輸出傳回user。而每次呼叫PHP時，都會產生一個獨一無二的session ID。但是如果手動指定一個session ID，就可以回復一個session的狀態。我們可以將變數存入session中，之後的request只要利用session ID，就可以提出session中的變數了。

實際上的做法是，在user輸入帳號密碼後，傳送到一個PHP script負責檢查，執行時就會產生一個session ID。如果登入成功，從此這個session ID就跟著這個user 直到登出為止了。只要把這個session ID用post的方式附加在網頁的每一個link中，一旦user使用任何一個link，都等於另外傳送了一個session ID到server端，我們就可以用來取出session中的變數。由於一個user從登入到登出只有一個session，所以從另一個角度來看，session ID是一個暫時的password，user就是靠著一個session ID來通行各個網頁之間，卻感覺不到它的存在。

User在此輸入帳號密碼，按下 “Go MyWap”的連結後，就傳送到server作檢查。

密碼驗證的部分原始碼如下，其中有session與資料庫的使用，這段程式碼可以套用在許多地方：

header("Content-Type：text/vnd.wap.wml"); // 送出MIME type header

include("big52uni.inc"); // BIG-5轉Unicode的function

session_start(); // 啟動session

if(!isset($myname))

{

session_register('myname'); // 將相關的變數註冊到session中

$myname=$SESS_NAME;

}

if(!isset($mypassword))

{

session_register('mypassword'); // 將相關的變數註冊到session中

$mypassword=$SESS_PASS;

}

$host = "localhost";

$dbname = "login";

$dbuser = "****";

$dbpasswd = "****";

mysql_pconnect($host, $dbuser, $dbpasswd); // 開啟資料庫，查詢有無相符的資料項

$sqlstr = "select * from password where name='$myname'";

$result = mysql_db_query($dbname, $sqlstr);

$arr=mysql_fetch_array($result);

if(!$arr)

// 帳號密碼錯誤

else

// 帳號密碼正確

輸入了正確的帳號密碼後，就列出可用的服務供user選擇，並且將session id隱藏在link中。此時觀察”我的郵件”這個link的原始碼是這樣的：

其中我的郵件就是”我的郵件”的Unicode格式，而SID=3e14a572451d6e7c904762a86e6ff6f6是這次產生的session ID，當session啟動之後，呼叫PHP的內部函式session_id()就可以得到。

當user輸入的密碼錯誤時，顯示錯誤的訊息，隔兩秒後自動跳回輸入畫面。

在user結束使用之前，應該要使用”登出”的選項，此時就會強迫終止session，以避免遭人竊用。不過就算user沒有正常登出，session也會在一段時間後自動失效。

我們並沒有架設郵件伺服器，所以user必須先提供郵件伺服器的資訊，包括mail server的位址，和user在mail server的帳號密碼。有了必須的資訊後，就可以連線到mail server查看user的信件，並且篩選部分的資料輸出到user端。

當user選擇要收發信時，就從資料庫中取出已經設定的伺服器，供user選擇。此處程式的寫法與前述查詢帳號密碼相似，故不再列出原始碼，詳見附錄。

User選擇一個伺服器收信之後，就連線到該伺服器，查詢user的信件，再把信件列表顯示給user看。考慮到手機的螢幕大小，所以只顯示寄信人和標題。

由於有些信件是經過編碼的，所以在顯示之前要先加以解碼，不然會看到亂碼。

收信及解碼的部分原始碼如下，因為PHP有完整的郵件處理函式，所以我們不用直接與server溝通：

$MAILSERVER= "{".$pop3[$POP3_NUM]["server"]."/pop3:110}INBOX";

$link = @imap_open($MAILSERVER, $pop3[$POP3_NUM]["name"], $pop3[$POP3_NUM]["pass"]); // 連線到POP3 Server

if(!$link)

// 連線失敗

else

$count=imap_num_msg($link); // 連線成功, 取得信件的數目

if($count==0)

// 信箱中沒有信

else

{ // 信箱中有信

echo "你有".$count."封信<br/>\n"; // 你有 n 封信

$overview = imap_fetch_overview($link, "1:".$count, 0); // 取出所有的信件標題

if(is_array($overview))

{

reset($overview);

$table=file("big5-uni.txt");

for($i=$count-1; $i>=0; $i-=1) // 針對每一封信, 處理標題中的資訊

{

$val=$overview[$i];

$sub=$val->subject;

// 以下處理被編碼的標題,

if(strtolower(substr($sub, 0, 7))=="=?big5?") // BASE64 encoded from BIG-5

{

$sub=base64_decode(substr($sub, 9, strlen($sub)-11));

// 將BIG-5轉成Unicode, 才能顯示

$mail_subject=big52uni($sub, 16, "", $table);

}

else if($sub=="")

$mail_subject="[無標題]"; //"[[無標題]]";

else if(strtolower(substr($sub, 0, 8))=="=?utf-8?") // base64 encoded from UTF-8

{

// 標題是用Unicode編碼, 所以不用再轉碼了

$sub=base64_decode(substr($sub, 10, strlen($sub)-14));

$mail_subject=substr($sub, 0, 16);

}

else

$mail_subject=big52uni($sub, 16, "", $table);

// 分解寄信人位址, 只顯示名稱的部分, 同時處理編碼

$from = strtok (strtok($val->from, "@"), "<>");

if(strtolower(substr($from, 0, 7))=="=?big5?") // BASE64 encoded from BIG-5

{

$from=base64_decode(substr($from, 9, strlen($from)-11));

$mail_from=big52uni(chop($from), 14, "", $table);

}

else if(strtolower(substr($from, 0, 8))=="=?utf-8?") // BASE64 encoded from UTF-8

{

$from=base64_decode(substr($from, 10, strlen($from)-14));

$mail_from=substr(chop($from), 0, 14);

}

else

$mail_from=big52uni(chop($from), 14, "", $table);

// 得到這封信的UID, 是一個不重複的代碼, 用來存取這封信的所有資料

$mail_uid=$val->uid;

// 顯示寄信人和標題, 供user選擇, 其中隱含了session ID和信件的UID

echo "[".$mail_from."]<anchor>$mail_subject<go href=\"viewmymail.php\">\n";

echo " <postfield name=\"SID\" value=\"".session_id()."\"/>\n";

echo " <postfield name=\"mail_num\" value=\"$mail_uid\"/>\n";

echo " </go>\n";

echo "</anchor><br/>\n";

}

電子郵件主要有兩種結構： TEXT(純文字)，與MULTIPART(多重文件，常用於附檔，或特殊的文件格式)。若是TEXT格式，此時依據編碼的方式加以解碼，就直接顯示出來。目前可支援的編碼有8Bit(未編碼)，BASE64與QUOTED-PRINTABLE，已經可以解出大部分的郵件了。

若是MULTIPART的格式，因為受限於手機的環境，附檔或是圖片都不容易顯示出來。於是就取出第一個part，習慣上通常是TEXT的格式。

以下是顯示信件內容，與處理MULTIPART及編碼的程式片段，同時也限制了輸出的長度：

// 連線到mail server

$MAILSERVER= "{".$pop3[$POP3_NUM]["server"]."/pop3:110}INBOX";

$link=@imap_open($MAILSERVER, $pop3[$POP3_NUM]["name"], $pop3[$POP3_NUM]["pass"]);

// 取得信件的格式資訊

$stru=imap_fetchstructure ($link, $mail_num, FT_UID);

$type=$stru->type;

if($type==0) //text格式

$encoding=$stru->encoding;

else if($type==1) //multipart格式

{

$encoding=$stru->parts[0]->encoding;

}

else // something unsupport....兩者皆非

{ $encoding=1;

echo big52uni("[[格式未支援]]");

}

// 取得信件的內容, 再依據編碼格式加以解碼

$message=imap_fetchbody($link, $mail_num, 1, FT_UID);

switch ($encoding)

{

case 0： //7BIT

$message=$message;

//$message="[[編碼未支援0]]\n".$message;

break;

case 1： //8BIT

$message=$message;

break;

case 2： //BINARY

//$message="[[編碼未支援2]]\n".$message;

break;

case 3： //BASE64

$message=base64_decode($message);

break;

case 4： //QUOTED-PRINTABLE

$message=imap_qprint ($message);

break;

case 5： //OTHER

//$message="[[編碼未知]]".$message;

break;

}

// 判斷是哪一種charset, 若是unicode就不用轉碼

$fullheader=imap_fetchheader ($link, $mail_num, FT_UID);

$charset=stristr($fullheader, "Content-Type:");

$charset=stristr($fullheader, "charset=\"UTF-8\"");

if($charset) // 是utf8

echo substr($message, 0, 600);

else // 不是utf8

echo big52uni($message, 600, "...\n[[訊息過長]]");

針對每一封信，可以進行一些動作，例如刪除，回信，轉寄等等，其中我們只實作了刪除的動作。

當user選擇要刪除郵件時，先顯示確認的畫面，之後就可以進行刪除的動作。

Mail server上刪除郵件分成兩個步驟，首先mark信件成deleted的狀態，此時信件仍留在server中，可以挽救回來。但我們希望馬上殺掉郵件，所以隨後就下expunge的指令，強迫刪除掉所有被mark成deleted的信，達成我們的目的。

當user選擇要寄信時，就出現寄信的設定畫面。要寄一封信，要決定的參數有：送信伺服器，寄信人地址(通常是給收信人回信用的地址)，收信人，標題以及內文。其中伺服器和寄信人兩項，可以事先設定好，節省輸入的時間。

收信人的選項，可以延伸出通訊錄的功能，此部份在下一章討論。

接下來的標題與內文，因為Unicode的關係，所以在模擬器上輸入中文的結果都是亂碼，不過在實際的手機(A6188太極)上顯示正常。目前網路上的討論，都認為中文輸入無法正確傳送，我認為這是模擬器的bug。因為模擬器所在的環境(Windows)是使用BIG-5，所以模擬器必須把Unicode轉為BIG-5才能在視窗中顯示，但是在模擬器上輸入的中文應該是以BIG-5的格式儲存的，顯示時模擬器卻把它當成Unicode進行轉碼，結果出現的自然是亂碼。在手機上一律都是用Unicode，所以沒有再轉碼的問題。

如果設定的內容都正確無誤，就可以成功送出信件。反之就告訴使用者發生什麼錯誤。

由於手機上輸入的中文是Unicode格式，所以郵件中的中文也是Unicode。收信人必須有支援才能正確顯示。

以下是發信的程式碼片段，其中使用了一個SMTP物件，負責直接與server溝通，詳細的方法可以在RFC821中找到。我們將信件的內容依照e-mail的標準格式設定到$mime變數中，再送給SMTP物件處理。[5][10]

include "smtp_mail.inc"; // 與server溝通用的smtp物件

# 取得電子郵件的資料

$mime = "";

if (!empty($from))

$mime .= "From： =?big5?B?".base64_encode($mynickname)."==?=<".$from.">\n";

if (!empty($to))

$mime .= "To： $to\n";

if (!empty($subject))

$mime .= "Subject： =?UTF-8?B?".$subject."==?=\n"; // 標題使用UTF-8編碼

$mime .= "MIME-Version： 1.0\n";

$mime .= "Content-Type： text/plain; charset=\"UTF-8\"\n"; // 設定編碼為UTF-8

$mime .= "Content-Transfer-Encoding： base64\n\n";

$mime .= $body."\n";

# 建立 smtp_mail 的實體

$smtp_sent = new smtp_mail;

# 寄出電子郵件

if( $smtp_sent->send_mail($smtp_server, $from, $to, $mime)) {

echo big52uni("成功送出了!")."\n";

} else {

echo big52uni("傳送失敗!")."<br/>\n";

echo big52uni($smtp_sent->lastmsg)."\n"; // 顯示相關的錯誤訊息

}

User登入之後，選擇”我的通訊錄”，就列出已經建立的通訊錄。此部份純粹是資料庫的查詢。

顯示詳細的資料後，有一些動作可以實現。首先是e-mail的部分，讓user點選之後，可以直接發信給此人。再來是電話的部分，可以利用WTAI(Wireless Telephony Application Interface)直接撥號。不過這兩部分都還在試驗中，因為設計通訊錄的目的，主要是用來配合寄信時，收信人的選項。

在寄信的時候，輸入收信人的部分可以和通訊錄結合，讓user可以選擇之前建立好的聯絡人，減少輸入的時間。

此部份的程式設計，充分的利用了session的功能。收信的設定畫面中，充滿了各種資料，User在進行設定的時候，這些資料要如何傳遞是一個大問題。但是因為我們使用session 的機制，變得非常容易解決。因為一次只會設定一個欄位，每次user設定一個欄位，只需要傳送那個欄位的資料和session ID即可。我們把每一筆資料都存入session中，到時就可以在session中找到完整的資料了。如果不用session，勢必每次都要傳送所有的欄位，那就浪費了不必要的頻寬。

我們設計時有一個原則，希望讓user在使用的時候，需要輸入的東西越少越好，盡量利用事先建立好的資料，利用點選的動作來作輸入。因為就手機來說，輸入字串，尤其是中文字的時候，是一件痛苦的事。於是我們又建立了一個讓user管理資料用的網站，由於WWW的環境不再有那麼多的限制，所以可以用比較活潑的方式表現，介面也友善許多。

在程式設計上，大多是資料庫的查詢與更新，並沒有太大的變化。

當然登入的帳號密碼與WAP上是一樣的，而且程式的設計上也極相似，所差只是顯示的方式不同而已。

登入成功之後，就顯示我們提供的服務，其中都有需要設定的資料。

如果user點選”我的郵件”，就從資料庫中取出郵件的設定，列出來供user編輯。

首先我們將Windows IIS的Web Server加上MIME設定，使她能接受由WAP來的要求，並且加以適當的回應。接下來規劃資料庫，以便能快速的存取使用者帳號和使用者的設定資料。

收信的部分，用使用者事先設定的郵件伺服器與帳號資料，透過POP3的通訊協定，為使用者抓取伺服器上的信件，再將所得的資料加以篩選，讓使用者能快速掌握他所需要的資訊，或是刪除不需要的信件。

發信的部分，同樣利用使用者事先設定好的伺服器資料，再加上通訊錄的功能，盡量減少使用者必須在線上輸入的資料。通訊錄的功能主要是配合發信時，能免去輸入E-mail address的麻煩，同時能做簡單的管理。

最後我們回到WWW的環境，建立了一個使用者設定介面，讓使用者能很方便的設定相關資訊，並且在WAP上快速取用。

至此，一個完整的WAP站台已經完成，其中還包含了一個資料管理介面。目前也開放使用，接受帳號的申請了。然而我們知道她並不是完美的，還有一些方面可以加強。

網路是不安全的，在傳遞各種資料時，都可能被有心人士擷取，因此產生不少的網路安全機制，如 SSL(Secured Sockets Layer)，TLS(Transaction Layer Security)，以及WAP上的WTLS(Wireless Transport Layer Security)。而且如果要實現WAP上的安全機制，則必須考慮到手機到gateway，以及gateway到server，這兩段之間的傳輸。

用手機處理電子郵件，有一個其他裝置無法超越的優勢，就是通話的功能。WAP針對這一點，制定了WTAI的介面，能夠讓user在上網的時候，使用手機本身的功能。舉例來說，當瀏覽一個商業網站時，就可以直接用點選link的方式撥號給該公司，作口頭上的溝通。我們將嘗試藉此做出語音郵件，用聲音代替文字，就可以完全免除輸入的不方便，更不會遇到編碼的問題了。

1.“WAP與WML行動通訊與科技應用”, 鄭吉峰, 實書堂文化, 臺北市, 2000

3.“Professional WAP”, Charles Arehart, Wrox Press Ltd., Birmingham UK , 2000

4.“最新PHP及MySQL入門與應用”, 榮欽科技主筆室, 松崗, 台北市, 2000

7. “http://kmserv.com/”, PHP/ZEND Resources Center技術與資源交流中心

12. RFC2045 , RFC2046 , RFC2047 , RFC2048 & RFC2049: Multipurpose Internet Mail Extensions (MIME).

文件類型	MIME 類型	典型的延伸檔名
簡單的WML文件	text/vnd.wap.wml	.wml
無線點陣圖片	Image/vnd.wap.wbmp	.wbmp
編譯過的WML文件	Application/vnd.wap.wmlc	.wmlc
WML Scripts	text/vnd.wap.wmlscript	.wmls
編譯過的WML Scripts	Application/vnd.wap.wmlscriptc	.wmlsc