從一維條形碼讀取的鍵值對的高效壓縮和表示

Question

我目前正在爲Windows Mobile編寫一個應用程序，它需要能夠從一維條形碼（配置設置）中獲取鍵值對。需要掃描的條形碼越少越好。樣品輸入：

------------------------------ 
| Key | Value    |  
------------------------------ 
| 12 | Söme UTF-8 Strîng | 
| 9 | & another string  | 
------------------------------ 

我以爲以下算法：

1的毗連的鍵值對，並與Base64編碼，值

所以我們會得到類似12=U8O2bWUgVVRGLTggU3Ryw65uZw==&9=JiBhbm90aGVyIHN0cmluZw==

2.使用霍夫曼編碼來壓縮數據

我會使用一個固定的哈夫曼樹爲此，提供以下信息，可以幫助我來壓縮數據：從編碼數據

------------------------------------------- 
| Enties      | Priority |  
------------------------------------------- 
| =, &       | High  | 
| 0-9       | Medium | 
| 5-bit Base64 Words (w/o 0-9) | Low  | 
------------------------------------------- 

3.生成代碼128B條碼

應用Base96編碼爲由Huffman算法生成的比特流以獲得可在Code 128B條形碼內使用的ASCII字符。根據需要將結果字符串拆分爲多個條形碼。

編碼這個步驟對我來說不會是一個問題，但我想對算法的效率和設計有一些反饋。

問題

• 難道我失去了一些潛在的更好的壓縮/短串的地方？
• 有沒有更好的方法來壓縮隨機的UTF8編碼數據？
• 我應該在編碼數據中嵌入一個動態霍夫曼表嗎？
• 如何考慮代碼128B的壓縮（0比&需要更少的空間）？

Answer 1

很多演奏和摸索之後，我們終於選擇這種方式：

1編碼設置成字節流

將字段值序列化爲字節流，併爲每個字段標題。標題消耗一個字節幷包含字段的ID和一些標誌，這些標誌有助於減少要傳輸的數據量。根據字段的類型（例如字符串，數字或IP地址），該值被有效地編碼到字節流中。例如，IP地址使用4個字節進行編碼，而布爾標誌則直接編碼到字段標題中。這樣，如果需要，我們甚至可以將SSL證書編碼到流中。由於典型的條形碼格式不能傳輸任意字節值，因此我們需要在下一步中對字節流進行編碼。

2.轉換爲條形碼格式

所得字節數組現在被視爲一個大的，大的整數，並轉換成使用鹼編碼和一個charset（見this question）目標條形碼格式。這樣，我們有效地使用條形碼格式來傳輸我們的數據（與Base64或其他編碼相比）。從結果字符串中，我們可以獲得大量的單個條形碼，併爲它們添加一些額外的標題信息（例如，需要掃描多少條形碼？數據是否被加密？......）。

當條形碼掃描獲得在移動設備上，已編碼的字符串可以被恢復並轉換成相同的，大的整數。然後可以將此整數視爲一個字節數組，可以在字段序列化格式已知時進行解析。

這種方法被證明是非常有效和快速（我們有關於BigInteger implementation上CF一些問題）。

Answer 2

一個簡單的方法是定義直接映射到code128的所有64個字符。這會留下30-40個可用的代碼128個插槽。在其餘的插槽中定義一些雙字符。 == = & 0 = 1 = 2 = 3 = 4 = 5 = 6 = 7 = 8 = 9 = 9（重複最後一個字符）= =（雙下一個字符）&（雙下一個字符）

Answer 3

雖然一些條碼格式有一組固定的，他們可以表示，並使用相同的空間量，以保持每個字符，其他人既可以使用多個字符集，或者使用不同量的空間來容納每個字符的字符。例如，「經典」代碼39定義了43個字符，每個字符由43個符號中的一個代表，並且不能代表任何其他字符，但是還有另一個代碼39變體代表39個使用一個符號的常用字符，以及其他字符雙字符序列。例如，假設有人想將一串二進制數據存儲在代碼39的條形碼中。如果將數據轉換爲base-64格式，與三個八位字節的原始數據關聯的四個字符可能需要平均約5.69個符號才能存儲[base64中使用的64個字符中的大約27個需要兩個符號來存儲在code39]。如果一個替代選擇32個字符，可通過一個碼元的每個來表示，一個可以存儲使用五個八位字節來存儲每個五個比特[每八位位組一致的1.67的符號24（或25）個比特，相對於平均的1.89和2.67最壞的情況下]。如果使用「經典」代碼39（其可以代表43個字符，每個代碼使用一個符號），則甚至可以在六個符號中存儲四個八位字節[每個八位字節的平均1.5個符號]。

不同條形碼格式「優化」爲不同的字符集;一些像Code 128一樣有多個字符集，並且可以有效地利用使用全部字符集的數據的數據，同時避免使用字符集外的字符。我不知道任何特定的推薦辦法重新格式化數據，從而優化使用的特定符號的字符集，但檢查由一個符號所使用的編碼和您的特定需求應該可以幫助你找出什麼編碼將工作最適合你應用。