本申請涉及計算機技術領域，尤其涉及一種信息發(fā)布方法、客戶端及服務端。

背景技術：

傳統(tǒng)技術中，在對用戶在客戶端通過表單輸入的信息進行發(fā)布時，也即在對表單中的信息進行發(fā)布時，為了防止表單被重復提交，客戶端首先對用戶提交的表單進行唯一性驗證，在唯一性驗證通過后；客戶端針對該提交成功的表單會向服務端發(fā)送一次信息發(fā)布請求，該信息發(fā)布請求通過隨機生成的請求標識(requestid)進行標記，并且該信息發(fā)布請求中包括表單中的信息；服務端為了避免對表單中的信息進行重復發(fā)布，會根據(jù)請求標識，對信息發(fā)布請求進行唯一性驗證，在唯一性驗證通過后，發(fā)布表單中的信息。

然而上述方法中，當用戶針對同一表單的兩次提交操作的時間間隔比較小時，該兩次提交的同一表單可能都會通過唯一性認證，一旦兩次提交的同一表單都通過唯一性認證，則客戶端會針對該同一表單向服務端發(fā)送兩次信息發(fā)布請求，且該兩個不同的信息發(fā)布請求通過兩個不同的請求標識進行標記；當服務端接收到通過兩個不同的請求標識標記的兩個不同的信息發(fā)布請求時，由于該兩個信息發(fā)布請求都會通過唯一性驗證，因此服務端會發(fā)布兩次上述表單中的信息，這影響了信息發(fā)布的準確性，進而浪費了計算機資源。

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

本申請描述了一種信息發(fā)布方法、客戶端及服務端，可以提高信息發(fā)布的準確性，從而可以達到節(jié)約計算機資源的目的。

第一方面，提供了一種信息發(fā)布方法，該方法包括：

客戶端接收用戶提交的表單

從所述表單中讀取所述表單的第一標識信息，所述表單是指所述客戶端中由所述用戶輸入所述待發(fā)布信息的區(qū)域；

根據(jù)所述第一標識信息，對所述表單的唯一性進行驗證；

在對所述表單的唯一性驗證通過后，根據(jù)所述第一標識信息，確定第二標識信息；

向服務端發(fā)送信息發(fā)布請求，所述信息發(fā)布請求包括所述第二標識信息以及所述待發(fā)布信息，所述信息發(fā)布請求用于指示所述服務端在根據(jù)所述第二標識信息對所述信息發(fā)布請求的唯一性驗證通過后，發(fā)布所述待發(fā)布信息。

第二方面，提供了一種信息發(fā)布方法，該方法包括：

服務端接收客戶端發(fā)送的信息發(fā)布請求，所述信息發(fā)布請求包括第二標識信息和待發(fā)布信息；

所述第二標識信息是由所述客戶端在對用戶提交的表單的唯一性驗證通過后根據(jù)所述表單的第一標識信息確定的，所述表單是指所述客戶端中由所述用戶輸入所述待發(fā)布信息的區(qū)域；

根據(jù)所述第二標識信息，對所述信息發(fā)布請求的唯一性進行驗證；

在對所述信息發(fā)布請求的唯一性驗證通過后，發(fā)布所述待發(fā)布信息。

第三方面，提供了一種客戶端，該客戶端包括：

接收單元，用于接收用戶提交的表單；

讀取單元，用于從接收單元接收的所述表單中讀取所述表單的第一標識信息，所述表單是指所述客戶端中由所述用戶輸入所述待發(fā)布信息的區(qū)域；

驗證單元，用于根據(jù)所述讀取單元讀取的所述第一標識信息，對所述表單的唯一性進行驗證；

確定單元，用于在所述驗證單元對所述表單的唯一性驗證通過后，根據(jù)所述第一標識信息，確定第二標識信息；

發(fā)送單元，用于向服務端發(fā)送信息發(fā)布請求，所述信息發(fā)布請求包括所述第二標識信息以及所述待發(fā)布信息，所述信息發(fā)布請求用于指示所述服務端在根據(jù)所述第二標識信息對所述信息發(fā)布請求的唯一性驗證通過后，發(fā)布所述待發(fā)布信息。

第四方面，提供了一種服務端，該服務端包括：

