次のページ 前のページ 目次へ

2. イントロダクション

2.1 なぜ Unicode を使うのですか？

異なった国の人々は、それぞれの母国語の単語を表現するのに異なった文字を使 用しています。現在では email システムや web ブラウザなど、ほとんどのアプ リケーションは 8 ビットクリーンです。つまり ISO-8859-1 のような 8 ビット 文字セットで表現されるテキストの取り扱いや表示を正しく行えるということで す。

世界には 256 よりも遥かに多くの文字があります。例えばキリル文字、ヘブラ イ語、アラビア語、中国語、日本語、韓国語、タイ語などです。新しい文字も時々 作られています。利用者に問題になってくることには次のようなものがあります。

この問題を解決するには、ワールドワイドに使用できる文字セットを使うことで す。その文字セットとは Unicode http://www.unicode.org/ のことです。Unicode に関する詳細は `man 7 unicode' を実行してください。(manpage は man-pages-1.20 パッ ケージに含まれています)

2.2 Unicode のエンコーディング

Unicode エンコーディングを使うと、文字セットを扱うユーザープログラムの問 題は、「どうやって 1 オクテット(8 ビット)で Unicode 文字を送るのか」とい う技術的な問題だけになります。8 ビットという単位は、多くのコンピュータで、 アドレスを表現する最小単位です。またこの 8 ビットという単位は、TCP/IP ネッ トワークでのコネクションにも使用されています。1 文字を表現するのに 1 バ イトを使用するというのは歴史的な偶然であり、これはコンピュータの開発がヨー ロッパとアメリカで始まったことによります。これらの国々では長い間、96 種 類の文字で充分とされてきました。

Unicode 文字をバイトでエンコードする方法には、通常 4 種類あります。

UTF-8

128 文字が 1 バイトでエンコードされます(ASCII 文字)。1920 文字が 2 バイ トでエンコードされます(ローマ字、ギリシャ文字、キリル文字、コプト語、ア ルメニア語、ヘブライ語、アラビア語の文字)。63488 文字が 3バイトでエンコー ドされます(中国語や日本語など)。残りの 2147418112 文字は 4 〜 6 バイトを 使ってエンコードすることができます(まだ割り当てられていません)。UTF-8 に 関する詳細は `man 7 utf-8' を実行してください。(manpage は ldpman-1.20 パッケージに含まれています)

UCS-2

全ての文字は 2 バイトで表現されます。このエンコーディングでは Unicodeの 始めの 65536 文字だけを表現できます。

UTF-16

これは UCS-2 の拡張で 1112064 の Unicode 文字を表現することができます。 Unicode の始めの 65536 文字は 2 バイトで、残りは 4 バイトで表現されます。

UCS-4

全ての文字は 4 バイトで表現されます。

テキストをエンコードするのに必要となる容量(ヨーロッパの言語では 1 文字あ たり 8ビットで、中国語、日本語、韓国語ではより多くのビット数)を、現在使 用されているエンコーディングと比べたものが以下になります。これはディスク で使用する容量や、ネットワークでのダウンロード速度に影響します（圧縮をし ていない場合）。

UTF-8

US ASCII なら変化なし、ISO-8859-1 なら数パーセント増え、中国語、日本語、 韓国語では 1.5 倍、ギリシャ文字やキリル文字では 2 倍になります。

UCS-2 および UTF-16

中国語、日本語、韓国語では変化なし、ASCII、ISO-8859-1、ギリシャ文字、 キリル文字では 2 倍になります。

UCS-4

中国語、日本語、韓国語では 2倍、ASCII、ISO-8859-1、ギリシャ文字、キリル 文字では 3 倍になります。

UCS-2, UTF-16, UCS-4 で US やヨーロッパの文書を書く場合にはASCII や ISO-8859-1 で書いたときよりもサイズが大きくなることがあるため、それらの エンコーディングが広く使われることはなさそうです。 Microsoft の Win32 API は UCS-2 エンコーディングを(少なくとも) 1995 年からサポートしていま すが、UCS-2は文書を記述するのに広く使われてはいません。日本ではシフト JIS がいまだ一般的です。

一方、US やヨーロッパの利用者にはペナルティがなく、また多くのテキスト操 作を行うプログラムは UTF-8 サポートのための変更が必要ないので、UTF-8 は 広く使われる可能性があります。

これから、テキストのエンコーディングとして UTF-8 を使うように Linux シス テムを変更する方法について説明していきます。

C/C++ 開発者への補足説明

Microsoft が Win32 API で取っているアプローチでは、開発者が Unicode 版の プログラムを作成することは簡単です。"#define UNICODE" をプログラムの 先頭で宣言して、コンパイルエラーがなくなるまで `char' を `TCHAR' へ変更します。この方法の問題は、最終的に 2 つのバージョ ンのプログラムができてしまうことです。1 つは UCS-2 のテキストを扱えます が、8 ビットのエンコーディングは駄目です。もう 1 つは旧来の 8 ビットエン コーディングしか扱えません。

さらに UCS-2 と UCS-4 にはエンディアンの問題があります。The Internet Assigned Numbers Authority (IANA) character set registry http://www.isi.edu/in-notes/iana/assignments/character-sets は ISO-10646-UCS-2 についてこのように述べています：

「これにはネット ワークバイトオーダーを指定する必要がある: 標準は定められていない」
ネットワークバイトオーダーはビッグエンディアンです。また RFC 2152 に、より明確に記述されています：「ISO/IEC 10646-1:1993(E) にはUCS-2 の文字がオクテットで表現される時には、最も大きいオクテットが始めに来ると 示されています」ところが Microsoftは自社の C/C++ 開発ツールではマシン依 存のエンディアン(つまり intel x86 系のプロセッサではリトルエンディアン) を使用することと、ドキュメントの始めにバイトオーダーのマークもしくは統計 的検出法(statistical heuristics)を使用することを推奨しています。

(訳注： heuristics とは例えば、バイトオーダが入れ替わっているような状態 では何の手がかりもないと、どんなキャラクタセットかわからない。でも例えば 日本語の文章の場合には統計的に、'、' や `。' などはそれなりの頻度で現れ ると予測されるので、もしそうなら日本語じゃないかと判断するようなことです)

それに対して UTF-8 のアプローチでは、`char*' を C の標準の文字 列型のままとしています。結果としてプログラムは ASCII テキストを環境変数 に関わらず扱うことができ、また LANG 環境変数を指定すれば ISO-8859-1 と UTF-8 でエンコードされたテキストをも扱うことができます。

2.3 関連文書

Markus Kuhn の最新リソースリスト：

Roman Czyborra の Unicode、UTF-8 および UTF-8 対応プログラムのオーバービュー：

http://czyborra.com/utf/#UTF-8

UTF-8 ファイルの例：

次のページ 前のページ 目次へ