プログラムが扱う言語や,文化的データ,文字のエンコード方式についてあらかじめ知らなくても,プログラムの開発が行える仕組みのことを国際化と呼びます。 システムの観点からは,プログラムが実行時の環境に合わせ,さまざまな出力を生成できるようにするインタフェースを提供することを国際化といいます。 国際化 (internationalization) を略して I18N と呼ぶことがあります。
本書では,国際化プログラムの開発に役立つ,Tru64 UNIX のインタフェースとユーティリティについて説明します。 これらのインタフェースとユーティリティは,X/Open の UNIX 標準仕様に準拠しています。 この標準仕様では,一部のインタフェースとユーティリティで,ベンダの実装に依存した動作が認められています。 本書では, Tru64 UNIX に固有のソフトウェア特性については,その旨を明記します。
以下の節では,国際化プログラムの開発に使用されるオペレーティング・システム・インタフェースおよびユーティリティの概要について説明します。
言語。 1.1 節では,言語に依存する処理の実装について概要を説明します。 1.2 節では,ソフトウェア・アプリケーションの立場から言語を明確にします。
文化的データ。 1.3 節では,文化的データを明確にします。 1.1.1 項では,コンピュータ・システムでの文化的要件またはローカル要件の実装について説明します。
文字セット。 1.4 節では,国際化の立場から文字セットを明確にします。
言語宣言は,システム全体で,またはアプリケーションごと,あるいはユーザごとに,言語,文化的データ,およびコードセットの要件を設定するためのメカニズムです。 言語宣言は,いくつかの予約されている環境変数にロケール名を設定することで行います。 システム管理者は,シェル環境ごとにこれらの変数の省略値を設定できます。 シェルに設定するロケールの省略値については,Tru64 UNIX の『システム管理ガイド』を参照してください。 ロケール変数は,プロセスごとに設定することもできます。
一般に,国際化プログラムは実行時にロケール変数を読み取り,ロケール変数の設定内容をプログラムの動作環境のロケール・カテゴリに取り込みます。
ただし,プログラムは,そのつどこれらのカテゴリを内部的に設定できます。
そのため,特定のロケールへのバインドは,プログラムのすべての部分に適用されるわけではありません。
同一の実行サイクル内で,プログラムの部分ごとに,異なる地域化を適用することもできます。
1.1.1 地域化
コンピュータ・システムに,ある地域における要件を実装する仕組みのことを地域化といいます。 これらの地域的要件のいくつかは,ロケールによって解決できます。 各ロケールは,その地域の言語,文化的データ,およびコードセットの特定の組み合わせをサポートするデータの集合です。 ロケールに含めることができる情報の種類と,ロケールを使用するインタフェースは,標準化されていますが,システム上のロケールのインストール位置とロケール名は,ベンダごとに異なります。
ロケールを提供するだけで地域化が実現できるわけではありません。 たとえば,地域化を実装するには,翻訳したソフトウェア・メッセージを用意して,適切なフォントと単位系をサポートし,さらにそれらが表示デバイスと印刷デバイスで利用できるようにする仕組みが必要になります。 また場合によっては,地域に固有な要件を満たすために,追加のソフトウェアを作成しなければなりません。
地域化 (localization) を略して L10N と呼ぶことがあります。
アプリケーション・プログラムでの地域化データおよびメッセージ・ファイルの作成と使用については,第 3 章を参照してください。 地域化とグラフィカル・ユーザ・インタフェースについては,第 5 章を参照してください。
地域化を実現する際のプログラミングについては第 2 章を参照し,ロケール (ソフトウェアの地域化の主要なツール) については第 6 章を参照してください。
1.2 言語
国際化プログラムは,特定の言語で文字データ (テキスト) を扱うことはありません。
言語は,テキスト処理における文字の扱いや単語の順序に影響します。 Tru64 UNIX には,国際化プログラムが,個々のユーザの使用する言語に応じてテキストを操作できるようにするインタフェースが用意されています。
言語の違いを吸収するためには,メッセージ・テキストとプログラム・コードを分離する必要があります。 Tru64 UNIX には,メッセージ・テキストをコードから分離して,別の言語に翻訳し,実行時にプログラムからアクセスできるようにする機能が備わっています。 第 3 章では,国際化インタフェース (WPI: Worldwide Portability Interfaces) を使用する国際化プログラムがどのようにメッセージを生成し,アクセスするかについて説明します。
X インタフェースと Motif インタフェースを使用する国際化プログラムは,次の方法でメッセージ・テキストをプログラム・コードから分離できます。
UIL (ユーザ・インタフェース言語) ファイル内にメニュー項目,タイトル,テキスト・フィールド,およびメッセージを定義する。
アプリケーションのリソース・ファイル内にタイトルとフォント・リストを指定する。
ヘルプ・ウィジェットが使用するファイル内にヘルプ・メッセージを指定する。
X インタフェースと Motif インタフェースでメッセージ・テキストをプログラム・コードから分離する方法については,次のドキュメントを参照してください。
『X Window System Toolkit』
『Common Desktop Environment: プログラマーズ・ガイド(国際化対応編)』
文字分類情報には,有効な各文字コードについての詳細な属性情報が含まれています。
つまり,コードがアルファベット,大文字,小文字,句読点,制御文字,スペースなどの文字種を定義しているかどうかを示します。
文字分類関数と国際化正規表現は,どちらもこの情報を使用して文字クラスを判別します。
1.2.2 大文字と小文字の変換
大文字/小文字変換では,有効な各文字コードにおける大文字と小文字を識別するための情報が参照されます。
大文字/小文字変換関数はこの情報を使用して,文字を大文字から小文字に,または小文字から大文字に変換します。
すべての英字に大文字と小文字の区別があるわけではなく,また,まったく区別のない言語もあります。
1.2.3 メッセージ・カタログ
メッセージ・カタログは,特定の言語のためのプログラム・メッセージ,コマンド・プロンプト,およびプロンプトへの応答を含むファイルまたは記憶領域です。
Motif アプリケーションでは,ロケールごとに異なるテキストやその他の値のために,メッセージ・カタログに加え,あるいはメッセージ・カタログの代わりに,リソース・ファイルと UIL ファイルを使用します。
メッセージ・システムについては,第 3 章で説明します。
1.3 文化的データ
文化的データとは,地理上の領域 (本書では地域と呼びます) の慣習のことです。 文化的データには,日付,時刻,通貨の書式などがあります。
国際化プログラムは,これらの文化的データがどのように設定されているかをあらかじめ想定することは不可能なため,実行時にシステム機能を使用して書式を判定します。
この機能は,言語情報データベース (langinfo データベース) から提供されます。
プログラムは,文化的データ項目に必要な書式情報をこのデータベースから取り出します。
1.3.1 言語情報
ロケールごとに異なる文化的データの書式と設定を記述する地域化データのことを,言語情報といいます。
langinfo データベースに格納される情報には,日付,時刻,通貨,および数値のための適切な書式と文字が含まれます。
1.4 文字セット
文字セットとは,自然言語やコンピュータ言語の単語と他の基本単位を構成する,アルファベットやその他の文字の集合です。 コード化文字セット (コードセット) とは,文字セットを定義し,その文字セット中の文字とそのビット表現との 1 対 1 の対応を明確に定義する規則の集合です。
さまざまなコードセットで記録されているテキストを扱うプログラムでは,文字コードのサイズやビット割り当てについて前提を設けることはできません。
特にそのようなプログラムでは,文字が格納されている領域の一部を他の用途に利用することはできません。
1.4.1 照合順序
照合順序 (文字の順序付け) は,ハードウェアでは暗黙的に決まっていることがありますが,ソフトウェアでは特定の地域で使用される言語に合わせて定義できます。 多くの言語には,複雑なソート規則があります。 照合規則の例を次に示します。
1 つのアルファベットが 1 つの文字で表現されるとはかぎらない。
たとえば伝統的なスペイン語では,ch
という文字の組み合わせが,文字
c
と
d
の間にソートされます。
1 つの文字が,複数文字の組み合わせと等価なことがある。
たとえば,ß という文字は,標準ドイツ語とスイス・ドイツ語では
ss
と等価であり,オーストリア・ドイツ語では
sz
と等価です。
アクセント文字が,アクセントの付かない文字の後に来るとはかぎらない。
多くの言語では,単語に含まれる文字がアクセント文字以外すべて同じ場合にのみ,アクセント文字を含む単語が後に置かれます。 また,特定のアクセント文字を独自の文字と見なし,アクセントの付かない文字とは別の文字の後にソートする言語もあります。
アジア系言語の表意文字には,読みに基づくソート順序と,2 種類の視覚的な構成要素 (意味を表す要素である部首と,画数) に基づくソート順序があります。
各ロケールには,対応するコードセットで定義されている文字の相対順序に関する照合順序情報が含まれており,この情報は文字列比較関数に渡されます。
また国際化対応の正規表現も,この照合順序を使用して,文字範囲,照合シンボル,および等価クラスを実装します。
1.4.2 文字と文字列
文字は,1 つのグラフィック・シンボルまたは制御コードを表す,1 つ以上のバイトの並びです。
文字という用語を,C プログラミング言語のデータ型である
char
と混同しないようにしてください。
char
は,基本実行文字セットの任意のメンバを格納するのに十分な大きさで,通常は 8 ビット値にマップされるオブジェクトを表します。
C の
char
データ型とは異なり,文字は,1 バイトまたは複数バイトの値で表現されます。
マルチバイト文字という表現は,文字という用語と同義です。
つまり両者とも,1 バイト値を含む,任意の長さの文字値を意味します。
文字の列または文字列は,ヌル・バイトで終わる,連続したバイト (ヌル・バイトも含む) の並びです。
C プログラミング言語では,文字列は
char
型の配列です。
ヌル・バイトは,すべてのビットにゼロ (0
) が設定されている値です。
ワイド文字は,拡張実行文字セットの任意のメンバを格納するのに十分な大きさの整数型です。
プログラムの観点からは,ワイド文字は,ヘッダ・ファイル
/usr/include/stddef.h
(X/Open XSH Specification に準拠) および
/usr/include/stdlib.h
(ANSI C 標準に準拠) で定義されている
wchar_t
型のオブジェクトです。
これらのヘッダ・ファイルの位置は,標準化組織が決定しますが,定義そのものは実装によって異なります。
たとえば,1 バイト・コードセットだけをサポートする実装 (Tru64 UNIX には当てはまりません) では,wchar_t
を 1 バイト値として定義することもあります。
ワイド文字列は,ヌル・ワイド文字で終わる,連続したワイド文字 (ヌル・ワイド文字も含む) の並びです。
ワイド文字列は,wchar_t
型の配列です。
ヌル・ワイド文字は,すべてのビットにゼロ (0
) が設定されている
wchar_t
値です。
空の文字列は,1 番目の要素がヌル・バイトの文字列です。
同様に,空のワイド文字列は,1 番目の要素がヌル・ワイド文字のワイド文字列です。
1.4.3 ポータブル文字セット
ポータブル文字セット (PCS) は,すべてのロケールにおいて,コンパイル時 (ソース) と実行時 (実行可能) 環境の両方でサポートされます。 PCS には次の文字が含まれます。
英語のアルファベットの 26 個の大文字
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
英語のアルファベットの 26 個の小文字
a b c d e f g h i j k l m n o p q r s t u v w x y z
10 個の 10 進数
0 1 2 3 4 5 6 7 8 9
次の 32 個のグラフィック文字
! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
スペース文字と,水平タブ,垂直タブ,および書式送りを表す制御文字
上記の文字に加え,実行時環境の PCS には,アラート,後退,復帰,および改行を表す制御文字が含まれる。
X/Open が規定するポータブル文字セットは,ISO/IEC 9899: 1990 で定義されている基本ソース文字セットおよび基本実行文字セットに類似しています。 ただし,X/Open バージョンには,ドル記号 ($),アットマーク (@),およびグレーブ・アクセント ( ` ) も含まれます。
一部のロケール (たとえば,ISO 646 の修正バージョン) では,上記の文字のいくつかが,他の文字で代用されていることがあります。 そのような場合,代用文字は,ポータブル文字セット中で置き換えられた文字と構文上同じ意味を持ちます。 文字の代用の例としては,省略時の番号記号 (#) に対するイギリスのポンド記号 ( £ ) があります。
すべてのコードセットに対応するポータブルな文字セットが定義された背景には,エンコード方式でサポートできる言語の数が限られていることが関係しています。
一般に,このことは,UNIX システム用に開発された文字エンコード方式にも当てはまります。
言い換えれば,中国語ロケールで使用されるコードセットは,中国語の文字に加え,すべての PCS 文字を含んでいなければなりませんが,ロシア語やアイスランド語をサポートするのに必要な文字を含むことはありません。
同様に,ロシア語に使用されるコードセットは,中国語の文字を含むことはありませんが,すべての PCS 文字を含んでいなければなりません。
つまり,ロケール設定が何であっても,プログラムは PCS 文字を使用できることになります。
1.4.4 ユニバーサル文字セット
Unicode および ISO/IEC 10646 標準で規定されているユニバーサル文字セット (UCS) は,本オペレーティング・システムでサポートされています。 UCS は,すべての主な言語で使用できる文字の種類を規定し,文字を処理するために各言語で使用するルールを標準化します。 この文字セットは,アプリケーションが同じエンコード方式と規則を使用することにより,すべての言語の文字を操作できるようにするという考えに基づいています。 このため,オペレーティング・システムで UCS をサポートするときには,複数のアルゴリズムを持つことなく,ファイル・コードと国際化プロセス・コードの変換をサポートすることができます。
ISO/IEC 10646 標準は,データの入出力に異なる解析方式を必要とする,2 種類の文字サイズ (16 ビットと 32 ビット) をサポートしています。 16 ビット単位 (2 オクテット) で解析する UCS エンコーディングを,UCS-2 といいます。 32 ビット単位 (4 オクテット) で解析する UCS エンコーディングを,UCS-4 といいます。 UCS-4 は,より多くの文字をサポートでき,大規模なコンピュータ・システムの内部処理コードとして使用したときに,効率的に操作することができます。
ファイル・データを取り扱うバイト指向のプロトコルで使用する UTF (Universal Transformation Format) を,標準では何種類も規定しています。 本オペレーティング・システムでは,UTF-8 と UTF-32 の使用をお勧めします。 本オペレーティング・システムは,次の UTF をサポートしています。
UTF-8 は,UCS-4 の処理コードを 8 ビットのバイト・シーケンスに変換し,C0 コード・ポジション (0 〜 31),SPACE 文字 (32),および DEL 文字 (127) の変換の透過性を保証する,標準的な方式です。 本オペレーティング・システムには,UTF-8 用のコードセット・コンパータおよびロケールが用意されています。
UTF-16 は,Unicode 標準で規定されている代替文字拡張手法を使用し,16 ビット単位で文字を表現します。 UTF-16 は UCS-2 のスーパセットですが,UCS-4 のコード空間のすべての表現はサポートしていません。 UTF-16 は,両方の標準でカバーしている言語で現在定義されている文字をすべてサポートしているわけではありません。
ファイル・コードのバイト・オーダは,ファイルが生成されたプラットフォームにより異なり,リトル・エンディアン (LE) またはビッグ・エンディアン (BE) になります。
UTF-16 では,バイト・オーダ・マーク (BOM) を使用して,バイト・オーダを示します。
BOM は,ファイル・テキスト・データの一部ではありません。
Unicode 標準には,BOM を含まない UTF-16LE と UTF-16BE (それぞれリトルエンディアンとビッグエンディアンのバイト・オーダ) も規定されています。
本オペレーティング・システムは,コードセット・コンバータを通して,UTF-16,UTF-16LE,および UTF-16BE をサポートします。
UCS-2 は UTF-16 のサブセットであるため,本オペレーティング・システムは,UCS-2 を UTF-16 コードセット・コンバータでサポートします。
UCS-2
コードセット・コンバータ名は,UTF-16*
という別名で認識されます。
ただし,文字の種類が制限されています。
オペレーティング・システムは通常,UTF-16LE や UTR-16BE ではなく,UTF-16 を想定します。
入力時,システムは BOM を探します。
BOM が見つからない場合,コンパータは UTF-16BE と見なします。
出力時,システムは自動的に BOM を挿入します。
アプリケーションが入力や出力時にリトル・エンディアンやビッグ・エンディアンのバイト・オーダを前提とする場合は,バイト・オーダを明示的に指示しなければなりません。
バイト・オーダの設定についての詳細は,
iconv_intro
(5)
UTF-32 では,4 バイトのエンコーディング単位で文字が表現されます。 UTF-32 は,文字の値の範囲が UTF-16 と同じ U+0000 〜 U+10FFFF に限定されている,UCS-4 の限定サブセットです。 U+10FFFF を超えるプライベート用範囲は,ISO/IEC 10646 と Unicode 標準のエンコーディング・フォーマットの相互動作性を向上するために,ISO/IEC 10646 の将来のバージョンでは削除されます。
UTF-32 では BOM を使用して,バイト・オーダがリトル・エンディアンとビッグ・エンディアンのどちらであるかを示します。 UTF-16 と同様に,Unicode 標準では BOM を含まない UTF-32LE と UTF-32BE を規定しています。 オペレーティング・システムでの入力および出力の省略時の設定も,UTF-16 と同じです。
UCS-4
コードセット・コンバータを使用して,UTF-32 を処理します。
本オペレーティング・システムは,コードセット・コンバータとロケールによって,UCS-4 をサポートします。 ロケールと一部のライブラリ関数では,アプリケーションが UCS-4 を内部処理コードとして使用することができます。 コードセット・コンバータを使用すると,ファイル・データを,システムに常駐しているフォントと他のソフトウェアがサポートするエンコーディング・フォーマットに変換することができます。
Unicode,ロケール,および関連するエンコーディング・フォーマットについての詳細は,2.2 節を参照してください。
curses
ライブラリと,ワイド文字フォーマットおよびマルチバイト文字のサポートについての情報は,第 4 章を参照してください。