本申請(qǐng)涉及通信技術(shù)領(lǐng)域，尤其涉及一種利用協(xié)議描述文件自動(dòng)生成通信代碼的方法及系統(tǒng)。

背景技術(shù)：

在常見(jiàn)的CS架構(gòu)中，客戶(hù)端和服務(wù)端通常是通過(guò)HTTP協(xié)議進(jìn)行通信的。在客戶(hù)端和服務(wù)端定義好相關(guān)的協(xié)議后，客戶(hù)端需要針對(duì)定義好的協(xié)議去開(kāi)發(fā)相關(guān)的訪(fǎng)問(wèn)接口程序，服務(wù)端也需要根據(jù)對(duì)應(yīng)的接口去開(kāi)發(fā)出相應(yīng)的接口程序。在網(wǎng)絡(luò)訪(fǎng)問(wèn)中訪(fǎng)問(wèn)網(wǎng)絡(luò)的大體過(guò)程基本是通用的，不同的地方是協(xié)議中定義的不同數(shù)據(jù)類(lèi)型。

通過(guò)上面分析我們可以發(fā)現(xiàn)我們可以把通信過(guò)程的過(guò)程分為2個(gè)部分，其一是通用的通信方法，其二是不同的通信數(shù)據(jù)。由于方法是通用的，所以客戶(hù)端和服務(wù)端在開(kāi)發(fā)的時(shí)候很多時(shí)候?qū)懙拇a冗余會(huì)非常多，很多代碼部分都是高度相似的，軟件開(kāi)發(fā)人員在編寫(xiě)這些高度相似代碼的時(shí)候是一個(gè)比較大的體力活。

由于服務(wù)器和客戶(hù)端的開(kāi)發(fā)時(shí)分開(kāi)進(jìn)行的，這樣就很可能會(huì)因?yàn)殚_(kāi)發(fā)者的疏忽或者不注意導(dǎo)致雙方通信過(guò)程中因?yàn)榻涌趯?shí)現(xiàn)的差異導(dǎo)致無(wú)法進(jìn)行通信成功。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明了提供了一種利用協(xié)議描述文件自動(dòng)生成通信代碼的方法及系統(tǒng)，以解決現(xiàn)有通信中由于接口實(shí)現(xiàn)的差異導(dǎo)致無(wú)法進(jìn)行通信的技術(shù)問(wèn)題，能夠提高開(kāi)發(fā)效率，降低開(kāi)發(fā)成本，并且能夠極大的提高穩(wěn)定性的方案。在實(shí)際應(yīng)用中能夠?qū)﹂_(kāi)發(fā)起到非常大的作用。

本發(fā)明提供了一種利用協(xié)議描述文件自動(dòng)生成通信代碼的方法，所述方法包括：

獲得所述協(xié)議描述文件，所述協(xié)議描述文件是對(duì)第一關(guān)鍵字和第二關(guān)鍵字進(jìn)行自定義協(xié)議格式之后形成的用于描述通信協(xié)議的描述文件；

解析所述協(xié)議描述文件，并利用所述協(xié)議描述文件生成所述通信代碼，所述通信代碼供客戶(hù)端和服務(wù)器在進(jìn)行通信時(shí)調(diào)用，以實(shí)現(xiàn)所述客戶(hù)端和所述服務(wù)端之間的通信。

優(yōu)選的，所述解析所述協(xié)議描述文件，包括：

判斷所述協(xié)議描述文件是否包含所述第一關(guān)鍵字；

若協(xié)議描述文件包含所述第一關(guān)鍵字，則從所述協(xié)議描述文件解析出所述客戶(hù)端和所述服務(wù)端之間往來(lái)的通信數(shù)據(jù)的描述信息；

利用所述通信數(shù)據(jù)的描述信息生成第一通信代碼；

若協(xié)議描述文件不包含所述第一關(guān)鍵字，則進(jìn)一步判斷協(xié)議描述文件是否包含所述第二關(guān)鍵字；

若協(xié)議描述文件包含所述第二關(guān)鍵字，則從所述協(xié)議描述文件解析出通信接口的接口函數(shù)描述信息；

利用所述通信接口的接口函數(shù)描述信息生成第二通信代碼。

優(yōu)選的，所述判斷所述協(xié)議描述文件是否包含所述第一關(guān)鍵字，包括：

依次獲取所述協(xié)議描述文件的每行信息，并依次判斷所述協(xié)議描述文件的每行信息是否為第一關(guān)鍵字；

所述若協(xié)議描述文件包含所述第一關(guān)鍵字，則從所述協(xié)議描述文件解析出所述客戶(hù)端和所述服務(wù)端之間往來(lái)的通信數(shù)據(jù)的描述，包括：

若有一行信息為所述第一關(guān)鍵字，則獲取所述一行信息包含的一行或者多行數(shù)據(jù)，并依次解析出所述一行或者多行數(shù)據(jù)的數(shù)據(jù)類(lèi)型。

所述利用所述通信數(shù)據(jù)的描述信息生成通信代碼，包括：

利用解析出的所述一行信息對(duì)應(yīng)的所有數(shù)據(jù)類(lèi)型生成第一通信代碼。

優(yōu)選的，所述依次解析出所述一行或者多行數(shù)據(jù)的數(shù)據(jù)類(lèi)型之后，包括：

將所述一行或者多行數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)類(lèi)型存入第一集合中。

優(yōu)選的，所述若協(xié)議描述文件不包含所述第一關(guān)鍵字，則進(jìn)一步判斷協(xié)議描述文件是否包含所述第二關(guān)鍵字，包括：

