从1D条形码中读取的键值对的有效压缩和表示



我目前正在为Windows Mobile编写一个应用程序,需要能够从1D条形码(配置设置)中拾取键值对。扫描的条形码越少越好。样例输入:

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

我想到了下面的算法:

1。连接键值对并使用Base64

对值进行编码

我们会得到12=U8O2bWUgVVRGLTggU3Ryw65uZw==&9=JiBhbm90aGVyIHN0cmluZw==

2。使用Huffman编码压缩数据

我将使用一个固定的霍夫曼树,与以下信息,帮助我压缩数据:

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

3。从编码数据生成Code 128B条形码

将Base96编码应用于由霍夫曼算法生成的位流,以获得可在code128b条形码内使用的ASCII字符。根据需要将结果字符串拆分为多个条形码。

编码这些步骤对我来说不是问题,但是我想得到一些关于算法的效率和设计的反馈。

  • 我是否在某个地方失去了一些更好的压缩/更短字符串的潜力?
  • 是否有更好的方法来压缩随机UTF8编码数据?
  • 我应该嵌入一个动态霍夫曼表到编码的数据?
  • 我怎么能考虑到代码128B的压缩(0需要比&更少的空间)?

一个简单的方法是定义所有64个字符直接映射到code128。这将留下30-40个可用的代码128插槽。在剩下的槽中定义一些双字符。= = =,0= 1= 2= 3= 4= 5= 6= 7= 8= 9= &0 &1 &2 &2 &5 &5 &6 &7 &8 &9(重复最后一个字符)= =(两个下一个字符)&(两个下一个字符)

经过多次尝试和摆弄,我们最终选择了这种方法:

1。将设置编码为字节流

字段值被序列化成字节流,每个字段都有一个头。报头消耗一个字节,包含字段的ID和一些有助于减少传输数据量的标志。根据字段的类型(例如字符串,数字或IP地址),该值被有效地编码到字节流中。例如,IP地址用4字节编码,而布尔标志则直接编码到字段报头中。这样,如果需要的话,我们甚至可以将SSL证书编码到流中。由于典型的条形码格式不能传输任意字节值,因此我们需要在下一步对字节流进行编码。

2。转换为条形码格式

生成的字节数组现在被视为一个大整数,并使用基本编码和字符集转换为目标条形码格式(参见这个问题)。这样,我们就可以有效地使用条形码格式来传输数据(与Base64或其他编码相比)。从结果字符串中,我们可以将单个条形码块并添加一些额外的标题信息(例如,需要扫描多少条形码?数据是否加密?…).

当条形码在移动设备上被扫描时,编码字符串可以被还原并转换为相同的大整数。然后可以将此整数视为字节数组,当字段序列化格式已知时可以对其进行解析。

这种方法被证明是非常高效和快速的(我们对CF上的BigInteger实现有些担忧)。

虽然一些条形码格式具有固定的字符集,它们可以表示并使用相同数量的空间来容纳每个字符,但其他条形码格式要么使用多个字符集,要么使用可变数量的空间来容纳每个字符。例如,"经典"代码39定义了43个字符,每个字符由43个符号中的一个表示,并且根本不能表示任何其他字符,但是存在另一个代码39变体,它使用一个符号表示39个常见字符,其他字符使用两个字符序列。例如,假设想要在code-39条形码中存储一堆二进制数据。如果将数据转换为base-64格式,则与三个八位字节的原始数据相关的四个字符可能平均需要大约5.69个符号来存储[base64中使用的64个字符中约有27个需要两个符号来存储在code39中]。如果选择32个字符,每个字符可以用一个符号表示,则可以使用5个八位元组存储24(或25)位,每个八位元组存储5位[一致的是每个八位元组存储1.67个符号,而不是平均1.89个,最坏的情况是2.67个]。如果使用"经典"代码39(每个符号可以表示43个字符),甚至可以在6个符号中存储4个八位组[平均每个八位组1.5个符号]。

不同的条码格式针对不同的字符集进行了"优化";像Code 128这样的代码有多个字符集,可以有效地处理使用一个字符集的全部范围的数据,同时避免使用该字符集以外的字符。我不知道有什么特别推荐的方法来重新格式化数据,以便优化特定符号集的使用,但是检查符号集使用的编码和您的特定需求应该有助于您找出哪种编码最适合您的应用程序。

相关内容

  • 没有找到相关文章

最新更新