我正在使用Perl v5.22.1,Storable
2.53_01和IO::Uncompress::Gunzip
2.068。
我想使用Perl在内存中压缩Storable
文件,而不使用中间文件。
我有一个变量$zip_file = '/some/storable.gz'
,指向此压缩文件。
如果我直接对文件进行gunzip,这样可以正常工作,并且%root
已正确设置为Storable
哈希。
gunzip($zip_file, '/home/myusername/Programming/unzipped');
my %root = %{retrieve('/home/myusername/Programming/unzipped')};
但是,如果我像这样枪口入内存:
my $file;
gunzip($zip_file, \$file);
my %root = %{thaw($file)};
我收到错误
Storable binary image v56.115 more recent than I am (v2.10)`
所以Storable的神奇数字已经被屠杀:它应该永远不会那么高。
但是,解压缩缓冲区中的字符串仍然是正确的;缓冲区以pst
开头,这是正确的Storable
标头。它似乎只是像整数这样的多字节变量被破坏了。
这是否与字节排序有关,这样在写入文件缓冲区时,写入文件的工作方式是另一种方式吗?如何在不破坏整数的情况下将其压缩到缓冲区?
答案 0 :(得分:3)
这与解压缩无关,而是与retrieve
与thaw
相关。他们都期望不同的输入,即thaw
期望freeze
的输出,而retrieve
期望store
的输出。
这可以通过简单的测试来验证:
$ perl -MStorable -e 'my $x = {}; store($x,q[file.store])'
$ perl -MStorable=freeze -e 'my $x = {}; print freeze($x)' > file.freeze
在我的机器上,这为store
创建的文件和freeze
创建的20个字节提供24个字节。如果我从file.store
中删除前4个字节,则该文件等同于file.freeze
,即存储刚刚添加了4个字节的标头。因此,您可能尝试解压缩内存中的文件,删除前4个字节并在其余部分上运行thaw
。