[perldocjp-cvs 267] CVS update: docs/perl/5.10.0

アーカイブの一覧に戻る

argra****@users***** argra****@users*****
2008年 6月 5日 (木) 16:33:43 JST


Index: docs/perl/5.10.0/perluniintro.pod
diff -u docs/perl/5.10.0/perluniintro.pod:1.1 docs/perl/5.10.0/perluniintro.pod:1.2
--- docs/perl/5.10.0/perluniintro.pod:1.1	Fri May 30 04:08:20 2008
+++ docs/perl/5.10.0/perluniintro.pod	Thu Jun  5 16:33:43 2008
@@ -49,14 +49,15 @@
 
 =end original
 
-Unicode と、ISO/IEC 10646 は、よく調整された、コードポイントを提供する標準です。
+Unicode と、ISO/IEC 10646 は、よく調整された、コードポイントを提供する
+標準です。
 Unicode は、ほとんど全ての現代の文字セット標準、30 以上の書記体系と、
 100 以上の言語を網羅します。
 全ての商業的に重要な現代の言語を含みます。
 もっとも大きい中国語、日本語、韓国語、それぞれの辞書の全ての文字もまた、
 符号化されています。
-この標準は、最終的には、250 の書記体系と、
-1000 以上の言語のほとんどすべての文字を網羅する予定です。
+この標準は、最終的には、250 の書記体系と、1000 以上の言語のほとんどすべての
+文字を網羅する予定です。
 Unicode 1.0 は、1991 年 10 月にリリースされ、Unicode 4.0 は、
 2003 年 4 月にリリースされました。
 
@@ -72,8 +73,8 @@
 =end original
 
 Unicode の I<文字> は、抽象的な存在です。
-Unicode の文字は、
-どんな特定の整数幅にも、特に、C 言語の C<char> にも束縛されません。
+Unicode の文字は、どんな特定の整数幅にも、特に、C 言語の C<char> にも
+束縛されません。
 Unicode は、言語中立で、表示中立です:
 Unicode は、テキストの言語をエンコードしませんし、
 フォントや他のグラフィカルなレイアウトの詳細を定義しません。
@@ -88,9 +89,8 @@
 
 =end original
 
-Unicode は、C<LATIN CAPITAL LETTER A> や
-C<GREEK SMALL LETTER ALPHA> のような文字と、
-その文字について固有の番号を定義します。
+Unicode は、C<LATIN CAPITAL LETTER A> や C<GREEK SMALL LETTER ALPHA> のような
+文字と、その文字について固有の番号を定義します。
 この場合は、それぞれ、0x0041 と、0x03B1 になります。
 このような固有の番号は、I<コードポイント> と呼ばれます。
 
@@ -105,8 +105,8 @@
 =end original
 
 Unicode 標準は、コードポイントに 16 進記法を使うのを好みます。
-C<0x0041> のような番号に馴染みがなければ、
-後のセクション、L</"Hexadecimal Notation"> を覗いて見て下さい。
+C<0x0041> のような番号に馴染みがなければ、後のセクション、
+L</"Hexadecimal Notation"> を覗いて見て下さい。
 Unicode 標準は、C<U+0041 LATIN CAPITAL LETTER A> という表記を使って、
 16 進法のコードポイントと標準的な文字の名前を書きます。
 
@@ -123,8 +123,8 @@
 Unicode はまた、様々な文字の I<性質> を定義します。
 "大文字"、"小文字"、"10進数字"、"句読点" など;
 これらの性質は、文字の名前と独立です。
-更に、様々な文字に対する操作、
-大文字化や小文字化や並び替えが定義されています。
+更に、様々な文字に対する操作、大文字化や小文字化や並び替えが
+定義されています。
 
 =begin original
 
@@ -140,8 +140,8 @@
 (C<LATIN CAPITAL LETTER A> のような)、I<基本文字> に続いて、
 1つ以上の(C<COMBINING ACUTE ACCENT> のような) I<修飾語句> の、
 どちらか一方から成っています。
-この基本文字と修飾語句の順番は、
-I<combining character sequence> と呼ばれます。
+この基本文字と修飾語句の順番は、I<combining character sequence> と
+呼ばれます。
 
 =begin original
 
@@ -154,13 +154,13 @@
 
 =end original
 
-これらの combining character sequence を "複数の文字"と呼ぶかどうかは、
+これらの combining character sequence を "複数の文字" と呼ぶかどうかは、
 考え方によります。
 プログラマならば、おそらく、この順番のそれぞれの要素を、
-1 つの単位か"文字"として、見ようとするでしょう。
+1 つの単位か "文字" として、見ようとするでしょう。
 全ての順番を一つの"文字"として見ることができます。
-ですが、
-ユーザの考え方からは、おそらくユーザの言語の文脈でみえるようなものでしょう。
+ですが、ユーザの考え方からは、おそらくユーザの言語の文脈でみえるような
+ものでしょう。
 
 =begin original
 
@@ -173,13 +173,12 @@
 
 =end original
 
-この、文字の"すべての順番"の見え方では、文字の総数には、
-制限がありません。
-ですが、プログラマーの"一つの単位は一つの文字"という考え方では、
-"文字"の概念は、より決定論的です。
+この、文字の"すべての順番"の見え方では、文字の総数には、制限がありません。
+ですが、プログラマーの"一つの単位は一つの文字"という考え方では、"文字" の
+概念は、より決定論的です。
 このドキュメントでは、2 番目の考え方を取ります:
-1 つの"文字"は、1 つの Unicode のコードポイントであり、
-それは、基本文字か、 combining character であるとします。
+1 つの"文字"は、1 つの Unicode のコードポイントであり、それは、基本文字か、
+combining character であるとします。
 
 =begin original
 
@@ -195,17 +194,16 @@
 
 =end original
 
-いくつかの組合せにとって、I<まだ構成されていない>文字があります。
-たとえば、C<LATIN CAPITAL LETTER A WITH ACUTE>は、
+いくつかの組合せにとって、I<まだ構成されていない> 文字があります。
+たとえば、C<LATIN CAPITAL LETTER A WITH ACUTE> は、
 単一のコードポイントとして定義されています。
-しかし、これらの、まだ構成されていない文字は、
-いくつかの組合せで可能でしかありません。
-そして、それらは、
-主に、Unicode と、レガシー標準(ISO 8859 のような)との間の相互変換を
-サポートすることを意味します。
+しかし、これらの、まだ構成されていない文字は、いくつかの組合せで
+可能でしかありません。
+そして、それらは、主に、Unicode と、レガシー標準(ISO 8859 のような)との
+間の相互変換をサポートすることを意味します。
 一般的なケースでは、構成する方法はより広がります。
-違った構成間の変換をサポートするために、
-表現を標準化する、様々な I<normalization forms> もまた定義されています。
+違った構成間の変換をサポートするために、表現を標準化する、様々な
+I<normalization forms> もまた定義されています。
 
 =begin original
 
@@ -221,8 +219,8 @@
 =end original
 
 レガシーエンコーディングとの後方互換性のために、
-"全ての文字に固有の番号"とうい考えは、少々壊れています:
-その代わりに、"少なくとも全ての文字に 1 つの番号"があります。
+"全ての文字に固有の番号" という考えは、少々壊れています:
+その代わりに、"少なくとも全ての文字に 1 つの番号" があります。
 同じ文字が、いくつかのレガシーエンコーディングの中で、違うように
 表現されていました。
 逆は真でもなく: コードポイントには、文字が割り当てられていないものも
@@ -248,15 +246,15 @@
 
 Unicode について、よく知られている神話は、Unicode が、"16-ビット" である、
 というものです。
-Unicode は、C<0x0000> から、C<0xFFFF> までで、
-C<0x10000> (か、65536)の文字を表現するだけ、というものです。
+Unicode は、C<0x0000> から、C<0xFFFF> までで、C<0x10000> (か、65536)の
+文字を表現するだけ、というものです。
 B<これは真実ではありません>。
 Unicode 2.0(1996 年 7 月)から、Unicode は、21ビット(C<0x10FFFF>)まで、
 様々に定義されています。
 Unicode 3.1(2001 年 3 月)から、文字は、C<0xFFFF> を超えて、定義されました。
 最初の C<0x10000> 文字は、
 I<Plane 0>、または、I<Basime Multilingual Plane>(BMP)と、と呼ばれました。
-Unicode 3.1 で、全部で 17(そう、17)のPlaneが定義されました -- ですが、
+Unicode 3.1 で、全部で 17(そう、17)の Plane が定義されました -- ですが、
 まだ、定義された全文字のどこにも、まだ近くにありません。
 
 =begin original
@@ -277,8 +275,8 @@
 それぞれのブロックは言語か言語のセットで使われている文字を
 定義するということです。
 B<これもまた真実ではありません>。
-ブロックに分割されたものはありますが、
-それは、ほとんど完全に、予想外のものです。
+ブロックに分割されたものはありますが、それは、ほとんど完全に、
+予想外のものです。
 代わりに、I<scripts> と呼ばれる、より有益なコンセプトがあります:
 C<Latin> script と、C<Greek> script と、その他のものがあります。
 scripts は、ふつう、いくつかのブロックの変えられた部分を測っています。
@@ -299,16 +297,15 @@
 =end original
 
 Unicode のコードポイントは、抽象的な数字です。
-この抽象的な数字を入出力するために、数字は、I<エンコードされる> 必要があるか、
-I<シリアライズされる> か、どうか、しなければなりません。
+この抽象的な数字を入出力するために、数字は、I<エンコードされる> 必要が
+あるか、I<シリアライズされる> か、どうか、しなければなりません。
 Unicode は、複数の I<character encoding forms> を定義していますが、
 その中で、I<UTF-8> は、たぶん、もっとも有名です。
 UTF-8 は、可変長のエンコーディングで、Unicode 文字を 1 から 6 バイト
-(only 4 with the currently defined characters)。
+(現在定義されている文字では 4 バイトまでです)。
 他のエンコーディングは、UTF-16 と UTF-32 と、それらの大小のエンディアンの
 変形(UTF-8 は、バイトオーダーと独立です)を含みます。
 ISO/IEC 10646 は、UCS-2 と UCS-4 の encoding forms を定義しています。
-(TBT)
 
 =begin original
 
@@ -366,7 +363,7 @@
 識別子の名前、文字の中と、正規表現のリテラルに、UTF-8 を使うことができます。
 これは、デフォルトではありません。
 なぜなら、レガシーの 8-bit データのスクリプトが壊れるからです。
-L<utf8>を見て下さい。
+L<utf8> を参照してください。
 
 =head2 Perl's Unicode Model
 
@@ -419,8 +416,8 @@
 =end original
 
 Perlのユーザは普通は、Perl がその内部文字列をたまたま、どのように
