国際化についての FAQ

このページでは、Java 2 Platform, Standard Edition, バージョン 1.4 および Sun の Java 2 Runtime Environment, Standard Edition, バージョン 1.4 の国際化に関する一般的な質問に答えています。 詳細については、「国際化」を参照してください。

• 一般的な質問
• ロケール
• リソースバンドル
• テキスト処理
• 文字エンコーディング
• テキスト入力
• テキストのレンダリング
• コンポーネントの向き
• その他

一般的な質問

国際化とは何ですか。

国際化により、ソフトウェアを任意の言語と文化的慣習に適応させることができます。 国際化のプロセスにおいてプログラマは、プログラム内で言語と文化に依存する部分を分離させます。 たとえば、プログラマがエラーメッセージを分離させるのは、地域対応の際にエラーメッセージは翻訳する必要があるためです。

地域対応とは何ですか。

地域対応とは、特定のロケールで使用するために、プログラムを適応させるプロセスです。 ロケールとは、同じ言語と習慣を共有する地理的または政治的な領域のことです。 地域対応には、GUI ラベル、エラーメッセージ、オンラインヘルプなどの翻訳が含まれます。 地域対応には、通貨や時間、日付や数値など、そのロケールの文化によって異なるデータ項目の書式設定も含まれます。

既存のプログラムを国際化する方法を教えてください。

『Java チュートリアル』の「Checklist」で解説されている手順を参照してください。

ロケール

ロケールとは何ですか。

ロケールとは、同じ言語と習慣を共有する地理的または政治的な領域のことです。 Java プログラミング言語では、ロケールは、Locale オブジェクトによって表されます。 照合、データ書式設定などロケールに依存する操作は、ロケールによって異なります。

Locale オブジェクトを使ったコード例はどこにありますか。

『Java チュートリアル』の「Setting the Locale」を参照してください。

どのロケールがサポートされていますか。

サポートされるロケールは、Java 2 プラットフォームの実装により、また機能範囲により異なります。 Sun の Java 2 Runtime Environment でサポートされるロケールについては、『サポートされているロケール』ドキュメントを参照してください。

Java アプリケーションでは複数のロケールを使用できますか。

できます。 この機能により、多言語対応のアプリケーションを作成することができます。

アプリケーションの外部からデフォルトのロケールを設定できますか。

使用している Java 2 プラットフォームの実装によって異なります。 通常、初期のデフォルトロケールは、ホストオペレーティングシステムのロケールによって決まります。 Sun の Java 2 Runtime Environment バージョン 1.4 では、コマンド行から user.language、user.country、および user.variant の各システムプロパティを設定することで、初期のデフォルトロケールを変更できます。 たとえば、初期のデフォルトロケールとして Locale("de", "DE", "EURO") を選択するには、次のコマンドを使用します。

java -Duser.language=de -Duser.country=DE -Duser.variant=EURO MainClass

この機能を使用できない実行環境もあるため、この機能はテスト目的だけに使用してください。

リソースバンドル

リソースバンドルとは何ですか。

ResourceBundle オブジェクトにより、アプリケーションの地域対応できる要素を他の要素から分離させることができます。 すべてのリソースをバンドルに分ければ、アプリケーションは実際に使用するロケールに適したバンドルをロードするだけで済みます。 ユーザがロケールを切り替えると、アプリケーションは別のバンドルをロードします。

ResourceBundle オブジェクトを使ったコード例はどこにありますか。

『Java チュートリアル』の「Isolating Locale-Specific Data」を参照してください。

プロパティファイルに ASCII 以外の文字列を指定する方法を教えてください。

任意の Unicode 文字を、¥uXXXX という表記によって指定できます (XXXX は、文字の Unicode 値を構成する 4 桁の 16 進数を表す)。 たとえば、プロパティファイルに、次のエントリを入力できます。

s1=hello there
s2=¥uff2d¥uff33¥u30b4

ファイルを ASCII 以外のエンコーディングで編集して保存した場合には、native2ascii ツールを使って ASCII コードに変換することができます。 たとえば、一般的な日本語のエンコーディングであるシフト JIS を使ってプロパティファイルを編集する場合には、この操作が必要になります。

ASCII 以外の ListResourceBundle をコンパイルする方法を教えてください。

