OSDN Git Service

Update README
[linuxjm/LDP_man-pages.git] / draft / man7 / utf-8.7
index 3621bbc..5efd599 100644 (file)
 .\" This file was generated with po4a. Translate the source file.
 .\"
 .\"*******************************************************************
-.TH UTF\-8 7 2012\-04\-30 GNU "Linux Programmer's Manual"
+.\"
+.\" Japanese Version Copyright (c) 1997 HANATAKA Shinya
+.\"         all rights reserved.
+.\" Translated Thu Jun  3 20:40:01 JST 1997
+.\"         by HANATAKA Shinya <hanataka@abyss.rim.or.jp>
+.\" Updated (add SECURITY section) & modified Mon Feb 26 2001
+.\"         by NAKANO Takeo <nakano@apm.seikei.ac.jp>
+.\" Updated & Modified Sun Jul  1 09:28:47 JST 2001
+.\"         by Yuichi SATO <ysato@h4.dion.ne.jp>
+.\" Updated 2012-05-29, Akihiro MOTOKI <amotoki@gmail.com>
+.\"
+.TH UTF\-8 7 2014\-06\-13 GNU "Linux Programmer's Manual"
 .SH 名前
 UTF\-8 \- ASCII と互換性のある多バイト Unicode の符号化
 .SH 説明