-エンコードするかを、知る必要も、気にする必要もありません。
-ですが、Unicode 文字列を PerlIO 層なしにストリームに出力しようとすると、
+エンコードするかを、知る必要も、気にする必要もありませんが、Unicode 文字列を
+PerlIO 層なしにストリームに出力しようとすると、
 関係するようになります -- one with the "default" encoding。
 このようなケースでは、内部的に使われている生のバイト列(それぞれの
 文字列の必要に応じて、ネイティブの文字セットか、UTF-8)が使われます。
@@ -482,7 +479,7 @@
 
 C<-C> コマンドラインスイッチか、C<PERL_UNICODE> 環境変数のどちらか一方を
 使うことで、標準ファイルハンドルと、デフォルトの C<open()> 層と、
-C<@ARGV> の UTF-8 化を自動的に有効に出来ます。
+C<@ARGV> の UTF-8 化を自動的に有効に出来ます;
 L<perlrun> の C<-C> スイッチのドキュメントを見て下さい。
 
 =begin original
@@ -513,7 +510,7 @@
 必要とします。
 ほとんど全ての Perl5.8 プラットフォームは、PerlIO を使います。
 ですが:
-"perl -V" を動かして、C<useperlio=define> を見れば、 PerlIO を
+"perl -V" を動かして、C<useperlio=define> を見れば、PerlIO を
 使っているかどうか、わかります。
 
 =head2 Unicode and EBCDIC
@@ -532,8 +529,8 @@
 Perl 5.8.0 は、EBCDIC プラットフォームでもまた、Unicode をサポートします。
 There,
 Unicode support is somewhat more complex to implement since
-additional conversions are needed at every step.  Some problems
-remain, see L<perlebcdic> for details.
+additional conversions are needed at every step.
+いくつかの問題が残っています; 詳しくは L<perlebcdic> を参照してください。
 (TBT)
 
 =begin original
@@ -622,11 +619,11 @@
 
 =end original
 