ソースファイルが ASCII 以外のエンコーディングで記述されている場合は、Unicode に変換するようコンパイラに指示します。 たとえば、シフト JIS エンコーディングで記述された日本語リソースバンドルをコンパイルするには、次のようにします。

javac -encoding SJIS LabelsResource_ja.java

テキスト処理

日付の書式設定の方法を教えてください。

ロケールに依存する形式で書かれている日付の書式設定と文法解析には、SimpleDateFormat を使用します。 『Java チュートリアル』の「Dates and Times」の書式設定を参照してください。

フォーマッタはスレッドに対して安全ですか。

通常、java.text.Format のインスタンスとそのサブクラスは同期化されていません。 スレッドごとに別個のフォーマットインスタンスを作成することをお勧めします。 1 つのフォーマットに複数のスレッドが同時にアクセスする場合は、外部的に同期化する必要があります。

デフォルトのロケールを設定すると、ソートの結果にどのように影響しますか。

ソートルーチンの構築には、Collator クラスとそのサブクラスが使用されます。 これらのクラスはロケールに依存し、引数なしのコンストラクタで作成された場合には、デフォルトロケールの照合シーケンスを使用します。

Collator オブジェクトは、さまざまなレベルの decomposition および strength プロパティをサポートします。 あるロケールで、適切な decomposition と strength を選択する方法を教えてください。

複合語の解析には時間がかかるため、decomposition をオフにすると、比較が高速になります。 ただし、ラテン系の言語では、テキストにアクセント記号が含まれている場合には NO_DECOMPOSITION モードは役に立ちません。 明確な目的がない限り、デフォルトの decomposition を使用してください。

strength プロパティの選択は、アプリケーションの目的によって異なります。 たとえば、テキスト検索を行うときに、大文字と小文字の区別およびアクセントを無視する、「弱い」マッチングを許可する場合があります。 このタイプの検索では、PRIMARY の strength を採用します。 単語のリストをソートする場合には、strength に TERTIARY を使うことがあります。 このモードでは、ベースの文字、アクセント、大文字と小文字の区別が一致する必要があります。

文字エンコーディング

文字エンコーディングとは何ですか。

文字エンコーディングとは、文字とコード値の間の割り当てです。

Unicode とは何ですか。

Java プログラミング言語では、char 値は Unicode の値を表します。 Unicode は世界の主要言語をサポートする 16 ビットの文字エンコーディングです。 Unicode 標準の詳細については、Unicode Consortium の Web サイトを参照してください。

Unicode と他の文字エンコーディング間でデータを変換する方法を教えてください。

『Java チュートリアル』の「Converting Non-Unicode Text」に、上位 API を使用してアプリケーション内で変換を実行する方法が説明されています。または、文字変換についてより直接的な情報が必要な場合は、java.nio.charset.Charset クラスを参照してください。 データファイルを変換するには、 native2ascii ツールを使用します。

Unicode との間での変換がサポートされている文字エンコーディングは何ですか。

「サポートされているエンコーディング」を参照してください。

独自の文字変換プログラムの作成方法を教えてください。

java.nio.charset.spi.CharsetProvider クラスを使用すると、独自の文字変換プログラムを作成できます。

デフォルトエンコーディングとは何ですか。

デフォルトエンコーディングは、ホストオペレーティングシステムおよびそのロケールに基づく Java 実行環境により選択されます。 たとえば、Windows の US ロケールでは、Cp1252 が使用されます。 Solaris の簡体字中国語ロケールでは、Solaris へのログイン時の選択に基づき、EUC_CN または GBK のいずれかがデフォルトエンコーディングになります。

Java プログラミング言語では文字の表現に Unicode を使用しますが、ホストオペレーティングシステムのファイルシステムでは通常、別のエンコーディングを使用するため、デフォルトエンコーディングは重要です。 正確な相互変換を保証するために、デフォルトエンコーディングを、ホストオペレーティングシステムが使用するエンコーディングに一致させる必要があります。

UTF-8 エンコーディングとは何ですか。

UTF-8 は、Universal Transformation Format の 8 ビットエンコード形式を表します。 これは、さまざまなネットワークプロトコルや UNIX ファイルシステムでの使用に適した、Unicode の伝送フォーマットです。

