【问题标题】:Compression Plus data format?Compression Plus 数据格式?
【发布时间】:2021-02-05 21:12:04
【问题描述】:

我收到了一个数据库,其格式可以追溯到 1990 年代,显然是在迁移到 SQL Server 之前首先创建为 MDB 格式。没问题,除了一件事......许多表的列包含 20 年数据的月度数据,每月一个双倍/浮点数。字段中的数据已“压缩”并存储为十六进制字符串。

有一个不再运行的相关应用程序,但有助于解决有关缺少 DLL CompPl32.dll 的错误。来自一家名为 EllTech 的公司的 it appears this was a 1996 compression library,早已不复存在。虽然 DLL 可供下载,但我宁愿避免使用它。是否有人熟悉该格式并对如何解压缩它有建议?这是数据库中的数据示例:

CompressedLen  UncompressedLen  Data
18             3080             EDC08100000000C2B0FCA903F936000020E70000

如果相信 18 位,那么前 32 位不是数据的一部分。每个字段的前两个字符都是“ED”。

【问题讨论】:

  • 将 3080 字节的数据压缩到 18 字节似乎不太可信,除非它可能有大量重复
  • “十六进制字符串”可能是 varbinary 列。将某些内容存储为十六进制字符串需要一个字节并将其转换为两个字符,因此无助于节省空间。
  • Compression Plus 是用于处理 .arj、.lha 和 .zip 文件的实用程序,因此不太可能使用在 PKZIP 2.04G 之后创建的任何高级算法。我知道这不是很有帮助,但至少限制了搜索可能的解压缩例程的范围。
  • @MartinSmith 确实,原来是 3080 个零字节压缩成 18 个字节。
  • @MartinSmith - 大多数数据非常稀少,通常 90% 的条目都是零。

标签: .net sql-server compression


【解决方案1】:

似乎压缩数据只是原始的放气,其中二进制数据以十六进制编码。实际上,将十六进制转换为二进制后的前 18 个字节是一个有效且完整的原始 deflate 流,它会解压缩为 3080 个字节。特别是全为零的 3080 个字节。

您可以使用DeflateStream class 解压缩原始deflate 数据。

我不知道为什么在 18 个字节的 deflate 数据之后有两个无关的零字节。也许他们觉得有必要将其四舍五入。

【讨论】:

  • 出色的工作马克,我现在要编写代码了。
猜你喜欢
  • 2019-04-22
  • 2016-08-28
  • 1970-01-01
  • 2011-08-11
  • 2011-01-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-12-22
相关资源
最近更新 更多