若所述一行信息不為所述第一關(guān)鍵字，則進(jìn)一步判斷所述一行信息是否為第二關(guān)鍵字；

所述若協(xié)議描述文件包含所述第二關(guān)鍵字，則從所述協(xié)議描述文件解析出通信接口的接口函數(shù)描述，包括：

若所述一行信息是所述第二關(guān)鍵字，解析第二關(guān)鍵字包含的一行或者多行數(shù)據(jù)；

依次讀取所述一行信息包含的一行或者多行數(shù)據(jù)，以分離出每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)；

依次判斷每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)是否包含所述第一關(guān)鍵字；

若包含，則調(diào)用所述第一集合，依次判斷每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型是否存在于所述第一集合中，若有一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型存在于所述第一集合中，則表示所述一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)解析成功；

利用所述通信接口的接口函數(shù)描述生成第二源文件，包括：

利用解析成功的接口函數(shù)生成第二通信代碼。

優(yōu)選的，所述依次判斷每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型是否存在于所述第一集合中之后，包括：

若有一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型存在于所述第一集合中，將所述一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型保存在第二集合中。

優(yōu)選的，所述第一關(guān)鍵字為Struct(結(jié)構(gòu)體)關(guān)鍵字，所述Struct關(guān)鍵字用于對(duì)客戶(hù)端和服務(wù)端之間往來(lái)的通信數(shù)據(jù)的描述；

所述第二關(guān)鍵字為Interface(接口)關(guān)鍵字，所述Interface關(guān)鍵字用于所述客戶(hù)端和所述服務(wù)端之間的通信行為的描述。

優(yōu)選的，所述Struct關(guān)鍵字包含的數(shù)據(jù)類(lèi)型至少包括：浮點(diǎn)型float、整形int、長(zhǎng)整型long、雙精度浮點(diǎn)型double、布爾型boolean。

優(yōu)選的，利用所述協(xié)議描述文件生成所述通信代碼之后，包括：

將所述通信代碼發(fā)送給所述服務(wù)端。

在本發(fā)明實(shí)施例中,還公開(kāi)了一種利用協(xié)議描述文件自動(dòng)生成通信代碼的系統(tǒng)，包括：

獲得模塊，用于獲得所述協(xié)議描述文件，所述協(xié)議描述文件是對(duì)第一關(guān)鍵字和第二關(guān)鍵字進(jìn)行自定義協(xié)議格式之后形成的用于描述通信協(xié)議的描述文件；

解析模塊，用于解析所述協(xié)議描述文件，并利用所述協(xié)議描述文件生成所述通信代碼，所述通信代碼供客戶(hù)端和服務(wù)器在進(jìn)行通信時(shí)調(diào)用，以實(shí)現(xiàn)所述客戶(hù)端和所述服務(wù)端之間的通信。

通過(guò)本發(fā)明的一個(gè)或者多個(gè)技術(shù)方案，本發(fā)明具有以下有益效果或者優(yōu)點(diǎn)：

本發(fā)明的方案提供了一種利用協(xié)議描述文件自動(dòng)生成通信代碼的方法，能夠自動(dòng)獲取并解析該協(xié)議描述文件，并且自動(dòng)生成與協(xié)議描述文件相關(guān)的通信代碼邏輯。由于本發(fā)明能夠自動(dòng)生成客戶(hù)端和服務(wù)端通信代碼，進(jìn)而在客戶(hù)端和服務(wù)段通信時(shí)，可直接調(diào)用該通信代碼進(jìn)行數(shù)據(jù)通信，并能夠保證發(fā)送接口和接受接口的對(duì)接沒(méi)有異常，同時(shí)也極大的降低了開(kāi)發(fā)過(guò)程中由于客戶(hù)端和服務(wù)端的疏忽可能產(chǎn)生的通信異常的概率。進(jìn)一步的，開(kāi)發(fā)者只需要關(guān)注第一關(guān)鍵字和第二關(guān)鍵字進(jìn)行自定義協(xié)議格式之后形成的用于描述通信協(xié)議的描述文件的設(shè)計(jì)，不需要去實(shí)現(xiàn)所有通信過(guò)程，能夠大幅提高開(kāi)發(fā)者的在通信部分的開(kāi)發(fā)效率。

附圖說(shuō)明

圖1為本發(fā)明實(shí)施例中一種利用協(xié)議描述文件自動(dòng)生成通信代碼的方法的實(shí)施過(guò)程圖；

圖2為本發(fā)明實(shí)施例中解析協(xié)議描述文件的流程圖；

圖3為本發(fā)明實(shí)施例中一種利用協(xié)議描述文件自動(dòng)生成通信代碼的系統(tǒng)的組成示意圖。

具體實(shí)施方式

為了使本申請(qǐng)所屬技術(shù)領(lǐng)域中的技術(shù)人員更清楚地理解本申請(qǐng)，下面結(jié)合附圖，通過(guò)具體實(shí)施例對(duì)本申請(qǐng)技術(shù)方案作詳細(xì)描述。

CS:Client/Server架構(gòu)，即服務(wù)器/客戶(hù)端架構(gòu)。是大家熟知的軟件系統(tǒng)體系結(jié)構(gòu)，通過(guò)將任務(wù)合理分配到Client端和Server端，降低了系統(tǒng)的通訊開(kāi)銷(xiāo)，需要安裝客戶(hù)端才可進(jìn)行管理操作。

