[perldocjp-cvs 1541] CVS update: docs/perl/5.12.1

Back to archive index

argra****@users***** argra****@users*****
2012年 9月 12日 (水) 05:28:20 JST


Index: docs/perl/5.12.1/perlunicode.pod
diff -u docs/perl/5.12.1/perlunicode.pod:1.3 docs/perl/5.12.1/perlunicode.pod:1.4
--- docs/perl/5.12.1/perlunicode.pod:1.3	Sun Aug 19 05:51:40 2012
+++ docs/perl/5.12.1/perlunicode.pod	Wed Sep 12 05:28:20 2012
@@ -130,9 +130,9 @@
 Unicode BOM (UTF-16LE, UTF16-BE, またはUTF-8)で Perl スクリプトが
 始まっていたり、スクリプトが BOM がついていない
 UTF-16(BE か LE のいずれか) であった場合、Perl はそのスクリプトを
-Unicode であるとして正しく読み込みます(BOM がない UTF-8 は、
-効率的に ISO 8859-1 などの 8 ビットエンコーディングと区別したり
-認識することができません。)
+Unicode であるとして正しく読み込みます。
+(BOM がない UTF-8 は、効率的に ISO 8859-1 などの 8 ビットエンコーディングと
+区別したり認識することができません。)
 
 =item C<use encoding> needed to upgrade non-Latin-1 byte strings
 
@@ -286,9 +286,8 @@
 C<utf8> プラグマは主としてパーサが遭遇するリテラル中の UTF-(8|EBCDIC) の
 認識を有効にする互換デバイス(compatibility device)です。
 このプラグマは Perl のデフォルトがバイトセマンティクスであるときにのみ
-必要であることに注意してください。
-文字セマンティクスがデフォルトである場合には、
-このプラグマは何もしません。
+必要であることに注意してください; 文字セマンティクスが
+デフォルトである場合には、このプラグマは何もしません。
 L<utf8> を参照してください。
 
 =begin original
@@ -587,12 +586,12 @@
 =end original
 
 文字列の位置や長さを取り扱う演算子の大部分は自動的に文字の位置を
-使うように変更されました。
-これには C<chop()>, C<chomp()>, C<substr()>, C<pos()>, C<index()>,
-C<rindex()>, C<sprintf()>, C<write()>, C<length()> が含まれます。
+使うように変更されました; これには C<chop()>, C<chomp()>, C<substr()>,
+C<pos()>, C<index()>, C<rindex()>, C<sprintf()>, C<write()>, C<length()> が
+含まれます。
 C<vec()> は変更されていません。
-文字列をビットのバケツのように扱う C<sort()>、ファイル名を取り扱う
-演算子は文字かどうかを気にしません。
+文字列をビットのバケツのように扱う C<sort()>、ファイル名を取り扱う演算子は
+文字かどうかを気にしません。
 
 =item *
 
@@ -603,8 +602,8 @@
 
 =end original
 
-C<pack()>/C<unpack()> の文字 C<C> は I<変更されていません>。
-なぜなら、これらはしばしばバイト指向の書式のために使われるからです。
+C<pack()>/C<unpack()> の文字 C<C> は I<変更されていません>; なぜなら、
+これらはしばしばバイト指向の書式のために使われるからです。
 繰り返しますが、C 言語の C<char> を考えてください。
 
 =begin original
@@ -1084,9 +1083,8 @@
 =end original
 
 (Perl 5.6 との)後方互換性のため、すべての特性はその名前の前に C<Is>
-または C<Is_> を置くことができます。
-したがって、C<\P{Is_Lu}> は C<\P{Lu}> と等価で、C<\p{IsScript:Arabic}> は
-C<\p{Arabic}> と等価です。
+または C<Is_> を置くことができます; したがって、C<\P{Is_Lu}> は C<\P{Lu}> と
+等価で、C<\p{IsScript:Arabic}> は C<\p{Arabic}> と等価です。
 
 =head3 B<Blocks>
 
@@ -1866,7 +1864,7 @@
 あなた自身のバイナリ文字特性を、"In" または "Is" で始まる名前のサブルーチンを
 定義することによって持つことができます。
 そのサブルーチンは任意のパッケージで定義することができます。
-ユーザー定義特性は正規表現の C<\p> 構造や C<\P> 構造で使うことができます。
+ユーザー定義特性は正規表現の C<\p> 構造や C<\P> 構造で使うことができます;
 もしユーザー定義特性をそれがあるパッケージ以外で使いたいのであれば、
 パッケージ名を C<\p> (もしくは C<\P>)のために指定する必要があります。
 
@@ -2305,8 +2303,8 @@
 
 =end original
 
-同様に Unicode::Regex::Set モジュールを参照してください。
-これは UTR #18のグルーピング、intersection、union, removal(substraction)構文を
+同様に Unicode::Regex::Set モジュールを参照してください; これは
+UTR #18 のグルーピング、intersection、union, removal(substraction)構文を
 フルに実装しています。
 
 =begin original
@@ -2534,9 +2532,8 @@
 C<U+0000..U+FFFF> の範囲の Unicode の符号位置はひとつの 16 ビット
 ユニットに収められ、C<U+10000..U+10FFFF> の範囲の符号位置は 2 つの
 16 ビットユニットに収められます。
-後者をサロゲート(surrogates) と呼びます。
-最初の 16 ビットユニットは I<high surrogate> で、二番目は
-I<low surrogate> となります。
+後者をサロゲート(surrogates) と呼びます; 最初の 16 ビットユニットは
+I<high surrogate> で、二番目は I<low surrogate> となります。
 
 =begin original
 
@@ -2574,9 +2571,9 @@
 
 =end original
 