Cp1252 エンコーディングと ISO8859_1 エンコーディングは同一ですか。

違います。Cp1252 には、0x80 から 0x9F の範囲の文字が追加されています。 詳細は、Microsoft のドキュメントを参照してください。

テキスト入力

Input Method Framework とは何ですか。

Input Method Framework により、すべてのテキスト編集コンポーネントはインプットメソッドを通じて日本語、中国語、韓国語のテキスト入力を受け取ることができます。 ユーザはインプットメソッドにより、ごく少数のキーを使って、キーボードから多くの異なった文字を入力することができます。 通常は、複数の文字のシーケンスを入力してから 1 つまたは複数の文字に変換します。 仕様と例については、「Input Method Framework」を参照してください。

「インプットメソッドを切り替える」とはどういう意味ですか。

ユーザが複数のインプットメソッドを利用できる場合があります。 たとえば、複数の異なる言語のためのインプットメソッドがある場合や、さまざまなタイプの入力を受け付けるインプットメソッドがある場合などです。 この場合、ユーザは特定の言語に使うインプットメソッドや、もっとも早く入力できるインプットメソッドを選択できます。

プログラムを使って、インプットメソッドを選択してアクティブにすることはできますか。

アプリケーションは、InputContext.selectInputMethod メソッドを使って、特定のロケールをサポートする入力メソッドを要求できますが、特定の入力メソッドを選択することはできません。選択を行えるのはユーザだけです。

アプリケーションは、InputContext.setCompositionEnabled メソッドを使って入力メソッドをアクティブにできます。

AWT コンポーネントと Swing (JFC) テキストコンポーネントでは、インプットメソッドが機能しますか。

「Java 2 SDK 国際化の概要」の「Input Method Framework」を参照してください。

テキストのレンダリング

アプリケーションでフォントを選択する場合、どんな方法がありますか。

軽量コンポーネントを使用するアプリケーションは、次の 4 通りの方法でフォントを選択できます。

• 論理フォント名の使用。 Java 2 プラットフォームでは、すべての実装でのサポートが求められる 5 つの論理フォント名 (Serif、SansSerif、Monospaced、Dialog、DialogInput) が定義されています。 論理フォント名は、実装に依存した方法で、物理フォントにマップされます。 一般に、1 つの論理フォント名は、広範囲の文字をカバーするために複数の物理フォント名に割り当てられます。
• 物理フォント名の使用。 アプリケーションは、Java 2 プラットフォームが提供する API を使用して、指定された実行環境で使用可能なフォント、および該当するフォントで処理可能な文字を判別し、そのフォントを実名 (Times Roman や Helvetica など) を使って要求します。 アプリケーションでは、ユーザにフォントの選択を任せることも、使用するフォントをプログラムを使って決定することもできます。
• Lucida フォントの使用。 Sun の Java 2 Runtime Environment に含まれるこの物理フォントファミリは、Java 2 プラットフォームの他の実装でも使用できるようライセンス付与されています。 これらのフォントは物理フォントですが、ホストオペレーティングシステムには依存しません。
• バンドルされている物理フォントの使用。 アプリケーションで TrueType フォントをバンドルし、Font.createFont メソッドを使ってこれらのフォントのインスタンスを作成できます。

ピア AWT コンポーネントを使用するアプリケーションでは、論理フォント名のみ使用できます。

これら 4 通りの選択方法の利点と欠点を教えてください。

以下に概要を示します。

• 論理フォント名の使用。
  • 利点: これらのフォント名は、どこでも動作することが保証されており、少なくともオペレーティングシステムのローカライズ対象言語でのテキストレンダリングは可能です (大抵は、より広範な言語でのテキストレンダリングが可能)。
  • 欠点: テキストレンダリングに使用される物理フォントは、実装、ホストオペレーティングシステム、およびロケールが異なると変化します。このため、アプリケーションの外観がどこでも同じになることはありません。 また、マッピング機構がレンダリング可能な文字の範囲を制限することもしばしばあります。 たとえば、Sun の Java 2 Runtime Environment では、日本語テキストのレンダリングは日本語にローカライズされたホストオペレーティングシステムでのみ可能です。日本語のフォントがインストールされている場合でも、他国語にローカライズされたシステムではレンダリングできません。