HTTP協(xié)議：超文本傳輸協(xié)議(HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。

值類(lèi)型的數(shù)據(jù)：值類(lèi)型這個(gè)概念經(jīng)常出現(xiàn)在類(lèi)似C#,JAVA等編程語(yǔ)言的書(shū)籍中."值類(lèi)型"直接將內(nèi)存存儲(chǔ)在棧內(nèi),由系統(tǒng)自動(dòng)釋放資源的數(shù)據(jù)類(lèi)型.

引用類(lèi)型的數(shù)據(jù)：引用類(lèi)型由類(lèi)型的實(shí)際值引用(類(lèi)似于指針)表示的數(shù)據(jù)類(lèi)型。如果為某個(gè)變量分配一個(gè)引用類(lèi)型，則該變量將引用(或“指向”)原始值。不創(chuàng)建任何副本。引用類(lèi)型包括類(lèi)、接口、委托和裝箱值類(lèi)型。

JDK:JDK是Java語(yǔ)言的軟件開(kāi)發(fā)工具包，主要用于移動(dòng)設(shè)備、嵌入式設(shè)備上的java應(yīng)用程序。JDK是整個(gè)java開(kāi)發(fā)的核心，它包含了JAVA的運(yùn)行環(huán)境，JAVA工具和JAVA基礎(chǔ)的類(lèi)庫(kù)。

正則表達(dá)式：正則表達(dá)式，又稱(chēng)規(guī)則表達(dá)式。(英語(yǔ)：Regular Expression，在代碼中常簡(jiǎn)寫(xiě)為regex、regexp或RE)，計(jì)算機(jī)科學(xué)的一個(gè)概念。正則表通常被用來(lái)檢索、替換那些符合某個(gè)模式(規(guī)則)的文本。

JavaBean：JavaBean是一種JAVA語(yǔ)言寫(xiě)成的可重用組件。為寫(xiě)成JavaBean，類(lèi)必須是具體的和公共的，并且具有無(wú)參數(shù)的構(gòu)造器。JavaBean通過(guò)提供符合一致性設(shè)計(jì)模式的公共方法將內(nèi)部域暴露成員屬性，long和class方法獲取。眾所周知，屬性名稱(chēng)符合這種模式，其他Java類(lèi)可以通過(guò)自省機(jī)制發(fā)現(xiàn)和操作這些JavaBean的屬性。

本發(fā)明是一個(gè)通過(guò)自定義協(xié)議文件(也可以稱(chēng)為：協(xié)議描述文件)自動(dòng)生成通信代碼的方法，將協(xié)議描述文件進(jìn)行解析之后，最后生成源文件(就是通信代碼)。該源文件一方面會(huì)封裝到HTTP請(qǐng)求中，然后將HTTP請(qǐng)求發(fā)給服務(wù)器。另一方面該源文件會(huì)保存在客戶(hù)端，進(jìn)而程序員在調(diào)用時(shí)，將生成的源文件直接放入到自己的項(xiàng)目中就可以正常調(diào)用并且能夠以此和服務(wù)器進(jìn)行正常通行。

由此可見(jiàn)，通過(guò)本方案生成的通信代碼能夠供開(kāi)發(fā)者直接調(diào)用，而不需要再要求開(kāi)發(fā)者進(jìn)行編程，能夠極大的提高開(kāi)發(fā)者的開(kāi)發(fā)效率，同時(shí)由于能夠自動(dòng)生成客戶(hù)端和服務(wù)端的通信代碼，這樣也極大的降低了客戶(hù)端和服務(wù)端通信出錯(cuò)的概率。另外，由于代碼是自動(dòng)生成的，所以也極大的降低開(kāi)發(fā)人員的開(kāi)發(fā)人力成本，為企業(yè)大大降低人力開(kāi)銷(xiāo)。

在具體的實(shí)施過(guò)程中，下面請(qǐng)參看圖1，是本發(fā)明的實(shí)施過(guò)程圖。

S1，獲得協(xié)議描述文件。

協(xié)議描述文件，是本發(fā)明自定義的描述文件，為T(mén)XT格式。

在執(zhí)行本發(fā)明S1(獲得協(xié)議描述文件)之前，本發(fā)明會(huì)先利用兩個(gè)關(guān)鍵字進(jìn)行自定義協(xié)議格式；來(lái)生成協(xié)議描述文件。

故而，本發(fā)明定義的協(xié)議描述文件，實(shí)際上是對(duì)第一關(guān)鍵字和第二關(guān)鍵字進(jìn)行自定義協(xié)議格式之后形成的用于描述通信協(xié)議的描述文件。

為了增加該協(xié)議描述文件的可讀性和易解析性，本發(fā)明利用兩個(gè)關(guān)鍵字對(duì)通信描述協(xié)議進(jìn)行自定義設(shè)計(jì)：Struct(結(jié)構(gòu)體)關(guān)鍵字和interface(接口)關(guān)鍵字。

下面分別對(duì)本發(fā)明自定義的兩個(gè)關(guān)鍵字進(jìn)行詳細(xì)描述。

Struct關(guān)鍵字：

這個(gè)Struct關(guān)鍵字代表一個(gè)結(jié)構(gòu)體，用于對(duì)客戶(hù)端和服務(wù)端之間往來(lái)的通信數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)組成的描述。

