Please reread my note. The problem is that the *A APIs are used, RegOpenKeyExA() not RegOpenKeyExW(). It is simply a limitation that only 8-bit characters are supported by these Microsoft APIs. The problem has nothing to do with Perl or the Perl modules, except in that those modules choose to use the *A APIs. The error you get is exactly as expected given how the *A APIs work.
Switching Win32::TieRegistry to support the *W APIs would be quite a bit of work, would add conversion overhead quite a few places, and would need to only be done optionally (due to overhead and because I don't trust Perl to prevent people from noticing that they are suddenly getting UTF-8 strings instead of 8-bit strings).
From what you've written, it sounds like you don't have a real need for this functionality anyway, it just being a limitation that you discovered more out of curiosity than pressing need. I've seen no other requests for supporting out-of-locale characters in Win32::TieRegistry to date. That doesn't mean it shouldn't be done or that it won't be done, it just affects what priority I'm likely to assign to it.
Win32API::Registry already supports the *W APIs, but you'll have to do some extra work, as I noted. pack and unpack should handle it, if you've got a version of Perl that supports Unicode well. Probably:
my $utf8 = pack "U*", unpack "S*", $ucs16; my $ucs16 = pack "S*", unpack( "U*", $utf8 ), 0;
Except you'll probably need to chop the "\0" of the end of $utf8 after that first line. But I haven't tested any of that code.
- tye
In reply to Re^3: possible perl bug or, at least, Win32::[TieRegistry|Registry] bug with difficult keynames (limitation)
by tye
in thread possible perl bug or, at least, Win32::[TieRegistry|Registry] bug with difficult keynames
by perl-diddler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |