The last time I checked, nothing needs to be done to a scalar variable containing a string of digit characters in order for it to be treated as an integer. The fact that it is made up of digits means that it will be interpreted as a numeric value in any sort of numeric context -- while still being used as a string in any string context. Run this snippet and see what you get:

$data = '01142000';
print "$data + 1 = ", $data + 1, $/;
print "$data / 2 = ", $data / 2, $/;
print "sqrt($data) = ", sqrt( $data ), $/;
[download]

The cases where you really need unpack (and pack) tend to be hard to explain... and builtins like "ord()", "chr()", "hex()" and so on tend to provide the most common functions that (un)pack might be used for -- and in much clearer terms.

BTW, I think the integer formats you were trying (I7,i7, L7,l7) are supposed to tell unpack that the scalar data being passed to it should contain seven binary "int" (i/I) or "long int" (l/L) values -- these would be either 16- and 32-bit values or 32- and 64-bit values (or 32- and 32-bit values), depending on your system (and maybe depending on how your perl interpreter was compiled for your system). So, it would have tried to read 7*2=14 bytes (16-bit i/I) or 7*4=28 bytes (32-bit i/I or l/L) or 7*8=56 bytes (64-bit l/L) from $data. But you only fed it a scalar containing 8 bytes. Whatever it ended up doing, at least it did the same thing consistently for these cases.

To top it off, of course, the perldoc descriptions for of pack and unpack are undeniable the hardest to grasp. Don't feel bad if you don't grok it, even after working through your own experiments with it.

(update: fixed a couple typos)