-(たとえば chr() を使って)サロゲートを生成しようとしたならば、
-警告が有効であれば警告が発生するでしょう。
-なぜなら、そういった符号位置は Unicode 文字としては正しいものではないからです。
+(たとえば chr() を使って)サロゲートを生成しようとしたならば、警告が
+有効であれば警告が発生するでしょう; なぜなら、そういった符号位置は
+Unicode 文字としては正しいものではないからです。
 
 =begin original
 
@@ -2618,7 +2615,7 @@
 
 =end original
 
-このトリックは、BOM を読み込んだときにバイト順がわかるということです。
+このトリックは、BOM を読み込んだときにバイト順がわかるということです;
 ビッグエンディアンのプラットフォームで書かれたものならなら
 C<0xFE 0xFF> を読み出し、リトルエンディガンのプラットフォームで
 書かれたものなら C<0xFF 0xFE> を読み出します。
@@ -2679,7 +2676,7 @@
 
 ISO 10646 標準で定義されているエンコーディングです。
 UCS-2 は 16 ビットエンコーディングです。
-UTF-16 とは異なり、UCS-2 は C<U+FFFF> を超えた範囲に拡張できません。
+UTF-16 とは異なり、UCS-2 は C<U+FFFF> を超えた範囲に拡張できません;
 これはサロゲートを使わないためです。
 UCS-4 は 32 ビットエンコーディングで、機能的には UTF-32 と同じです。
 
@@ -2744,7 +2741,7 @@
 残念ながら、UTF-8 の仕様ではひとつの Unicode 文字の入力から
 何バイトのエンコードされた出力として解釈するのかについていくらかの
 余地があります。
-厳密にいえば、可能な限り最も短い UTF-8 バイト列が生成されるべきです。
+厳密にいえば、可能な限り最も短い UTF-8 バイト列が生成されるべきです;
 なぜなら、そうしないと UTF-8 コネクションの終わりにおいて、入力バッファが
 オーバーフローする可能性があるからです。
 Perl は常に最も短い長さの UTF-8 を生成し、本当の Unicode の符号位置でない
@@ -2882,10 +2879,10 @@
 
 =end original
 
-デフォルトの C<open()> 層や C<@ARGV> の標準ファイルハンドルの
-自動的な UTF-8 化を、C<-C> コマンドラインスイッチか
-環境変数 C<PERL_UNICODE> によって有効にできます。
-C<-C> スイッチについての説明は L<perlrun> を参照してください。
+デフォルトの C<open()> 層や C<@ARGV> の標準ファイルハンドルの自動的な
+UTF-8 化を、C<-C> コマンドラインスイッチか環境変数 C<PERL_UNICODE> によって
+有効にできます; C<-C> スイッチについての説明は L<perlrun> を
+参照してください。
 
 =item *
 
@@ -3314,7 +3311,7 @@
 =end original
 
 C<uvchr_to_utf8(buf, chr)> は Unicode の文字符号位置を UTF-8 で
-エンコードされたの符号位置としてバッファに書き込みます。
+エンコードされたの符号位置としてバッファに書き込みます;
 そして、その UTF-8 バイトの後を指し示すポインタを返します。
 これは EBCDIC のマシンでも適切に動作します。
 
@@ -3368,6 +3365,7 @@
 C<sv_utf8_downgrade(sv)> は(可能であれば)その反対の動作をします。
 C<sv_utf8_encode(sv)> は C<sv_utf8_upgrade> に似ていますが、
 C<UTF8> フラグをセットしない点が異なります。
+C<sv_utf8_decode()> は C<sv_utf8_encode()> の逆を行います。
 これらの欠如が一般的な目的のエンコーディングやデコーディングの
 インターフェースとして使われていることに注意してください:
 C<use Encode> がそのためにあります。
@@ -3417,9 +3415,8 @@
 C<UNISKIP(chr)> は UTF-8 エンコードする Unicode 文字の符号位置が要求する
 バイト数を返します。
 C<UTF8SKIP()> は UTF-8 エンコードされたバッファの文字に対して繰り返しを
-行うような例に便利です。
-C<UNISKIP()> はたとえば、UTF-8 エンコードされたバッファの要求する大きさを
-計算するのに便利です。
+行うような例に便利です; C<UNISKIP()> はたとえば、UTF-8 エンコードされた
+バッファの要求する大きさを計算するのに便利です。
 
 =item *
 
@@ -3745,11 +3742,9 @@
 =end original
 
 一部のエクステンションはデータのエントリ/脱出ポイントでフィルターを
-提供しています。
-たとえば DB_File::filter_store_keyとその仲間です。
+提供しています; たとえば DB_File::filter_store_keyとその仲間です。
 あなた使うエクステンションのドキュメントにあるそのようなフィルターに
-注意してください。
-それらは Unicode データの変化をより容易にします。
+注意してください; それらは Unicode データの変化をより容易にします。
 
 =head2 Speed
 
@@ -3784,9 +3779,9 @@
 
 =end original
 
-Perl 5.8.0 ではこの遅さはしばしば目立つものでした。
-Perl 5.8.1 では少なくとも一部の操作については、遅さを改善することを
-期待するキャッシングスキーム(caching scheme)が導入されました。
+Perl 5.8.0 ではこの遅さはしばしば目立つものでした; Perl 5.8.1 では
+少なくとも一部の操作については、遅さを改善することを期待する
+キャッシングスキーム(caching scheme)が導入されました。
 一般的には、UTF-8 エンコードされた文字列に対する操作はまだ遅いものです。
 たとえば、C<\p{Nd}> のような Unicode の特性(文字クラス)は対応する
 C<\d> のような単純なものよりも目立って遅い(5 倍から10 倍)ことが



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