接收單元，用于接收客戶端發(fā)送的信息發(fā)布請求，所述信息發(fā)布請求包括第二標識信息和待發(fā)布信息；所述第二標識信息是由所述客戶端在對用戶提交的表單的唯一性驗證通過后根據(jù)所述表單的第一標識信息確定的，所述表單是指所述客戶端中由所述用戶輸入所述待發(fā)布信息的區(qū)域；

驗證單元，用于根據(jù)所述接收單元接收的所述第二標識信息，對所述信息發(fā)布請求的唯一性進行驗證；

發(fā)布單元，用于在所述驗證單元對所述信息發(fā)布請求的唯一性驗證通過后，發(fā)布所述待發(fā)布信息。

本申請?zhí)峁┑男畔l(fā)布方法、客戶端及服務端，客戶端在對用戶提交的表單的唯一性驗證通過后，根據(jù)表單中的第一標識信息，確定第二標識信息；之后客戶端向服務端發(fā)送通過第二標識信息標記的信息發(fā)布請求；服務端在接收到信息發(fā)布請求之后，根據(jù)第二標識信息對信息發(fā)布請求進行唯一性驗證，并在唯一性驗證通過后，發(fā)布表單中的信息。由此可以看出，本申請中的第二標識信息是根據(jù)第一標識信息生成的，也即本申請中針對同一表單只能生成一個第二標識信息，由此當客戶端針對兩次提交的同一表單向服務端發(fā)送兩次信息發(fā)布請求時，由于該兩次信息發(fā)布請求的第二標識信息相同，所以第二次信息發(fā)布請求不能通過唯一性驗證，從而服務端不對第二次信息發(fā)布請求中已發(fā)布的表單中的信息進行重復發(fā)布，由此避免了現(xiàn)有技術中對表單中的信息重復發(fā)布的問題。

附圖說明

為了更清楚地說明本發(fā)明實施例的技術方案，下面將對實施例描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其它的附圖。

圖1為本申請?zhí)峁┑男畔l(fā)布方法的應用場景示意圖；

圖2為本申請一種實施例提供的信息發(fā)布方法的流程圖；

圖3為本申請?zhí)峁┑娜谫Y需求發(fā)布方法的信息交互圖；

圖4為本申請另一種實施例提供的信息發(fā)布方法的流程圖；

圖5為本申請再一種實施例提供的客戶端的示意圖；

圖6為本申請又一種實施例提供的服務端的示意圖。

具體實施方式

下面結合附圖，對本發(fā)明的實施例進行描述。

本申請實施例提供的信息發(fā)布方法適用于對用戶在客戶端通過表單輸入的信息進行發(fā)布的場景，此處的客戶端可以為web服務頁面(以下簡稱網(wǎng)頁頁面)。

如，適用于對機構用戶(也稱融資方)在招財寶融資平臺的前端(也稱協(xié)作中心(fincooprod))的融資需求申請表單中填寫的融資需求進行發(fā)布的場景。此處，招財寶融資平臺可以是指提供給合作金融機構發(fā)布融資需求的平臺，其可以包括上述前端以及與前端對應的融資服務中心(finloancenter)，其中，前端用于接收融資方填寫的融資需求，融資服務中心用于落地融資需求；上述融資需求可以是指融資方通過合作金融機構向招財寶融資平臺發(fā)起的一筆借款請求，如果發(fā)布成功，會在招財寶融資平臺形成一筆融資需求。融資需求包含融資方信息、融資金額、利率、借款期限、募集期、產(chǎn)品期限、借款協(xié)議編號等信息。需要說明的是，在融資需求包含上述幾種信息時，則上述落地融資需求可以是指將融資需求中包含的信息保存到數(shù)據(jù)庫的過程。

具體地，合作金融機構將融資方的借款需求發(fā)布至招財寶融資平臺，投資人通過招財寶融資平臺購買產(chǎn)品。招財寶融資平臺支持頁面發(fā)布融資需求、直連接口發(fā)布融資需求和excel批量發(fā)布融資需求，滿足機構的多種需求。而本申請信息發(fā)布不準確的問題主要是針對在招財寶融資平臺上通過網(wǎng)頁頁面的方式發(fā)布融資需求時存在的?？梢岳斫獾氖?，在對融資需求進行發(fā)布的應用場景下，本申請背景技術中所指出的信息發(fā)布不準確問題可以是指融資需求重發(fā)發(fā)布的問題，即融資方的一筆融資請求，在招財寶融資平臺上發(fā)布了多筆相同的融資需求。

