X-Git-Url: http://git.osdn.net/view?p=linuxjm%2FLDP_man-pages.git;a=blobdiff_plain;f=draft%2Fman7%2Futf-8.7;fp=draft%2Fman7%2Futf-8.7;h=0000000000000000000000000000000000000000;hp=5efd59906130bd0d534b386df695cd9070a6015c;hb=2460a0b8024ceb8570acdbc9208713d79458efcb;hpb=83f9e5d087c3464d5131604d3c9893479e6228eb

diff --git a/draft/man7/utf-8.7 b/draft/man7/utf-8.7
deleted file mode 100644
index 5efd5990..00000000
--- a/draft/man7/utf-8.7
+++ /dev/null
@@ -1,216 +0,0 @@
-.\" Copyright (C) Markus Kuhn, 1996, 2001
-.\"
-.\" %%%LICENSE_START(GPLv2+_DOC_FULL)
-.\" This is free documentation; you can redistribute it and/or
-.\" modify it under the terms of the GNU General Public License as
-.\" published by the Free Software Foundation; either version 2 of
-.\" the License, or (at your option) any later version.
-.\"
-.\" The GNU General Public License's references to "object code"
-.\" and "executables" are to be interpreted as the output of any
-.\" document formatting or typesetting system, including
-.\" intermediate and printed output.
-.\"
-.\" This manual is distributed in the hope that it will be useful,
-.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
-.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-.\" GNU General Public License for more details.
-.\"
-.\" You should have received a copy of the GNU General Public
-.\" License along with this manual; if not, see
-.\" <http://www.gnu.org/licenses/>.
-.\" %%%LICENSE_END
-.\"
-.\" 1995-11-26  Markus Kuhn <mskuhn@cip.informatik.uni-erlangen.de>
-.\"      First version written
-.\" 2001-05-11  Markus Kuhn <mgk25@cl.cam.ac.uk>
-.\"      Update
-.\"
-.\"*******************************************************************
-.\"
-.\" This file was generated with po4a. Translate the source file.
-.\"
-.\"*******************************************************************
-.\"
-.\" 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 説明
-ユニコード (Unicode) 3.0 文字集合は 16 ビットのコード空間を占める。
-最も単純な Unicode の符号化方法 (UCS\-2)
-では、文字は 16 ビットワード (16 ビット文字の列) で構成される。
-この列には、
-\(aq\e0\(aq や \(aq/\(aq のような (ファイル名や C のライブラリ関数の引き数の内部で)
-特殊な意味を持つ 16 ビット文字が含まれることがある。
-さらに、ほとんどの UNIX ツールは ASCII ファイルを入力として期待するので、
-大幅な変更なしには 16 ビットワードを文字として読むことができない。
-これらの理由から、UCS\-2 はファイル名・テキストファイル・環境変数などに用いる、
-外部用の Unicode 符号としては不適切である。
-Unicode のスーパーセットである
-ISO 10646 Universal Character Set (UCS)
-は \\(em 31 ビットのような \\(em もっと大きなコード空間を占めるが、
-その最も単純な符号化である UCS\-4 にも (32 ビットワードの列として) 同じ問題がある。
-
-Unicode と UCS の UTF\-8 符号化にはこれらの問題がないので、
-UNIX 形式の OS 上で Unicode 文字集合を使用するための一般的な方法となっている。
-.SS 性質
-UTF\-8 符号化は以下のような素晴しい性質を備えている:
-.TP  0.2i
-*
-UCS 文字のうち 0x00000000 から 0x0000007f まで (古典的な US\-ASCII の文字) は
-(ASCII との互換性のために) 単純に 0x00 から 0x7f のバイトに符号化する。
-これは 7 ビット ASCII 文字のみを含むファイルや文字列に関しては、
-ASCII と UTF\-8 で同じ符号化を行なうことを意味する。
-.TP 
-*
-0x7f より大きいのすべての
-UCS 文字は、 0x80 から 0xfd までの範囲のバイトのみを含む
-多バイト文字列に符号化される。
-したがって文字列に
-ASCII バイトが含まれることがなく、\(aq\e0\(aq や \(aq/\(aq の問題は発生しない。
-.TP 
-*
-UCS\-4 文字列では辞書的ソートの順序が保たれる。
-.TP 
-*
-2^31 ビットのすべての UCS コード が UTF\-8 を使用して符号化できる。
-.TP 
-*
-UTF\-8 符号化ではバイト 0xc0, 0xc1, 0xfe, 0xff が使用されることはない。
-.TP 
-*
-ASCII でない UCS 文字の多バイト列の最初のバイトは、
-常に 0xc2 から 0xfd の範囲で表現され、
-その文字が何バイトで構成されているかを示す。
-多バイト列の残りの部分のバイトは、それぞれ 0x80 から 0xbf の範囲にある。
-これにより同期が容易になり、ステートレスな符号化が可能になり、
-バイトの紛失に対して堅固になる。
-.TP 
-*
-UTF\-8 を使用した UCS 文字の符号化は最大 6 バイトの長さになる。
-しかし、Unicode 規格では 0x10ffff より先の文字を指定しないので、
-Unicode 文字は UTF\-8 では 4 バイトまでにしかならない。
-.SS 符号化
-以下のバイト列が文字の表現に使用される。
-どのバイト列を使用するかは文字の UCS コード番号に依存する:
-.TP  0.4i
-0x00000000 \- 0x0000007F:
-0\fIxxxxxxx\fP
-.TP 
-0x00000080 \- 0x000007FF:
-110\fIxxxxx\fP 10\fIxxxxxx\fP
-.TP 
-0x00000800 \- 0x0000FFFF:
-1110\fIxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
-.TP 
-0x00010000 \- 0x001FFFFF:
-11110\fIxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
-.TP 
-0x00200000 \- 0x03FFFFFF:
-111110\fIxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
-.TP 
-0x04000000 \- 0x7FFFFFFF:
-1111110\fIx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP
-.PP
-\fIxxx\fP ビットの部分には 2 進数で表わした文字コードのビット部分が対応する。
-その文字を表現するのに最も短いバイト列のみが使用できる。
-.PP
-0xd800\(en0xdfff (UTF\-16 サロゲート) や
-0xfffe, 0xffff (UCS の noncharacter) という UCS コードの値は、
-UTF\-8 に準拠したストリームに入れるべきではない。
-.SS 例
-Unicode 文字の 0xa9 = 1010 1001 (コピーライトマーク) は UTF\-8 で符号化すると
-以下のようになる。
-.PP
-.RS
-11000010 10101001 = 0xc2 0xa9
-.RE
-.PP
-0x2260 = 0010 0010 0110 0000 (不等号) は以下の通り。
-.PP
-.RS
-11100010 10001001 10100000 = 0xe2 0x89 0xa0
-.RE
-.SS アプリケーションにおける注意
-ユーザーはアプリケーションの UTF\-8 サポートを有効にするために、
-.PP
-.RS
-export LANG=en_GB.UTF\-8
-.RE
-.PP
-のようにして UTF\-8 ロケールを選択しなければならない。
-.PP
-使用されている文字符号化を分かっていなければならない
-アプリケーションソフトウェアは、
-以下のようにして常にロケールを設定すべきである。
-.PP
-.RS
-setlocale(LC_CTYPE, "")
-.RE
-.PP
-また、プログラマーは
-.PP
-.RS
-strcmp(nl_langinfo(CODESET), "UTF\-8") == 0
-.RE
-.PP
-という式を評価することで、
-UTF\-8 ロケールが選択されていて、プレーンテキストの標準入出力・端末間通信・
-プレーンテキストファイルの内容・ファイル名・環境変数が
-UTF\-8 で符号化されているかをチェックすることができる。
-.PP
-US\-ASCII や ISO 8859
-といったシングルバイトの符号化が習慣になっているプログラマーは、
-これまでの 2 つの仮定が
-UTF\-8 ロケールにおいては最早有効ではなくなったことを知っておくべきだ。
-1 番目の変更点は、1 バイトが必ずしも 1 つの文字に対応しないという点である。
-2 番目の変更点は、最近の端末エミュレータは
-UTF\-8 モードにおいて中国語・日本語・韓国朝鮮語の
-全角文字やスペースが入らない (nonspacing)
-合成文字 (combining characters) に対応しているので、
-ASCII のときのように 1 文字出力した後で
-カーソルを必ずしも 1 つだけ進めるわけではないという点である。
-今日では、文字やカーソルの位置を数えるのに
-\fBmbsrtowcs\fP(3) や \fBwcswidth\fP(3)
-といったライブラリ関数を使うべきである。
-.PP
-(VT100 端末などで使われる) ISO 2022 符号化形式から
-UTF\-8 へ切替える公式なエスケープシーケンスは ESC % G ("\x1b%G") である。
-これに対応する UTF\-8 から ISO 2022 へのリターンシーケンスは
-ESC % @ ("\x1b%@") である。
-(G0 セットと G1 セットを切替えるといった)
-その他の ISO 2022 シーケンスは、UTF\-8 モードでは使えない。
-.SS セキュリティ
-Unicode と UCS の規格では、
-UTF\-8 の生成者はできるだけ短い形式を用いるよう要求している。
-例えば、先頭バイトが 0xc0 であるような 2 バイト列を
-生成するのは準拠しているとはいえない。
-Unicode 3.1 では、規格に準拠するプログラムは
-最短の表現形式ではない入力を受け付けない、という要求事項が追加された。
-これはセキュリティ上の理由による。
-ユーザー入力がセキュリティ上の危険に対しチェックされる場合、
-プログラムは ASCII 版の "/../" や ";" や "NUL" だけをチェックし、
-最短に符号化されてないこれらの文字を見過ごしてしまうかもしれないからである。
-なぜなら、最短ではない 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 関連項目
-\fBlocale\fP(1), \fBnl_langinfo\fP(3), \fBsetlocale\fP(3), \fBcharsets\fP(7),
-\fBunicode\fP(7)
-.SH この文書について
-この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.79 の一部
-である。プロジェクトの説明とバグ報告に関する情報は
-http://www.kernel.org/doc/man\-pages/ に書かれている。