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

Back to archive index

argra****@users***** argra****@users*****
2009年 4月 18日 (土) 20:00:54 JST


Index: docs/perl/5.10.0/perlunicode.pod
diff -u docs/perl/5.10.0/perlunicode.pod:1.5 docs/perl/5.10.0/perlunicode.pod:1.6
--- docs/perl/5.10.0/perlunicode.pod:1.5	Sat Apr  4 01:35:44 2009
+++ docs/perl/5.10.0/perlunicode.pod	Sat Apr 18 20:00:54 2009
@@ -15,6 +15,8 @@
 
 =head2 Important Caveats
 
+(重要な警告)
+
 =begin original
 
 Unicode support is an extensive requirement. While Perl does not
@@ -108,8 +110,8 @@
 互換性のために、ASCII ベースのマシンにおいて Perl スクリプトそれ自身の
 中の UTF-8 を(文字列や正規表現リテラル、あるいは変数名で) 認識可能に
 するためや、EBCDIC ベースのマシンで UTF-EBCDIC を認識させるために
-C<use utf8> プラグマを陽に含めなければなりません。
-B<これらは陽に C<use utf8> が必要な唯一の場合です。>
+C<use utf8> プラグマを明示的に含めなければなりません。
+B<これらは明示的に C<use utf8> が必要な唯一の場合です。>
 L<utf8> を参照してください。
 
 =item BOM-marked scripts and UTF-16 scripts autodetected
@@ -162,6 +164,8 @@
 
 =head2 Byte and Character Semantics
 
+(バイトと文字のセマンティクス)
+
 =begin original
 
 Beginning with version 5.6, Perl uses logically-wide characters to
@@ -261,12 +265,12 @@
 
 =end original
 
-陽に指定されない限り、Perl の演算子は Unicode データに対しては
+明示的に指定されない限り、Perl の演算子は Unicode データに対しては
 文字セマンティクスを用い、非 Unicode データに対しては
 バイトセマンティクスを用います。
 文字セマンティクスの使用の決定はトランスペアレントに行われます。
 もし入力データが Unicode ソースから来たもの -- たとえば、
-文字エンコーディングレイヤーがファイルハンドルに附加されているか
+文字エンコーディング層がファイルハンドルに附加されているか
 リテラルの Unicode 文字列定数がプログラムの中にある -- のであれば
 文字セマンティクスが適用されます。
 そうでなければ、バイトセマンティクスが有効になります。
@@ -706,6 +710,8 @@
 
 =head2 Unicode Character Properties
 
+(Unicode 文字特性)
+
 =begin original
 
 Named Unicode properties, scripts, and block ranges may be used like
@@ -1313,6 +1319,8 @@
 
 =head2 User-Defined Character Properties
 
+(ユーザ定義文字特性)
+
 =begin original
 
 You can define your own character properties by defining subroutines
@@ -1553,6 +1561,8 @@
 
 =head2 User-Defined Case Mappings
 
+(ユーザ定義の大文字・小文字の対応関係)
+
 =begin original
 
 You can also define your own mappings to be used in the lc(),
@@ -1566,7 +1576,7 @@
 =end original
 
 同様に、lc()、lcfirst()、uc()、ucfirst() (あるいはその文字列組み込み版)で