-\fBユニコード (Unicode) 3.0\fP 文字集合は 16 ビットのコード空間を占める。
-最も単純な Unicode の符号化方法 (\fBUCS\-2\fP)
\81§ã\81¯ã\80\81æ\96\87å­\97ã\81¯ 16 ã\83\93ã\83\83ã\83\88ã\83»ã\83¯ã\83¼ã\83\89 (16 ã\83\93ã\83\83ã\83\88æ\96\87å­\97ã\81®å\88\97) ã\81§æ§\8bæ\88\90ã\81\95ã\82\8cã\82\8bã\80\82
+ユニコード (Unicode) 3.0 文字集合は 16 ビットのコード空間を占める。
+最も単純な Unicode の符号化方法 (UCS\-2)
+では、文字は 16 ビットワード (16 ビット文字の列) で構成される。
 この列には、
 \(aq\e0\(aq や \(aq/\(aq のような (ファイル名や C のライブラリ関数の引き数の内部で)
 特殊な意味を持つ 16 ビット文字が含まれることがある。
 さらに、ほとんどの UNIX ツールは ASCII ファイルを入力として期待するので、
 大幅な変更なしには 16 ビットワードを文字として読むことができない。
-これらの理由から、\fBUCS\-2\fP はファイル名・テキストファイル・環境変数などに用いる、
-外部用の \fBUnicode\fP 符号としては不適切である。
+これらの理由から、UCS\-2 はファイル名・テキストファイル・環境変数などに用いる、
+外部用の Unicode 符号としては不適切である。
 Unicode のスーパーセットである
-\fBISO 10646 Universal Character Set (UCS)\fP
-は 31 ビットのコード空間を占めるが、その最も単純な符号化である
-\fBUCS\-4\fP にも (32 ビット・ワードの列として) 同じ問題がある。
+ISO 10646 Universal Character Set (UCS)
+は \\(em 31 ビットのような \\(em もっと大きなコード空間を占めるが、
+その最も単純な符号化である UCS\-4 にも (32 ビットワードの列として) 同じ問題がある。
 
-\fBUnicode\fP と \fBUCS\fP の \fBUTF\-8\fP 符号化にはこれらの問題がないので、
-UNIX 形式の OS 上で \fBUnicode\fP 文字集合を使用するための一般的な方法となっている。
+Unicode と UCS の UTF\-8 符号化にはこれらの問題がないので、
+UNIX 形式の OS 上で Unicode 文字集合を使用するための一般的な方法となっている。
 .SS 性質
-\fBUTF\-8\fP 符号化は以下のような素晴しい性質を備えている:
+UTF\-8 符号化は以下のような素晴しい性質を備えている:
 .TP  0.2i
 *
-\fBUCS\fP 文字のうち 0x00000000 から 0x0000007f まで (古典的な \fBUS\-ASCII\fP の文字) は
+UCS 文字のうち 0x00000000 から 0x0000007f まで (古典的な US\-ASCII の文字) は
 (ASCII との互換性のために) 単純に 0x00 から 0x7f のバイトに符号化する。
 これは 7 ビット ASCII 文字のみを含むファイルや文字列に関しては、
-\fBASCII\fP と \fBUTF\-8\fP で同じ符号化を行なうことを意味する。
+ASCII と UTF\-8 で同じ符号化を行なうことを意味する。
 .TP 
 *
 0x7f より大きいのすべての
-\fBUCS\fP 文字は、 0x80 から 0xfd までの範囲のバイトのみを含む
+UCS 文字は、 0x80 から 0xfd までの範囲のバイトのみを含む
 多バイト文字列に符号化される。
 したがって文字列に
 ASCII バイトが含まれることがなく、\(aq\e0\(aq や \(aq/\(aq の問題は発生しない。
 .TP 
 *
-\fBUCS\-4\fP
-文字列では辞書的ソートの順序が保たれる。
+UCS\-4 文字列では辞書的ソートの順序が保たれる。
 .TP 
 *
-2^31 ビットのすべての UCS コード が \fBUTF\-8\fP を使用して符号化できる。
+2^31 ビットのすべての UCS コード が UTF\-8 を使用して符号化できる。
 .TP 
 *
-\fBUTF\-8\fP 符号化ではバイト 0xc0, 0xc1, 0xfe, 0xff が使用されることはない。
+UTF\-8 符号化ではバイト 0xc0, 0xc1, 0xfe, 0xff が使用されることはない。
 .TP 
 *
-ASCII でない \fBUCS\fP 文字の多バイト列の最初のバイトは、
+ASCII でない UCS 文字の多バイト列の最初のバイトは、
 常に 0xc2 から 0xfd の範囲で表現され、
 その文字が何バイトで構成されているかを示す。
 多バイト列の残りの部分のバイトは、それぞれ 0x80 から 0xbf の範囲にある。
@@ -87,9 +97,9 @@ ASCII でない \fBUCS\fP 文字の多バイト列の最初のバイトは、
 バイトの紛失に対して堅固になる。
 .TP 
 *
-\fBUTF\-8\fP を使用した \fBUCS\fP 文字の符号化は最大 6 バイトの長さになる。
-しかし、\fBUnicode\fP 規格では 0x10ffff より先の文字を指定しないので、
-Unicode 文字は \fBUTF\-8\fP では 4 バイトまでにしかならない。
+UTF\-8 を使用した UCS 文字の符号化は最大 6 バイトの長さになる。
+しかし、Unicode 規格では 0x10ffff より先の文字を指定しないので、
+Unicode 文字は UTF\-8 では 4 バイトまでにしかならない。
 .SS 符号化
 以下のバイト列が文字の表現に使用される。
 どのバイト列を使用するかは文字の UCS コード番号に依存する:
@@ -116,10 +126,10 @@ Unicode 文字は \fBUTF\-8\fP では 4 バイトまでにしかならない。
 その文字を表現するのに最も短いバイト列のみが使用できる。
 .PP
 0xd800\(en0xdfff (UTF\-16 サロゲート) や
-0xfffe, 0xffff (UCS の noncharacter) という \fBUCS\fP コードの値は、
-\fBUTF\-8\fP に準拠したストリームに入れるべきではない。
+0xfffe, 0xffff (UCS の noncharacter) という UCS コードの値は、
+UTF\-8 に準拠したストリームに入れるべきではない。
 .SS 例
-\fBUnicode\fP 文字の 0xa9 = 1010 1001 (コピーライト・マーク) は UTF\-8 で符号化すると
+Unicode 文字の 0xa9 = 1010 1001 (コピーライトマーク) は UTF\-8 で符号化すると
 以下のようになる。
 .PP
 .RS
@@ -132,13 +142,13 @@ Unicode 文字は \fBUTF\-8\fP では 4 バイトまでにしかならない。
 11100010 10001001 10100000 = 0xe2 0x89 0xa0
 .RE
 .SS アプリケーションにおける注意
-ユーザーはアプリケーションの \fBUTF\-8\fP サポートを有効にするために、
+ユーザーはアプリケーションの UTF\-8 サポートを有効にするために、
 .PP
 .RS
 export LANG=en_GB.UTF\-8
 .RE
 .PP
-のようにして \fBUTF\-8\fP ロケールを選択しなければならない。
+のようにして UTF\-8 ロケールを選択しなければならない。
 .PP
 使用されている文字符号化を分かっていなければならない
 アプリケーションソフトウェアは、
@@ -155,55 +165,52 @@ strcmp(nl_langinfo(CODESET), "UTF\-8") == 0
 .RE
 .PP
 という式を評価することで、
-\fBUTF\-8\fP ロケールが選択されていて、プレーンテキストの標準入出力・端末間通信・
+UTF\-8 ロケールが選択されていて、プレーンテキストの標準入出力・端末間通信・
 プレーンテキストファイルの内容・ファイル名・環境変数が
-\fBUTF\-8\fP で符号化されているかをチェックすることができる。
+UTF\-8 で符号化されているかをチェックすることができる。
 .PP
-\fBUS\-ASCII\fP や \fBISO 8859\fP
+US\-ASCII や ISO 8859
 といったシングルバイトの符号化が習慣になっているプログラマーは、
 これまでの 2 つの仮定が
-\fBUTF\-8\fP ロケールにおいては最早有効ではなくなったことを知っておくべきだ。
+UTF\-8 ロケールにおいては最早有効ではなくなったことを知っておくべきだ。
 1 番目の変更点は、1 バイトが必ずしも 1 つの文字に対応しないという点である。
 2 番目の変更点は、最近の端末エミュレータは
-\fBUTF\-8\fP モードにおいて中国語・日本語・韓国朝鮮語の
-\fB全角文字\fP やスペースが入らない (nonspacing)
-\fB合成文字 (combining characters)\fP に対応しているので、
-\fBASCII\fP のときのように 1 文字出力した後で
+UTF\-8 モードにおいて中国語・日本語・韓国朝鮮語の
+全角文字やスペースが入らない (nonspacing)
+合成文字 (combining characters) に対応しているので、
+ASCII のときのように 1 文字出力した後で
 カーソルを必ずしも 1 つだけ進めるわけではないという点である。
 今日では、文字やカーソルの位置を数えるのに
 \fBmbsrtowcs\fP(3) や \fBwcswidth\fP(3)
 といったライブラリ関数を使うべきである。
 .PP
-(VT100 端末などで使われる) \fBISO 2022\fP 符号化形式から
-\fBUTF\-8\fP へ切替える公式なエスケープシーケンスは ESC % G ("\x1b%G") である。
-これに対応する \fBUTF\-8\fP から \fBISO 2022\fP へのリターンシーケンスは
+(VT100 端末などで使われる) ISO 2022 符号化形式から
+UTF\-8 へ切替える公式なエスケープシーケンスは ESC % G ("\x1b%G") である。
+これに対応する UTF\-8 から ISO 2022 へのリターンシーケンスは
 ESC % @ ("\x1b%@") である。
 (G0 セットと G1 セットを切替えるといった)
 その他の ISO 2022 シーケンスは、UTF\-8 モードでは使えない。
-.PP
-予知できる将来では、POSIX システム上の一般的な文字符号化の全てのレベルで
-\fBUTF\-8\fP が \fBASCII\fP と \fBISO 8859\fP を置き換え、
-プレーンテキストを扱う非常に優れた環境が作られることが期待できる。
 .SS セキュリティ
-\fBUnicode\fP と \fBUCS\fP の規格では、
-\fBUTF\-8\fP の生成者はできるだけ短い形式を用いるよう要求している。
+Unicode と UCS の規格では、
+UTF\-8 の生成者はできるだけ短い形式を用いるよう要求している。
 例えば、先頭バイトが 0xc0 であるような 2 バイト列を
 生成するのは準拠しているとはいえない。
-\fBUnicode 3.1\fP では、規格に準拠するプログラムは
+Unicode 3.1 では、規格に準拠するプログラムは
 最短の表現形式ではない入力を受け付けない、という要求事項が追加された。
 これはセキュリティ上の理由による。
 ユーザー入力がセキュリティ上の危険に対しチェックされる場合、
-プログラムは \fBASCII\fP 版の "/../" や ";" や "NUL" だけをチェックし、
+プログラムは ASCII 版の "/../" や ";" や "NUL" だけをチェックし、
 最短に符号化されてないこれらの文字を見過ごしてしまうかもしれないからである。
-なぜなら、最短ではない \fBUTF\-8\fP 符号化では、これらの文字を表現するような様々な
-\fBASCII\fP 以外の形式が存在するためである。
+なぜなら、最短ではない UTF\-8 符号化では、これらの文字を表現するような様々な
+ASCII 以外の形式が存在するためである。
 .SS 標準
 .\" .SH AUTHOR
 .\" Markus Kuhn <mgk25@cl.cam.ac.uk>
 ISO/IEC 10646\-1:2000, Unicode 3.1, RFC\ 3629, Plan 9.
 .SH 関連項目
-\fBnl_langinfo\fP(3), \fBsetlocale\fP(3), \fBcharsets\fP(7), \fBunicode\fP(7)
+\fBlocale\fP(1), \fBnl_langinfo\fP(3), \fBsetlocale\fP(3), \fBcharsets\fP(7),
+\fBunicode\fP(7)
 .SH この文書について
-この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.51 の一部
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.79 の一部
 である。プロジェクトの説明とバグ報告に関する情報は
 http://www.kernel.org/doc/man\-pages/ に書かれている。