需要說明的是，因為金融機構在協(xié)作中心發(fā)布融資需求的時候，會生成一份與招財寶融資平臺的線上合同，形成法律約束，并且選擇增信公司進行擔保。發(fā)布的融資需求，由招財寶融資平臺進行公開募集，募集成功以后，將募集到資金打款給對應的金融機構，并收取一定的平臺手續(xù)費。而該筆融資需求對外承諾的利率也由融資方承擔，并按時還款。而對于這種是因為招財寶融資平臺本身的問題而產(chǎn)生的重復多筆的募集，融資方是不予承認的，如果一旦募集成功，那么對外承諾的利率只能由招財寶融資平臺自己承擔，現(xiàn)在招財寶融資平臺上的一筆融資需求動輒億萬，這將會是一起嚴重的資金損失。因此迫切需要解決因表單多次提交而導致融資需求重復發(fā)布的問題。

圖1為本申請?zhí)峁┑男畔l(fā)布方法的應用場景示意圖，圖1中，客戶端可以是指安裝在個人電腦上的網(wǎng)頁頁面，在該客戶端上可以生成對應的表單，如上述融資需求申請表單，用戶通過客戶端上的表單來輸入待發(fā)布信息，如，融資需求。具體地，在用戶提交表單成功后，客戶端可以將表單中待發(fā)布信息發(fā)送至服務端，由服務端對表單中待發(fā)布信息進行發(fā)布。可以理解的是，在發(fā)布融資需求的場景下，上述客戶端可以是指招財寶融資平臺的前端，而上述服務端可以是指融資服務中心。

圖2為本申請一種實施例提供的信息發(fā)布方法的流程圖，圖2中，所述方法的執(zhí)行主體可以為圖1中的客戶端，如，招財寶融資平臺的前端，如圖2所示，所述方法具體可以包括：

步驟210，當客戶端接收到用戶提交的表單時，從表單中讀取表單的第一標識信息。

此處的表單可以是指客戶端中由用戶輸入待發(fā)布信息的區(qū)域。

可選地，上述第一標識信息可以是由客戶端在生成表單時填寫到表單中的n位隨機數(shù)據(jù)，其中，n為正整數(shù)。

在一種具體實現(xiàn)方式中，該第一標識信息可以是指表單令牌(模型-視圖-控制器(modelviewcontroller，mvc)框架的formtoken)，客戶端可以通過對表單令牌的驗證，來避免表單重復提交的問題。具體地，當客戶端接收到用戶訪問包含表單的網(wǎng)頁頁面的訪問請求時，可以生成一個32位的隨機數(shù)作為表單令牌，并將該表單令牌存儲到會話(session)緩存中，此處，表單令牌在session緩存中的生命周期可以為30分鐘，也即每隔30分鐘，session緩存中的表單令牌會被更新一次。在客戶端將表單令牌存儲到session緩存之后，客戶端可以將該表單令牌填寫到表單中；當用戶填寫完表單并提交表單時，客戶端可以從表單中讀取表單令牌，也即從表單中讀取第一標識信息。

可以理解的是，客戶端將表單令牌填寫到表單中即為將表單令牌填寫到表單對應的代碼中。在一個例子中，表單中的表單令牌可以如下所示：

<inputtype＝"hidden"name＝"_form_token"value＝"sizgsbknjhxowi2iglu1rwjc6xxxxxx"/>

其中，"_form_token"為表單令牌在表單中對應的名稱，"sizgsbknjhxowi2iglu1rwjc6xxxxxx"為表單令牌的值，即為32位的隨機數(shù)。

步驟220，根據(jù)第一標識信息，對表單的唯一性進行驗證。

以第一標識信息為表單令牌為例來說，對表單的唯一性驗證過程具體可以為：從session緩存中讀取表單令牌，并將從表單中讀取的表單令牌與從session緩存中讀取的表單令牌進行比對，若比對一致，則對表單的唯一性驗證通過，也即用戶提交表單成功；否則對表單的唯一性驗證不通過，也即用戶提交表單不成功。