• 物理フォント名の使用
  • 利点: この方法を利用すると、利用可能なフォントすべてをアプリケーションで最大限活用して、テキストの外観を変化させたり、利用可能な言語の範囲を最大限拡大したりすることができます。
  • 欠点: この方法では、プログラミングがかなり難しくなります。
• Lucida フォントの使用。
  • 利点: これらのフォントを使用するアプリケーションでは、環境が異なってもフォントが存在すれば、共通の外観を提供できます。 またこれらのフォントは、言語範囲が広範囲に渡るため (特にヨーロッパおよび中近東の言語)、サポート対象の言語用の多言語対応アプリケーションを作成できます。
  • 欠点: これらのフォントは、Java 2 Runtime Environment すべてで使用できるとは限りません。 また、現在のところ、Unicode 文字セットの範囲を完全にはカバーしていません。特に、中国語、日本語、韓国語はサポートされていません。
• バンドルされている物理フォントの使用。
  • 利点: これらのフォントを使用するアプリケーションでは、環境が異なっても共通の外観を提供できます。また、サポートする言語をアプリケーションで完全に制御できます。
  • 欠点: 中国語、日本語、および韓国語をサポートする場合は特に、バンドルされるフォントのサイズがかなり大きくなります。 ライセンスの問題を解決する必要もあります。

中国語、日本語、または韓国語のフォントがインストールされているのに、アプリケーションでこれらの言語の文字が表示されないのはなぜですか。

アプリケーションからのフォントの選択方法によって異なります。上記を参照してください。

• 論理フォント名の使用。 物理フォントを使用する場合、マッピング機構を使ってフォントを選択する必要があります。 Sun の Java 2 Runtime Environment では、中国語、日本語、または韓国語のフォントは、これらの特定言語用にローカライズされたホストオペレーティングシステムが稼動している場合にのみ、選択可能になります。 マッピングを変更するには、font.properties ファイル (以下を参照) を変更する必要があります。
• 物理フォント名の使用。 アプリケーションでフォントが適切に選択されていない、または Java 2 Runtime Environment でサポートしていないエンコーディングがフォントで使用されている場合があります。
• Lucida フォントの使用。 Sun の Java 2 Runtime Environment に含まれる Lucida フォントは、中国語、日本語、韓国語をサポートしていません。
• バンドルされている物理フォントの使用。 アプリケーションにバンドルされているフォントが、これらの言語をサポートしていない可能性があります。

font.properties ファイルとは何ですか。

Sun の Java 2 Runtime Environment では、論理フォント名から物理フォントへのマッピングに font.properties ファイルが使用されます。 ホストオペレーティングシステムのバージョンおよびロケールに基づき、異なるマッピングをサポートする複数のファイルが存在します。 ファイルの位置は、J2RE のインストール先の lib ディレクトリです。

font.properties ファイルは実装に依存しています。 Java 2 プラットフォームの実装すべてでこのファイルが使用されるわけではありません。また、その内容と形式は実行環境およびリリースにより異なります。

論理フォントのマッピングに物理フォントを追加する方法を教えてください。

論理フォントから物理フォントへのマッピングは実装に依存しているため、複数の回答が存在します。 Sun の Java 2 Runtime Environment では、font.properties ファイルを作成または変更する必要があります。Web ページ「font.properties ファイル」を参照してください。 ただし、この操作により J2RE が変更されますが、Sun は変更後の J2RE をサポートしないことに留意してください。 他の実装については、該当するドキュメントを参照してください。

Swing コンポーネントでは表示されるある文字が、ピア AWT コンポーネントでは表示されません。なぜですか。

Swing ユーザインタフェースコンポーネントが使用するレンダリング機構は、ピア AWT コンポーネントが使用するレンダリング機構とは異なります。 Swing コンポーネントは、Graphics.drawString メソッドを使用します。このメソッドでは、一般に論理フォント名が指定されます。 次に論理フォント名から物理フォントセットへのマッピングが実行されて、広範囲の文字がカバーされます。 一方、AWT コンポーネントは、ホストオペレーティングシステムのコンポーネントを使って実装されます。 ホストオペレーティングシステムのコンポーネントでは、Unicode がサポートされていないことがよくあります。このため、ホストオペレーティングシステムおよびロケールに基づき、テキストが別の文字エンコーディングに変換されます。 これらのエンコーディングでは、論理フォント名の実装に使用される物理フォントに比べて、カバーする文字範囲が狭くなることがよくあります。 たとえば、日本語 Windows システムでは、アクセント記号付きの文字の多くは Swing コンポーネントでは Arial フォントに割り当てられますが、テキストをピア AWT コンポーネント用のシフト JIS エンコーディングに変換すると、これらの文字は失われてしまいます。