-C<0x100>(10 進の 256)未満の引数の、C<\x..> (C<{}> ではなく、
+C<0x100>(10 進の 256)未満の引数の、C<\x..> (C<{}> なしで、
 2 つの 16 進数の数字のみです)と、C<\x{...}> と、C<chr(...)> は、古い
 Perl との互換性のために、8 ビットの文字列を生成します。
-C<x100> かそれ以上の引数では、Unicode 文字が、常に生成されます。
-何が何でも、数字の値の Unicode 文字を、強制的にに生成したければ、
+C<x100> かそれ以上の引数では、常に Unicode 文字が生成されます。
+何が何でも、数字の値の Unicode 文字を、強制的に生成したければ、
 C<\x..>、C<\x{...}>、C<chr()> の代わりに、C<pack("U", ...)> を使って下さい。
 
 =begin original
@@ -637,7 +634,7 @@
 =end original
 
 ダブルクォートされた文字列内で、名前で文字を呼び出すために、
-C<charnames> プラグマを使うこともできます。
+C<charnames> プラグマを使うこともできます:
 
     use charnames ':full';
     my $arabic_alef = "\N{ARABIC LETTER ALEF}";
@@ -649,7 +646,7 @@
 
 =end original
 
-そして、上述のように、数字を Unicode 文字に、C<pack()> できます。
+そして、上述のように、数字を Unicode 文字に、C<pack()> できます:
 
    my $georgian_an  = pack("U", 0x10a0);
 
@@ -663,8 +660,8 @@
 
 C<\x{...}> と、C<\N{...}> の両方は、コンパイル時の文字列定数です:
 その中に変数を使うことはできません。
-類似のことを実行時にしたいなら、
-c<chr()> と、C<charnames::vianame()> を使ってください。
+類似のことを実行時にしたいなら、c<chr()> と、C<charnames::vianame()> を
+使ってください。
 
 =begin original
 
@@ -674,9 +671,8 @@
 
 =end original
 
-結果を、Unicode 文字に強制したいなら、特別な、C<"U0"> 接頭辞を
-使って下さい。
-これは、引数を消費しませんが、引き続くバイト列を Unicode 文字の
+結果を Unicode 文字に強制したいなら、特別な、C<"U0"> 接頭辞を使って下さい。
+これは引数を消費しませんが、引き続くバイト列を Unicode 文字の
 UTF-8 エンコーディングとして解釈させます:
 
    my $chars = pack("U0W*", 0x80, 0x42);
@@ -688,13 +684,12 @@
 
 =end original
 
-Likewise, you can stop such UTF-8 interpretation by using the special
-C<"C0"> prefix.
-(TBT)
+同様に、特殊な C<"C0"> 接頭辞を使うことによって、このような UTF-8 の解釈を
+停止させることができます。
 
 =head2 Handling Unicode
 
-(Unicode を使う)
+(Unicode を扱う)
 
 =begin original
 
@@ -707,8 +702,8 @@
 
 Unicode を扱うことは、多くの部分にとって、透過的です:
 文字列をいつものように使うだけです。
-C<index()>、C<length()>、C<substr()> のような関数は
-Unicode 文字列で動きます;
+C<index()>、C<length()>、C<substr()> のような関数は Unicode 文字列で
+動きます;
 正規表現も Unicode 文字列で動きます(L<perlunicode> と L<perlretut> を
 参照してください)。
 
@@ -719,7 +714,7 @@
 
 =end original
 
-Perlは、 combining character sequences を別々の文字と考えていることに
+Perl は combining character sequences を別々の文字と考えていることに
 注意して下さい。
 ですので、例えば
 
@@ -744,9 +739,8 @@
 
 =end original
 
-Life is not quite so transparent, however, when working with legacy
-encodings, I/O, and certain special cases:
-(TBT)
+しかし、レガシーエンコーディング、I/O、そしてある種の特殊な状況では、
+人生はそれほど透過的ではありません:
 
 =head2 Legacy Encodings
 
@@ -761,8 +755,8 @@
 =end original
 
 レガシーデータと Unicode とを組み合わせる時は、
-レガシーデータを、Unicode にアップグレードしなければなりません。
-通常、ISO 8859-1 (か、必要なら EBCDIC)が想定されます。
+レガシーデータを Unicode にアップグレードしなければなりません。
+通常、ISO 8859-1 (か、必要なら EBCDIC)が仮定されます。
 
 =begin original
 
@@ -771,7 +765,7 @@
 
 =end original
 
-C<Encode> モジュールは、多くのエンコーディングを知っており、
+C<Encode> モジュールは多くのエンコーディングを知っており、
 それらのエンコーディングの間の変換をするインターフェースを持っています。
 
     use Encode 'decode';
@@ -845,11 +839,9 @@
 エンコーディング名のマッチングはルーズです: 大文字小文字は重要ではなく、
 多くのエンコーディングでは、いくつかの別名があります。
 C<:utf8> 層は、常に、きっちりとそのように指定される必要があります。
-このことは、エンコーディング名のルーズなマッチングの主題では I<ありません>。
-Also note that C<:utf8> is unsafe for
-input, because it accepts the data without validating that it is indeed valid
-UTF8.
-(TBT)
+このことは、エンコーディング名のルーズなマッチングの対象では I<ありません>。
+データが妥当な UTF8 であるかどうかを検証せずに受け入れるので、入力に
+対しては C<:utf8> は安全ではないことにも注意してください。
 
 =begin original
 
@@ -860,10 +852,10 @@
 
 =end original
 
-C<:utf8> 層に関しては、L<PerlIO> を見て下さい。
-C<:encoding()> に関しては、L<Encode::PerlIO> を見て下さい。
+C<:utf8> 層に関しては、L<PerlIO> を参照してください;
+C<:encoding()> に関しては、L<Encode::PerlIO> を参照してください;
 C<Encode> モジュールでサポートされている、多くのエンコーディングに関しては、
-L<Encode::Supported> を見て下さい。
+L<Encode::Supported> を参照してください。
 
 =begin original
 
@@ -893,7 +885,7 @@
 =end original
 
 I/O 層は、もっと柔軟に、C<open> プラグマでもまた、指定することが出来ます。
-L<open> を見るか、次の例を見て下さい。
+L<open> を参照するか、次の例を見て下さい。
 
     use open ':encoding(utf8)'; # input/output default encoding will be UTF-8
     open X, ">file";
@@ -909,7 +901,7 @@
 
 =end original
 
-C<open> プラグマで、C<:local> 層も使えます。
+C<open> プラグマで、C<:local> 層も使えます:
 
     BEGIN { $ENV{LC_ALL} = $ENV{LANG} = 'ru_RU.KOI8-R' }
     # the :locale will probe the locale environment variables like LC_ALL
@@ -930,8 +922,8 @@
 =end original
 
 ストリームからファイルが読まれるときに、特定のエンコーディングから、
-データを変換するI/Oストリーム上の透過的な層です。
-その結果は、常に Unicode です。
+データを変換する I/O ストリーム上の透過的な層です。
+その結果は常に Unicode です。
 
 =begin original
 
@@ -941,9 +933,9 @@
 
 =end original
 
-L<open> プラグマは、デフォルトの層を設定することで、プラグマの後の、
+L<open> プラグマは、デフォルトの層を設定することで、プラグマの後の
 全ての C<open()> 呼び出しに影響します。
-あるストリームだけに、影響を限定したいなら、C<open()> 呼び出しで、明示的な
+あるストリームだけに影響を限定したいなら、C<open()> 呼び出しで明示的な
 層を使って下さい。
 
 =begin original
@@ -953,9 +945,8 @@
 
 =end original
 
-C<binmode()>; を使って、すでに開かれているストリームで、エンコーディングを
-変えることが出来ます。
-L<perlfunc/binmode> を見て下さい。
+C<binmode()> を使って、すでに開かれているストリームのエンコーディングを
+変えることが出来ます; L<perlfunc/binmode> を参照してください。
 
 =begin original
 
@@ -966,10 +957,10 @@
 
 =end original
 
-C<:;pcate> は、現在(Perl 5.8.0 の時点で)、C<open()>と、C<binmode()> では
+C<:locale> は、現在(Perl 5.8.0 の時点で)、C<open()> と C<binmode()> では
 動きません。
 C<open> プラグマでのみ動きます。
-C<:utf8> と、C<:encoding(...)> メソッドは、全ての C<open()>、C<binmode()>、
+C<:utf8> と C<:encoding(...)> メソッドは、全ての C<open()>、C<binmode()>、
 C<open> プラグマで動きます。
 
 =begin original
@@ -986,7 +977,7 @@
 特定のエンコーディングに変換する、出力ストリームの I/O 層を使うかも
 知れません。
 例えば、次のようなコードの断片は、(ISO-2022-JP, またの名を JIS として
-エンコードされている)"text.jis" ファイルの内容を、UTF-8 として
+エンコードされている)" text.jis" ファイルの内容を、UTF-8 として
 エンコードされる "text.utf8" ファイルにコピーします。
 
     open(my $nihongo, '<:encoding(iso-2022-jp)', 'text.jis');
@@ -1001,7 +992,7 @@
 
 =end original
 