需要說明的是，在客戶端從session緩存中讀取表單令牌之后，可以立即刪除session緩存中的表單令牌，以免同一表單被重復提交。此處，通過刪除session緩存中的表單令牌來避免同一表單被重復提交的實現(xiàn)原理如下：當表單被第一次提交時，且為未超時(即沒超過30分鐘)提交時，從表單中讀取的表單令牌與從session緩存中讀取的表單令牌會比對一致，從而用戶提交表單成功，當該同一表單被再次提交時，即便未超時，由于session緩存中的表單令牌已經(jīng)被刪除，因此，肯定比對不一致，從而用戶提交表單不會成功。

然而，由于目前的系統(tǒng)或平臺往往具有很高的并發(fā)性，所以在session緩存中的表單令牌未被刪除的瞬間，客戶端可能會接收用戶對同一表單執(zhí)行了第二次提交操作，而針對該兩次提交操作，客戶端都可以讀取到session緩存中的表單令牌，那么該兩次提交的表單都可以通過唯一性驗證，由此出現(xiàn)了同一表單重復提交的問題。因此，就需要在下一階段能夠?qū)χ貜偷谋韱芜M行識別，以免服務端對表單中的信息進行重復發(fā)布。

上述用戶針對同一表單多次提交的操作可能是由用戶快速多次點擊提交按鈕導致的，或者也可能是瀏覽器發(fā)生抖動導致的，還可能是因網(wǎng)絡較慢用戶再次點擊提交按鈕導致的。

步驟230，在對表單的唯一性驗證通過后，根據(jù)第一標識信息，確定第二標識信息。

此處的第二標識信息(requestid)可以用于標記信息發(fā)布請求，該信息發(fā)布請求用于客戶端請求服務端發(fā)布已成功提交的表單中的信息?？梢岳斫獾氖?，針對每個已成功提交的表單，客戶端可以向服務端發(fā)送一次信息發(fā)布請求，以請求服務端發(fā)布表單中的信息。

對于重復提交的表單，實際上每次提交的表單中的表單令牌都是一樣的。于是本申請進行了這樣的優(yōu)化：在生成第二標識信息時，不再隨機生成，而是根據(jù)第一標識信息來生成第二標識信息，而由于同一表單的第一標識信息是相同的，由此生成的第二標識信息也是相同的；當客戶端針對重復的表單向服務端發(fā)送兩次信息發(fā)布請求時，由于該兩次信息發(fā)布請求的第二標識信息相同，所以第二次信息發(fā)布請求不能通過唯一性驗證，也即服務端過濾掉了第二標識信息相同的第二次信息發(fā)布請求，從而可以確保即使同一表單被提交多次，但該表單的信息只發(fā)布一次。

在一種具體實現(xiàn)方式中，客戶端可以通過如下步驟來確定第二標識信息：

根據(jù)預設的算法，將第一標識信息轉化為對應的字節(jié)元素；

確定與字節(jié)元素對應的字符串；

根據(jù)字符串，確定第二標識信息。

此處的預設的算法可以為消息摘要算法第五版(messagedigestalgorithm，md5)算法。以第一標識信息為32位隨機數(shù)據(jù)，第二標識信息為32位的字符串為例來說，第二標識信息的確定過程可以為：可以通過java自帶的md5轉化器(具有實現(xiàn)上述md5算法的功能)，將32位隨機數(shù)據(jù)轉換為16個字節(jié)(byte)元素，之后將每個字節(jié)元素表示為2位的字符串，從而就可以得到32位的字符串。舉例來說，md5轉化器轉換得到的16個字節(jié)元素可以分別為：-44、29、-116、-39、-113、0、-78、4、-23、-128、9、-104、-20、-8、66、126，之后將每個字節(jié)元素表示為2位的字符串(也即表示為16進制數(shù)據(jù))，其中，當任一個字節(jié)元素只能表示為1位的字符串時，則可以通過補0的方式，補齊2位的字符串，如，對字節(jié)元素“0”，與其對應的16進制數(shù)據(jù)為0，即為1位，補0后，得到：00；最后就可以得到字符串：d41d8cd98f00b204e9800998ecf8427e。此處，通過md5轉化器，將32位隨機數(shù)據(jù)轉換為16個字節(jié)(byte)元素屬于現(xiàn)有成熟技術，本申請在此不復贅述。

需要說明的是，雖然上述示例以n＝m為例來說，在實際應用中，n也可以小于m或者大于m；當n小于或者大于m時，md5轉化器同樣可以轉換出16個字節(jié)(byte)元素，這個是現(xiàn)有md5轉化器的功能，本申請在此不復贅述。

當然，在實際應用中，m也可以不為32，其還可以為：16、48或者64等，當m為48時，則可以對md5轉化器轉換得到的16個字節(jié)元素做如下處理來獲得48位的字符串：先確定與16個元素對應的32位的字符串，之后從32位的字符串中截取(如，從最左側截取)16位的字符串，最后將16位的字符串和32位的字符串組合在一起就可以得到48位的字符串。當然，這只是一種獲得48位的字符串的方式，本領域技術人員還可以通過結合某一算法來確定m位的字符串，本申請對此不作限定。

步驟240，向所述服務端發(fā)送信息發(fā)布請求。

其中，信息發(fā)布請求包括第二標識信息以及待發(fā)布信息，信息發(fā)布請求用于指示服務端在根據(jù)第二標識信息對信息發(fā)布請求的唯一性驗證通過后，發(fā)布待發(fā)布信息。

在一種實現(xiàn)方式中，客戶端可以將第二標識信息以及待發(fā)布信息封裝為請求對象，該請求對象包括屬性名和屬性值，以封裝后的第二標識信息為例來說，第二標識信息的屬性名可以為“requestid”，而屬性值則可以為“0a20202020777269”。客戶端在封裝得到請求對象之后，可以將封裝后的請求對象發(fā)送給服務端。

服務端在接收到信息發(fā)布請求之后，對該信息發(fā)布請求進行唯一性驗證，也即對信息發(fā)布請求進行冪等控制，該冪等控制的過程具體為：服務端讀取信息發(fā)布請求中的第二標識信息，并將第二標識信息與數(shù)據(jù)庫中已存儲的第二標識信息進行一一比對，若與已存儲的第二標識信息均比對不一致，則信息發(fā)布請求唯一性驗證通過，否則信息發(fā)布請求唯一性驗證不通過。在信息發(fā)布請求驗證通過后，服務端發(fā)布待發(fā)布信息，如，融資需求，并將待發(fā)布信息以及第二標識信息存儲到數(shù)據(jù)庫中?？梢岳斫獾氖?，數(shù)據(jù)庫中的第二標識信息可以唯一的標識一個以發(fā)布的信息，如，標識一個融資需求。

綜上，本申請利用了服務端的后臺冪等控制來解決表單重復提交導致表單中的信息發(fā)布多次的問題。這樣的實現(xiàn)還有一個優(yōu)點，因為服務端對第二標識信息的冪等控制是數(shù)據(jù)庫層面的，所以只要待發(fā)布信息被成功存儲到數(shù)據(jù)庫，那么后面第二標識信息相同的表單中的待發(fā)布信息都是無法重復入庫的，不存在同時并發(fā)入庫的問題，真正有效地解決了信息發(fā)布不準確的問題。

當本申請的信息發(fā)布方法應用于在招財寶融資平臺上發(fā)布融資需求時，招財寶融資平臺的前端與融資服務中心之間的信息交互可以如圖3所示。圖3中，主要包括如下步驟：

步驟310，機構用戶登錄協(xié)作中心。

步驟320，機構用戶選擇融資模板。

在結構用戶選擇融資模板之后，協(xié)作中心可以生成表單令牌，并將表單令牌填寫到融資需求申請表單中。

步驟330，機構用戶填寫與選擇的融資模板對應的融資需求申請表單。

步驟340，機構用戶提交融資需求申請表單。

步驟350，協(xié)作中心調(diào)用融資服務中心對融資需求申請表單進行預校驗。

步驟360，協(xié)作中心顯示包含融資需求申請表單的預覽頁面。

步驟370，機構用戶確認提交融資需求申請表單。

步驟380，協(xié)作中心從融資需求申請表單中讀取表單令牌，并根據(jù)表單令牌對融資需求申請表單的唯一性進行驗證。

步驟390，協(xié)作中心驗證權限，安全服務化。

步驟3100，協(xié)作中心根據(jù)表單令牌，生成第二標識信息(requestid)。

步驟3110，協(xié)作中心根據(jù)requestid和融資需求申請表單中的信息，封裝融資需求。

步驟3120，協(xié)作中心調(diào)用融資服務中心發(fā)布融資需求。

步驟3130，融資服務中心返回已成功受理的消息。

步驟3140，融資服務中心根據(jù)requestid對融資需求進行冪等控制。

步驟3150，融資服務中心對融資需求中的參數(shù)進行校驗。

