【发布时间】:2016-12-16 12:02:38
【问题描述】:
我将哈希存储在这样的脚本中(部分代码省略):
use strict;
use warnings;
use utf8;
use Storable qw(nstore_fd);
open( my $fh, ">", 'hash.hash');
my $hash_ref = \%hash;
nstore_fd($hash_ref, $fh);
close $fh;
这会创建一个文件hash.hash。然后,在另一个文件中,我尝试“导入”散列并读取其要使用的值(例如,循环散列、读取值、检查存在......)。
我尝试了一些简单的方法,即读取哈希、取消引用并读取其键,然后将其打印出来。但是我收到错误Not a HASH reference at CreateSql.pl line 12. 这是一个标量。但我不明白为什么。模块的The documentation 声明返回一个引用。
要检索存储到磁盘的数据,请使用带有文件名的retrieve。这 存储在该文件中的对象会为您重新创建到内存中,并且 返回对根对象的引用。
那么我做错了什么,如何访问存储的哈希?
use strict;
use warnings;
use utf8;
use Data::Dumper;
use Storable qw(retrieve);
my ($hash_path) = @ARGV;
my $hash_ref = retrieve($hash_path);
my @keys = keys % { $hash_ref }; # throws error
print Dumper(\@keys);
【问题讨论】:
-
我也敦促 - 不要使用 Storable 来存储东西。有些开放格式通常更好,因为它们是可移植的,例如 JSON 或 YAML。 (也许是 XML,但前提是您确实需要 XML 的功能,这对于 大多数 应用程序来说太过分了)
-
@Sobrique 存储散列的唯一目标是在另一个脚本中使用。即使在这种情况下,您认为在第一个脚本中编码为 JSON,然后在第二个脚本中以新的哈希读取 JSON 是否更好?我不太了解存储和效率,但是从速度上看,这似乎不是很有效。数据永远不会在这两个脚本之外使用,所以我认为不需要通用数据类型。考虑到脚本的效率,您怎么看?
-
除非您的数据量很大,否则它会产生微小的差异。如果您的数据很大,那么以这种方式转储数据结构无论如何都不是一个好计划。对于互操作性、支持和诊断,IMO 的人类可读选项只是出于样式原因而更好。
-
我同意@Sobrique ...虽然
Storable很棒,但我过去在不同版本的发行版中遇到过问题。JSON同样简单易用,而且它的格式是一个非常一致的标准。它也是跨语言的。此外,“数据永远不会在这两个脚本之外使用”......我总是假设相反,只是为了安全。 -
Re "但在速度方面这似乎不是很有效",我不明白为什么它不会有效。 JSON 解析起来非常简单。