大数据集的编码方案

Question

假设有一个安全传输层可以安全地传输文件，那么如果我们想在一轮中通过这个通道传输多个文件呢？那么，它应该被编码到同一个文件中，所以当Bob接收到该文件时，它能够解码并看到多个文件(例如相册)。我认为ASN.1对小数据集(例如文本证书)很好，但是在大数据集中，这样的编码方案可以增加密文大小。

我的问题是，对于大型数据集，您推荐什么样的编码规则？它必须是安全(审核好了才能被免费利用)和有效的(不要大规模增加规模)

Answer 1

ASN.1实际上是一种有效的编码。如果您查看一个长字节序列(一个OCTET STRING)的DER编码，您将看到如下内容：

04 [len] [the data bytes]

其中04是单个字节值，而len是以合理紧凑的格式表示的数据的长度。然后，数据字节如下所示。长度为n字节的长流的开销是2+ceil(log2(n)/8)字节；换句话说，对于高达256 to的流，开销最多为8个字节。

DER的一个奇怪之处是，在开始对数据进行编码之前，您必须知道数据的总长度。然而，柏尔编码(其中DER只是一个子集)可以拯救它:一个值可以被分割成连续的块，而不需要预先定义块的数量。每个块的开销将是最小的(例如，块高达64千字节的4字节)，使总开销小于0.01%。你会有困难做得更好。

如果您想将这个大流分成几个内部“文件”，那么您将需要一些约定，而且ASN.1也是有效的：

BigStream ::= SEQUENCE OF SEQUENCE {
        fileName    UTF8String,
        fileData    OCTET STRING
}

SEQUENCE OF的一个通用头(小于8个字节)；然后，对于每个文件，如果使用DER，数据本身和名称( UTF-8字符串)之外的开销将小于20个字节(通常要少得多)。对于长度不容易预先计算的大型文件，可以使用BER编码，开销可以降低到0.01%，如前所述。

如果您的大小不足，而且数据是“正常数据”(具有某种结构)，请考虑应用压缩。大多数编程框架都可以使用zlib，或者已经提供了与zlib兼容的实现(例如，Java和C#/.NET都有)。

至于审核，这不是编码问题，而是实现问题。ASN.1/BER编码可以在几行代码中实现，特别是如果您只对OCTET STRING、UTF8String和SEQUENCE感兴趣的话。我们在这里讨论的注释少于1000行的Java或C#；如果不能审计，那么就不能审计任何内容。