[perldocjp-cvs 219] CVS update: docs/perl/5.8.8

Back to archive index

argra****@users***** argra****@users*****
2007年 11月 19日 (月) 08:16:00 JST


Index: docs/perl/5.8.8/perlpacktut.pod
diff -u docs/perl/5.8.8/perlpacktut.pod:1.4 docs/perl/5.8.8/perlpacktut.pod:1.5
--- docs/perl/5.8.8/perlpacktut.pod:1.4	Sun Oct 28 16:17:11 2007
+++ docs/perl/5.8.8/perlpacktut.pod	Mon Nov 19 08:16:00 2007
@@ -22,12 +22,14 @@
 =end original
 
 C<pack> は C<unpack> は、ユーザーが定義したテンプレートに従って、
-between the guarded way Perl stores values
-and some well-defined representation as might be required in the 
-environment of a Perl program.
+the guarded way Perl stores values と
+some well-defined representation as might be required in the 
+environment of a Perl program 
+の間を変換する二つの関数です。
 残念ながら、これらは Perl が提供する関数の中でもっとも誤解され、
 もっとも見落とされやすい関数でもあります。
 このチュートリアルではこれらを分かりやすく説明します。
+(TBT)
 
 =head1 The Basic Principle
 
@@ -61,9 +63,10 @@
 
 =end original
 
