RE: Why, what, where to unpack?! (was: Files, unpack and text values)

[mdillon]

i believe that a single element consisting of 'H*' is the template you are interested in.

i'm not sure if it is correct to loop on a binary file handle like that, but it certainly doesn't make much sense to me: "for each line in this binary file" is a contradiction in terms, since binary files don't have any "lines".

i don't know why your hex editor breaks strings at that interval, but it seems a little narrow for you to store it that way. i would use 36 bytes per line with no spaces, myself.

the following code works fine for me. however, i would probably use MIME::Base64 to encode the data if it were my choice. plain hex is just a little too fat for my taste.

open IMG, "foo.gif" or die "Couldn't open image: $!\n";

undef $/;
$image = <IMG>;

print unpack("H*", $image);

close IMG;

[BBQ]

You are absolutely right! That did the trick... This is what I turned up with to get it looking somewhat with my hex editors output:

open IMG, "foo.gif" or die "Couldn't open image: $!\n";

undef $/;
$image = <IMG>;

$hex = unpack("H*", $image);

close IMG;

while ($txt = substr($hex,0,32,'')) {
    $txt =~ s/(..)/$1 /g;
    print $txt."\n";
}

Now all I have to do is figure out where those extra bytes went (the results are still not exactly the same), and who's goofing up on this one. I bet you its the editor...

#!/home/bbq/bin/perl
# Trust no1!

[mdillon]

the slurp/unpack method does not lose any bytes. i checked my code's round-trip integrity with cmp(1) like so:

[mike@prometheus ~]$ perl -e 'undef $/; open IMG, "foo.gif";
print pack("H*", unpack("H*", <IMG>));' | cmp foo.gif -