步驟3160，融資服務中心簽約招財寶協(xié)議。

步驟3170，融資服務中心融資保障投保，預約保單。

步驟3180，融資服務中心落地融資需求。

步驟3190，融資服務中心發(fā)布招財產(chǎn)品。

步驟3200，產(chǎn)品中心(fundselling)對招財產(chǎn)品參數(shù)進行校驗。

步驟3210，產(chǎn)品中心落地招財寶產(chǎn)品。

綜上，本申請上述實施例解決了招財寶融資平臺因表單重復提交導致融資需求發(fā)布多筆的問題。同時，該實施例還利用了融資需求本身的冪等控制，由此不僅解決了前臺表單重復提交帶來的問題，同時利用了后臺數(shù)據(jù)庫層面的冪等控制，真正有效的控制住了融資需求重復發(fā)布的問題。

圖4為本申請另一種實施例提供的信息發(fā)布方法的流程圖，圖4中，所述方法的執(zhí)行主體可以為圖1中的服務端，如，融資服務中心，如圖4所示，所述方法具體可以包括：

步驟410，服務端接收客戶端發(fā)送的信息發(fā)布請求。

其中，該信息發(fā)布請求包括第二標識信息和待發(fā)布信息；該第二標識信息可以是由客戶端在對用戶提交的表單的唯一性驗證通過后根據(jù)表單的第一標識信息確定的，其中，表單是指客戶端中由用戶輸入待發(fā)布信息的區(qū)域。

其中，第一標識信息是由客戶端在生成表單時填寫到表單中的n位隨機數(shù)據(jù)，其中，n為正整數(shù)。

在一種實現(xiàn)方式中，客戶端可以將第二標識信息以及待發(fā)布信息封裝為請求對象，該請求對象包括屬性名和屬性值，以封裝后的第二標識信息為例來說，第二標識信息的屬性名可以為“requestid”，而屬性值則可以為“0a20202020777269”。客戶端在封裝得到請求對象之后，可以將封裝后的請求對象發(fā)送給服務端。

步驟420，根據(jù)所述第二標識信息，對信息發(fā)布請求的唯一性進行驗證。

步驟430，在對信息發(fā)布請求的唯一性驗證通過后，發(fā)布待發(fā)布信息。

服務端在接收到信息發(fā)布請求之后，對該信息發(fā)布請求進行唯一性驗證，也即對信息發(fā)布請求進行冪等控制，該冪等控制的過程具體為：服務端讀取信息發(fā)布請求中的第二標識信息，并將第二標識信息與數(shù)據(jù)庫中已存儲的第二標識信息進行一一比對，若與已存儲的第二標識信息均比對不一致，則信息發(fā)布請求唯一性驗證通過，否則信息發(fā)布請求唯一性驗證不通過。在信息發(fā)布請求驗證通過后，服務端發(fā)布待發(fā)布信息，如，融資需求，并將待發(fā)布信息以及第二標識信息存儲到數(shù)據(jù)庫中?？梢岳斫獾氖牵瑪?shù)據(jù)庫中的第二標識信息可以唯一的標識一個以發(fā)布的信息，如，標識一個融資需求。

綜上，本申請利用了服務端的后臺冪等控制來解決表單重復提交導致表單中的信息發(fā)布多次的問題。這樣的實現(xiàn)還有一個優(yōu)點，因為服務端對第二標識信息的冪等控制是數(shù)據(jù)庫層面的，所以只要待發(fā)布信息被成功存儲到數(shù)據(jù)庫，那么后面第二標識信息相同的表單中的待發(fā)布信息都是無法重復入庫的，不存在同時并發(fā)入庫的問題，真正有效地解決了信息發(fā)布不準確的問題。

與上述信息發(fā)布方法對應地，本申請實施例還提供的一種客戶端，如圖5所示，該客戶端包括：

接收單元501，用于接收用戶提交的表單。

讀取單元502，用于從接收單元501接收的表單中讀取表單的第一標識信息，表單是指客戶端中由用戶輸入待發(fā)布信息的區(qū)域。

其中，第一標識信息是由客戶端在生成表單時填寫到表單中的n位隨機數(shù)據(jù)，其中，n為正整數(shù)。

驗證單元503，用于根據(jù)讀取單元502讀取的第一標識信息，對表單的唯一性進行驗證。

確定單元504，用于在驗證單元503對表單的唯一性驗證通過后，根據(jù)第一標識信息，確定第二標識信息。

