OSDN Git Service

(split) LDP: Restore and add Copyrights for draft pages
[linuxjm/LDP_man-pages.git] / draft / man7 / utf-8.7
1 .\" Copyright (C) Markus Kuhn, 1996, 2001
2 .\"
3 .\" %%%LICENSE_START(GPLv2+_DOC_FULL)
4 .\" This is free documentation; you can redistribute it and/or
5 .\" modify it under the terms of the GNU General Public License as
6 .\" published by the Free Software Foundation; either version 2 of
7 .\" the License, or (at your option) any later version.
8 .\"
9 .\" The GNU General Public License's references to "object code"
10 .\" and "executables" are to be interpreted as the output of any
11 .\" document formatting or typesetting system, including
12 .\" intermediate and printed output.
13 .\"
14 .\" This manual is distributed in the hope that it will be useful,
15 .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
16 .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
17 .\" GNU General Public License for more details.
18 .\"
19 .\" You should have received a copy of the GNU General Public
20 .\" License along with this manual; if not, see
21 .\" <http://www.gnu.org/licenses/>.
22 .\" %%%LICENSE_END
23 .\"
24 .\" 1995-11-26  Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
25 .\"      First version written
26 .\" 2001-05-11  Markus Kuhn <mgk25@cl.cam.ac.uk>
27 .\"      Update
28 .\"
29 .\"*******************************************************************
30 .\"
31 .\" This file was generated with po4a. Translate the source file.
32 .\"
33 .\"*******************************************************************
34 .\"
35 .\" Japanese Version Copyright (c) 1997 HANATAKA Shinya
36 .\"         all rights reserved.
37 .\" Translated Thu Jun  3 20:40:01 JST 1997
38 .\"         by HANATAKA Shinya <hanataka@abyss.rim.or.jp>
39 .\" Updated (add SECURITY section) & modified Mon Feb 26 2001
40 .\"         by NAKANO Takeo <nakano@apm.seikei.ac.jp>
41 .\" Updated & Modified Sun Jul  1 09:28:47 JST 2001
42 .\"         by Yuichi SATO <ysato@h4.dion.ne.jp>
43 .\" Updated 2012-05-29, Akihiro MOTOKI <amotoki@gmail.com>
44 .\"
45 .TH UTF\-8 7 2012\-04\-30 GNU "Linux Programmer's Manual"
46 .SH 名前
47 UTF\-8 \- ASCII と互換性のある多バイト Unicode の符号化
48 .SH 説明
49 \fBユニコード (Unicode) 3.0\fP 文字集合は 16 ビットのコード空間を占める。
50 最も単純な Unicode の符号化方法 (\fBUCS\-2\fP)
51 では、文字は 16 ビット・ワード (16 ビット文字の列) で構成される。
52 この列には、
53 \(aq\e0\(aq や \(aq/\(aq のような (ファイル名や C のライブラリ関数の引き数の内部で)
54 特殊な意味を持つ 16 ビット文字が含まれることがある。
55 さらに、ほとんどの UNIX ツールは ASCII ファイルを入力として期待するので、
56 大幅な変更なしには 16 ビットワードを文字として読むことができない。
57 これらの理由から、\fBUCS\-2\fP はファイル名・テキストファイル・環境変数などに用いる、
58 外部用の \fBUnicode\fP 符号としては不適切である。
59 Unicode のスーパーセットである
60 \fBISO 10646 Universal Character Set (UCS)\fP
61 は 31 ビットのコード空間を占めるが、その最も単純な符号化である
62 \fBUCS\-4\fP にも (32 ビット・ワードの列として) 同じ問題がある。
63
64 \fBUnicode\fP と \fBUCS\fP の \fBUTF\-8\fP 符号化にはこれらの問題がないので、
65 UNIX 形式の OS 上で \fBUnicode\fP 文字集合を使用するための一般的な方法となっている。
66 .SS 性質
67 \fBUTF\-8\fP 符号化は以下のような素晴しい性質を備えている:
68 .TP  0.2i
69 *
70 \fBUCS\fP 文字のうち 0x00000000 から 0x0000007f まで (古典的な \fBUS\-ASCII\fP の文字) は
71 (ASCII との互換性のために) 単純に 0x00 から 0x7f のバイトに符号化する。
72 これは 7 ビット ASCII 文字のみを含むファイルや文字列に関しては、
73 \fBASCII\fP と \fBUTF\-8\fP で同じ符号化を行なうことを意味する。
74 .TP 
75 *
76 0x7f より大きいのすべての
77 \fBUCS\fP 文字は、 0x80 から 0xfd までの範囲のバイトのみを含む
78 多バイト文字列に符号化される。
79 したがって文字列に
80 ASCII バイトが含まれることがなく、\(aq\e0\(aq や \(aq/\(aq の問題は発生しない。
81 .TP 
82 *
83 \fBUCS\-4\fP
84 文字列では辞書的ソートの順序が保たれる。
85 .TP 
86 *
87 2^31 ビットのすべての UCS コード が \fBUTF\-8\fP を使用して符号化できる。
88 .TP 
89 *
90 \fBUTF\-8\fP 符号化ではバイト 0xc0, 0xc1, 0xfe, 0xff が使用されることはない。
91 .TP 
92 *
93 ASCII でない \fBUCS\fP 文字の多バイト列の最初のバイトは、
94 常に 0xc2 から 0xfd の範囲で表現され、
95 その文字が何バイトで構成されているかを示す。
96 多バイト列の残りの部分のバイトは、それぞれ 0x80 から 0xbf の範囲にある。
97 これにより同期が容易になり、ステートレスな符号化が可能になり、
98 バイトの紛失に対して堅固になる。
99 .TP 
100 *
101 \fBUTF\-8\fP を使用した \fBUCS\fP 文字の符号化は最大 6 バイトの長さになる。
102 しかし、\fBUnicode\fP 規格では 0x10ffff より先の文字を指定しないので、
103 Unicode 文字は \fBUTF\-8\fP では 4 バイトまでにしかならない。
104 .SS 符号化
105 以下のバイト列が文字の表現に使用される。
106 どのバイト列を使用するかは文字の UCS コード番号に依存する:
107 .TP  0.4i
108 0x00000000 \- 0x0000007F:
109 0\fIxxxxxxx\fP
110 .TP 
111 0x00000080 \- 0x000007FF:
112 110\fIxxxxx\fP 10\fIxxxxxx\fP
113 .TP 
114 0x00000800 \- 0x0000FFFF:
115 1110\fIxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
116 .TP 
117 0x00010000 \- 0x001FFFFF:
118 11110\fIxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
119 .TP 
120 0x00200000 \- 0x03FFFFFF:
121 111110\fIxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
122 .TP 
123 0x04000000 \- 0x7FFFFFFF:
124 1111110\fIx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
125 .PP
126 \fIxxx\fP ビットの部分には 2 進数で表わした文字コードのビット部分が対応する。
127 その文字を表現するのに最も短いバイト列のみが使用できる。
128 .PP
129 0xd800\(en0xdfff (UTF\-16 サロゲート) や
130 0xfffe, 0xffff (UCS の noncharacter) という \fBUCS\fP コードの値は、
131 \fBUTF\-8\fP に準拠したストリームに入れるべきではない。
132 .SS 例
133 \fBUnicode\fP 文字の 0xa9 = 1010 1001 (コピーライト・マーク) は UTF\-8 で符号化すると
134 以下のようになる。
135 .PP
136 .RS
137 11000010 10101001 = 0xc2 0xa9
138 .RE
139 .PP
140 0x2260 = 0010 0010 0110 0000 (不等号) は以下の通り。
141 .PP
142 .RS
143 11100010 10001001 10100000 = 0xe2 0x89 0xa0
144 .RE
145 .SS アプリケーションにおける注意
146 ユーザーはアプリケーションの \fBUTF\-8\fP サポートを有効にするために、
147 .PP
148 .RS
149 export LANG=en_GB.UTF\-8
150 .RE
151 .PP
152 のようにして \fBUTF\-8\fP ロケールを選択しなければならない。
153 .PP
154 使用されている文字符号化を分かっていなければならない
155 アプリケーションソフトウェアは、
156 以下のようにして常にロケールを設定すべきである。
157 .PP
158 .RS
159 setlocale(LC_CTYPE, "")
160 .RE
161 .PP
162 また、プログラマーは
163 .PP
164 .RS
165 strcmp(nl_langinfo(CODESET), "UTF\-8") == 0
166 .RE
167 .PP
168 という式を評価することで、
169 \fBUTF\-8\fP ロケールが選択されていて、プレーンテキストの標準入出力・端末間通信・
170 プレーンテキストファイルの内容・ファイル名・環境変数が
171 \fBUTF\-8\fP で符号化されているかをチェックすることができる。
172 .PP
173 \fBUS\-ASCII\fP や \fBISO 8859\fP
174 といったシングルバイトの符号化が習慣になっているプログラマーは、
175 これまでの 2 つの仮定が
176 \fBUTF\-8\fP ロケールにおいては最早有効ではなくなったことを知っておくべきだ。
177 1 番目の変更点は、1 バイトが必ずしも 1 つの文字に対応しないという点である。
178 2 番目の変更点は、最近の端末エミュレータは
179 \fBUTF\-8\fP モードにおいて中国語・日本語・韓国朝鮮語の
180 \fB全角文字\fP やスペースが入らない (nonspacing)
181 \fB合成文字 (combining characters)\fP に対応しているので、
182 \fBASCII\fP のときのように 1 文字出力した後で
183 カーソルを必ずしも 1 つだけ進めるわけではないという点である。
184 今日では、文字やカーソルの位置を数えるのに
185 \fBmbsrtowcs\fP(3) や \fBwcswidth\fP(3)
186 といったライブラリ関数を使うべきである。
187 .PP
188 (VT100 端末などで使われる) \fBISO 2022\fP 符号化形式から
189 \fBUTF\-8\fP へ切替える公式なエスケープシーケンスは ESC % G ("\x1b%G") である。
190 これに対応する \fBUTF\-8\fP から \fBISO 2022\fP へのリターンシーケンスは
191 ESC % @ ("\x1b%@") である。
192 (G0 セットと G1 セットを切替えるといった)
193 その他の ISO 2022 シーケンスは、UTF\-8 モードでは使えない。
194 .PP
195 予知できる将来では、POSIX システム上の一般的な文字符号化の全てのレベルで
196 \fBUTF\-8\fP が \fBASCII\fP と \fBISO 8859\fP を置き換え、
197 プレーンテキストを扱う非常に優れた環境が作られることが期待できる。
198 .SS セキュリティ
199 \fBUnicode\fP と \fBUCS\fP の規格では、
200 \fBUTF\-8\fP の生成者はできるだけ短い形式を用いるよう要求している。
201 例えば、先頭バイトが 0xc0 であるような 2 バイト列を
202 生成するのは準拠しているとはいえない。
203 \fBUnicode 3.1\fP では、規格に準拠するプログラムは
204 最短の表現形式ではない入力を受け付けない、という要求事項が追加された。
205 これはセキュリティ上の理由による。
206 ユーザー入力がセキュリティ上の危険に対しチェックされる場合、
207 プログラムは \fBASCII\fP 版の "/../" や ";" や "NUL" だけをチェックし、
208 最短に符号化されてないこれらの文字を見過ごしてしまうかもしれないからである。
209 なぜなら、最短ではない \fBUTF\-8\fP 符号化では、これらの文字を表現するような様々な
210 \fBASCII\fP 以外の形式が存在するためである。
211 .SS 標準
212 .\" .SH AUTHOR
213 .\" Markus Kuhn <mgk25@cl.cam.ac.uk>
214 ISO/IEC 10646\-1:2000, Unicode 3.1, RFC\ 3629, Plan 9.
215 .SH 関連項目
216 \fBnl_langinfo\fP(3), \fBsetlocale\fP(3), \fBcharsets\fP(7), \fBunicode\fP(7)
217 .SH この文書について
218 この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.53 の一部
219 である。プロジェクトの説明とバグ報告に関する情報は
220 http://www.kernel.org/doc/man\-pages/ に書かれている。