謝國坤, 霍愛清, 湯 楠
(西安石油大學陜西省鉆機控制技術重點實驗室,陜西西安710065)
Vcard[1]也稱為電子名片,是一種交換個人信息(如姓名、地址、電話號碼和電子郵件地址)的簡單方法。Vcard規范可作為各種應用或系統之間的交換格式,且這種格式與傳遞的方式無關。符合Vcard規范的文件可以在文件系統、點對點交換的公共電話網絡、以有線網絡或無線傳遞等方式進行交換。由于Vcard文件具有如此出眾的優點,現在越來越多的應用軟件都選擇支持 Vcard功能來實現聯系人或日程表信息的本地存儲。如何將 Vcard文件的數據解析出來存放到不支持Vcard數據的單板中就顯得十分重要,是一個有待解決的問題。
某軟件的用戶界面是采用Vcard3.0規范來保存聯系記錄的,而絕大多數型號的單板又不支持Vcard格式。為了解決這一問題,在分析了直傳單板方式、AT命令寫單板方式基礎上,提出并設計了SDK層直接解析轉換方式,即在SDK層對Vcard字符流進行解析,并轉換成Vcard對象模型,動態拆分成AT命令并分段下發給單板,實現了Vcard字符流的解析存儲。該方案既滿足SDK層作為工具集的設計原則,又可以不依賴于單板型號,給第三方的UI用戶界面提供了更強的功能集合。該方案的設計原則是首次使單板在不改變其硬件結構的基礎上,具有了存儲Vcard數據的能力,通過SDK層的適配作用,使單板作為底層存儲介質,可以支持更多樣化的用戶界面,具有非常廣泛的應用前景和市場價值。
對于每一條聯系人記錄來說,用戶界面通過接口參數傳下來的是標準的Vcard3.0字符流。基于這個原因,可以采用在SDK層對數據不做任何解析,直接透傳到單板上,單板將該條記錄形成一個文件進行存儲[2-3]。這種做法的優點就是SDK層和單板對Vcard均不做出任何解析,不用增加額外的代碼,以文件的形式保存到單板的Flash中,每個文件都有一個唯一的索引進行標識。在用戶讀取的時候可以直接將文件中的Vcard字符流上傳給界面,由界面顯示成聯系人記錄格式。該方法的缺點也是顯而易見的,以文件的形式直接進行存儲犧牲了高通平臺的電話本的讀寫響應速度 (通常對單板的讀寫性能都有著較高的要求,一般單條記錄的讀寫時間不能超過240ms)。
為了解決記錄讀寫效率的問題,決定記錄內容的存儲還是要交給高通平臺提供的電話本實現機制,可以利用電話本的備注字段進行Vcard字符流的存儲[4-5]。這樣對Vcard字符流也不需要做任何解析,通過AT命令寫到單板上,并利用單板提供的索引標識每一條記錄,SDK和單板均不需要額外的算法開銷,易于實現,并且存儲效率很高。但是有一個致命的缺陷,那就是AT命令固有的長度限制。AT命令通過通信端口傳輸數據包,包的大小是有嚴格限制的,對于AT的發送除了AT兩個字符外最多可以接受260個字符,終端設備主動上報的消息或者用戶請求相關(userrequestcorrelation,URC)最大長度都限定在668個字符范圍之內,而用戶界面傳下來的字符長度完全是隨機的、未知的。
考慮以上兩種方案的不足,提出采用在SDK層對Vcard字符流進行解析,并轉換成Vcard對象模型的方式。根據單板所能支持的字段數量和順序動態合成AT命令,同時為了避免AT超長,對電話本的讀寫命令進行了擴展,每次只下發4個字段的內容,并標識這條記錄一共被拆分成多少條,當前AT內容屬于第幾條,類似于長短信的拆分方法。這種方法的優點是單板方面改動較少,完全保留了高通平臺的電話本存取機制,記錄讀寫的效率也是非常高。當然也存在一定的缺點,那就是 SDK層要增加解析 Vcard文件的算法,并且要建立Vcard字段和單板字段的映射表,動態組成AT命令下發單板,而且要對現有的讀寫命令進行擴展。但是這些算法的開銷還是很值得的,這部分可以封裝成一個動態庫,用于擴展SDK的功能。只要單板支持擴展的AT命令,那么就可以給任何使用Vcard保存聯系人的第三方UI軟件提供無縫集成。下面以增加一條聯系人記錄為例,給出從界面到單板的處理流程[6-9],如圖1所示。而讀取過程就是該流程的逆操作,本文將不再贅述。
為了避免AT超長,對電話本的讀寫命令進行了擴展,每次只下發4個字段的內容,并標識這條記錄一共被拆分成多少條,當前AT內容屬于第幾條[10-13]。

圖1 從界面到單板的處理流程
擴展讀取命令AT^CPBREX,命令格式及響應如表1所示。