-C<open()> と、C<open> プラグマの両方で使われている、エンコーディングの
+C<open()> と、C<open> プラグマの両方で使われているエンコーディングの
 名前は、フレキシブルな名前でも使えます: C<koi8-r>と、C<KOI8R> は、
 両方とも理解されます。
 
@@ -1014,8 +1005,8 @@
 =end original
 
 ISO、MIME、IANA、様々な他の標準化機関が認識している、一般的な
-エンコーディングが認識されます: 詳細なリストは、L<Encode::Supported> を
-見て下さい。
+エンコーディングが認識されます; より詳細なリストは、
+L<Encode::Supported> を参照してください。
 
 =begin original
 
@@ -1026,8 +1017,8 @@
 =end original
 
 C<read()> は、文字を読み、文字の数を返します。
-C<seek()> と、C<tell()> は、バイトカウントに関して操作します。
-C<sysread> と、C<sysseek()> も同様です。
+C<seek()> と C<tell()> は、バイトカウントに関して操作します。
+C<sysread> と C<sysseek()> も同様です。
 
 =begin original
 
@@ -1039,7 +1030,7 @@
 =end original
 
 デフォルト層がなければ、入力になんの変換もしないのがデフォルトの
-振るまいなので、繰り返しデータをエンコーディングすることで、
+振る舞いなので、繰り返しデータをエンコーディングすることで、
 ファイルを展開し続けるコードを誤って書きやすいです。
 
     # BAD CODE WARNING
@@ -1061,7 +1052,7 @@
 
 このコードを 2 回実行すると、F<file> の内容は、UTF-8 に、2 回
 エンコードされます。
-C<use open 'encoding(utf8)'> は、バグを避けるでしょう。
+C<use open 'encoding(utf8)'> は、バグを避けるでしょう;
 もしくは、UTF-8 として入力するために、F<File> を、明示的に開くことです。
 
 =begin original
@@ -1072,9 +1063,9 @@
 
 =end original
 
-B<注意>: C<:utf8> と、C<:encoding> の機能は、Perl が、新しい PerlIO の
-機能で、ビルドされている場合のみ、動きます
-(ほとんどのシステムで、それがデフォルトです)。
+B<注意>: C<:utf8> と C<:encoding> の機能は、Perl が新しい PerlIO の機能で
+ビルドされている場合(ほとんどのシステムで、それがデフォルトです)にのみ
+動作します。
 
 =head2 Displaying Unicode As Text
 
@@ -1093,7 +1084,7 @@
 Unicode を含んでいる Perl のスカラを、単純な ASCII(か、EBCDIC)の
 テキストとして、表示したいかもしれません。
 下のサブルーチンは、引数を変換して、255 より大きいコードポイントの
-Unicode 文字を、C<\x{...}> として表示し、(C<\n> のような)コントロール文字は、
+Unicode 文字を、C<\x{...}> として表示し、(C<\n> のような)制御文字は、
 C<\x..> として表示します。
 残りの文字は、そのまま表示します:
 
@@ -1123,7 +1114,7 @@
 
 =end original
 
-次のような文字列になり:
+は、次のような文字列になり:
 
    'foo\x{0100}bar\x0A'
 
@@ -1165,13 +1156,13 @@
 
 演算子 C<~> は、255 を超える序数の値の文字を含んでいる文字列で、
 使われると、驚くべき結果になるでしょう。
-そのようなケースでは、
-その結果は文字の内部的なエンコーディングで一貫性があります。
+そのようなケースでは、その結果は文字の内部的なエンコーディングで一貫性が
+あります。
 しかし、他の多くでは違います。
 ですので、そのようなことはしないでください。
 C<vec()> も同様です: コードポイントの値ではなく、内部的にエンコードされた、
-Unicode 文字列のビットパターンを操作しているでしょう。
-おそらく、それは、望んでいないでしょう。
+Unicode 文字列のビットパターンを操作することになります;
+おそらく、それは望んだことではないでしょう。
 
 =item *
 
@@ -1193,11 +1184,11 @@
 
 =end original
 
-(Unicode で文字列の内容に達する普通の方法 -- 入出力 -- は、つねに、
-明示的に定義された I/O 層を経由すべきです)
-Perl がどのように、どんな特別な Unicode 文字列をエンコードしているかを、
-Perl の普通のユーザは気にするべきではありません。
-ですが、必要なら、隠れている裏側を見る 2 つの方法があります。
+Perl がどのように、特定の Unicode 文字列をエンコードしているかを、
+Perl の普通のユーザは気にするべきではありません
+(Unicode で文字列の内容に達する普通の方法 -- 入出力によって -- は、常に
+明示的に定義された I/O 層を経由すべきだからです)。
+ですが、もし必要なら、隠れている裏側を見る 2 つの方法があります。
 
 =begin original
 
@@ -1208,7 +1199,7 @@
 
 =end original
 
