argra****@users*****
argra****@users*****
2009年 4月 1日 (水) 01:29:20 JST
Index: docs/perl/5.10.0/perlretut.pod
diff -u docs/perl/5.10.0/perlretut.pod:1.8 docs/perl/5.10.0/perlretut.pod:1.9
--- docs/perl/5.10.0/perlretut.pod:1.8 Wed Feb 18 00:56:03 2009
+++ docs/perl/5.10.0/perlretut.pod Wed Apr 1 01:29:20 2009
@@ -60,7 +60,8 @@
=end original
-正規表現とは何でしょうか? 正規表現とはパターンを表す単純な文字列です。
+正規表現とは何でしょうか?
+正規表現とはパターンを表す単純な文字列です。
パターンは今日広く使われています。
たとえば、ウェブページを見つけ出すために検索エンジンにタイプしたり、
ディレクトリの中のファイルをリストアップするために C<ls *.txt> とか
@@ -82,7 +83,7 @@
正規表現には抽象的で理解するのが難しいという不適切な悪名があります。
正規表現は条件とループのような単純なコンセプトを使って構成されていて、
-Perl 自身の C<if> であるとかC<while> のようなそれと対応するものに比べて
+Perl 自身の C<if> であるとか C<while> のようなそれと対応するものに比べて
難しいことはありません。
事実、正規表現を学ぶにあたっての主な挑戦はこれらのコンセプトを
表現するために簡潔な記述を使おうとすることなのです。
@@ -161,9 +162,9 @@
=end original
-このPerlの文が行っていることは何でしょう?
+この Perl の文が行っていることは何でしょう?
C<"Hello World"> は単純な、ダブルクォートで囲まれた文字列です。
-C<World> は正規表現であり、 C<//> で囲まれたC</World/> は
+C<World> は正規表現であり、 C<//> で囲まれた C</World/> は
Perl に対してマッチのために文字列を検索することを指示します。
C<=~> という演算子は正規表現にマッチする文字列に結び付けられ、
正規表現がマッチすれば真の値を生成し、マッチしなければ偽となります。
@@ -236,7 +237,7 @@
=end original
-最後に、マッチのための C<//> のデフォルトデリミタは C'm'> を
+最後に、マッチのための C<//> のデフォルトデリミタは C<'m'> を
前置することにより任意のものにすることができます:
=begin original
@@ -308,7 +309,7 @@
なぜなら、正規表現は大文字と小文字を区別するからです。
二番目の正規表現は S<C<"Hello World">> という文字列の中に S<C<'o W'>> と
いう部分があるのでマッチします。
-スペース ' 'は正規表現の中で他の文字と同じように扱われ、この場合
+スペース ' ' は正規表現の中で他の文字と同じように扱われ、この場合
マッチするのに必要なものです。
スペースがないことが三番目の正規表現 C<'oW'> がマッチしない理由です。
四番目の正規表現は正規表現の末尾にスペースがついているのに、文字列の
@@ -323,7 +324,7 @@
=end original
-正規表現が文字列の二箇所以上にマッチするならば、Perlは常に文字列の中で
+正規表現が文字列の二箇所以上にマッチするならば、Perl は常に文字列の中で
最初に現れるものをマッチしようとします:
=begin original
@@ -459,7 +460,7 @@
"1000\t2000" =~ m(0\t2) # マッチする
"1000\n2000" =~ /0\n20/ # マッチする
- "1000\t2000" =~ /\000\t2/ # マッチしない。"0" は "\000" ではない
+ "1000\t2000" =~ /\000\t2/ # マッチしない; "0" は "\000" ではない
"cat" =~ /\143\x61\x74/ # マッチするが、cat を綴る変な方法
=begin original
@@ -792,7 +793,7 @@
したがって、C</[yY][eE][sS]/;> は C</yes/i;> と書き換えることができます。
この C<'i'> は大小文字の違いを無視することを意味していて、マッチング操作の
I<修飾子> (modifier)の実例です。
-本チュートリアルの先のほうで他の修飾子がでてくることでしょう。
+本チュートリアルの後の方で他の修飾子がでてくることでしょう。
=begin original
@@ -810,10 +811,11 @@
=end original
-このセクションの前のほうで、自分自身を表す通常の文字とそれ自身を表すためには
+このセクションの前のほうで、自分自身を表す通常の文字と、
+それ自身を表すためには
バックスラッシュ C<\> が必要な特殊文字があることを見てきました。
同じことが文字クラスの中でも言えます。
-しかし、文字クラスの内側にある通常の文字の集合と特殊文字は、文字クラスの
+しかし、文字クラスの内側にある通常の文字と特殊文字の集合は、文字クラスの
外側にあるものと異なります。
文字クラスのために特殊な文字は C<-]\^$>
(および(何であれ)デリミタ)です。
@@ -848,10 +850,10 @@
=end original
最後の二つはちょっとトリッキーです。
-C<[\$x]> の中ではバックスラッシュはドル記号をプロテクトしているので、
-文字クラスは C<$> とC<x> という二つのメンバーを持ちます。
-C<[\\$x]> ではバックラッシュがプロテクトされているので、C<$x> は変数として
-扱われ、ダブルクォート規則にのっとり置換が行われます。
+C<[\$x]> の中ではバックスラッシュはドル記号を保護しているので、
+文字クラスは C<$> とC<x> という二つのメンバを持ちます。
+C<[\\$x]> ではバックラッシュが保護されているので、C<$x> は変数として
+扱われ、ダブルクォート規則に従って置換が行われます。
=begin original
@@ -869,6 +871,8 @@
書き換えられます。
幾つか例を挙げましょう
+=begin original
+
/item[0-9]/; # matches 'item0' or ... or 'item9'
/[0-9bx-z]aa/; # matches '0aa', ..., '9aa',
# 'baa', 'xaa', 'yaa', or 'zaa'
@@ -876,6 +880,15 @@
/[0-9a-zA-Z_]/; # matches a "word" character,
# like those in a Perl variable name
+=end original
+
+ /item[0-9]/; # 'item0' ... 'item9' にマッチする
+ /[0-9bx-z]aa/; # '0aa' ... '9aa',
+ # 'baa', 'xaa', 'yaa', 'zaa' のいずれかにマッチする
+ /[0-9a-fA-F]/; # 16 進数にマッチする
+ /[0-9a-zA-Z_]/; # Perl の変数名のような
+ # 「単語」文字にマッチする
+
=begin original
If C<'-'> is the first or last character in a character class, it is
@@ -900,7 +913,7 @@
文字クラスの先頭の位置にある特殊文字 C<^> は 文字クラスの反転を表し、
ブラケットの中にない文字にマッチします。
C<[...]> と C<[^...]> の両方とも、一つの文字にマッチせねばならず、
-そうでないばあいにはマッチは失敗します。
+そうでない場合にはマッチは失敗します。
ですから
=begin original
@@ -1437,7 +1450,8 @@
=end original
この最後の例は文字クラスが文字の選択に似ていることを表しています。
-与えられた文字位置で、正規表現のマッチングを成功させるための最初の選択肢はマッチする一つとなります。
+与えられた文字位置で、正規表現のマッチングを成功させるための
+最初の選択肢はマッチする一つとなります。
=head2 Grouping things and hierarchical matching
@@ -1571,16 +1585,16 @@
'バックトラッキング'という単語は正規表現のマッチングが森の中の散歩に
似ていることからきています。
正規表現のマッチングが成功することは目的地にたどり着くことです。
-多くのtrailheadsがあり、文字列の各位置のひとつで左から右へと順序だてて
+多くの起点があり、文字列の各位置のひとつで左から右へと順序だてて
一つ一つ試します。
-それぞれのtrailheadsからは多くの通り道があり、どれかはあなたが目指す場所で
-ほかのどれかは行き止まりになっています。
-歩いていて行き止まりにあたったら、あなたはもときた道を後戻り(backtrack)して
+それぞれの起点からは多くの通り道があり、どれかはあなたが目指す場所で
+他のどれかは行き止まりになっています。
+歩いていて行き止まりに当たったら、あなたはもと来た道を後戻り(backtrack)して
別の道を試してみなければなりません。
-目的地に着いたなら、即座に止まって他の未知は忘れてしまいます。
-あなたは粘り強いので、すべてのtrailheadsからすべての通り道を試してそれでも
+目的地に着いたなら、即座に止まって他の道は忘れてしまいます。
+あなたは粘り強いので、すべての起点からすべての通り道を試してそれでも
目的地に着かなければ、失敗を宣言します。
-具体的に、Perlが正規表現のマッチを試しているときに行っていることを
+具体的に、Perl が正規表現のマッチを試しているときに行っていることを
ステップを追って説明しましょう
"abcde" =~ /(abd|abc)(df|d|de)/;
@@ -1722,11 +1736,11 @@
=end original
この調査に関して注意すべき点が二、三あります。
-第一に、二番目のグループの三番目の選択肢'de'もまたマッチしますが、
+第一に、二番目のグループの三番目の選択肢 'de' もまたマッチしますが、
そこに行く前に停止しました。
与えられた文字の位置で、最も左のものが優先されるからです。
第二に、文字列の最初の文字が 'a' であったのでマッチすることができました。
-もし最初の位置でマッチに成功しなければ、Perl は二番目にある文字'b'へと
+もし最初の位置でマッチに成功しなければ、Perl は二番目にある文字 'b' へと
移動して同じことを繰り返します。
すべての可能な文字位置で、すべての可能な道筋が尽きたときにのみ Perl は
マッチをあきらめ、
@@ -1805,7 +1819,7 @@
正規表現中のグループ化がネストしていた場合、C<$1> は最も左にある
開きかっこによってグループ化されているものを取り、C<$2> は
-次の開きかっこによるものを取り・・・となっていきます。
+次の開きかっこによるものを取り…となっていきます。
これがネストしたグループをもつ正規表現です:
/(ab(cd|ef)((gi)|j))/;
@@ -1861,7 +1875,7 @@
後方参照は正規表現の I<内側> で使うことのできるマッチング変数です。
これは実に良い機能です - 正規表現の中で後でマッチするものがそれ以前に
マッチしていたものに依存させることができます。
-'the the'のように繰り返しされた単語をテキストの中から探したいとしましょう。
+'the the' のように繰り返しされた単語をテキストの中から探したいとしましょう。
以下の正規表現はスペースで分けられた三文字の重複単語を見つけ出します:
/\b(\w\w\w)\s\1\b/;
@@ -1907,9 +1921,9 @@
この正規表現は四文字の組み合わせ、三文字の組み合わせなどを扱うただ一つの
グループ化を持っています。
そして、C<\1> は繰り返しを探します。
-$1と\1が同じものを表現しているにもかかわらず、マッチ変数 C<$1>, C<$2> …は
-正規表現の I<外側> のみで用い、後方参照 C<\1>, C<\2> …は正規表現の
-I<内側> でのみ使うようにすべきです。
+$1 と \1 が同じものを表現しているにもかかわらず、
+マッチ変数 C<$1>, C<$2> …は正規表現の I<外側> のみで用い、
+後方参照 C<\1>, C<\2> …は正規表現の I<内側> でのみ使うようにすべきです。
そうしないと驚くような不満足な結果を招くかもしれません。
=head2 Relative backreferences
@@ -1978,7 +1992,7 @@
しかしこれはマッチングしません -- 少なくとも予想した通りには。
変数展開された C<$a99a> を挿入した後でだけ、結果となる
正規表現のテキストを見ると、後方参照が逆効果となるのは明らかです --
- 部分式 C<(\w+)> が 1 番を奪ってしまい、C<$a99a> のグループが
+部分式 C<(\w+)> が 1 番を奪ってしまい、C<$a99a> のグループが
1 つ格下げになります。
これは相対後方参照を使うことで回避できます:
@@ -2075,13 +2089,12 @@
=end original
-Processing the results requires an additional if statement to determine
-whether C<$1> and C<$2> or C<$3> and C<$4> contain the goodies. It would
-be easier if we could use buffer numbers 1 and 2 in second alternative as
-well, and this is exactly what the parenthesized construct C<(?|...)>,
-set around an alternative achieves.
+結果の処理には、C<$1> と C<$2>、または C<$3> と C<$4> に有用なものが
+含まれれているかを決定するために追加の if 文が必要です。
+2 番目の選択肢にもバッファ番号 1 と 2 をつけられればより簡単になります;
+これがまさに、選択肢の周りにかっこをつけた構造 C<(?|...)> が
+意味するものです。
これは以前のパターンの拡張版です:
-(TBT)
if ( $time =~ /(?|(\d\d|\d):(\d\d)|(\d\d)(\d\d))\s+([A-Z][A-Z][A-Z])/ ){
print "hour=$1 minute=$2 zone=$3\n";
@@ -2180,7 +2193,7 @@
C<$&> も遅くなる原因です。
なぜなら、プログラムの中の正規表現でこれらを使ったならばプログラムの中の
I<すべて> の正規表現に対してこれらが生成されるからです。
-ですから、raw パフォーマンスがあなたの作るアプリケーションのゴールで
+ですから、生のパフォーマンスがあなたの作るアプリケーションのゴールで
あるならば、これらを排除すべきです。
もし対応する吹く文字列の展開が必要なら、代わりに C<@-> とC<@+> を
使いましょう:
@@ -2216,20 +2229,19 @@
=end original
-A group that is required to bundle a set of alternatives may or may not be
-useful as a capturing group. If it isn't, it just creates a superfluous
-addition to the set of available capture buffer values, inside as well as
-outside the regexp.
+選択肢の集合をまとめるために必要なグループは、捕捉グループとして
+有用な場合もありますし、有用でない場合もあります。
+有用でない場合は、これは正規表現の内外で、無駄な捕捉バッファ値を
+作ることになります。
非捕捉グループ化は C<(?:regexp)> のように表記され regexp を一つの
-ユニットのように扱うことができるようにするが、同時に捕捉バッファを
-作成しません。
+ユニットのように扱うことができるようにしますが、同時に捕捉バッファを
+作成することはしません。
捕捉するグループ化と捕捉しないグループ化の両方が同じ正規表現の
中で共存することができます。
-部分文字列の抜き出しをしないので非捕捉グループ化は捕捉する
+部分文字列の抜き出しをしないので、非捕捉グループ化は捕捉する
グループ化よりも高速です。
非捕捉グループ化はマッチ変数を使って抽出する正規表現の部分を
選択するのに便利です:
-(TBT)
# match a number, $1-$4 are set, but we only want $1
/([+-]?\ *(\d+(\.\d*)?|\.\d+)([eE][+-]?\d+)?)/;
@@ -3026,10 +3038,9 @@
=end original
-Backtracking during the relentless search for a match may be a waste
-of time, particularly when the match is bound to fail. Consider
-the simple pattern
-(TBT)
+マッチングのための容赦ない検索中のバックトラッキングは時間の無駄の場合が
+あります; とくにマッチングが失敗する運命にあるときはそうです。
+簡単なパターンを考えてみます
/^\w+\s+\w+$/; # a word, spaces, a word
@@ -3045,14 +3056,12 @@
=end original
-Whenever this is applied to a string which doesn't quite meet the
-pattern's expectations such as S<C<"abc ">> or S<C<"abc def ">>,
-the regex engine will backtrack, approximately once for each character
-in the string. But we know that there is no way around taking I<all>
-of the initial word characters to match the first repetition, that I<all>
-spaces must be eaten by the middle part, and the same goes for the second
-word.
-(TBT)
+これが、S<C<"abc ">> や S<C<"abc def ">> のような、パターンが
+想定していなかったような文字列に適用されると、正規表現エンジンは
+文字列のそれぞれの文字に対してほぼ 1 回バックトラックを行います。
+しかし、私たちは I<全ての> 最初の単語文字列が最初の繰り返しにマッチングし、
+I<全ての> 空白が中間の部分で消費され、2 番目の単語も同じように
+なるしかない、ということを知っています。
=begin original
@@ -3137,14 +3146,13 @@
=end original
-As an example where a possessive quantifier is suitable we consider
-matching a quoted string, as it appears in several programming languages.
-The backslash is used as an escape character that indicates that the
-next character is to be taken literally, as another character for the
-string. Therefore, after the opening quote, we expect a (possibly
-empty) sequence of alternatives: either some character except an
-unescaped quote or backslash or an escaped character.
-(TBT)
+絶対最大量指定子がふさわしい例として、いくつかのプログラミング言語で
+現れるような、クォートされた文字列のマッチングを考えます。
+バックスラッシュは次の文字が他の文字と同様リテラルに扱われることを示す
+エスケープ文字として使われます。
+従って、開きクォートの後、選択肢の(空かもしれない)並びを想定します:
+エスケープされていないクォート文字以外の何らかの文字か、
+バックスラッシュか、エスケープされた文字です。
/"(?:[^"\\]++|\\.)*+"/;
@@ -4791,12 +4799,9 @@
コンパイル済み正規表現は、現れるたびにコンパイルする必要のない動的な
マッチングを生成するのに便利です。
-コンパイル済み正規表現を使って、
-we write a C<grep_step> program
-which greps
-for a sequence of patterns, advancing to the next pattern as soon
-as one has been satisfied.
-(TBT)
+コンパイル済み正規表現を使って、ひとつのパターンを満足したらすぐに
+次のパターンに進むような、パターンの並びを grep する
+C<grep_step> を書けます。
% cat > grep_step
#!/usr/bin/perl
@@ -4848,8 +4853,8 @@
=end original
-Backtracking is more efficient than repeated tries with different regular
-expressions. If there are several regular expressions and a match with
+バックトラッキングは、異なる正規表現を繰り返し試すよりも効果的です。
+If there are several regular expressions and a match with
any of them is acceptable, then it is possible to combine them into a set
of alternatives. If the individual expressions are input data, this
can be done by programming a join operation. We'll exploit this idea in
@@ -5274,12 +5279,11 @@
=end original
-Here is an example where a string containing blank-separated words,
-numbers and single dashes is to be split into its components.
-Using C</\s+/> alone won't work, because spaces are not required between
-dashes, or a word or a dash. Additional places for a split are established
-by looking ahead and behind:
-(TBT)
+これは、空白で区切られた単語、数値、一つのダッシュを含む文字列を、その要素で
+split するという例です。
+単に C</\s+/> だけを使っても動作しません; なぜならダッシュの間、単語、
+ダッシュには空白が不要だからです。
+split のための追加の場所は前方参照と後方参照で構築されます:
$str = "one two - --6-8";
@toks = split / \s+ # a run of spaces
Index: docs/perl/5.10.0/perlunicode.pod
diff -u docs/perl/5.10.0/perlunicode.pod:1.3 docs/perl/5.10.0/perlunicode.pod:1.4
--- docs/perl/5.10.0/perlunicode.pod:1.3 Wed Feb 18 00:56:03 2009
+++ docs/perl/5.10.0/perlunicode.pod Wed Apr 1 01:29:20 2009
@@ -564,9 +564,8 @@
=end original
Unicode の文字と符号位置の間の変換を行う新たな C<U> 指定子があります。
-There is also a C<W> specifier that is the equivalent of
-C<chr>/C<ord> and properly handles character values even if they are above 255.
-(TBT)
+C<chr>/C<ord> と等価で、文字の値が 255 を超えていても適切に扱える
+C<W> 指定子もあります。
=item *
@@ -604,16 +603,15 @@
=end original
-The bit string operators, C<& | ^ ~>, can operate on character data.
-However, for backward compatibility, such as when using bit string
-operations when characters are all less than 256 in ordinal value, one
-should not use C<~> (the bit complement) with characters of both
-values less than 256 and values greater than 256.
-最も重要なことはド・モルガンの法則 (C<~($x|$y) eq ~$x&~$y> と
+ビット文字列演算子 C<& | ^ ~> は文字データを操作できます。
+しかし、例えば全ての文字の値が 255 以下のときに
+ビット文字列演算を使った場合の後方互換性のために、
+256 以上の値の文字と 255 以下の値の文字の両方が含まれている文字列に
+C<~> (ビット補数) を使うべきではありません。
+最も重要なことは、ド・モルガンの法則 (C<~($x|$y) eq ~$x&~$y> と
C<~($x&$y) eq ~$x|~$y>) が成り立たないということです。
この数学的な I<過失> の理由は補数(complement)が 8 ビットのビット補数
B<および> 文字幅のビット補数の B<両方> を返すことができないためです。
-(TBT)
=item *