in reply to utf-8 keys in a tied hash cause warning

Following up on the earlier replies, if I supplement the OP code like so: 
use Encode;

my $utf8key = "\x{05D0}";
my $usable_key = encode( 'utf8', $utf8key );

dbmopen(my %hash, "/tmp/mydb", 0666) || die "d'oh!";
$hash{$usable_key} = "bar";
dbmclose(%hash);

[download]
I don't get the warning message. I also noticed some differences in the content of the resulting dbm file -- the OP version had null bytes where the 'encoded' version had non-null bytes, suggesting that the warning issued by the OP version reflects an actual failure to store the data.

Having to encode the hash keys like this is certainly a PITA (a minor one, but still). Perhaps the maintainer(s) the various *DBM_File modules can be persuaded to update them so as to handle this properly -- easy enough to do, I'd expect.

Replies are listed 'Best First'.
Re^2: utf-8 keys in a tied hash cause warning
by ikegami (Patriarch) on Aug 04, 2006 at 04:32 UTC
    I don't get the warning message

    It's not a warning. It's a fatal error. It was added to newer versions of Perl.

    I also noticed some differences in the content of the resulting dbm file

    Not here. 5.8.0 with Encode, 5.8.0 without Encode and 5.8.8 with Encode output: 

    0000: 02 00 FE 03 FB 03 00 00 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
03D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
03F0: 00 00 00 00 00 00 00 00 00 00 00 62 61 72 D7 90

    [download]

    Since strings of chars are stored internally as UTF-8, the resulting file is indentical.

[reply]
[d/l]
Re^2: utf-8 keys in a tied hash cause warning
by Anonymous Monk on Aug 04, 2006 at 09:56 UTC
    dbmopen is obsolete.
[reply]
      It doesn't matter if you use dbmopen or tie in this scenario, the problem seems to lie in the storage engine(s) used by these functions.
[reply]

In Section Seekers of Perl Wisdom