-Unicode文字を内部的にエンコーディングする、内側を覗き見る 1 つの方法は、
+Unicode 文字を内部的にエンコーディングする、内側を覗き見る 1 つの方法は、
 C<unpack("C*", ...> を使い、to get the bytes of whatever the string
 encoding happens to be, or C<unpack("U0..", ...)> to get the bytes of the
 UTF-8 encoding:
@@ -1223,7 +1214,7 @@
 
 =end original
 
-別の方法は、Dvel::Peek モジュールを使うことです:
+もう一つの方法は、Dvel::Peek モジュールを使うことです:
 
     perl -MDevel::Peek -e 'Dump(chr(0x100))'
 
@@ -1237,12 +1228,15 @@
 
 これは、FLAGS の C<UTF8> フラグと、UTF-8 バイトと、C<PV> の中の
 Unicode 文字の両方を見せます。
-このドキュメントの後にある、C<utf8::is_utf8()> 機能についての議論も見て下さい。
+このドキュメントの後にある、C<utf8::is_utf8()> 機能についての議論も
+参照してください。
 
 =back
 
 =head2 Advanced Topics
 
+(発展した話題)
+
 =over 4
 
 =item *
@@ -1263,7 +1257,7 @@
 =end original
 
 文字列の等価性の疑問は、Unicode でいくぶん複雑になります。
-"等価"で、何を意味していますか?
+"等価" で、何を意味していますか?
 
 =begin original
 
@@ -1273,7 +1267,7 @@
 =end original
 
 (IS C<LATIN CAPITAL LETTER A WITH ACCUTE> と
-C<LATIN CAPITAL LETTER A>は、等しいでしょうか?)
+C<LATIN CAPITAL LETTER A>は、等しいでしょうか?)
 
 =begin original
 
@@ -1285,11 +1279,11 @@
 =end original
 
 短く答えれば次のようになります。
-デフォルトでは、Perl は(C<eq> と、C<ne> で)等しさを
+デフォルトでは、Perl は(C<eq> と、C<ne> で)等価性を
 比較しますが、これらは、文字のコードポイントでのみに基づいています。
 上のケースでは、答えはいいえです(0x00C1 != 0x0041 ですから)。
-ですが、どんな CAPITAL LETTER A もどんなケースの A も等しいと考えるべき
-時もあります。
+しかし、どんな CAPITAL LETTER A も等しいと考えるべき時や、大文字小文字に
+関わらずどんな A も等しいと考えるべき時もあります。
 
 =begin original
 
@@ -1301,7 +1295,7 @@
 
 =end original
 
-長く答えるなら、文字標準化と大文字小文字の問題を考える必要があります:
+長く答えるなら、文字の正規化と大文字小文字の問題を考える必要があります:
 L<Unicode::Normalize>、Unicode テクニカルレポート #15 と #21 である
 I<Unicodde Normalization Forms> と I<Case Mappings>
 ( http://www.unicode.org/unicode/reports/tr15/,
@@ -1325,8 +1319,7 @@
 
 =end original
 
-String Collation
-(TBT)
+文字列の照合(Collation)
 
 =begin original
 
@@ -1335,10 +1328,9 @@
 
 =end original
 
-文字列がうまくソートされているのを好みます-- or as Unicode
-parlance goes, collated。
- ですが、再び、collate で何を意味していますか?
-(TBT)
+文字列がうまくソートされている(あるいは Unicode の業界用語を使えば、
+照合されている(collated))のを好みます。
+ですが、再び、照合で何を意味していますか?
 
 =begin original
 
@@ -1349,7 +1341,7 @@
 
 (C<LATIN CAPITAL LETTER A WITH ACUTE> は、
 C<LATIN CAPITAL LETTER A WITH GRAVE> より、
-前でしょうか後でしょうか?)
+前でしょうか後でしょうか?)
 
 =begin original
 
@@ -1363,7 +1355,7 @@
 短く答えれば次のようになります。
 Perl は、文字列を、(C<lt>、C<le>、C<cmp>、C<ge>、C<gt>)で比較しますが、
 これらは、文字のコードポイントでのみに基づいています。
-上のケースでは、答えは、C<0x00C1> > C<0x00C0>ですので、"後"になります。
+上のケースでは、答えは、C<0x00C1> > C<0x00C0> ですので、"後"になります。
 
 =begin original
 
@@ -1375,9 +1367,10 @@
 =end original
 
 長く答えるなら、"依存して"います。
-良い答えは、(とても少なくとも)言語のコンテキストを知らずには、与えられません。
-L<Unicode::Collate>と、I<Unicode Collation Algorithm> を見て下さい。
-http://www.unicode.org/unicode/reports/tr10/
+良い答えは、(とても少なくとも)言語のコンテキストを知らずには、
+与えられません。
+L<Unicode::Collate>, I<Unicode Collation Algorithm>
+http://www.unicode.org/unicode/reports/tr10/ を参照してください。
 
 =back
 
@@ -1395,8 +1388,7 @@
 
 =end original
 
-Character Ranges and Classes
-(TBT)
+文字の範囲とクラス
 
 =begin original
 
@@ -1408,11 +1400,10 @@
 
 =end original
 
-正規表現の文字クラス(C</[a-z]/>)内と、C<tf///>(C<y///>としても知られる)
-演算子内では、魔法を使ったようには、Unicode に気付きません。
-これが意味することは、C<[A-Za-z]> は、"全てのアルファベット文字"を
-魔法を使ったようには意味しはじめません。
-8 ビットの文字で意味します。
+正規表現の文字クラス(C</[a-z]/>)内と、C<tf///>(C<y///> としても知られる)
+演算子内では、自動的には Unicode 対応にはなりません。
+これが意味することは、C<[A-Za-z]> は、自動的に "全てのアルファベット文字"を
+意味するようにはなりません; 8 ビットの文字で意味します;
 このケースでは、C</[[:alpha:]]/> を使うべきです。
 
 =begin original
@@ -1427,10 +1418,10 @@
 
 =end original
 
-正規表現内のこのような特定の文字クラスに、様々な Unicode プロパティ--
+正規表現内のこのような特定の文字クラスに、様々な Unicode プロパティ --
 C<\pL>、または、この特別なケースでは、たぶん、C<\p{Alphabetic}> を
 使うことができます。
-文字の範囲の終りのポイントとして、Unicode のコードポイントを
+文字の範囲の終わりのポイントとして、Unicode のコードポイントを
 使うことが出来ます。
 ですが、ある範囲を特定するのに結びつける何の魔法もありません。
 詳しいことは--数ダースの Unicode 文字クラスがあります--
@@ -1476,7 +1467,7 @@
 
 =end original
 
-古いスクリプトは壊れるでしょうか?
+古いスクリプトは壊れるでしょうか?
 
 =begin original
 
@@ -1491,11 +1482,12 @@
 =end original
 
 たぶん、壊れません。
-どうにかして、Unicode 文字を生成していなければ、古い挙動は、保護されます。
-変更される、Unicode を生成し始める唯一の挙動は古い C<chr()> の挙動です。
-ここでは、255 を法として、文字を生成する 255 より上の引数を供給します。
-C<chr(300)> は、例えば、C<chr(45)> か、(ASCII の)"-" と同じでした。
-現在は、それは、LATIN CAPITAL LETTER I WITH BREVE と同じです。
+どうにかして、Unicode 文字を生成していなければ、古い挙動は保護されます。
+振る舞いが変更され、Unicode を生成し始める唯一のものは、古い C<chr()> は
+引数として 255 を超える値が指定されると、255 を法とした文字が生成される
+というものです。
+例えば、C<chr(300)> は、C<chr(45)> あるいは (ASCII の)"-" と同じでした。
+現在ではそれは、LATIN CAPITAL LETTER I WITH BREVE です。
 
 =item *
 
@@ -1505,7 +1497,7 @@
 
 =end original
 
-Unicode スクリプトを動かすにはどうすればいいですか?
+私のスクリプトを Unicode で動かすには?
 
 =begin original
 
@@ -1527,7 +1519,7 @@
 
 =end original
 
-Unicode の文字列かどうかを知るにはどうしますか?
+Unicode の文字列かどうかを知るには?
 
 =begin original
 
@@ -1538,10 +1530,10 @@
 =end original
 
 気にすることはありません。
-本当に、気にするべきではありません。
-本当に。
+ええ、本当に、気にするべきではありません。
+ええ、本当に。
 気にする必要があるなら -- このケースは上で書いています --
-本当に正しく、Unicode の透過性を得ないことを意味します。
+本当に正しく、Unicode の透過性を得ていないことを意味します。
 
 =begin original
 
@@ -1571,19 +1563,20 @@
 
 =end original
 
-ですが、これは、文字列の文字のすべてが、UTF-8 でエンコードされているか、
-文字のすべてが、0xFF(255) か、0x80(128) より大きいコードポイントか、
-文字列はすべて文字をもつ必要があります。
+しかし、これは、文字列の文字のすべてが UTF-8 でエンコードされているとか、
+文字のすべてが 0xFF(255)(あるいは 0x80(128)) より大きいコードポイントを
+持つとか、文字列に文字が含まれているかとかいうことを
+意味するわけではないことに注意してください。
 C<is_utf8()> がすることの全ては、C<$string> につけられている内部の
 "utf8ness" フラグの値を返すことです。
 フラグが無効であれば、スカラ内のバイト列は、シングルバイト
 エンコーディングとして解釈されます。
-フラグが有効であれば、スカラ内のバイト列は、(マルチバイト、可変調の) 
+フラグが有効であれば、スカラ内のバイト列は、(マルチバイト、可変長の) 
 UTF-8 でエンコードされた文字のコードポイントとして解釈されます。
-非 UTF-8 と、UTF-8 のスカラがマージされた(ダブルクオートされた語句、
-明示的な連結、printf/sprintf パラメタの代用)場合、この結果は、
+(ダブルクオートされた語句、明示的な連結、printf/sprintf パラメタ
+置換によって)非 UTF-8 と、UTF-8 のスカラがマージされた場合、この結果は、
 バイト文字列のコピーが UTF-8 でアップグレードされるように、
-UTF-8 でエンコードされています。
+UTF-8 でエンコードされています: 例えば、
 
     $a = "ab\x80c";
     $b = "\x{100}";
@@ -1596,8 +1589,8 @@
 
 =end original
 
-出力する文字列は UTF-8 エンコードされた C<ab\x80c = \x{100}\n> になります。
-ですが、C<$a> は、バイトエンコードされます。
+出力する文字列は UTF-8 エンコードされた C<ab\x80c = \x{100}\n> になりますが、
+C<$a> は、バイトエンコードされたままです。
 
 =begin original
 
@@ -1628,7 +1621,7 @@
 
 =end original
 
-あるエンコーディングで、データが、妥当でないことを調べるにはどうしますか?
+あるエンコーディングで、データが妥当でないことを検出するには?
 
 =begin original
 
@@ -1654,8 +1647,7 @@
 
 =end original
 
-Or use C<unpack> to try decoding it:
-(TBT)
+または C<unpack> を使ってデコードしてみてください:
 
     use warnings;
     @chars = unpack("C0U*", $string_of_bytes_that_I_think_is_utf8);
@@ -1685,7 +1677,7 @@
 
 =end original
 
-バイナリデータを特定のエンコーディングに変換するには?また、その逆は?
+バイナリデータを特定のエンコーディングに変換するには? また、その逆は?
 
 =begin original
 
@@ -1795,9 +1787,8 @@
 
 =end original
 
-If you have a sequence of bytes you B<know> is valid UTF-8,
-but Perl doesn't know it yet, you can make Perl a believer, too:
-(TBT)
+あなたはバイト列が妥当な UTF-8 であると B<分かっている> けれども、Perl が
+知らない場合、Perl に信じさせることができます:
 
     use Encode 'decode_utf8';
     $Unicode = decode_utf8($bytes);
@@ -1808,8 +1799,7 @@
 
 =end original
 
-or:
-(TBT)
+または:
 
     $Unicode = pack("U0a*", $bytes);
 
@@ -1848,7 +1838,7 @@
 =end original
 
 http://www.alanwood.net/unicode/ と
-http://www.cl.cam.ac.uk/~mgk25/unicode.html を見てください。
+http://www.cl.cam.ac.uk/~mgk25/unicode.html を参照してください。
 
 =item *
 
@@ -1858,7 +1848,7 @@
 
 =end original
 
-これまでのロケールで、Unicode は、どのようにうごきますか?
+伝統的なロケールと Unicode は、どのように動きますか?
 
 =begin original
 
@@ -1871,10 +1861,10 @@
 =end original
 
 Perl では、あまりうまくありません。
-C<locale>プラグマでロケールを使うことを避けて下さい。
-1 つのみか、別のものを使ってください。
-C<-C> スイッチと、その環境で対応する C<$ENV{PERL_UNICODE}> の説明のために、
-L<perlrun> を見て下さい。
+C<locale> プラグマでロケールを使うことを避けて下さい。
+どちらか片方だけを使ってください。
+しかし、C<-C> スイッチと、それに対応する環境変数である
+C<$ENV{PERL_UNICODE}> の説明のために、L<perlrun> を参照してください;
 様々な Unicode の機能が、どのように可能になっているのか、たとえば、
 ロケールの設定によって、が、わかります。
 
@@ -1900,8 +1890,7 @@
 他の表記よりわかりやすいからです。
 10 進記法を使うことも出来ますが、16 進記法を使うことを学べば、
 Unicode 標準との暮らしが楽になります。
-C<U+HHHH> 表記は、16 進記法を使います。
-たとえば、
+例えば、C<U+HHHH> 表記は、16 進記法を使います。
 
 =begin original
 
@@ -1915,9 +1904,8 @@
 =end original
 
 C<0x> の接頭辞は、16 進の数字を意味しています。
-数字は、0-9 と、
-a-f(か、A-F、大文字小文字は問いません)です。
-それぞれの、16 進の数字は、4 ビット、1/2 バイトを表します。
+数字は、0-9 I<および> a-f(か、A-F、大文字小文字は問いません)です。
+それぞれの 16 進の数字は 4 ビット、1/2 バイトを表します。
 C<print 0x..., "\n"> は 16 進数を 10 進で見せます。
 C<printf "%x\n", $decimal> は 10 進数を 16 進で見せます。
 "hex digits" の 16 進の数字があるなら、C<hex()> 関数を使うことが出来ます。
@@ -1994,7 +1982,8 @@
 
 =end original
 
-Unicode サポートのファイルは、Perl をインストールしたディレクトリ内にあります
+Unicode サポートのファイルは、Perl をインストールしたディレクトリ内に
+あります;
 
     $Config{installprivlib}/unicore
 
@@ -2004,7 +1993,7 @@
 
 =end original
 
-Perl 5.8.0 以上では、
+Perl 5.8.0 以上ではここです;
 
     $Config{installprivlib}/unicode
 
@@ -2017,10 +2006,10 @@
 
 =end original
 
-Perl 5.6 シリーズでは。
+Perl 5.6 シリーズではここです。
 (大文字小文字を区別しないファイルシステムでは、lib/Unicode 名前の衝突を
-避けるために、F<lib/unicore> にリネームされています)
-メインの Unicode データファイルは、F<UnicodeData.txt>(か、Perl5.6.1 の
+避けるために、F<lib/unicore> にリネームされています。)
+メインの Unicode データファイルは、F<UnicodeData.txt>(か、Perl 5.6.1 の
 F<Unicode.301>)です。
 次のようにして、C<$Config{installprivlib}> を見つけることができます。
 
@@ -2033,7 +2022,7 @@
 
 =end original
 
-C<Unicode::UCD> モジュールを使って、Unicode データファイルから、
+C<Unicode::UCD> モジュールを使って、Unicode データファイルから
 様々な情報を調べることができます。
 
 =back
@@ -2054,10 +2043,9 @@
 
 Perl 5.8.0 以降にアップグレード出来なくても、まだ、CPAN から利用できる、
 C<Unicode::String>、C<Unicode::Mmap8>、C<bUnicode::Map> を使って、
-Unicode 処理をすることができます。
-If you have the GNU recode installed, you can also use the
-Perl front-end C<Convert::Recode> for character conversions.
-(TBT)
+いくつかの Unicode 処理ができます。
+GNU recode がインストールされているなら、それの Perl フロントエンドである
+C<Convert::Recode> を文字変換のために使えます。
 
 =begin original
 
@@ -2066,8 +2054,8 @@
 
 =end original
 
-下記のものは、ISO 8859-1 (Latin-1) バイト列から UTF-8 バイト列に、
-素早く変換するものです。
+下記のものは、ISO 8859-1 (Latin-1) バイト列から UTF-8 バイト列に
+(あるいはその逆に)素早く変換するものです。
 このコードは古い Perl 5 でも動きます。
 
     # ISO 8859-1 to UTF-8


perldocjp-cvs メーリングリストの案内
アーカイブの一覧に戻る