通常來(lái)說(shuō)，為了方便客戶(hù)端和服務(wù)端之間的通信，通常會(huì)把關(guān)聯(lián)性比較大的通信數(shù)據(jù)進(jìn)行封裝成一個(gè)結(jié)構(gòu)體，然后直接使用該結(jié)構(gòu)體來(lái)進(jìn)行通信。而為了方便描述客戶(hù)端和服務(wù)端往來(lái)的通信數(shù)據(jù)，本發(fā)明使用了Struct來(lái)描述通信數(shù)據(jù)的結(jié)構(gòu)組成(該結(jié)構(gòu)組成至少包括通信數(shù)據(jù)的數(shù)據(jù)類(lèi)型)，故而Struct關(guān)鍵字表示的結(jié)構(gòu)體，至少包括通信數(shù)據(jù)的數(shù)據(jù)類(lèi)型。

每個(gè)Struct關(guān)鍵字，都對(duì)應(yīng)有一個(gè)各自的數(shù)據(jù)結(jié)構(gòu)，而在每個(gè)數(shù)據(jù)結(jié)構(gòu)中，都具有各自的數(shù)據(jù)類(lèi)型。

Struct中可以包含基本的數(shù)據(jù)類(lèi)型(例如：浮點(diǎn)型float、整形int、長(zhǎng)整型long、雙精度浮點(diǎn)型double、布爾型boolean)，也可以包含其他Struct的數(shù)據(jù)類(lèi)型。

通過(guò)上述Struct的設(shè)計(jì)，可以使用Struct來(lái)描述程序里面的任何通信數(shù)據(jù)的數(shù)據(jù)類(lèi)型。

為了方便理解，下面舉例說(shuō)明利用對(duì)Struct關(guān)鍵字進(jìn)行自定義協(xié)議格式之后，形成的協(xié)議描述文件。

舉例說(shuō)明如下：

Struct Brithday

{

Long daytime；

}

在此協(xié)議描述文件中，我們首先定義了一個(gè)數(shù)據(jù)結(jié)構(gòu)Brithday，該數(shù)據(jù)結(jié)構(gòu)中包含一個(gè)long類(lèi)型的daytime參數(shù)，該參數(shù)表明的是生日時(shí)間。

Struct Person

在此協(xié)議描述文件中，描述了一個(gè)Person的數(shù)據(jù)結(jié)構(gòu)，該結(jié)構(gòu)中包含了一個(gè)int類(lèi)型的age參數(shù)，該參數(shù)表示的是用戶(hù)的年齡信息，同時(shí)Person數(shù)據(jù)結(jié)構(gòu)中還包含了一個(gè)Brithday的bday數(shù)據(jù)，這個(gè)數(shù)據(jù)是用于描述生日信息的。

可以看得出來(lái)上述2個(gè)協(xié)議描述文件的數(shù)據(jù)結(jié)構(gòu)中，Brithday的數(shù)據(jù)結(jié)構(gòu)僅僅包含值類(lèi)型的數(shù)據(jù)結(jié)構(gòu)，而Person中除了包含值類(lèi)型的數(shù)據(jù)結(jié)構(gòu)以外，還包含了一個(gè)Struct類(lèi)型的Brithday的引用數(shù)據(jù)類(lèi)型。

通過(guò)這個(gè)實(shí)例的舉例我們對(duì)Struct關(guān)鍵字的理解更加清晰和深刻。Struct主要是針對(duì)客戶(hù)端和服務(wù)端通信數(shù)據(jù)的結(jié)構(gòu)組成的描述。

Interface：

Interface關(guān)鍵字用于所述客戶(hù)端和所述服務(wù)端通信行為的描述。

在協(xié)議描述文件的設(shè)計(jì)中，除了對(duì)通信數(shù)據(jù)的數(shù)據(jù)類(lèi)型進(jìn)行設(shè)計(jì)之外，本發(fā)明還會(huì)對(duì)客戶(hù)端和服務(wù)端的通信行為進(jìn)行設(shè)計(jì)。而通信行為的基礎(chǔ)，則是通信接口的定義。

通信接口，主要是客戶(hù)端和服務(wù)器進(jìn)行溝通的橋梁，通信數(shù)據(jù)則類(lèi)似于這個(gè)橋梁上的小汽車(chē)。

下面我們看看此Interface是如何定義通信接口的。

Interface關(guān)鍵字的內(nèi)部，主要是定義了一些通信的方法，包括接口函數(shù)名稱(chēng)、接口函數(shù)參數(shù)的類(lèi)型，返回值。這些方法是客戶(hù)端和服務(wù)端進(jìn)行通信的工具。

為了方便理解Interface的接口設(shè)計(jì)理念，下面通過(guò)舉例說(shuō)明，方便理解這個(gè)關(guān)鍵字的作用。

客戶(hù)端：

Interface

{

Void sendInfo(Person p,ICallback callback)；

}

在該客戶(hù)端側(cè)設(shè)計(jì)的通信接口中，sendInfo是相關(guān)的函數(shù)名稱(chēng)，Person數(shù)據(jù)類(lèi)型是上文中提到的通過(guò)Struct來(lái)定義的Person數(shù)據(jù)，也就是本方案中需要發(fā)送給服務(wù)端的數(shù)據(jù)。ICallback是異常和結(jié)果反饋接口，有異常或結(jié)果有信息返回的時(shí)候會(huì)通過(guò)ICallback這個(gè)接口轉(zhuǎn)發(fā)給開(kāi)發(fā)者。

服務(wù)端：

Interface

{

Void receiverInfo(Person p,ICallback callback)；

}