-あなた自身のマッピングを定義することもできます。
+あなた自身の対応関係を定義することもできます。
 原則は
 ユーザー定義文字特性の場合と似ています: C<ToLower> (lc() と lcfirst()用), 
 C<ToTitle> (ucfirst() の最初の文字用), C<ToUpper> (uc() 用と ucfirst() の
@@ -1612,7 +1622,7 @@
 
 =end original
 
-もしソースの範囲に言及することがなければ、つまり、マッピングが単一の
+もしソースの範囲に言及することがなければ、つまり、対応関係が単一の
 文字から別の単一の文字に変換するものであったならば、ソースの範囲の
 終わりは空のままでよいけれども二つのタブは必要です。
 例を挙げましょう:
@@ -1647,7 +1657,7 @@
 
 =end original
 
-(For serious hackers only) デフォルトのマッピングを内省したいのなら、
+(真剣なハッカー専用) デフォルトのマッピングを内省したいのなら、
 C<$Config{privlib}>/F<unicore/To/> というディレクトリにデータを
 見つけ出すことができます。
 マッピングデータはヒアドキュメントとして返され、C<utf8::ToSpecFoo> は
@@ -1665,7 +1675,7 @@
 
 =end original
 
-ユーザー定義ケースマッピングに関する最後の注意: これらはスカラが
+ユーザー定義の大文字・小文字の対応関係に関する最後の注意: これらはスカラが
 Unicode 文字としてマークされているときにのみ使われます。
 古いバイト形式の文字列には影響を及ぼしません。
 
@@ -1683,6 +1693,8 @@
 
 =head2 Unicode Regular Expression Support Level
 
+(Unicode 正規表現対応レベル)
+
 =begin original
 
 The following list of Unicode support for regular expressions describes
@@ -1692,8 +1704,8 @@
 
 =end original
 
-以下に挙げるリストは現在サポートされているすべての機能を記述する
-正規表現のための Unicode サポートのリストです。
+以下に挙げるリストは、現在対応している全ての機能を記述する、
+正規表現のための Unicode 対応のリストです。
 "Level N" に対する参照とセクション番号は
 Unicode Technical Standard #18,
 "Unicode Regular Expressions", version 11, in May 2005
@@ -1877,6 +1889,8 @@
 
 =head2 Unicode Encodings
 
+(Unicode のエンコーディング)
+
 =begin original
 
 Unicode characters are assigned to I<code points>, which are abstract
@@ -1902,9 +1916,8 @@
 
 =end original
 
-UTF-8は可変長(1から6バイト。
-現在の文字アロケーションは4バイトを要求します)で、バイトの並び順に依存しない
-エンコーディングです。
+UTF-8 は可変長(1 から 6 バイト; 現在の文字配置では 4 バイトを要求します)で、
+バイトの並び順に依存しないエンコーディングです。
 ASCII(ここでは 7-bit ASCII のことで、他の 8-bit エンコーディングのことでは
 ありません)と UTF-8 は透過です。
 
@@ -1941,14 +1954,14 @@
 
 =end original
 
-Note the C<A0..BF> in C<U+0800..U+0FFF>, the C<80..9F> in
-C<U+D000...U+D7FF>, the C<90..B>F in C<U+10000..U+3FFFF>, and the
-C<80...8F> in C<U+100000..U+10FFFF>.  The "gaps" are caused by legal
-UTF-8 avoiding non-shortest encodings: it is technically possible to
-UTF-8-encode a single code point in different ways, but that is
-explicitly forbidden, and the shortest possible encoding should always
-be used.  So that's what Perl does.
-(TBT)
+C<U+0800..U+0FFF> の中の C<A0..BF>、C<U+D000...U+D7FF> の中の C<80..9F>、
+C<U+10000..U+3FFFF> の中の C<90..BF>、C<U+100000..U+10FFFF> の中の
+C<80...8F> に注意してください。
+この「隙間」は、正当な UTF-8 が最短でないエンコードを避けるために
+あります: 技術的には UTF-8 エンコードは一つの符号位置を複数の方法で
+表すことができますが、これは明示的に禁止されていて、可能な限り最短の
+エンコードが常に使われます。
+従って、Perl もそうします。
 
 =begin original
 
@@ -1956,8 +1969,7 @@
 
 =end original
 
-Another way to look at it is via bits:
-(TBT)
+これを見るもう一つの方法はビット単位で見ることです:
 
  Code Points                    1st Byte   2nd Byte  3rd Byte  4th Byte
 
@@ -2185,6 +2197,8 @@
 
 =head2 Security Implications of Unicode
 
+(Unicode のセキュリティへの影響)
+
 =over 4
 
 =item *
@@ -2288,7 +2302,7 @@
 すでに述べている通り、Perl は二つの世界のそれぞれに片方の足
 (二つのひづめ?) を突っ込んでいます: 古いバイトの世界と新しい文字の世界で、
 必要に応じてバイトから文字にアップグレードします。
-もしあなたの古いコードが陽に Unicode を使っていないのなら、文字への
+もしあなたの古いコードが明示的に Unicode を使っていないのなら、文字への
 切り替えが自動的になされることはありません。
 文字はバイトにダウングレードされるべきではありません。
 偶発的にバイトと文字が混じる可能性がありますが(L<perluniintro> を参照)、
@@ -2300,6 +2314,8 @@
 
 =head2 Unicode in Perl on EBCDIC
 
+(EBCDIC 上の Perl での Unicode)
+
 =begin original
 
 The way Unicode is handled on EBCDIC platforms is still
@@ -2335,7 +2351,7 @@
 =end original
 
 通常ロケールの設定と Unicode は互いに影響を及ぼすことはありませんが、
-二、三の例外があります:
+いくつかの例外があります:
 
 =over 4
 
@@ -2350,7 +2366,7 @@
 
 =end original
 
-デフォルトの C<open()> レイヤーや C<@ARGV> の標準ファイルハンドルの
+デフォルトの C<open()> 層や C<@ARGV> の標準ファイルハンドルの
 自動的な UTF-8 化を、C<-C> コマンドラインスイッチか
 環境変数 C<PERL_UNICODE> によって有効にできます。
 C<-C> スイッチについての説明は L<perlrun> を参照してください。
@@ -2373,6 +2389,8 @@
 
 =head2 When Unicode Does Not Happen
 
+(Unicode ではない場合)
+
 =begin original
 
 While Perl does have extensive ways to input and output in Unicode,
@@ -2383,12 +2401,11 @@
 
 =end original
 
-While Perl does have extensive ways to input and output in Unicode,
-and few other 'entry points' like the @ARGV which can be interpreted
-as Unicode (UTF-8), there still are many places where Unicode (in some
-encoding or another) could be given as arguments or received as
-results, or both, but it is not.
-(TBT)
+Perl には入出力を Unicode で行うための多数の方法があり、
+ @ ARGV のように Unicode (UTF-8) として解釈できるようなその他の
+「エントリポイント」はほとんどない一方、(何らかのエンコーディングで)
+Unicode が引数として与えられたり結果として返されるべきにも関わらず、
+そうなっていない場所も未だ多くあります。
 
 =begin original
 
@@ -2415,12 +2432,13 @@
 =end original
 
 このようなケースにおいて、Perl がなぜ Unicode による解決を
-しないのかの理由ですが、その答えはオペレーティングシステムや
-ファイルシステムに強く依存しています。
+しないのかの理由の一つは、答えがオペレーティングシステムや
+ファイルシステムに強く依存しているからです。
 たとえば、ファイル名が Unicode で記述できてエンコーディングが
 合っていたとしてもそれは移植性のあるコンセプトではないのです。
 同様なことが qx や system にも言えます:
-'コマンドラインインターフェース' は Unicode をどのように扱うのでしょうか?
+「コマンドラインインターフェース」は Unicode をどのように
+扱うのでしょうか?
 
 =over 4
 
@@ -2656,11 +2674,11 @@
 
 C<UTF8SKIP(buf)> はバッファの中にある UTF-8 エンコードされた文字の
 バイト数を返します。
-C<UNISKIP(chr)> はUTF-8エンコードする Unicode 文字の符号位置が要求する
+C<UNISKIP(chr)> は UTF-8 エンコードする Unicode 文字の符号位置が要求する
 バイト数を返します。
-C<UTF8SKIP()> はUTF-8エンコードされたバッファの文字に対して繰り返しを
+C<UTF8SKIP()> は UTF-8 エンコードされたバッファの文字に対して繰り返しを
 行うような例に便利です。
-C<UNISKIP()> はたとえば、 UTF-8 エンコードされたバッファの要求する大きさを
+C<UNISKIP()> はたとえば、UTF-8 エンコードされたバッファの要求する大きさを
 計算するのに便利です。
 
 =item *
@@ -2673,7 +2691,7 @@
 =end original
 
 C<utf8_distance(a, b)> は同じ UTF-8 エンコードされたバッファをさす
-二つのポインタの間の文字の距離を返します。
+二つのポインタの間の文字単位の距離を返します。
 
 =item *
 
@@ -2687,12 +2705,11 @@
 
 =end original
 
-C<utf8_hop(s, off)> will return a pointer to an UTF-8 encoded buffer
-that is C<off> (positive or negative) Unicode characters displaced
-from the UTF-8 buffer C<s>.  Be careful not to overstep the buffer:
-C<utf8_hop()> will merrily run off the end or the beginning of the
-buffer if told to do so.
-(TBT)
+C<utf8_hop(s, off)> は、UTF-8 バッファ C<s> から Unicode で C<off> 文字分
+(正数でも負数でも) 移動した UTF-8 エンコーディングバッファへの
+ポインタを返します。
+バッファを超えないように注意してください: C<utf8_hop()> は、そう
+指示されれば何も気にせずにバッファの先頭や末尾を踏み越えます。
 
 =item *
 
@@ -2806,7 +2823,7 @@
 考慮し、そしてそのモジュールがどのように実装されているかを知るために
 ソースを見ることになるかもしれません。
 完全に Perl で書かれたモジュールは問題を引き起こしません。
-他のプログラミング言語で書かれている直接/間接にアクセスするコードに
+他のプログラミング言語で書かれている直接または間接にアクセスするコードに
 リスクがあるのです。
 
 =begin original
@@ -2821,15 +2838,14 @@
 =end original
 
 影響を受けた関数のための、データの劣化(data corruption)を防ぐ単純な
-戦略とは、常に交換するデータのエンコーディングを明確にするということです。
+戦略とは、交換するデータのエンコーディングを常に明確にするということです。
 エクステンションが取り扱うことができると知っているエンコーディングを
 選択してください。
 エクステンションに渡す引数を選択したエンコーディングに変換し、
 エクステンションから返ってきた結果をそのエンコーディングから
 逆方向に変換します。
-変換を行ってくれるラッパー関数を書きましょう。
-それによりエクステンションがキャッチアップしたときに関数を
-変更することができます。
+変換を行ってくれるラッパ関数を書いておいて、
+エクステンションが追いついた時に関数を変更できるようにしておきます。
 
 =begin original
 
@@ -2840,9 +2856,9 @@
 
 =end original
 
-例として、ポピュラーな Foo::Bar::escape_html について述べましょう。
-これはまだ Unicode データを取り扱うようにはできていません。
-ラッパー関数は引数を生の UTF-8 に変換し、結果を Perl の内部表現に
+例として、まだ Unicode データを取り扱うようにはできていない、
+有名なな Foo::Bar::escape_html について述べましょう。
+ラッパ関数は引数を生の UTF-8 に変換し、結果を Perl の内部表現に
 逆変換します:
 
     sub my_escape_html ($) {
@@ -2866,7 +2882,7 @@
 使うことがあるかもしれません。
 C で書かれていて、データを以下のプロトタイプに従って格納したり
 取り出したりする C<param> メソッドを持っている
-ポピュラーな C<Foo::Bar> エクステンションについて述べてみましょう:
+有名な C<Foo::Bar> エクステンションについて述べてみましょう:
 
     $self->param($name, $value);            # set a scalar
     $value = $self->param($name);           # retrieve a scalar
@@ -2878,7 +2894,7 @@
 
 =end original
 
-なんらかのエンコーディングをまだサポートしていないのなら、
+どのエンコーディングもまだサポートしていないのなら、
 以下のような C<param> メソッドを持った派生クラスを
 記述することができるでしょう:
 
@@ -2955,6 +2971,8 @@
 
 =head2 Porting code from perl-5.6.X
 
+(perl 5.6.X からコードを移植する)
+
 =begin original
 
 Perl 5.8 has a different Unicode model from 5.6. In 5.6 the programmer
@@ -3071,7 +3089,7 @@
 
 =end original
 
-fetchrow_array と fetchrow_hashref へのラッパー
+fetchrow_array と fetchrow_hashref へのラッパ
 
 =begin original
 
@@ -3085,10 +3103,10 @@
 
 =end original
 
-データベースが UTF-8 のみから構成されているとき、ラッパー関数や
-ラッパーメソッドはあなたの fetchrow_array や fetchrow_hashref の呼び出しを
+データベースが UTF-8 のみから構成されているとき、ラッパ関数や
+ラッパメソッドはあなたの fetchrow_array や fetchrow_hashref の呼び出しを
 置き換えるのに便利な方法でしょう。
-ラッパー関数はまた、あなたの使っているデータベースドライバが
+ラッパ関数はまた、あなたの使っているデータベースドライバが
 将来拡張されたときに適用しやすくするでしょう。
 このドキュメントを書いている時点(2002 年 10 月)では、DBI は UTF-8 のデータを
 扱う標準的な方法を持っていません。



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