表1 擴展讀取命令AT^CPBREX
擴展寫入命令AT^CPBWEX,命令格式及響應如表2所示。

表2 擴展寫入命令AT^CPBWEX
結合增加一條聯系人記錄的實例,對所做設計進行具體闡述。
將一條記錄寫到單板上步驟如下:
步驟1 假如用戶從接口參數傳下來Vcard字符流如下[14]:
BEGIN:VCARD
VERSION:3.0
FN:Joe Smith
TEL;TYPE=CELL:+13913131212
TEL;TYPE=HOME:949-362-2399
TEL;TYPE=WORK:029-88886666
X-WMC-MOBILE-2:949-555-1212
TEL;TYPE=FAX:949-362-2300
EMAIL:jsmith@smith.com
X-WMC-EMAIL:joe.smith@smith.com
UID:{4421FEE4-A25D-11D3-9F7C-005004AE6818}
步驟2 使用擴展的讀取命令獲取單板所支持的字段列表和字段長度,該命令的上報應該以OK結尾,由于所有的字段名稱都做了縮寫處理,所以單條AT足以上報所有單板側所支持的字段類型,命令格式如下所示:
AT^CPBREX=?
^ CPBREX:(1-500),”FN”,32,”CELL”,48,”HOME”,48,”WORK”,48,”EM”,48,”XWEM”,XWGD,5
OK
步驟3 建立單板側上報字段與用戶界面支持的 Vcard字段對應的映射表,如表3所示。其中以X-WMC開頭的是自定義的字段名稱。將步驟1中傳下來的Vcard字符流轉換成Vcard對象模型,包括解析用戶自定義的字段。
步驟4 過濾掉單板側不支持的字段類型,按照單板上報的字段順序從對應的Vcard對象中獲取數據,構造出即將下發的AT結構[15]。就本例而言需要獲取姓名、手機號碼、家庭號碼、辦公號碼、電子郵件、擴展電子郵件和群組編號這7個字段內容。然后每4個一組分段下發,其中字段編碼內容是可缺省的,每下發一條寫命令如果成功,單板側需要上報一個OK響應,必須拆分的每條命令都返回OK,這條記錄才算保存成功,否則按保存失敗處理。寫命令的執行流程如下所示:
AT ^ CPBWEX:3,2,1,”80534E4E3A”,1,”+13913131212”,2,”949-362-2399”,2,”029-88886666”,2
OK
AT ^ CPBWEX:3,2,2,”jsmith@smith.com”,1,”joe.smith@smith.com”,1,”4”,2
OK
至此一條記錄就被寫到單板上了。

表3 單板側上報字段與Vcard字段對應的映射
在不改變單板存儲結構以及存儲方式的基礎上,無需實現Obex協議或Diag協議的前提下,通過建立Vcard對象模型以及AT命令的擴展,實現了Vcard數據的動態字段解析和存儲。整個過程大部分工作都是放在SDK層來完成的,單板側只需要支持擴展的AT命令即可,而用戶界面無需做任何額外的改動。這種方案符合了SDK層作為工具集的設計原則,在不依賴于單板型號的同時,給第三方的UI界面提供了更強的功能集合。
[1]Cronin.From victorian visiting card to vcard:the evolution of a communicative genre[J].Journal of Information Science,2003,29(1):65-68.
[2]孫鶴飛.基于IMS的雙模智能手機的設計與實現[D].西安:西北大學,2008.
[3]Deitel H M,Deitel P J.C++編程金典[M].周靖,黃都培,譯.北京:清華大學出版社,2002.
[4]CN101237610,基于點還本分組的短信息發送方法和移動終端[P].中興通訊股份有限公司,2008-08-06.
[5]蔡東.基于BREW平臺的CEMA移動終端電話本的研究和實現[D].西安:西安電子科技大學,2008.
[6]Gary JBronson.C++程序開發與設計[M].劉勇,譯.北京:人民郵電出版社,2002.
[7]劉天印,李福亮.C++程序設計[M].北京:北京大學出版社,2006.
[8]Andrew Koenig,Barbara Moo.C++沉思錄[M].黃曉春,譯.北京:人民郵電出版社,2008:133-150.
[9]趙清杰.C++程序設計 [M].北京:清華大學出版社,2008:183-193.
[10]深圳市森森科技發展有限公司.AT指令集[Z].4-5.
[11]華為技術有限公司.GTM 900 AT命令手冊Version 1.12[Z].2007:40-56.
[12]李志偉.基于AT指令的串行通信程序的設計[J].微計算機信息,2007,23(3):272-274.
[13]李佳.一種數據卡PC側收發AT命令模塊的實現方法[J].計算機測量與控制,2010,18(6):1370-1372.
[14]杜青.Symbian OS C++編程訣竅[M].北京:清華大學出版社,2009:103-106.
[15]CN101140517,在PC軟件中實現名片夾Vcard格式方法及裝置[P].中興通訊股份有限公司,2008-03-12.