perlpacktut.1

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

.Ve
.PP
\&\s-1OK\s0, it's a start, but what happened to the spaces? We put \f(CW\*(C`x\*(C'\fR, didn't
we? Shouldn't it skip forward? Let's look at what \*(L"pack\*(R" in perlfunc says:
.PP
.Vb 1
\&    x   A null byte.
.Ve
.PP
Urgh. No wonder. There's a big difference between \*(L"a null byte\*(R",
character zero, and \*(L"a space\*(R", character 32. Perl's put something
between the date and the description \- but unfortunately, we can't see
it!
.PP
What we actually need to do is expand the width of the fields. The \f(CW\*(C`A\*(C'\fR
format pads any non-existent characters with spaces, so we can use the
additional spaces to line up our fields, like this:
.PP
.Vb 1
\&    print pack("A11 A28 A8 A*", $date, "Totals", $tot_income, $tot_expend);
.Ve
.PP
(Note that you can put spaces in the template to make it more readable,
but they don't translate to spaces in the output.) Here's what we got
this time:
.PP
.Vb 4
\&    01/24/2001 Ahmed\*(Aqs Camel Emporium                   1147.99
\&    01/28/2001 Flea spray                                 24.99
\&    01/29/2001 Camel rides to tourists     1235.00
\&    03/23/2001 Totals                      1235.00 1172.98
.Ve
.PP
That's a bit better, but we still have that last column which needs to
be moved further over. There's an easy way to fix this up:
unfortunately, we can't get \f(CW\*(C`pack\*(C'\fR to right-justify our fields, but we
can get \f(CW\*(C`sprintf\*(C'\fR to do it:
.PP
.Vb 4
\&    $tot_income = sprintf("%.2f", $tot_income); 
\&    $tot_expend = sprintf("%12.2f", $tot_expend);
\&    $date = POSIX::strftime("%m/%d/%Y", localtime); 
\&    print pack("A11 A28 A8 A*", $date, "Totals", $tot_income, $tot_expend);
.Ve
.PP
This time we get the right answer:
.PP
.Vb 3
\&    01/28/2001 Flea spray                                 24.99
\&    01/29/2001 Camel rides to tourists     1235.00
\&    03/23/2001 Totals                      1235.00      1172.98
.Ve
.PP
So that's how we consume and produce fixed-width data. Let's recap what
we've seen of \f(CW\*(C`pack\*(C'\fR and \f(CW\*(C`unpack\*(C'\fR so far:
.IP "\(bu" 3
Use \f(CW\*(C`pack\*(C'\fR to go from several pieces of data to one fixed-width
version; use \f(CW\*(C`unpack\*(C'\fR to turn a fixed-width-format string into several
pieces of data.
.IP "\(bu" 3
The pack format \f(CW\*(C`A\*(C'\fR means \*(L"any character\*(R"; if you're \f(CW\*(C`pack\*(C'\fRing and
you've run out of things to pack, \f(CW\*(C`pack\*(C'\fR will fill the rest up with
spaces.
.IP "\(bu" 3
\&\f(CW\*(C`x\*(C'\fR means \*(L"skip a byte\*(R" when \f(CW\*(C`unpack\*(C'\fRing; when \f(CW\*(C`pack\*(C'\fRing, it means
\&\*(L"introduce a null byte\*(R" \- that's probably not what you mean if you're
dealing with plain text.
.IP "\(bu" 3
You can follow the formats with numbers to say how many characters
should be affected by that format: \f(CW\*(C`A12\*(C'\fR means \*(L"take 12 characters\*(R";
\&\f(CW\*(C`x6\*(C'\fR means \*(L"skip 6 bytes\*(R" or \*(L"character 0, 6 times\*(R".
.IP "\(bu" 3
Instead of a number, you can use \f(CW\*(C`*\*(C'\fR to mean \*(L"consume everything else
left\*(R".
.Sp
\&\fBWarning\fR: when packing multiple pieces of data, \f(CW\*(C`*\*(C'\fR only means
\&\*(L"consume all of the current piece of data\*(R". That's to say
.Sp
.Vb 1
\&    pack("A*A*", $one, $two)
.Ve
.Sp
packs all of \f(CW$one\fR into the first \f(CW\*(C`A*\*(C'\fR and then all of \f(CW$two\fR into
the second. This is a general principle: each format character
corresponds to one piece of data to be \f(CW\*(C`pack\*(C'\fRed.
.SH "Packing Numbers"
.IX Header "Packing Numbers"
So much for textual data. Let's get onto the meaty stuff that \f(CW\*(C`pack\*(C'\fR
and \f(CW\*(C`unpack\*(C'\fR are best at: handling binary formats for numbers. There is,
of course, not just one binary format  \- life would be too simple \- but
Perl will do all the finicky labor for you.
.Sh "Integers"
.IX Subsection "Integers"
Packing and unpacking numbers implies conversion to and from some
\&\fIspecific\fR binary representation. Leaving floating point numbers
aside for the moment, the salient properties of any such representation
are:
.IP "\(bu" 4
the number of bytes used for storing the integer,
.IP "\(bu" 4
whether the contents are interpreted as a signed or unsigned number,
.IP "\(bu" 4
the byte ordering: whether the first byte is the least or most
significant byte (or: little-endian or big-endian, respectively).
.PP
So, for instance, to pack 20302 to a signed 16 bit integer in your
computer's representation you write
.PP
.Vb 1
\&   my $ps = pack( \*(Aqs\*(Aq, 20302 );
.Ve
.PP
Again, the result is a string, now containing 2 bytes. If you print 
this string (which is, generally, not recommended) you might see
\&\f(CW\*(C`ON\*(C'\fR or \f(CW\*(C`NO\*(C'\fR (depending on your system's byte ordering) \- or something
entirely different if your computer doesn't use \s-1ASCII\s0 character encoding.
Unpacking \f(CW$ps\fR with the same template returns the original integer value:
.PP
.Vb 1
\&   my( $s ) = unpack( \*(Aqs\*(Aq, $ps );
.Ve
.PP
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 \f(CW\*(C`s\*(C'\fR, an excess value may result in the sign bit
getting set, and unpacking this will smartly return a negative value.
.PP
16 bits won't get you too far with integers, but there is \f(CW\*(C`l\*(C'\fR and \f(CW\*(C`L\*(C'\fR
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 \f(CW\*(C`q\*(C'\fR and \f(CW\*(C`Q\*(C'\fR. A notable exception is provided
by pack codes \f(CW\*(C`i\*(C'\fR and \f(CW\*(C`I\*(C'\fR for signed and unsigned integers of the 
\&\*(L"local custom\*(R" variety: Such an integer will take up as many bytes as
a local C compiler returns for \f(CW\*(C`sizeof(int)\*(C'\fR, but it'll use \fIat least\fR
32 bits.
.PP
Each of the integer pack codes \f(CW\*(C`sSlLqQ\*(C'\fR 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 
\&\s-1XS\s0 extensions or the Perl function \f(CW\*(C`syscall\*(C'\fR), 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 \f(CW\*(C`short\*(C'\fR or
\&\f(CW\*(C`unsigned long\*(C'\fR, 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 \f(CW%Config\fR in your program
you have to import it with \f(CW\*(C`use Config\*(C'\fR.)
.PP
.Vb 5
\&   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}
.Ve
.PP
The \f(CW\*(C`i!\*(C'\fR and \f(CW\*(C`I!\*(C'\fR codes aren't different from \f(CW\*(C`i\*(C'\fR and \f(CW\*(C`I\*(C'\fR; they are
tolerated for completeness' sake.
.Sh "Unpacking a Stack Frame"
.IX Subsection "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:
.PP
.Vb 11
\&      +\-\-\-\-\-\-\-\-\-+        +\-\-\-\-+\-\-\-\-+               +\-\-\-\-\-\-\-\-\-+
\& 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    |
\&                         +\-\-\-\-+\-\-\-\-+               +\-\-\-\-\-\-\-\-\-+
.Ve
.PP
First, we note that this time-honored 16\-bit \s-1CPU\s0 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 \f(CW\*(C`v\*(C'\fR. A repeat
count unpacks all 12 shorts:
.PP
.Vb 2
\&   my( $ip, $cs, $flags, $ax, $bx, $cd, $dx, $si, $di, $bp, $ds, $es ) =
\&     unpack( \*(Aqv12\*(Aq, $frame );
.Ve
.PP
Alternatively, we could have used \f(CW\*(C`C\*(C'\fR to unpack the individually
accessible byte registers \s-1FL\s0, \s-1FH\s0, \s-1AL\s0, \s-1AH\s0, etc.:
.PP
.Vb 2
\&   my( $fl, $fh, $al, $ah, $bl, $bh, $cl, $ch, $dl, $dh ) =
\&     unpack( \*(AqC10\*(Aq, substr( $frame, 4, 10 ) );
.Ve
.PP
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 \fIis\fR nice, it
proffers the template code \f(CW\*(C`X\*(C'\fR to back up one byte. Putting this all
together, we may now write:
.PP
.Vb 5
\&   my( $ip, $cs,
\&       $flags,$fl,$fh,
\&       $ax,$al,$ah, $bx,$bl,$bh, $cx,$cl,$ch, $dx,$dl,$dh, 
\&       $si, $di, $bp, $ds, $es ) =
\&   unpack( \*(Aqv2\*(Aq . (\*(AqvXXCC\*(Aq x 5) . \*(Aqv5\*(Aq, $frame );
.Ve
.PP
(The clumsy construction of the template can be avoided \- just read on!)
.PP
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 \f(CW\*(C`unpack\*(C'\fR could not unpack all. If \f(CW\*(C`pack\*(C'\fR runs out of items, it will
supply null strings (which are coerced into zeroes whenever the pack code
says so).
.Sh "How to Eat an Egg on a Net"
.IX Subsection "How to Eat an Egg on a Net"
The pack code for big-endian (high order byte at the lowest address) is
\&\f(CW\*(C`n\*(C'\fR for 16 bit and \f(CW\*(C`N\*(C'\fR 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 \fInetwork order\fR, 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:
.PP
.Vb 1
\&   my $buf = pack( \*(AqN\*(Aq, length( $msg ) ) . $msg;
.Ve
.PP
or even:
.PP
.Vb 1
\&   my $buf = pack( \*(AqNA*\*(Aq, length( $msg ), $msg );
.Ve
.PP
and pass \f(CW$buf\fR 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\*(R" before
you really code this!)
.Sh "Byte-order modifiers"
.IX Subsection "Byte-order modifiers"
In the previous sections we've learned how to use \f(CW\*(C`n\*(C'\fR, \f(CW\*(C`N\*(C'\fR, \f(CW\*(C`v\*(C'\fR and
\&\f(CW\*(C`V\*(C'\fR 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:
.PP
.Vb 1
\&   my @data = unpack \*(Aqs*\*(Aq, pack \*(AqS*\*(Aq, unpack \*(Aqn*\*(Aq, $buf;
.Ve
.PP
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 \f(CW\*(C`>\*(C'\fR and \f(CW\*(C`<\*(C'\fR modifiers.
\&\f(CW\*(C`>\*(C'\fR is the big-endian modifier, while \f(CW\*(C`<\*(C'\fR is the little-endian
modifier. Using them, we could rewrite the above code as:
.PP
.Vb 1
\&   my @data = unpack \*(Aqs>*\*(Aq, $buf;
.Ve
.PP
As you can see, the \*(L"big end\*(R" of the arrow touches the \f(CW\*(C`s\*(C'\fR, which is a
nice way to remember that \f(CW\*(C`>\*(C'\fR is the big-endian modifier. The same
obviously works for \f(CW\*(C`<\*(C'\fR, where the \*(L"little end\*(R" touches the code.
.PP
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\*(R" for more on that.
.Sh "Floating point Numbers"
.IX Subsection "Floating point Numbers"
For packing floating point numbers you have the choice between the
pack codes \f(CW\*(C`f\*(C'\fR, \f(CW\*(C`d\*(C'\fR, \f(CW\*(C`F\*(C'\fR and \f(CW\*(C`D\*(C'\fR. \f(CW\*(C`f\*(C'\fR and \f(CW\*(C`d\*(C'\fR pack into (or unpack
from) single-precision or double-precision representation as it is provided
by your system. If your systems supports it, \f(CW\*(C`D\*(C'\fR can be used to pack and
unpack extended-precision floating point values (\f(CW\*(C`long double\*(C'\fR), which
can offer even more resolution than \f(CW\*(C`f\*(C'\fR or \f(CW\*(C`d\*(C'\fR. \f(CW\*(C`F\*(C'\fR packs an \f(CW\*(C`NV\*(C'\fR,
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 \s-1ASCII\s0 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.)
.SH "Exotic Templates"
.IX Header "Exotic Templates"
.Sh "Bit Strings"
.IX Subsection "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 \f(CW0\fR and \f(CW1\fR 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:
.PP
.Vb 5
\&     7 6 5 4 3 2 1 0
\&   +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
\&   | 1 0 0 0 1 1 0 0 |
\&   +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
\&    MSB           LSB
.Ve
.PP
It's egg-eating all over again: Some think that as a bit string this should
be written \*(L"10001100\*(R" i.e. beginning with the most significant bit, others
insist on \*(L"00110001\*(R". Well, Perl isn't biased, so that's why we have two bit
string codes:
.PP
.Vb 2
\&   $byte = pack( \*(AqB8\*(Aq, \*(Aq10001100\*(Aq ); # start with MSB
\&   $byte = pack( \*(Aqb8\*(Aq, \*(Aq00110001\*(Aq ); # start with LSB
.Ve
.PP
It is not possible to pack or unpack bit fields \- just integral bytes.
\&\f(CW\*(C`pack\*(C'\fR always starts at the next byte boundary and \*(L"rounds up\*(R" to the
next multiple of 8 by adding zero bits as required. (If you do want bit
fields, there is \*(L"vec\*(R" in perlfunc. Or you could implement bit field 
handling at the character string level, using split, substr, and
concatenation on unpacked bit strings.)
.PP
To illustrate unpacking for bit strings, we'll decompose a simple
status register (a \*(L"\-\*(R" stands for a \*(L"reserved\*(R" bit):
.PP
.Vb 4
\&   +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
\&   | S Z \- A \- P \- C | \- \- \- \- O D I T |
\&   +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
\&    MSB           LSB MSB           LSB
.Ve
.PP
Converting these two bytes to a string can be done with the unpack 
template \f(CW\*(Aqb16\*(Aq\fR. To obtain the individual bit values from the bit
string we use \f(CW\*(C`split\*(C'\fR with the \*(L"empty\*(R" separator pattern which dissects
into individual characters. Bit values from the \*(L"reserved\*(R" positions are
simply assigned to \f(CW\*(C`undef\*(C'\fR, a convenient notation for \*(L"I don't care where
this goes\*(R".
.PP
.Vb 3
\&   ($carry, undef, $parity, undef, $auxcarry, undef, $zero, $sign,
\&    $trace, $interrupt, $direction, $overflow) =
\&      split( //, unpack( \*(Aqb16\*(Aq, $status ) );
.Ve
.PP
We could have used an unpack template \f(CW\*(Aqb12\*(Aq\fR just as well, since the
last 4 bits can be ignored anyway.
.Sh "Uuencoding"
.IX Subsection "Uuencoding"