在該服務(wù)端設(shè)計(jì)的通信接口中，receiverInfo是相關(guān)的函數(shù)名稱(chēng)，Person數(shù)據(jù)類(lèi)型是上文中提到的通過(guò)Struct來(lái)定義的Person數(shù)據(jù)，也就是本方案中服務(wù)端需要接收的數(shù)據(jù)。ICallback是異常和結(jié)果反饋接口，有異?；蚪Y(jié)果有信息返回的時(shí)候會(huì)通過(guò)ICallback這個(gè)接口轉(zhuǎn)發(fā)給開(kāi)發(fā)者。

上述示例中，總共設(shè)計(jì)了2個(gè)通信接口，第一個(gè)是客戶(hù)端的通信接口，發(fā)送數(shù)據(jù)給服務(wù)端用的，另外一個(gè)是服務(wù)端的通信接口，用于接收客戶(hù)端發(fā)送過(guò)來(lái)的信息。

通過(guò)上面的描述發(fā)現(xiàn)，Interface主要作用是用于對(duì)客戶(hù)端和服務(wù)端之間的通信行為的描述。

以上便是有關(guān)協(xié)議描述文件的介紹，本發(fā)明的協(xié)議描述文件，是采用了兩個(gè)關(guān)鍵字(Struct和interface)進(jìn)行自定義格式之后形成的，用于描述通信協(xié)議的描述文件。

故而在獲得協(xié)議描述文件之后，最主要的目的就是為了執(zhí)行下面的步驟：

S2，解析所述協(xié)議描述文件，并利用所述協(xié)議描述文件生成所述通信代碼，所述通信代碼供客戶(hù)端和服務(wù)器在進(jìn)行通信時(shí)調(diào)用，以實(shí)現(xiàn)客戶(hù)端和服務(wù)端之間的通信。

解析協(xié)議描述文件的過(guò)程如下：

判斷協(xié)議描述文件是否包含所述第一(Struct)關(guān)鍵字。

若協(xié)議描述文件包含所述第一關(guān)鍵字，則從所述協(xié)議描述文件解析出所述客戶(hù)端和所述服務(wù)端之間往來(lái)的通信數(shù)據(jù)的描述信息，然后利用所述通信數(shù)據(jù)的描述信息生成第一通信代碼。

若協(xié)議描述文件不包含所述第一關(guān)鍵字，則進(jìn)一步判斷協(xié)議描述文件是否包含所述第二關(guān)鍵字，若協(xié)議描述文件包含所述第二關(guān)鍵字，則從所述協(xié)議描述文件解析出通信接口的接口函數(shù)描述信息；然后利用所述通信接口的接口函數(shù)描述信息生成第二通信代碼。

而在判斷協(xié)議描述文件是否包含所述第一(Struct)關(guān)鍵字的具體實(shí)施中，會(huì)依次獲取所述協(xié)議描述文件的每行信息，并依次判斷所述協(xié)議描述文件的每行信息是否為第一關(guān)鍵字，若有一行信息為所述第一關(guān)鍵字，則獲取所述一行信息包含的一行或者多行數(shù)據(jù)，并依次解析出所述一行或者多行數(shù)據(jù)的數(shù)據(jù)類(lèi)型。然后利用解析出的所述一行信息對(duì)應(yīng)的所有數(shù)據(jù)類(lèi)型生成第一通信代碼。

作為一種可選的實(shí)施例，在依次解析出所述一行或者多行數(shù)據(jù)的數(shù)據(jù)類(lèi)型之后，可將所述一行或者多行數(shù)據(jù)的數(shù)據(jù)類(lèi)型存入第一集合中。

而若協(xié)議描述文件不包含所述第一關(guān)鍵字，則進(jìn)一步判斷協(xié)議描述文件是否包含所述第二(Interface)關(guān)鍵字并進(jìn)行后續(xù)處理。

在具體的實(shí)施過(guò)程中，若所述一行信息不為所述第一關(guān)鍵字，則進(jìn)一步判斷所述一行信息是否為第二關(guān)鍵字；若所述一行信息是所述第二關(guān)鍵字，解析第二關(guān)鍵字包含的一行或者多行數(shù)據(jù)；然后依次讀取所述一行信息包含的一行或者多行數(shù)據(jù)，以分離出每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)；并依次判斷每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)是否包含所述第一關(guān)鍵字；若包含，則調(diào)用所述第一集合，依次判斷每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型是否存在于所述第一集合中，若有一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型存在于所述第一集合中，則表示所述一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)解析成功；然后利用解析成功的接口函數(shù)生成第二通信代碼。

作為一種可選的實(shí)施例，若有一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型存在于所述第一集合中，將所述一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型保存在第二集合中。

具體的解析邏輯如圖2所示：

S201，將協(xié)議描述文件讀取到內(nèi)存中。

具體讀取方法，是通過(guò)JDK提供的文件讀取方法，將協(xié)議描述文件讀取到文件輸入流中，具體實(shí)施函數(shù)是FileInputStream(file)，通過(guò)系統(tǒng)函數(shù)FileInputStream的調(diào)用，可以將協(xié)議描述文件file讀取到內(nèi)存中。

為了方便后續(xù)的描述本發(fā)明將讀取到的文件輸入流用變量inputStream來(lái)標(biāo)示。

文件輸入流inputStream中有一個(gè)readline函數(shù)，該函數(shù)的主要功能是讀取文件中的一整行數(shù)據(jù)。我們通過(guò)調(diào)用readline函數(shù)得到文件的這一行的lineInfo(標(biāo)示文件的一整行信息)。

S202，獲取所述協(xié)議描述文件的一行l(wèi)ineInfo，并依次判斷這一行l(wèi)ineInfo是否為Struct關(guān)鍵字。

在具體的實(shí)施過(guò)程中，首先，對(duì)協(xié)議描述文件的這一行l(wèi)ineInfo內(nèi)容進(jìn)行判斷，首先判斷這一行l(wèi)ineInfo是不是Struct。本處的判斷方式是通過(guò)調(diào)用java中String類(lèi)中的equals方法去判斷2個(gè)字符串是否相等來(lái)判別的，下文所有判別方法相同。

若判斷出所述協(xié)議描述文件的這一行l(wèi)ineInfo是Struct關(guān)鍵字：

執(zhí)行S203的步驟：獲取所述Struct關(guān)鍵字中的包含的一行或者多行數(shù)據(jù)，并依次解析出所述一行或者多行數(shù)據(jù)的數(shù)據(jù)類(lèi)型。即：解析整個(gè)Struct后面“{}”內(nèi)的信息。解析方法就是每次讀取一行數(shù)據(jù)，則解析出該數(shù)據(jù)的數(shù)據(jù)類(lèi)型，然后再次讀取一行數(shù)據(jù)，并解析出該數(shù)據(jù)的數(shù)據(jù)類(lèi)型，以此按照順序依次解析出Struct關(guān)鍵字中每行數(shù)據(jù)中的數(shù)據(jù)類(lèi)型。當(dāng)然，若Struct只有一行數(shù)據(jù)，則判斷出該行數(shù)據(jù)的數(shù)據(jù)類(lèi)型即可。

舉例來(lái)說(shuō)，當(dāng)解析了Struct里面包含的第一行數(shù)據(jù)的數(shù)據(jù)類(lèi)型之后，如果Struct里面還有第二行數(shù)據(jù)，那么我們就跳轉(zhuǎn)到第二行數(shù)據(jù)中解析第二行數(shù)據(jù)的數(shù)據(jù)類(lèi)型。當(dāng)然，若還包括其他行數(shù)據(jù)，則依次跳入其他行數(shù)據(jù)進(jìn)行解析，獲得對(duì)應(yīng)的數(shù)據(jù)類(lèi)型。

例如：

Struct Person

在解析了Struct里面包含的第一行數(shù)據(jù)Int age的數(shù)據(jù)類(lèi)型為Int之后，則跳轉(zhuǎn)到第二行數(shù)據(jù)中解析Brithday bday的數(shù)據(jù)類(lèi)型的引用數(shù)據(jù)類(lèi)型。

解析完成第二行數(shù)據(jù)的數(shù)據(jù)類(lèi)型后，返回繼續(xù)解析上述未完成的Struct數(shù)據(jù)。

舉例來(lái)說(shuō)，比如解析到Brithday類(lèi)型，由于Brithday并不是基本數(shù)據(jù)類(lèi)型，如果在解析Person之前沒(méi)有解析Brithday，那么Person是不知道Brithday是個(gè)什么類(lèi)型的，此時(shí)可以先預(yù)留，等后面繼續(xù)解析過(guò)程中解析出Brithday結(jié)構(gòu)后，再返回來(lái)確定Person類(lèi)的所有信息。

如果有多層Struct的包含關(guān)系，就逐層跳入解析然后逐層返回直到所有數(shù)據(jù)都被解析完成。

舉例來(lái)說(shuō)，比如解析到Brithday類(lèi)型，由于Brithday并不是基本數(shù)據(jù)類(lèi)型，如果在解析Person之前沒(méi)有解析Brithday，那么Person是不知道Brithday是個(gè)什么類(lèi)型的，此時(shí)可以先預(yù)留，等后面繼續(xù)解析過(guò)程中解析出Brithday結(jié)構(gòu)后，再返回來(lái)確定Person類(lèi)的所有信息。

解析完成后：

執(zhí)行S204的步驟：將所述一行或者多行數(shù)據(jù)對(duì)應(yīng)的數(shù)據(jù)類(lèi)型存入第一集合中(也稱(chēng)為結(jié)構(gòu)體集合或者listStruct)。

本發(fā)明將所有這些的Struct數(shù)據(jù)結(jié)構(gòu)解析完畢之后獲得的數(shù)據(jù)和數(shù)據(jù)類(lèi)型存放在一個(gè)結(jié)構(gòu)體集合里面，該集合我們用listStruct進(jìn)行標(biāo)示。

執(zhí)行S205的步驟：利用解析出的所述一行信息對(duì)應(yīng)的所有數(shù)據(jù)類(lèi)型生成第一通信代碼。

具體來(lái)說(shuō)，在執(zhí)行完畢S203之后，可直接執(zhí)行S205，也可以按照順序執(zhí)行S203-S204-S205。本發(fā)明對(duì)此不做限制。

每行信息可對(duì)應(yīng)一個(gè)Struct關(guān)鍵字，進(jìn)而在解析完每行信息之后，每行信息的Struct關(guān)鍵字可以對(duì)應(yīng)生成各自的第一通信代碼。并且每行信息對(duì)應(yīng)的數(shù)據(jù)類(lèi)型都存入各自的第一集合中。

第一通信代碼也可以稱(chēng)作通信數(shù)據(jù)描述源文件，進(jìn)而可利用第一集合中的數(shù)據(jù)類(lèi)型生成通信數(shù)據(jù)描述源文件。

生成Struct關(guān)鍵字對(duì)應(yīng)的通信數(shù)據(jù)描述源文件的過(guò)程：

一個(gè)Struct其中包含的元素信息可以從listStruct中進(jìn)行獲取。我們通過(guò)循環(huán)遍歷的方式每次取出一個(gè)Struct的數(shù)據(jù)類(lèi)型，然后通過(guò)Java寫(xiě)入文件接口的方式將對(duì)應(yīng)的變量寫(xiě)入到文件中。生成源文件的格式按照J(rèn)avaBean的規(guī)范進(jìn)行命名和生成。其中將數(shù)據(jù)寫(xiě)入文件是一個(gè)通用方法，本方案中不再贅述。其次JavaBean是一個(gè)標(biāo)準(zhǔn)的文件格式類(lèi)型，對(duì)其中的元素命名和函數(shù)有嚴(yán)格要求，是一個(gè)通用規(guī)范本方案不再詳細(xì)描述JavaBean規(guī)范。

若判斷出所這一行l(wèi)ineInfo不是Struct關(guān)鍵字：

執(zhí)行S206，判斷這一行l(wèi)ineInfo是不是Interface關(guān)鍵字。

如果這一行l(wèi)ineInfo也不是interface關(guān)鍵字：

執(zhí)行S207：結(jié)束解析流程。這個(gè)時(shí)候就拋出一個(gè)異常信息，提示協(xié)議描述文件解析錯(cuò)誤。

如果這一行l(wèi)ineInfo是interface關(guān)鍵字：

依次解析interface關(guān)鍵字包含的一行或者多行數(shù)據(jù)，以分離出每行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)。

以某行數(shù)據(jù)為例。

執(zhí)行S208：解析interface關(guān)鍵字包含的一行數(shù)據(jù)，以分離出這一行數(shù)據(jù)對(duì)應(yīng)的接口函數(shù)參數(shù)。

具體來(lái)說(shuō)，解析interface關(guān)鍵字后面”{}”內(nèi)的信息。解析方法是，每次讀取一行數(shù)據(jù)，分離出其中的接口函數(shù)名稱(chēng)，接口函數(shù)參數(shù)和返回值，其中所述接口函數(shù)參數(shù)具有自己獨(dú)特的數(shù)據(jù)類(lèi)型。(這個(gè)地方獲取接口函數(shù)名稱(chēng)，接口函數(shù)的參數(shù)類(lèi)型和返回值是通過(guò)正則表達(dá)式的方式來(lái)分離出來(lái)的，此處正則表達(dá)式方法是一個(gè)通用的分離字符串的方法)。

執(zhí)行S209，對(duì)該行數(shù)據(jù)的接口函數(shù)參數(shù)進(jìn)行判定，判定該接口函數(shù)參數(shù)是否是Struct。若不是，執(zhí)行S207。

若該接口函數(shù)參數(shù)是Struct：

執(zhí)行S210，調(diào)用結(jié)構(gòu)體集合查找是否包含該接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型。

如果listStruct不包含該接口函數(shù)參數(shù)(param)的數(shù)據(jù)類(lèi)型，即：接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型不存在于所述結(jié)構(gòu)體集合listStruct中。說(shuō)明interface中使用了未知的數(shù)據(jù)類(lèi)型，則解析會(huì)直接停止，提示協(xié)議描述文件解析錯(cuò)誤，此時(shí)：

執(zhí)行S207，結(jié)束解析流程。

如果listStruct中包含param的數(shù)據(jù)類(lèi)型，即：接口函數(shù)參數(shù)的數(shù)據(jù)類(lèi)型存在于所述結(jié)構(gòu)體集合listStruct中。說(shuō)明是可以識(shí)別該數(shù)據(jù)結(jié)構(gòu)的，解析成功。此時(shí)：

執(zhí)行S211，繼續(xù)依次解析Interface中的其他行數(shù)據(jù)的接口函數(shù)參數(shù)，直到interface關(guān)鍵字包含的一行或者多行數(shù)據(jù)都解析完成。

解析完成后，為了方便源文件的生成，執(zhí)行S212，我們將所有解析出的通信接口的接口函數(shù)參數(shù)存放在一個(gè)接口集合里面，該集合我們用listInterface進(jìn)行標(biāo)示。當(dāng)然，接口函數(shù)參數(shù)、函數(shù)名稱(chēng)、返回值等都存在于該集合中。當(dāng)然，并非所有的接口函數(shù)都有參數(shù)和返回值，對(duì)于沒(méi)有參數(shù)的，集合中關(guān)于參數(shù)部分的描述就是空的。

執(zhí)行S213，利用接口集合中包含的解析成功的接口函數(shù)參數(shù)生成第二通信代碼。

具體來(lái)說(shuō)，在執(zhí)行完畢S211之后，可直接執(zhí)行S213，也可以按照順序執(zhí)行S211-S212-S213。本發(fā)明對(duì)此不做限制。

第二通信代碼也叫通信行為描述源文件。

生成Interface對(duì)應(yīng)的通信行為描述源文件的過(guò)程：

由于解析后所有函數(shù)信息存放在listInterface集合中，我們可以通過(guò)循環(huán)遍歷的方式每次取出一條數(shù)據(jù)，該條數(shù)據(jù)包含了函數(shù)的返回值，函數(shù)名稱(chēng)，函數(shù)參數(shù)等信息。然后根據(jù)獲得的返回值，接口函數(shù)名稱(chēng)，接口函數(shù)參數(shù)生成對(duì)應(yīng)的第二通信代碼。

第二通信代碼主要是可將函數(shù)參數(shù)封裝到HTTP請(qǐng)求中，然后將請(qǐng)求發(fā)給服務(wù)器。由于HTTP請(qǐng)求服務(wù)器這部分是一個(gè)公用方法，本方案不做詳細(xì)贅述，這樣就能夠?qū)⑺薪涌趯?duì)應(yīng)的接口方法生成通信行為描述源文件了。

由上可知，所有通信數(shù)據(jù)的數(shù)據(jù)類(lèi)型都存放在listStruct結(jié)構(gòu)體中。所有通信數(shù)據(jù)的接口函數(shù)描述都存放在listInterface中。

由上可知，生成的源文件總共有2類(lèi)：

第1類(lèi)是Struct關(guān)鍵字對(duì)應(yīng)的通信數(shù)據(jù)描述源文件(類(lèi)型為Java源文件)，并且一個(gè)Struct關(guān)鍵字對(duì)應(yīng)一個(gè)Java源文件，因?yàn)樵诰W(wǎng)絡(luò)傳輸中一個(gè)Struct關(guān)鍵字對(duì)應(yīng)一個(gè)數(shù)據(jù)結(jié)構(gòu)，該數(shù)據(jù)結(jié)構(gòu)在網(wǎng)絡(luò)中進(jìn)行傳輸一定需要對(duì)其進(jìn)行序列化才能進(jìn)行傳輸。所以對(duì)于每一個(gè)Struct都需要生成一個(gè)通信數(shù)據(jù)描述源文件，然后在該源文件中實(shí)現(xiàn)序列化接口。

第2類(lèi)是Interface關(guān)鍵字對(duì)應(yīng)的通信行為描述源文件(類(lèi)型為Java源文件)，所有的Interface關(guān)鍵字可以只需要生成一個(gè)Java源文件，該源文件中包含了所有的接口函數(shù)參數(shù)。

通過(guò)上述描述過(guò)程，本發(fā)明最后能夠生成所有的Struct各自對(duì)應(yīng)Java源文件和所有接口對(duì)應(yīng)的Java源文件了。用戶(hù)將生成的源文件直接放入到自己的項(xiàng)目中就可以正常使用并且能夠和服務(wù)器進(jìn)行正常通行了。

參看圖3，基于同一發(fā)明構(gòu)思，下面的實(shí)施例公開(kāi)了一種利用協(xié)議描述文件自動(dòng)生成通信代碼的系統(tǒng)，包括：

獲得模塊301，用于獲得所述協(xié)議描述文件，所述協(xié)議描述文件是對(duì)第一關(guān)鍵字和第二關(guān)鍵字進(jìn)行自定義協(xié)議格式之后形成的用于描述通信協(xié)議的描述文件。

解析模塊302，用于解析所述協(xié)議描述文件，并利用所述協(xié)議描述文件生成所述通信代碼，所述通信代碼供客戶(hù)端和服務(wù)器在進(jìn)行通信時(shí)調(diào)用，以實(shí)現(xiàn)所述客戶(hù)端和所述服務(wù)端之間的通信。

通過(guò)本發(fā)明的一個(gè)或者多個(gè)實(shí)施例，本發(fā)明具有以下有益效果或者優(yōu)點(diǎn)：

本方案是一套提高開(kāi)發(fā)效率，降低開(kāi)發(fā)成本，并且能夠極大的提高穩(wěn)定性的方案。在實(shí)際應(yīng)用中能夠?qū)﹂_(kāi)發(fā)起到非常大的作用。

本發(fā)明的方案提供了一種利用協(xié)議描述文件自動(dòng)生成通信代碼的方法，能夠自動(dòng)獲取并解析該協(xié)議描述文件，并且自動(dòng)生成與協(xié)議描述文件相關(guān)的通信代碼邏輯。由于本發(fā)明能夠自動(dòng)生成客戶(hù)端和服務(wù)端通信代碼，進(jìn)而在客戶(hù)端和服務(wù)段通信時(shí)，可直接調(diào)用該通信代碼進(jìn)行數(shù)據(jù)通信，并能夠保證發(fā)送接口和接受接口的對(duì)接沒(méi)有異常，同時(shí)也極大的降低了開(kāi)發(fā)過(guò)程中由于客戶(hù)端和服務(wù)端的疏忽可能產(chǎn)生的通信異常的概率。進(jìn)一步的，開(kāi)發(fā)者只需要關(guān)注第一關(guān)鍵字和第二關(guān)鍵字進(jìn)行自定義協(xié)議格式之后形成的用于描述通信協(xié)議的描述文件的設(shè)計(jì)，不需要去實(shí)現(xiàn)所有通信過(guò)程，能夠大幅提高開(kāi)發(fā)者的在通信部分的開(kāi)發(fā)效率。

盡管已描述了本申請(qǐng)的優(yōu)選實(shí)施例，但本領(lǐng)域內(nèi)的普通技術(shù)人員一旦得知了基本創(chuàng)造性概念，則可對(duì)這些實(shí)施例作出另外的變更和修改。所以，所附權(quán)利要求意欲解釋為包括優(yōu)選實(shí)施例以及落入本申請(qǐng)范圍的所有變更和修改。

顯然，本領(lǐng)域的技術(shù)人員可以對(duì)本申請(qǐng)進(jìn)行各種改動(dòng)和變型而不脫離本申請(qǐng)的精神和范圍。這樣，倘若本申請(qǐng)的這些修改和變型屬于本申請(qǐng)權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本申請(qǐng)也意圖包含這些改動(dòng)和變型在內(nèi)。