[發明專利]數據處理方法及數據處理裝置

有效

• 申請號: 201410446836.4
• 申請日: 2014-09-03
• 公開（公告）號: CN104199927B
• 公開（公告）日: 2016-11-30
• 發明（設計）人: 卜祥坤
• 申請（專利權）人: 騰訊科技（深圳）有限公司
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 廣州華進聯合專利商標代理有限公司 44224
• 代理人: 黃曉慶;王茹

技術領域

本發明涉及數據處理領域，特別涉及一種數據處理方法及數據處理裝置。

背景技術

目前在涉及不同設備之間的信息交互時，例如客戶端與服務器之間的交互，需要對待傳輸的數據按照規定的協議進行編碼后進行傳輸，目前關于協議報文的編碼定義主要有XML(可擴展標記語言，Extensible?Markup?Language)、JSON(JavaScript?Object?Notation)、Protocol?Buffers(、一種數據描述語言)和數據結構體(使用C&C++語言中結構體定義的數據塊，用struct定義)等幾種。

在使用XML進行數據交互時，比較方便調試，但是服務器和客戶端都需要花費很多代碼去解析XML，從而在代碼量提升的同時，不論是服務器還是客戶端，維護都會變得比較困難。Json數據格式與XML相比，易于讀寫，并且有公開各種語言的解析庫用于讀取，但是在交互頻繁的場景，例如游戲過程中，Json使用文本來傳輸比較容易被破解并且協議包也不是最優。Protobuf使用鍵值對的方式來保存數據，在多次重復出現同一數據的時候，用于表示類型和長度的鍵值可能會比本身要傳遞的數據都要大，極大的占用存儲量。Struct使用的是最基本的結構體來傳輸，客戶端與服務器使用相同的結構體，把傳遞的數據流轉換為結構體來使用，這樣看來最簡單直接，但是遇到變長數據的時候必須要考慮最大的長度，也就是說每次都必須采用最大長度來發送協議，不僅占用較多的存儲量，數據傳輸時也會占用較多的帶寬。

發明內容

基于此，本發明的目的在于提供一種數據處理方法及一種數據處理裝置，其可以減少存儲時占用的存儲空間，在進行傳輸時也可以減少對帶寬的占用。

為達到上述目的，本發明實施例采用以下技術方案：

一種數據處理方法，包括步驟：

獲取待處理數據包；

讀取所述待處理數據包中的數據；

根據所述數據的數據類型，采用預設數據轉換方式對所述數據進行轉換，獲得轉換后數據；

采用預設字節編碼方式對所述轉換后數據進行編碼，得到編碼后數據，并將該編碼后數據序列化存儲。

一種數據處理裝置，包括：

數據包獲取模塊，用于獲取待處理數據包；

數據讀取模塊，用于讀取所述待處理數據包中的數據；

數據類型確定模塊，用于確定所述數據讀取模塊所讀取數據的數據類型；

轉換模塊，用于根據所述數據類型，采用預設數據轉換方式對所述數據進行轉換，獲得轉換后數據；

編碼模塊，用于采用預設字節編碼方式對所述轉換模塊得到的轉換后數據進行編碼，得到編碼后數據；

存儲控制模塊，用于將所述編碼后數據序列化存儲。

根據上述本發明實施例的方案，其在對數據進行處理時，是基于數據類型的不同，進行相應的轉換后采用預設字節編碼方式進行編碼，并對編碼后數據進行序列化存儲，其按照緊密結構來序列化，從而減少了保存相同數據時所占用的存儲空間，在進行傳輸是也可以減少對帶寬的占用。

附圖說明

圖1是一個實施例中的本發明方案的工作環境示意圖；

圖2是一個實施例中終端的組成結構示意圖；

圖3是一個實施例中的數據處理方法的流程示意圖；

圖4是一個具體示例中的數據處理方法的流程示意圖；

圖5是一個實施例中包含子數據包時的數據處理方法的流程示意圖；

圖6是一個具體示例中確定待處理數據的長度的流程示意圖；

圖7是一個實施例中的逆向解析數據的流程示意圖；

圖8是一個實施例中的數據處理裝置的結構示意圖。

具體實施方式

為使本發明的目的、技術方案及優點更加清楚明白，以下結合附圖及實施例，對本發明進行進一步的詳細說明。應當理解，此處所描述的具體實施方式僅僅用以解釋本發明，并不限定本發明的保護范圍。

本發明方案提供的數據處理方法和數據處理裝置，可以應用于任何一個終端設備，以實現對數據的存儲，同時也可以用于不同設備之間的信息交互，例如網絡游戲。以應用于用戶終端與服務器之間的交互為例，圖1示出了一個實施例中的工作環境示意圖。該工作環境所在系統包括用戶終端和服務器，用戶終端、服務器通過網絡連接，用戶終端與服務器之間交互的數據通過網絡進行傳輸，這里的網絡可以是無線網絡，也可以是有線網絡。結合圖1所示，本發明實施例的方案涉及用戶終端和服務器對需要存儲、以及需要發送給對方的數據的處理。