Unicode フォントをインストールしましたが、アプリケーションですべての Unicode 文字を表示できません。なぜですか。

上記の「中国語/日本語/韓国語の場合」で説明したように、原因は、Unicode フォントを使ってテキストが全く、または一部しかレンダリングされないことにあります。 アプリケーションが物理フォント名を使って Unicode フォントを選択していても、すべての文字をレンダリングできない場合、その Unicode フォントが実はすべての Unicode 文字セットをカバーしていない可能性があります。あるフォントの提供するテーブルが Unicode 文字エンコーディングをサポートしているだけで、そのフォントが Unicode フォントと呼ばれる場合があります。

Sun の Java 2 Runtime Environment がサポートするフォントにはどのようなものがありますか。

「サポートされているフォント」を参照してください。

Sun の Java 2 Runtime Environment で複数の言語を表示することはできますか。

簡単に言えば、それは可能です。 詳しい説明としては、同時に表示する言語、およびアプリケーションでフォントを選択する方法を調査する必要があります。

• 言語グループで小規模な共通文字セットを共有するのは、一般的な方法です。たとえば、西ヨーロッパ言語は、ISO 8859-1 文字セットでの記述が可能です。 この種のグループ内だけで言語を表示する場合、そのままの状態で機能するため、特に操作は必要ありません。
• 表示する言語がすべて Lucida フォントファミリによりサポートされている場合、およびこのフォントファミリを含む Java 2 Runtime Environment 上でのみアプリケーションを実行する場合、このフォントファミリのフォントを使用するだけで十分です。
• 文字範囲の異なる言語をサポートする必要がある場合、およびアプリケーションでのフォントの選択に論理フォント名を使用する場合、使用する言語すべてをサポートする font.properties ファイルを作成する必要があります。 詳細は、Web ページ「font.properties ファイル」を参照してください。
• 異なる文字範囲をサポートする必要がある場合、およびアプリケーションでのフォントの選択に物理名を使用する場合、フォントの選択を、フォントがサポートする文字範囲の情報を使って行う必要があります。

Sun の Java 2 Runtime Environment では、タイ語、ラオ語、ビルマ語、またはインド語派の文字体系のテキストレンダリングが可能ですか。

Sun の Java 2 Runtime Environment のバージョン 1.4 では、南アジアおよび東南アジアの文字体系のうち、タイ語とデーヴァナーガリー文字 (インド諸言語用文字) がサポートされています。 サポートされているすべての書記体系の一覧については、「サポートされているロケール」ドキュメントを参照してください。 その他の書記体系のサポートは、今後のリリースで追加される可能性があります。

コンポーネントの向き

Sun の Java 2 Runtime Environment で、コンポーネントの向きを実装しているのはどのユーザインタフェースコンポーネントですか。

「サポートされているロケール」を参照してください。

その他

Sun の Java 2 Runtime Environment はユーロ通貨をサポートしていますか。

サポートしています。Sun の Java 2 Runtime Environment では、ユーロ文字の入力、レンダリング、さまざまな文字エンコーディングへの変換が可能です。また、数値を通貨に変換する際にユーロ文字を使用することもできます。 テキストを入力およびレンダリングする場合、ホストオペレーティングシステムの適切なサポートが必要です。詳細は、Windows のドキュメントおよび Solaris のドキュメント (「一般的な情報」 および 「パッチ」) を参照してください。 2002 年 1 月 1 日より前にユーロ通貨記号を使用して書式設定をする場合は、EURO 形式でロケールを要求するか、または新しい java.util.Currency クラスを指定します。 Sun の Java 2 Runtime Environments v. 1.4 では、2002 年 1 月 1 日から、ユーロを欧州通貨統合の参加国のデフォルト通貨として使用します。