perlpacktut.pod

来自「视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.」· POD 代码 · 共 1,222 行 · 第 1/4 页

Packing and unpacking numbers implies conversion to and from some
I<specific> binary representation. Leaving floating point numbers
aside for the moment, the salient properties of any such representation
are:

=over 4

=item *

the number of bytes used for storing the integer,

=item *

whether the contents are interpreted as a signed or unsigned number,

=item *

the byte ordering: whether the first byte is the least or most
significant byte (or: little-endian or big-endian, respectively).

=back

So, for instance, to pack 20302 to a signed 16 bit integer in your
computer's representation you write

   my $ps = pack( 's', 20302 );

Again, the result is a string, now containing 2 bytes. If you print 
this string (which is, generally, not recommended) you might see
C<ON> or C<NO> (depending on your system's byte ordering) - or something
entirely different if your computer doesn't use ASCII character encoding.
Unpacking C<$ps> with the same template returns the original integer value:

   my( $s ) = unpack( 's', $ps );

This is true for all numeric template codes. But don't expect miracles:
if the packed value exceeds the allotted byte capacity, high order bits
are silently discarded, and unpack certainly won't be able to pull them
back out of some magic hat. And, when you pack using a signed template
code such as C<s>, an excess value may result in the sign bit
getting set, and unpacking this will smartly return a negative value.

16 bits won't get you too far with integers, but there is C<l> and C<L>
for signed and unsigned 32-bit integers. And if this is not enough and
your system supports 64 bit integers you can push the limits much closer
to infinity with pack codes C<q> and C<Q>. A notable exception is provided
by pack codes C<i> and C<I> for signed and unsigned integers of the 
"local custom" variety: Such an integer will take up as many bytes as
a local C compiler returns for C<sizeof(int)>, but it'll use I<at least>
32 bits.

Each of the integer pack codes C<sSlLqQ> results in a fixed number of bytes,
no matter where you execute your program. This may be useful for some 
applications, but it does not provide for a portable way to pass data 
structures between Perl and C programs (bound to happen when you call 
XS extensions or the Perl function C<syscall>), or when you read or
write binary files. What you'll need in this case are template codes that
depend on what your local C compiler compiles when you code C<short> or
C<unsigned long>, for instance. These codes and their corresponding
byte lengths are shown in the table below.  Since the C standard leaves
much leeway with respect to the relative sizes of these data types, actual
values may vary, and that's why the values are given as expressions in
C and Perl. (If you'd like to use values from C<%Config> in your program
you have to import it with C<use Config>.)

   signed unsigned  byte length in C   byte length in Perl       
     s!     S!      sizeof(short)      $Config{shortsize}
     i!     I!      sizeof(int)        $Config{intsize}
     l!     L!      sizeof(long)       $Config{longsize}
     q!     Q!      sizeof(long long)  $Config{longlongsize}

The C<i!> and C<I!> codes aren't different from C<i> and C<I>; they are
tolerated for completeness' sake.


=head2 Unpacking a Stack Frame

Requesting a particular byte ordering may be necessary when you work with
binary data coming from some specific architecture whereas your program could
run on a totally different system. As an example, assume you have 24 bytes
containing a stack frame as it happens on an Intel 8086:

      +---------+        +----+----+               +---------+
 TOS: |   IP    |  TOS+4:| FL | FH | FLAGS  TOS+14:|   SI    |
      +---------+        +----+----+               +---------+
      |   CS    |        | AL | AH | AX            |   DI    |
      +---------+        +----+----+               +---------+
                         | BL | BH | BX            |   BP    |
                         +----+----+               +---------+
                         | CL | CH | CX            |   DS    |
                         +----+----+               +---------+
                         | DL | DH | DX            |   ES    |
                         +----+----+               +---------+

First, we note that this time-honored 16-bit CPU uses little-endian order,
and that's why the low order byte is stored at the lower address. To
unpack such a (unsigned) short we'll have to use code C<v>. A repeat
count unpacks all 12 shorts:

   my( $ip, $cs, $flags, $ax, $bx, $cd, $dx, $si, $di, $bp, $ds, $es ) =
     unpack( 'v12', $frame );

Alternatively, we could have used C<C> to unpack the individually
accessible byte registers FL, FH, AL, AH, etc.:

   my( $fl, $fh, $al, $ah, $bl, $bh, $cl, $ch, $dl, $dh ) =
     unpack( 'C10', substr( $frame, 4, 10 ) );

It would be nice if we could do this in one fell swoop: unpack a short,
back up a little, and then unpack 2 bytes. Since Perl I<is> nice, it
proffers the template code C<X> to back up one byte. Putting this all
together, we may now write:

   my( $ip, $cs,
       $flags,$fl,$fh,
       $ax,$al,$ah, $bx,$bl,$bh, $cx,$cl,$ch, $dx,$dl,$dh, 
       $si, $di, $bp, $ds, $es ) =
   unpack( 'v2' . ('vXXCC' x 5) . 'v5', $frame );

(The clumsy construction of the template can be avoided - just read on!)  

We've taken some pains to construct the template so that it matches
the contents of our frame buffer. Otherwise we'd either get undefined values,
or C<unpack> could not unpack all. If C<pack> runs out of items, it will
supply null strings (which are coerced into zeroes whenever the pack code
says so).


=head2 How to Eat an Egg on a Net

The pack code for big-endian (high order byte at the lowest address) is
C<n> for 16 bit and C<N> for 32 bit integers. You use these codes
if you know that your data comes from a compliant architecture, but,
surprisingly enough, you should also use these pack codes if you
exchange binary data, across the network, with some system that you
know next to nothing about. The simple reason is that this
order has been chosen as the I<network order>, and all standard-fearing
programs ought to follow this convention. (This is, of course, a stern
backing for one of the Lilliputian parties and may well influence the
political development there.) So, if the protocol expects you to send
a message by sending the length first, followed by just so many bytes,
you could write:

   my $buf = pack( 'N', length( $msg ) ) . $msg;

or even:

   my $buf = pack( 'NA*', length( $msg ), $msg );

and pass C<$buf> to your send routine. Some protocols demand that the
count should include the length of the count itself: then just add 4
to the data length. (But make sure to read L<"Lengths and Widths"> before
you really code this!)


=head2 Byte-order modifiers

In the previous sections we've learned how to use C<n>, C<N>, C<v> and
C<V> to pack and unpack integers with big- or little-endian byte-order.
While this is nice, it's still rather limited because it leaves out all
kinds of signed integers as well as 64-bit integers. For example, if you
wanted to unpack a sequence of signed big-endian 16-bit integers in a
platform-independent way, you would have to write:

   my @data = unpack 's*', pack 'S*', unpack 'n*', $buf;

This is ugly. As of Perl 5.9.2, there's a much nicer way to express your
desire for a certain byte-order: the C<E<gt>> and C<E<lt>> modifiers.
C<E<gt>> is the big-endian modifier, while C<E<lt>> is the little-endian
modifier. Using them, we could rewrite the above code as:

   my @data = unpack 's>*', $buf;

As you can see, the "big end" of the arrow touches the C<s>, which is a
nice way to remember that C<E<gt>> is the big-endian modifier. The same
obviously works for C<E<lt>>, where the "little end" touches the code.

You will probably find these modifiers even more useful if you have
to deal with big- or little-endian C structures. Be sure to read
L<"Packing and Unpacking C Structures"> for more on that.


=head2 Floating point Numbers

For packing floating point numbers you have the choice between the
pack codes C<f>, C<d>, C<F> and C<D>. C<f> and C<d> pack into (or unpack
from) single-precision or double-precision representation as it is provided
by your system. If your systems supports it, C<D> can be used to pack and
unpack extended-precision floating point values (C<long double>), which
can offer even more resolution than C<f> or C<d>. C<F> packs an C<NV>,
which is the floating point type used by Perl internally. (There
is no such thing as a network representation for reals, so if you want
to send your real numbers across computer boundaries, you'd better stick
to ASCII representation, unless you're absolutely sure what's on the other
end of the line. For the even more adventuresome, you can use the byte-order
modifiers from the previous section also on floating point codes.)



=head1 Exotic Templates


=head2 Bit Strings

Bits are the atoms in the memory world. Access to individual bits may
have to be used either as a last resort or because it is the most
convenient way to handle your data. Bit string (un)packing converts
between strings containing a series of C<0> and C<1> characters and
a sequence of bytes each containing a group of 8 bits. This is almost
as simple as it sounds, except that there are two ways the contents of
a byte may be written as a bit string. Let's have a look at an annotated
byte:

     7 6 5 4 3 2 1 0
   +-----------------+
   | 1 0 0 0 1 1 0 0 |
   +-----------------+
    MSB           LSB

It's egg-eating all over again: Some think that as a bit string this should
be written "10001100" i.e. beginning with the most significant bit, others
insist on "00110001". Well, Perl isn't biased, so that's why we have two bit
string codes:

   $byte = pack( 'B8', '10001100' ); # start with MSB
   $byte = pack( 'b8', '00110001' ); # start with LSB

It is not possible to pack or unpack bit fields - just integral bytes.
C<pack> always starts at the next byte boundary and "rounds up" to the
next multiple of 8 by adding zero bits as required. (If you do want bit
fields, there is L<perlfunc/vec>. Or you could implement bit field 
handling at the character string level, using split, substr, and
concatenation on unpacked bit strings.)

To illustrate unpacking for bit strings, we'll decompose a simple
status register (a "-" stands for a "reserved" bit):

   +-----------------+-----------------+
   | S Z - A - P - C | - - - - O D I T |
   +-----------------+-----------------+
    MSB           LSB MSB           LSB

Converting these two bytes to a string can be done with the unpack 
template C<'b16'>. To obtain the individual bit values from the bit
string we use C<split> with the "empty" separator pattern which dissects
into individual characters. Bit values from the "reserved" positions are
simply assigned to C<undef>, a convenient notation for "I don't care where
this goes".

   ($carry, undef, $parity, undef, $auxcarry, undef, $zero, $sign,
    $trace, $interrupt, $direction, $overflow) =
      split( //, unpack( 'b16', $status ) );

We could have used an unpack template C<'b12'> just as well, since the
last 4 bits can be ignored anyway. 


=head2 Uuencoding

Another odd-man-out in the template alphabet is C<u>, which packs an
"uuencoded string". ("uu" is short for Unix-to-Unix.) Chances are that
you won't ever need this encoding technique which was invented to overcome
the shortcomings of old-fashioned transmission mediums that do not support
other than simple ASCII data. The essential recipe is simple: Take three 
bytes, or 24 bits. Split them into 4 six-packs, adding a space (0x20) to 
each. Repeat until all of the data is blended. Fold groups of 4 bytes into 
lines no longer than 60 and garnish them in front with the original byte count 
(incremented by 0x20) and a C<"\n"> at the end. - The C<pack> chef will
prepare this for you, a la minute, when you select pack code C<u> on the menu:

   my $uubuf = pack( 'u', $bindat );

A repeat count after C<u> sets the number of bytes to put into an
uuencoded line, which is the maximum of 45 by default, but could be
set to some (smaller) integer multiple of three. C<unpack> simply ignores
the repeat count.


=head2 Doing Sums

An even stranger template code is C<%>E<lt>I<number>E<gt>. First, because 
it's used as a prefix to some other template code. Second, because it
cannot be used in C<pack> at all, and third, in C<unpack>, doesn't return the
data as defined by the template code it precedes. Instead it'll give you an
integer of I<number> bits that is computed from the data value by 
doing sums. For numeric unpack codes, no big feat is achieved:

    my $buf = pack( 'iii', 100, 20, 3 );
    print unpack( '%32i3', $buf ), "\n";  # prints 123

For string values, C<%> returns the sum of the byte values saving
you the trouble of a sum loop with C<substr> and C<ord>:

    print unpack( '%32A*', "\x01\x10" ), "\n";  # prints 17

Although the C<%> code is documented as returning a "checksum":
don't put your trust in such values! Even when applied to a small number
of bytes, they won't guarantee a noticeable Hamming distance.

In connection with C<b> or C<B>, C<%> simply adds bits, and this can be put
to good use to count set bits efficiently:

    my $bitcount = unpack( '%32b*', $mask );

And an even parity bit can be determined like this: