我需要解压缩嵌入在xlsx文件中的数据模型文件。该文件应该使用MS-XLDM文件格式，并且应包含3个部分（电子表格数据模型标题，文件和虚拟目录），并且只有中间部分被压缩。第一部分和最后一部分是使用unicode / utf-16编码的xml（每个其他字节为0x00，其内容之前为0xFF和0xFE）。中间文件之前是一小段xml。 More detail about the file structure.
现在，根据documentation，应使用指定的here Xpress压缩来压缩文件，该压缩使用LZ77压缩和DIRECT2编码。
现在要点了。根据我的理解，应该始终有一个4字节的位掩码，该掩码指示相应位置的字节是1：1数据还是元数据。
例如，给定一个假设的8位掩码，字符串“ ABCABCDEF”被压缩为（0,0）A（0,0）B（0,0）C（3,3）D（0,0 ）E（0,0）F。它的位掩码为b'00010001'（0x11）。
如果给定位置应该是元数据，则至少应读取2个字节。在这16位中，前13位是偏移量，后3位是长度（除非最后一位为1，则必须读取另一个字节）。
因此，现在来看我所奋斗的具体示例。前两个块很容易。
第一个是：
....<Load xmlns="http://schemas.micr
前4个字节（点）为0x00，因此后面的32个字节未压缩。下一块相似：
....osoft.com/analysisservices/2003/
现在第三块是我迷路的地方
w±engine":ddl27/"/2G_W?%g100gO8eðg_‡_)§è.Õ®]›‡o
我不确定该块到底在哪里结束，因为一段时间后我开始计算那些第一个字节之后的每36个字节时，我会到达该字节流的一部分，该字节流应该被解压缩并且没有对齐。
回到第三块。该位的掩码为 0x77 0xB1 0x04 0x01 。
或二进制 01110111 10110001 00000100 00000001 。我试图将其与字节对齐，这没有任何意义。显然，“引擎”一词是未压缩的，并且适合于先前的代码块，因为谷歌的快速搜索向我显示了名称空间为“ http://schemas.microsoft.com/analysisservices/2003/engine”的结果。
01110111 10110001 00000100 00000001
engine" :ddl27 /"/2G_W ?%g100gO8eðg_‡_)
这使我认为，如果位掩码的顺序相反，则可能是字节。这对我来说更有意义。
00000001
engine"
如果是这样，则元数据应为 0x0B 0x02 。
或二进制 00001011 00000010 。因此，如果我将其拆分，则前13位将构成元数据的偏移量。长度为010 + constant offset 3 = 2 + 3 = 5。
Before 0000101100000
Invert 1111010011111
Decimal -353
但是向后看353个字节，它会落在未压缩的分区xml部分中，并应返回括号中的字符（上午）。这对我来说没有意义，可能是错误的。
这是我尝试解压缩的file。