Now I see what you mean. Is fits in one byte. But perl uses 2 bytes for it (because this is not ASCII but rather german umlaute):
use Devel::Peek;
use bytes;
$c = pack ("U", 0xfc);
print Dump($c);
print length($c);
Output:
SV = PV(0x15d559c) at 0x1a45848
REFCNT = 1
FLAGS = (POK,pPOK,UTF8)
PV = 0x15dd39c "\303\274"\0 [UTF8 "\x{fc}"]
CUR = 2
LEN = 3
2
But it seems that representing it as \x{fc} doesn't work, as somebody else already noticed.
| [reply]
[d/l]
[select] |
| [reply] |
Perl is supposed to treat 0xFC as a single byte.
No it's not. There are actually basically two different encodings for the same character: As one byte "\xFC" (ISO-Latin-1 string), and as 2 UTF-8 bytes, "\xC3\xBC" (UTF-8 string). That's one of the most annoying things about Perl's "smart" automatic UTF-8 processing: that it occasionally does the wrong thing, i.e. not what you mean, and that you're left to pick up the pieces.
These strings are actually marked as different, internally: the latter will have the UTF-8 flag set, the former, not. Perl can turn the former into the latter by joining it with a UTF-8 marked string. I'm not totally convinced that is something to cheer at. But anyway: it may even be a zero length string.
$x = "\xFC"; # ISO-Latin-1: 1 byte
$x .= pack 'U0'; # append a zero length UTF-8 string
# which will turn the whole thing into UTF-8!
# hex dump:
local($\, $,) = ("\n", " ");
print map { sprintf "%02X", $_ } unpack 'C*', $x;
Result:
C3 BC
Using tricks like these, one can force perl into submission, even without use bytes (works even for pre 5.8 perls):
$l1 = pack 'C0a*', $s; # copies the bytes out of $s and marks the r
+esult as non-UTF-8
$u8 = pack 'U0a*', $s; # copies the bytes out of $s and marks the r
+esult as UTF-8 -- even if the bytes don't form proper UTF-8 strings!
| [reply]
[d/l]
[select] |
I agree. I thought that written as \x{fc} would get "special treatment".
A determined individual can write garbage code in any language. -- Alan Holub
| [reply] |