国際化プログラミングの話題

ファイルエンコーディングとフォント

Unicode は、一般的には Mac OS X のためのネイティブ【本来の】エンコーディングとされており、ほぼすべての状況において使用されるべきであるといえます。

以前のバージョンの Mac OS は MacRoman といったファイルエンコーディングに対応していましたが、ほとんどの新しい Mac OS X ライブラリは、初めから Unicode に対応しています。

もし、あなたが Cocoa もしくは Core Foundation ルーチンを使用するのであれば、おそらく、他のファイルエンコーディングについて心配する必要はないでしょう。

けれども、もしあなたのソフトウェアが旧来のファイル形式に対応するのであれば、あなたは旧来のファイル形式をインポートする際にファイルエンコーディングの問題点を考慮する必要があるはずです。

以下のセクションでは、 Unicode 対応と、旧来のファイルエンコーディングに関連する、いくつかの問題点を説明します。

ファイルシステムと Unicode 対応

Mac OS X のさまざまなファイルシステムは、Unicode 対応の水準もさまざまです…

Mac OS 拡張（HFS+）は、16ビットコードの列【sequence】から構成される、canonically decomposed Unicode 3.2 in UTF-16 形式を使用します。（U2000-U2FFF、UF900-UFA6A、U2F800-U2FA1D の範囲にある文字は分解【decompose】されません。）
UFS ファイルシステムは Unicode 2.1 以降のあらゆる文字を許容しますが、UTF-8 形式を使用しており、これはほとんど 8ビット ASCII コードで構成されますが、マルチバイトコードも含んでいることがあります。（U2000-U2FFF、UF900-UFA6A、U2F800-U2FA1D の範囲にある文字は分解されません。）
Mac OS 標準（HFS）は Unicode に対応しておらず、代わりに MacRoman といった旧来の Mac エンコーディングを使用します。

Unicode の特定のバージョンに対して正規分解【canonically decomposed】を固定することによって、Unicode のより新しいバージョンで定義された文字の使用を拒絶することはありません。

なぜなら、Unicode 協会は合成済み【precomposed】の文字をこれ以上追加することはないことを保障しているため、アプリケーションは、Unicode の将来のバージョンで定義される文字を、互換性の問題を伴わずに記録することを想定できるのです。

注：実装の差異のため、Mac OS 9 上で入力されたけれど Mac OS X 上では化けて見えるときに、HFS+ ボリューム上のファイル名の中の誤った Unicode が正しく表示されることがあります。同様に、Mac OS X 上で入力された、誤った Unicode は、Mac OS 9 では化けて見えることがあります。【？】

すべての BSD システム関数は、その文字列パラメータが UTF-8 エンコーディングであり、例外はないと想定しています。BSD システムルーチンを呼ぶコードは、すべての const *char パラメータの内容が正規の UTF-8 エンコーディングであることを保障する必要があります。

正規の UTF-8 文字列内では、分解可能な文字列はすべて分解されています。たとえば、é（0x00E9）は、e（0x0065）+ ́（0x0301）で表されます。

何かを正規の UTF-8 エンコーディングにするには、Cocoa と Carbon （Core Foundation を含む）において定義されている、「ファイルシステム表現」【file-system representation】インタフェースを使用します。

正規の文字列を取得する

Cocoa および Core Foundation は、共に、正規および非正規 Unicode 文字列にアクセスするためのルーチンを提供します。

Cocoa の文字列操作は、すべて NSString クラスと、そのサブクラスを通じて取り扱われます。

Core Foundation においては、望みのエンコーディングを伴う C 文字列を取得するために、あなたは CFStringGetCString および CFStringGetCStringPtr 関数を使用することができます。

Carbon と QuickDraw の問題点

もし、既存の QuickDraw コードがあって、文字列を描画したい場合、あなたは QuickDraw Text ルーチンが、直接 Unicode に対応していないという点を認識する必要があります。

Carbon File Manager は、Mac エンコーディングを返すファイルシステム呼び出しをいくつか持っており、そのほかは Unicode を返します。もし、あなたがこの Unicode テキストを直接 QuickDraw ルーチンに渡したら、あなたは問題に直面することになるでしょう。

同様に、もしあなたが Mac エンコーディングでテキストを取得し、それを Cocoa や Carbon の Apple Type Services for Unicode Imaging（ATSUI）API と共に使用したい場合、あなたはまず初めにそのテキストを Unicode に変換しなければなりません。

一般的に、使用されるエンコーディングが依存しているのはあなたの使用する API に対してであって、フォントではありません。フォントは特定のエンコーディングに制限する必要はありません。

たとえば、TrueType フォントは、自らが実装しているグリフ【字の形】のセットを宣言しており、また、これらのグリフを特定のエンコーディングにおける文字の値に対応付ける、エンコーディングテーブルを提供します。PostScript フォントも同様のエンコーディングテーブルを持ちます。

オペレーティングシステムのさまざまな部分は、あるエンコーディングから別のエンコーディングへと、どのように文字を対応付けるのかを知っています。

Cocoa そして ATSUI は、Unicode をフォントの「行き先」の対応付けとして用います。

Carbon における QuickDraw Text ルーチンは、フォントの'FOND'リソースに対応する筆記形式【スクリプト】に一致するように選択された、Mac エンコーディングを使用します。

Mac OS X と共にインストールされたフォントは、幅広いエンコーディングと筆記形式に対応する、大きな文字セットをもちます。たとえば、システムフォントである Lucida は、拡張ラテン語、ギリシャ語、キリル語、アラビア語、ヘブライ語、タイ語に対応しています。

ですが、もしあなたが QuickDraw Text を通じてテキストを描画するのであれば、あなたは MacRoman のレパートリーへのアクセスしか持ちません。残りにアクセスするためには、あなたは Cocoa や ATSUI を使用する必要があります。

同様に、ヒラギノフォントは MacJapanese での対応を上回る、文字の大きなレパートリーを持ちます。そしてこれらは Cocoa か ATSUI を通じてのみアクセスできるのです。

また、Cocoa と ATSUI の両者は共に、要求されたグリフが使用できないときには、他のフォントからグリフを代用します。ただし、フォント代用のための両者のアルゴリズムは異なります。

マルチスクリプト対応の文脈におけるファイルスクリプトの詳細については、「マルチスクリプト対応を追加するためのガイドライン」（26ページ）を参照してください。

Cocoa の問題点

Cocoa は Unicode を文字のエンコーディングのために使用し、あらゆる Cocoa アプリケーションに、ほとんどの自然言語を表示する能力を与えます。

Cocoa は縦書きや双方向テキストに対応していますが、NSTypesetter クラスは水平テキストのためのレイアウトのみに対応しています。