It seems to depend on whether chr(0), chr(1), and chr(2) are in your string. I'm guessing those are used as "magic" during the tr?
In any case, try these tests:
It also appears that if you use more characters in the left hand side of the tr///, more of the "low byte values" become magical.$_ = join '', map chr(), 1 .. 0x1f; tr [\3\5\7] [\10\10\10]cd; print join('', map sprintf("\\%o",ord), split //), $/; # prints \10\10\3\5\7 $_ = join '', map chr(), 2 .. 0x1f; tr [\3\5\7] [\10\10\10]cd; print join('', map sprintf("\\%o",ord), split //), $/; # prints \10\3\5\7 $_ = join '', map chr(), 3 .. 0x1f; tr [\3\5\7] [\10\10\10]cd; print join('', map sprintf("\\%o",ord), split //), $/; # prints \3\5\7 $_ = join '', reverse map chr(), 0,0,0,1,0,1,0,1,0 .. 0xA; tr [\3\5\7] [\10\10\10]cd; print join('', map sprintf("\\%o",ord), split //), $/; #prints \7\5\3\10\10\10\10\10\10\10\10\10\10\10
Sorry I can't tell you WHY it happens, but I hope this helps...
--
Mike
In reply to Re: Inconsistent transliteration for non-printing octets
by RMGir
in thread Inconsistent transliteration for non-printing octets
by diotalevi
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |