Here's what use diagnostics has to say about that:

(W utf8) Perl met a wide character (>255) when it wasn't expecting one. This warning is by default on for I/O (like print). The easiest way to quiet this warning is simply to add the :utf8 layer to the output, e.g. binmode STDOUT, ':utf8'. Another way to turn off the warning is to add no warnings 'utf8'; but that is often closer to cheating. In general, you are supposed to explicitly mark the filehandle with an encoding, see open and perlfunc/binmode.

Hope that helps!

It's not the fault of tied hashes.

use Tie::Hash qw( );
our @ISA = 'Tie::StdHash';

sub STORE {
   my ($self, $key, $val) = @_;
   print($key eq "\x{05D0}" ? "utf" : "not utf", "\n");
   return $self->SUPER::STORE($key, $val);
}

my %h;
tie %h, __PACKAGE__;
$h{"\x{05D0}"} = 1;   # Prints 'utf' in 5.8.6

dbm probably doesn't support unicode keys. The workaround is to encode your strings of chars into strings of bytes. UTF-8 is probably the best suited encoding.

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);

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.