確定單元504具體用于：

根據(jù)預設的算法，將第一標識信息轉化為對應的字節(jié)元素；

確定與字節(jié)元素對應的字符串；

根據(jù)字符串，確定所述第二標識信息。

發(fā)送單元505，用于向服務端發(fā)送信息發(fā)布請求，信息發(fā)布請求包括第二標識信息以及待發(fā)布信息，信息發(fā)布請求用于指示服務端在根據(jù)第二標識信息對信息發(fā)布請求的唯一性驗證通過后，發(fā)布待發(fā)布信息。

本申請實施例裝置的各功能模塊的功能，可以通過上述方法實施例的各步驟來實現(xiàn)，因此，本申請?zhí)峁┑难b置的具體工作過程，在此不復贅述。

本申請實施例提供的客戶端，接收單元501接收用戶提交的表單；讀取單元502從表單中讀取表單的第一標識信息，表單是指客戶端中由用戶輸入待發(fā)布信息的區(qū)域；驗證單元503根據(jù)第一標識信息，對表單的唯一性進行驗證；確定單元504在對表單的唯一性驗證通過后，根據(jù)第一標識信息，確定第二標識信息；發(fā)送單元505向服務端發(fā)送信息發(fā)布請求，信息發(fā)布請求包括第二標識信息以及待發(fā)布信息，信息發(fā)布請求用于指示服務端在根據(jù)第二標識信息對信息發(fā)布請求的唯一性驗證通過后，發(fā)布待發(fā)布信息。由此避免了現(xiàn)有技術中對表單中的信息重復發(fā)布的問題。

與上述信息發(fā)布方法對應地，本申請實施例還提供的一種服務端，如圖6所示，該服務端包括：

接收單元601，用于接收客戶端發(fā)送的信息發(fā)布請求，信息發(fā)布請求包括第二標識信息和待發(fā)布信息；第二標識信息是由客戶端在對用戶提交的表單的唯一性驗證通過后根據(jù)表單的第一標識信息確定的，表單是指客戶端中由用戶輸入待發(fā)布信息的區(qū)域。

其中，第一標識信息是由客戶端在生成表單時填寫到表單中的n位隨機數(shù)據(jù)，其中，n為正整數(shù)。

驗證單元602，用于根據(jù)接收單元601接收的第二標識信息，對信息發(fā)布請求的唯一性進行驗證。

發(fā)布單元603，用于在驗證單元602對信息發(fā)布請求的唯一性驗證通過后，發(fā)布待發(fā)布信息。

本申請實施例裝置的各功能模塊的功能，可以通過上述方法實施例的各步驟來實現(xiàn)，因此，本申請?zhí)峁┑难b置的具體工作過程，在此不復贅述。

本申請實施例提供的服務端，接收單元601接收客戶端發(fā)送的信息發(fā)布請求；驗證單元602根據(jù)第二標識信息，對信息發(fā)布請求的唯一性進行驗證；發(fā)布單元603在對信息發(fā)布請求的唯一性驗證通過后，發(fā)布待發(fā)布信息。也即，本申請利用了服務端的后臺冪等控制來解決表單重復提交導致表單中的信息發(fā)布多次的問題。這樣的實現(xiàn)還有一個優(yōu)點，因為服務端對第二標識信息的冪等控制是數(shù)據(jù)庫層面的，所以只要待發(fā)布信息被成功存儲到數(shù)據(jù)庫，那么后面第二標識信息相同的表單中的待發(fā)布信息都是無法重復入庫的，不存在同時并發(fā)入庫的問題，真正有效地解決了信息發(fā)布不準確的問題。

本領域技術人員應該可以意識到，在上述一個或多個示例中，本發(fā)明所描述的功能可以用硬件、軟件、固件或它們的任意組合來實現(xiàn)。當使用軟件實現(xiàn)時，可以將這些功能存儲在計算機可讀介質(zhì)中或者作為計算機可讀介質(zhì)上的一個或多個指令或代碼進行傳輸。

以上所述的具體實施方式，對本發(fā)明的目的、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本發(fā)明的具體實施方式而已，并不用于限定本發(fā)明的保護范圍，凡在本發(fā)明的技術方案的基礎之上，所做的任何修改、等同替換、改進等，均應包括在本發(fā)明的保護范圍之內(nèi)。