-In Perl, you just can't access memory at random, but the structural and
-representational conversion provided by C<pack> and C<unpack> is an
-excellent alternative. The C<pack> function converts values to a byte
+Perl では、メモリにランダムにアクセスすることはできませんが、C<pack> と
+C<unpack> によって提供される構造的および表現的な変換は素晴らしい
+代替案です。
+The C<pack> function converts values to a byte
 sequence containing representations according to a given specification,
 the so-called "template" argument. C<unpack> is the reverse process,
 deriving some values from the contents of a string of bytes. (Be cautioned,
@@ -85,8 +88,9 @@
 
 =end original
 
-Why, you may ask, would you need a chunk of memory containing some values
-in binary representation? One good reason is input and output accessing
+あなたはどうしてバイナリ表現の中に値が含まれているメモリの塊が必要なのか、と
+問うかもしれません。
+One good reason is input and output accessing
 some file, a device, or a network connection, whereby this binary
 representation is either forced on you or will give you some benefit
 in processing. Another cause is passing data to some system call that
@@ -109,9 +113,10 @@
 
 =end original
 
-To see how (un)packing works, we'll start with a simple template
-code where the conversion is in low gear: between the contents of a byte
-sequence and a string of hexadecimal digits. Let's use C<unpack>, since
+(un)pack がどのように働くのかを見るために、変換がのろのろと行われる単純な
+テンプレートコードから始めましょう: バイトシーケンスと 16 進数の文字列との
+変換です。
+Let's use C<unpack>, since
 this is likely to remind you of a dump program, or some desperate last
 message unfortunate programs are wont to throw at you before they expire
 into the wild blue yonder. Assuming that the variable C<$mem> holds a 
@@ -129,9 +134,8 @@
 
 =end original
 
-whereupon we might see something like this, with each pair of hex digits
-corresponding to a byte:
-(TBT)
+するとすぐに、1 バイトに対応して 16 進数 2 文字が対応する、以下のような
+ものが表示されます:
 
    41204d414e204120504c414e20412043414e414c2050414e414d41
 
@@ -192,8 +196,8 @@
 16 進で 2 桁の数値を示す文字列 10 個からなるリストを C<pack> に
 渡しているので、pack テンプレートは 10 個の pack コードを含んでいる
 必要があります。
-これが ASCII 文字コードのコンピュータで実行されると、 C<0123456789> を
-表示されます。
+これが ASCII 文字コードのコンピュータで実行されると、C<0123456789> を
+表示します。
 
 =head1 Packing Text
 
@@ -220,7 +224,8 @@
 
 =end original
 
-どうすればいいでしょう?最初に思いつくのは C<split> かもしれません;
+どうすればいいでしょう?
+最初に思いつくのは C<split> かもしれません;
 しかし、C<split> は空白のフィールドを壊してしまうので、
 そのレコードが収入だったか支出だったが分かりません。あらら。
 では、C<substr> を使うとどうでしょう:
@@ -244,7 +249,7 @@
 =end original
 
 これはあまり愉快ではないですよね?
-実際、これは思ったより悪いです;注意深い人は最初のフィールドが 10 文字分しか
+実際、これは思ったより悪いです; 注意深い人は最初のフィールドが 10 文字分しか
 なく、エラーが他の数値に拡大してしまう - 手で数えなければなりません -
 ことに気付くでしょう。
 従って、これは恐ろしく不親切であると同様、間違いが発生しやすいです.
@@ -286,7 +291,7 @@
 ええ、できます、正しい道具を使えば。
 C<pack> と C<unpack> は上記のような固定長データを扱う時の
 助けになるように設計されています。
-C<unpack> による開放を見てみましょう:
+C<unpack> による解法を見てみましょう:
 
     while (<>) { 
         my($date, $desc, $income, $expend) = unpack("A10xA27xA7A*", $_);
@@ -422,8 +427,8 @@
 =end original
 
 これで、データがパースできます。
-今ほしいものが収入と支出をそれぞれ足し合わせて、台帳の最後に - 同じ形式で - 1 行
-付け加えることで、どれだけの収入と支出があったかを記すことだとします:
+今ほしいものが収入と支出をそれぞれ足し合わせて、台帳の最後に - 同じ形式で -
+1 行付け加えることで、どれだけの収入と支出があったかを記すことだとします:
 
     while (<>) {
         my($date, $desc, $income, $expend) = unpack("A10xA27xA7xA*", $_);
@@ -462,8 +467,9 @@
 
 =end original
 
-まあ、これはスタートです。しかしスペースに何が起きたのでしょう?
-C<x> を指定しましたよね?これでは飛ばせない?
+まあ、これはスタートです; しかしスペースに何が起きたのでしょう?
+C<x> を指定しましたよね?
+これでは飛ばせない?
 L<perlfunc/pack> に書いていることを見てみましょう:
 
     x   A null byte.
@@ -664,8 +670,10 @@
 
 =end original
 
-So much for textual data. Let's get onto the meaty stuff that C<pack>
-and C<unpack> are best at: handling binary formats for numbers. There is,
+テキストデータについてはこれくらいです。
+C<pack> と C<unpack> が最良である、いやらしい代物: 数値のためのバイナリ
+フォーマットに進みましょう。
+There is,
 of course, not just one binary format  - life would be too simple - but
 Perl will do all the finicky labor for you.
 (TBT)
@@ -698,7 +706,7 @@
 
 =end original
 
-整数の保存に複数バイトを使う。
+整数の保存に使うバイト数。
 
 =item *
 
@@ -731,7 +739,7 @@
 
 =end original
 
-それで、例えば、20302 をコンピューターの符号付き 16 ビット整数に
+それで、例えば、20302 をあなたのコンピュータの符号付き 16 ビット整数に
 pack するとすると、以下のように書きます:
 
    my $ps = pack( 's', 20302 );
@@ -796,6 +804,7 @@
 "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.
+(TBT)
 
 =begin original
 
@@ -828,6 +837,7 @@
 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>.)
+(TBT)
 
    signed unsigned  byte length in C   byte length in Perl       
      s!     S!      sizeof(short)      $Config{shortsize}
@@ -1315,11 +1325,11 @@
 
 =end original
 
-Prior to Perl 5.8, repetitions of templates had to be made by
-C<x>-multiplication of template strings. Now there is a better way as
-we may use the pack codes C<(> and C<)> combined with a repeat count.
-The C<unpack> template from the Stack Frame example can simply
-be written like this:
+Perl 5.8 以前では、テンプレートの繰り返しはテンプレート文字列を C<x> 回
+繰り返すことで作る必要がありました。
+今では、pack コード C<(> と C<)> に繰り返し数を組み合わせて使うという
+よりよい方法があります。
+スタックフレームの例の C<unpack> テンプレートは単に以下のように書けます:
 
    unpack( 'v2 (vXXCC)5 v5', $frame )
 
@@ -1447,6 +1457,7 @@
 techniques are used: after two null terminated strings with source and
 destination address, a Short Message (to a mobile phone) is sent after
 a length byte:
+(TBT)
 
    my $msg = pack( 'Z*Z*CA*', $src, $dst, length( $sm ), $sm );
 
@@ -1512,6 +1523,16 @@
 
 =end original
 
+Combining two pack codes with a slash (C</>) associates them with a single
+value from the argument list. In C<pack>, the length of the argument is
+taken and packed according to the first code while the argument itself
+is added after being converted with the template code after the slash.
+This saves us the trouble of inserting the C<length> call, but it is 
+in C<unpack> where we really score: The value of the length byte marks the
+end of the string to be taken from the buffer. Since this combination
+doesn't make sense except when the second pack code isn't C<a*>, C<A*>
+or C<Z*>, Perl won't let you.
+(TBT)
 
 =begin original
 
@@ -1521,6 +1542,10 @@
 
 =end original
 
+The pack code preceding C</> may be anything that's fit to represent a
+number: All the numeric binary pack codes, and even text codes such as
+C<A4> or C<Z*>:
+(TBT)
 
    # pack/unpack a string preceded by its length in ASCII
    my $buf = pack( 'A4/A*', "Humpty-Dumpty" );
@@ -1535,6 +1560,10 @@
 
 =end original
 
+C</> is not implemented in Perls before 5.6, so if your code is required to
+work on older Perls you'll need to C<unpack( 'Z* Z* C')> to get the length,
+then use it to make a new unpack string. For example
+(TBT)
 
    # pack a message: ASCIIZ, ASCIIZ, length, string, byte (5.005 compatible)
    my $msg = pack( 'Z* Z* C A* C', $src, $dst, length $sm, $sm, $prio );
@@ -1550,6 +1579,9 @@
 
 =end original
 
+But that second C<unpack> is rushing ahead. It isn't using a simple literal
+string for the template. So maybe we should introduce...
+(TBT)
 
 =head2 Dynamic Templates
 
@@ -1875,6 +1907,7 @@
 Where's the catch? Padding is neither required before the first field C<count>,
 nor between this and the next field C<glyph>, so why can't we simply pack
 like this:
+(TBT)
 
    # something goes wrong here:
    pack( 's!a' x @buffer,
@@ -1895,6 +1928,7 @@
 the required alignment of a structure or array is propagated to the
 next higher level where we have to consider padding I<at the end>
 of each component as well. Thus the correct template is:
+(TBT)
 
    pack( 's!ax' x @buffer,
          map{ ( $_->{count}, $_->{glyph} ) } @buffer );
@@ -1946,12 +1980,12 @@
 
 =end original
 
-The title of this section indicates the second problem you may run into
-sooner or later when you pack C structures. If the function you intend
-to call expects a, say, C<void *> value, you I<cannot> simply take
-a reference to a Perl variable. (Although that value certainly is a
-memory address, it's not the address where the variable's contents are
-stored.)
+この章のタイトルは、C の構造体を pack するときに遅かれ早かれ出会うことになる
+2 番目の問題を指し示しています。
+呼び出そうとしている関数が、例えば、C<void *> の値を想定している場合、
+単純に Perl の変数のリファレンスを使うことは I<できません>。
+(確かに値はメモリアドレスですが、値の内容が保持されているアドレスでは
+ないからです。)
 
 =begin original
 
@@ -1962,6 +1996,7 @@
 
 Template code C<P> promises to pack a "pointer to a fixed length string".
 Isn't this what we want? Let's try:
+(TBT)
 
     # allocate some storage and pack a pointer to it
     my $memory = "\x00" x $size;
@@ -1982,6 +2017,7 @@
 nothing but a number?
 答えは単純です: C<pack> で返されたバイト列から数値のアドレスを得なければ
 なりません。
+(TBT)
 
     my $ptr = unpack( 'L!', $memptr );
 
@@ -2000,6 +2036,7 @@
 be taken as a universal law. - Now that we have this pointer the next question
 is: How can we put it to good use? We need a call to some C function
 where a pointer is expected. The read(2) system call comes to mind:
+(TBT)
 
     ssize_t read(int fd, void *buf, size_t count);
 
@@ -2041,6 +2078,7 @@
 access Perl's otherwise well-guarded memory! (Important note: Perl's
 C<syscall> does I<not> require you to construct pointers in this roundabout
 way. You simply pass a string variable, and Perl forwards the address.) 
+(TBT)
 
 =begin original
 
@@ -2057,6 +2095,7 @@
 produce the C<undef> value) we have a start address - but then what?
 Perl has no way of knowing how long this "fixed length string" is, so
 it's up to you to specify the actual size as an explicit length after C<P>.
+(TBT)
 
    my $mem = "abcdefghijklmn";
    print unpack( 'P5', pack( 'P', $mem ) ); # prints "abcde"
@@ -2084,6 +2123,7 @@
 answer lies behind the simple fact that an C<unpack> with C<p> promises
 a null-terminated string starting at the address taken from the buffer,
 and that implies a length for the data item to be returned:
+(TBT)
 
    my $buf = pack( 'p', "abc\x00efhijklmn" );
    print unpack( 'p', $buf );    # prints "abc"


perldocjp-cvs メーリングリストの案内
Back to archive index