- 一般的な質問
- Core Java の国際化
- Desktop Java の国際化
- Enterprise Java の国際化
 |
国際化とは、ソフトウェアが容易に、低コストで、尚且つソフトウェアに技術的な変更を加える事なく、 様々な言語や地域に対応（地域化）できる様にする為のソフトウェア設計の過程です。 地域化する際に、ソフトウェアに技術的な変更を加える必要が無いというのが中でもとりわけ重要なポイントです。 通常、国際化には、プログラムから言語や文化に依存する部分を取り除く処理が含まれます。たとえば、エラーメッセージのテキスト は、地域対応化の過程で翻訳する必要があるので、プログラムのソースコードから切り離しておかなければなりません。
地域対応とは、特定のロケールで使用するために、プログラムを適応させるプロセスです。ロケールと は、同じ言語と習慣を共有する地理的または政治的な領域のことです。地域対応化には、ユーザインタフェースのラベル、エラーメッセージ、オンラインヘルプ などの翻訳が含まれます。地域対応には、通貨や時間、日付や数値など、そのロケールの文化によって異なるデータ項目の書式設定も含まれます。
プログラムの国際化を行いたいのですが、どこから始めたらよいでしょうか。
最初から始めることをお勧めします。具体的には、ソフトウェアの要件を決定するときから始めます。地域対応化を簡単に行える柔軟なソフトウェアを設 計するには、サポート予定のすべての国、すべての言語 (ロケール) で、要件がどのように異なるかを把握しておく必要があります。このプロセスでは、Sun Software Product Internationalization Taxonomy を利用するとよいでしょう。Java チュートリアルにも、いくつかの共通の問題の特定に役立つ簡単なチェックリストが付いていま す。要件を特定できたら、Java チュートリアルの「Internationalization Trail」や、「Java Internationalization」のページから参照されているその他の資料を参考に、設計および実装上の適切なソリューションを見つけ てください。
Sun の JRE は、ユーロ (通貨単位) をサポートしていますか。
サポートしています。Sun の JRE では、ユーロ文字の入力、レンダリング、さまざまな文字エンコーディングへの変換が可能です。また、数値を通貨に変換する際にユーロ文字を使用することも できます。テキストを入力およびレンダリングする場合、ホストオペレーティングシステムの適切なサポートが必要です。詳細は、 のドキュメントおよび Solaris のドキュメントを参照してください。通貨文字の書式に関して、Sun の JRE のバージョン 1.4 では、欧州通貨同盟の加盟国のデフォルト通貨はユーロになっています。JRE 1.3.1 では、EURO バリアントを使ってロケールを選択する必要があります。
|
Java プラットフォームではテキストはどのように表示されますか。
Java プログラミング言語は Unicode 文字セットをベースにしており、いくつかのライブラリでは Unicode 標準が実装されています。Java プログラミング言語の基本データ型 char は、符号なしの 16 ビット整数なので、U+0000 ～ U+FFFF の範囲の Unicode コードポイントや、UTF-16 のコード単位を表現できます。Java プラットフォームで文字シーケンスを表現する各種の型およびクラスは、UTF-16 のシーケンスです。そのような型およびクラスとしては、char[]、java.lang.CharSequence の実装 (String クラスなど)、java.text.CharacterIterator の実装などがあります。
Unicode は、世界の主要な書記法すべてに加えて、基本的な学術記号をサポートしています。Unicode 仕様では最初、各文字を 16 ビット固定長の実体として定義していましたが、その後、16 ビットより長い表現を必要とする文字も取り扱えるように Unicode 標準が変更されました。有効なコードポイントの範囲は現在、U+ 0000 ～ U+10FFFF です。Unicode 標準の詳細については、Unicode Consortium の Web サイトを参照してください。
J2SE プラットフォームでサポートされる Unicode 標準のバージョンと、補助文字について教えてください。
J2SE 5 では、文字処理が Unicode 標準のバージョン 4.0 に基づいて行われるようになりました。このアップグレードの一環として、補助文字のサポートが JSR 204 エキスパートグループによって規定され、JDK 全体に実装されました。詳細については、「Java プラットフォームにおける補助文字のサポート」および「Java Specification Request 204」の各資料と、Character クラスのドキュメントを参照してください。
J2SE 1.4 では Unicode 標準のバージョン 3.0、J2SE 1.3 では Unicode 標準のバージョン 2.1 が使用されます。通常、補助文字のサポートはありません。
コードポイント、 コードユニット、補助文字などについて教えてください。
「コード化文字セット」は文字セット (一揃いの文字) の一種です。この文字セットに含まれる各文字には、固有の番号が割り当てられています。Unicode 標準の核となるのは、文字 A に数字 004116、 文字 € (ユーロ記号) に数字 20AC16 を割り当てるコード化文字セットです。Unicode 標準では、常に 16 進数が使用されます。これらの 16 進数には「U+」という接頭辞が付けられるので、たとえば文字 A は「U+0041」のように記述されます。
コードポイントは、コード化文字セットで使用可能な数字です。コード化文字セッ トでは、有効なコードポイントが定義されています。ただし、コードポイント全部に文字が割り当てられているとは限りません。Unicode では、U+0000 ～ U+10FFFF の範囲のコードポイントが有効です。Unicode 4.0 では、100 万以上に及ぶコードポイントのうち 96,382 個に文字が割り当てられています。
補助文字は、U+10000 ～ U+10FFFF の範囲のコードポイントを持つ文字です。これらは、元の 16 ビット方式では表現できない文字に該当します。U+0000 ～ U+FFFF の範囲の文字セットは、「基本多言語面 (BMP: Basic Multilingual Plane)」と呼ばれます。このように、Unicode の各文字は、BMP か補助文字のどちらかになります。
文字エンコーディングスキーマは、1 つまたは複数のコード化文字セットの番号を 1 つまたは複数の固定長コードユニットのシーケンスに対応付けるものです。もっともよく使用されるコードユニットは 8 ビットバイトですが、内部処理には 16 ビットや 32 ビットの整数も使用できます。UTF-32、UTF-16、UTF-8 は、Unicode 標準のコード化文字セットに対応する文字エンコーディングスキーマです。
文字エンコーディングは、コードユニットのシーケンスに文字セットを対応付けるもの です。文字エンコーディングスキーマは、1 つまたは複数のコード化文字セットに適用されます。もっともよく使用される文字エンコーディングは、UTF-8、ISO-8859-1、GB18030、 Shift_JIS です。
UTF-16 は、符号なしの 16 ビットコードユニットを 1 ～ 2 個使って、Unicode のコードポイントを符号化します。U+0000 ～ U+FFFF の値は、同じ値の 16 ビットユニット 1 個で符号化されます。補助文字はコードユニット 2 個でエンコードされます。1 つめのコードユニットは上位サロゲート範囲 (U+D800 ～ U+DBFF)、2 つめのコードユニットは下位サロゲート範囲 (U+DC00 ～ U+DFFF) に対応しています。これは複数バイトのエンコーディングと概念上よく似ていますが、重要な違いがあります。U+D800 ～ U+DFFF の値は UTF-16 用に予約されていて、これらの値にコードポイントとして文字が割り当てられることはありません。つまり、文字列内の個々のコードユニットが 1 ユニットの文字を表しているのか、2 ユニットの文字の最初のユニットまたは 2 番目のユニットを表しているのかをソフトウェアで判断できるということです。これにより、0x41 が文字 A であるのか 2 バイト文字の 2 番目のバイトであるのか判りづらかった、従来の複数バイト文字エンコーディングが大幅に改善されました。
|
ロケールとは、同じ言語と習慣を共有する地理的または政治的な領域のことです。Java プラットフォームでは、ロケールは、Locale オブジェクトによって表されます。照合、データ書式設定などロケールに依存 する操作は、ロケールによって異なります。
Locale オブジェクトを使ったコード例はどこにありますか。
『Java チュートリアル』の「Setting the Locale」を 参照してください。
サポートされるロケールは、Java プラットフォームの実装により、また機能範囲により異なります。Sun の JRE でサポートされるロケールについては、J2SE 5.0、J2SE 1.4.2、 および J2SE 1.3.1 の「サポートされているロケール」または「サポートするロケール」に記載されています。
Java アプリケーションでは複数のロケールを使用できますか。
ロケールの影響を受ける API では、多くの場合、ロケールの指定が可能です。このため、複数の異なったロケールを同時に処理できるアプリケーションを作成できます。たとえば、Java で作成された Web アプリケーションでは、複数のロケールを同時に使用して、異なった要求を処理できます。
アプリケーションの外部からデフォルトのロケールを設定できますか。
使用している Java プラットフォームの実装によって異なります。通常、初期のデフォルトロケールは、ホストオペレーティングシステムのロケールによって決まります。Sun の JRE のバージョン 1.4 以降では、コマンド行から user.language、user.country、および user.variant の各システムプロパティを設定することで、初期のデフォルトロケールを変更できます。たとえば、初期のデフォルトロケールとして Locale("th", "TH", "TH") を選択するには、次のコマンドを使用します。
java -Duser.language=th -Duser.country=TH -Duser.variant=TH MainClass
この機能を使用できない実行環境もあるため、この機能はテスト目的だけに使用してください。
ResourceBundle オブジェクトにより、アプリケーションの地域対応できる要素を他の要素から分離させることができます。すべてのリソースをバンドルに分けれ ば、アプリケーションは要求されたロケールに適したバンドルをロードするだけで済みます。別のロケールが要求されると、アプリケーションは別のバンドルを ロードします。
ResourceBundle オブジェクトを使ったコード例はどこにありますか。
『Java チュートリアル』の「Isolating Locale-Specific Data」を参照してください。
プロパティファイルに ASCII 以外の文字列を指定する方法を教えてください。
任意の Unicode 文字を、\uXXXX というエスケープシーケンスによって指定できます。補助文字の場合、UTF-16 のコード単位 (2 個) それぞれに 1 つずつ、合計 2 個のエスケープシーケンスが必要です。XXXX は、UTF-16 コード単位の値を表す 4 桁の 16 進数字です。たとえ ば、プロパティファイルに、次のエントリを入力できます。
s1=hello there
s2=\u3053\u3093\u306b\u3061\u306f
ファイルを ASCII 以外のエンコーディングで編集して保存した場合には、native2ascii ツールを使って ASCII コードに変換することができます。たとえば、一般的な日本語コードである Shift_JIS を使ってプロパティファイルを編集する場合には、この操作が必要になります。
ASCII 以外の文字を含む ListResourceBundle をコンパイルする方法を教えてください。
ソースファイルに ASCII 文字以外の文字が含まれている場合は、コンパイラにファイルのエンコーディングを指定する必要があります。たとえば、Shift_JIS で書かれている日本語のリソースバンドルをコンパイルするには、次のようにします。
javac -encoding Shift_JIS LabelsResource_ja.java
|
ロケールに依存する形式で書かれている日付の書式設定と文法解析には、DateFormat クラスを使用します。『Java チュートリアル』の「Dates and Times」の書式設定を参照してください。
通常、java.text.Format のインスタンスとそのサブクラスは同期化されていません。スレッドごとに別個のフォーマットインスタンスを作成することをお勧めします。1 つのフォーマットに複数のスレッドが同時にアクセスする場合は、外部的に同期化する必要があります。
デフォルトのロケールを設定すると、ソー トの結果にどのように影響しますか。
ソートルーチンの構築には、Collator クラスとそのサブクラスが使用されます。これらのクラスはロケールに依存 し、引数なしのコンストラクタで作成された場合には、デフォルトロケールの照合シーケンスを使用します。
Collator オブジェクトは、さまざまなレベルの decomposition および strength プロパティをサポートします。あるロケールで、適切な decomposition と strength を選択する方法を教えてください。
複合語の解析には時間がかかるため、decomposition をオフにすると、比較が高速になります。ただし、ラテン系の言語では、テキストにアクセント記号が含まれている場合には NO_DECOMPOSITION モードは役に立ちません。明確な目的がない限り、デフォルトの decomposition を使用してください。
strength プロパティの選択は、アプリケーションの目的によって異なります。たとえば、テキ スト検索を行うときに、大文字と小文字の区別およびアクセントを無視する、「弱い」マッチングを許可する場合があります。このタイプの検索では、PRIMARY の strength を採用します。単語のリストをソートする場合には、strength にTERTIARY を使うことがあります。このモードでは、ベースの文字、アクセント、大文字と小文字の区別が一致する必要があります。
|
上記の説明を参照してください。
国際化関連の仕様や Java API では、「charset」という語を「文字エンコーディング」 の同義語として使用しています。charset と「文字セット」、「コード化文字セット」はまったく別物ですの で、注意してください。charset の名前の多く (ただし全部ではない) は、IANA に登録されています。
Unicode とほかの文字エンコーディング間でデータを変換する方法を教えてください。
アプリケーションの内部で変換を行う場合は、Java チュートリアルの「Converting Non-Unicode Text」に説明されているように、java.lang パッケージと java.io パッケージの API を使用します。J2SE 1.4 から提供されている java.nio.charset.Charset クラスを使用すると、より直接的に文字変換を行うことができます。java.net パッケージから JSP コンパイラに至るその他の多くの Java インタフェースは、それぞれの機能上の必要性に応じて、こうした低レベルのインタフェースを利用して文字変換を行います。データファイルを変換するには、 native2ascii ツールを使用します。
Unicode との間での変換がサポートされている文字エンコーディングは何ですか。
サポートされるエンコーディングは、Java プラットフォームの実装によって異なります。Sun の JRE でサポートされるエンコーディングについては、J2SE 5.0、J2SE 1.4.2、および J2SE 1.3.1 の「サポートされているロケール」または「サポートするロケール」に記載されています。
ほ かのソフトウェアと通信する場合、どの文字エンコーディングを使ったらよいでしょうか。
通信するソフトウェアの種類や、テキストを記述する言語によって異なります。状況が許すならば、次のような理由で、UTF-8 の利用をお勧めします。
- UTF-8 は、すべての Unicode 文字をエンコードします。したがって、Java の内部表現 (UTF-16) との間で変換処理を行う際、情報が失われることがありません。その他の多くのエンコーディングでは、Unicode 文字セットのサブセットしか表現できません。
- UTF-8 は、標準化のレベルが高いため、現在のアプリケーション以外のほかのプロセスも同じ方法でテキストを解釈できます。一方、Shift_JIS をはじめとするいくつかの文字エンコーディングは、その独自の特色のため、解釈違いが生じることがあります。
- UTF-8 は ASCII 文字エンコーディングの論理的拡張として設計されています。特に、一見 ASCII エンコーディングされた文字のように見えるすべてのバイト値は、実際には同じ文字を表すという特徴があります。この特徴は、多くのネットワークプロトコル やファイルシステムが ASCII に依存している点、また、UTF-8 がこうしたコンテキストで安全に利用できる点を考えると、たいへん有用です。一方、URF-16 エンコーディングされたテキストには、ASCII 制御文字のように見える (でも実際にはそうではない) バイト値が含まれることがあります。よって、UTF-16 は、常に安全に利用できるとは言えません。
- UTF-8 では、ある文字を表すバイトシーケンスの開始位置がわかりやすく、万一エラーが発生しても簡単に再同期できます。ほかのマルチバイト文字エンコーディング では、必ずしもこのようなことができるとは限りません。
- XML ファイルでは、XML プロセッサがサポートしなければならない文字エンコーディングとして、UTF-8 と UTF-16 の 2 つが指定されています。これ以外の文字エンコーディングは、サポートされていないことがあります。
以下に、UTF-8 を使用できないケースを紹介します。
- ホスト OS のデフォルトのエンコーディング (UTF-8 以外) で解釈されるプレーンテキストファイルを作成するとき。
- UTF-8 を正しく処理しない古いブラウザ (Solaris の Netscape 4.7 など) に HTML コンテンツを送信するとき。
- UTF-8 をまったくサポートしないシステム (一部の携帯電話端末など) と通信するとき。
UTF-8 は、Unicode (または UCS) Transformation Format の 8 ビットエンコード形式を表します。Unicode の 8 ビットコード単位の伝送形式です。
デフォルトエンコーディングは、ホストオペレーティングシステムおよびそのロケールに基づく JRE により選択されます。たとえば、Windows の US ロケールでは、windows-1252 が使用されます。Solaris の簡体字中国語ロケールでは、Solaris へのログイン時の選択に基づき、GB2312、GBK、GB18030、UTF-8 のいずれかがデフォルトエンコーディングになります。
デフォルトエンコーディングは、通常、JRE とホストオペレーティングシステム間でやりとりされるテキストに使用される、重要なエンコーディングです。 正確な相互変換を保証するために、デフォルトエンコーディングを、ホストオペレーティングシステムが使用 するエンコーディングに一致させる必要がありま す。
アプリケーションは、J2SE 5 から提供されている Charset.defaultCharset メソッドを呼び出すことにより、デフォルトエンコーディングを特定します。なお、J2SE 5 より古いバージョンの Java プラットフォームでは、次のような式が使用されていました。
(new OutputStreamWriter(new ByteArrayOutputStream())).getEncoding()
なぜ Solaris では一部の欧文文字を使用できないのですか。
文字エンコーディングの中には、一部の欧文文字 (たとえば「ß」や「é」) をサポートしないものが多数存在します。この問題は、Solaris C ロケールのユーザから多く寄せられています。Solaris や Linux では、JRE は、デフォルトエンコーディングを特定する際に nl_langinfo 関数を呼び出します。C ロケールでは、この関数の戻り値は 646 です。これは、デフォルトエンコーディングが US-ASCII であることを示しています。US-ASCII には、ISO-8859-1 の半分の文字数しか含まれません。つまり、よく使用される欧文文字の多くは除外されています。
欧文文字を使用したい場合、簡単な方法としては文字エンコーディングとして ISO-8859-1 を使用する Solaris en_US ロケールを使用します。ログイン画面で Solaris のロケールを設定する方法や、LC_ALL 環境変数を設定する方法があります。このほか、使用するすべてのインタフェースの文字エンコーディングを明示的に指定して、エンコーディング変換を実行さ せる方法もあります。
windows-1252 と ISO-8859-1 は同じものですか。
違います。windows-1252 には、0x80 から 0x9F の範囲の文字が追加されています。詳細は、Microsoft のドキュメントを参照してください。
J2SE 1.4 から提供されている java.nio.charset.spi.CharsetProvider クラスを使用すると、独自の文字変換プログラムを作成できます。
|
Input Method Framework とは何ですか。
Input Method Framework により、すべてのテキスト編集コンポーネントはインプットメソッドを通じて日本語、中国語、韓国語のテキスト入力を受け取ることができます。ユーザはイン プットメソッドにより、ごく少数のキーを使って、キーボードから多くの異なった文字を入力することができます。通常は、複数の文字のシーケンスを入力して から 1 つまたは複数の文字に変換します。仕様と例については、「Input Method Framework」を 参照してください。
ユーザが複数のインプットメソッドを利用できる場合があります。たとえば、複数の異なる言語のための インプットメソッドがある場合や、さまざまなタイプの入力を受け付けるインプットメソッドがある場合などです。この場合、ユーザは特定の言語に使うイン プットメソッドや、もっとも早く入力できるインプットメソッドを選択できます。
プログラムを使って、インプットメソッドを選択してアクティブにすることはできますか。
アプリケーションは、InputContext.selectInputMethod メソッドを使って特定のロケールをサポートする入力メソッドを要求できますが、特定の入力メソッドを選択することはできません。選択を行えるのはユーザだ けです。
アプリケーションは、InputContext.setCompositionEnabled メソッドを使って入力メソッドをアクティブにできます。
AWT コンポーネントと Swing (JFC) テキストコンポーネントでは、インプットメソッドが機能しますか。
『国際化の概要』の「Input Method Framework」を参照してください。
|
アプリケーションでフォ ントを選択する場合、どんな方法がありますか。
軽量コンポーネントを使用するアプリケーションは、次の 4 通りの方法でフォントを選択できます。
- 論理フォント名の使用: Java プラットフォームでは、すべての実装でのサポートが求められる 5 つの論理フォント名 (Serif、SansSerif、Monospaced、Dialog、DialogInput) が定義されています。これらの論理フォント名は、実 装に依存した方法で、物理フォントにマップされます。一般に、1 つの論理フォント名は、広範囲の文字をカバーするために複数の物理フォント名に割り当てられます。
- 物理フォント名の使用: アプリケーションは、Java プラットフォームが提供する API を使用して、指定された実行環境で使用可能なフォント、および該当するフォントで処理可能な文字を判別し、そのフォントを実名 (Times Roman や Helvetica など) を使って要求します。アプリケーションでは、ユーザにフォントの選択を任せることも、使用するフォントをプ ログラムを使って決定することもできます。
- Lucida フォントの使用: Sun の JRE に含まれるこの物理フォントファミリは、Java プラットフォームの他の実装でも使用できるようライセンス付与されています。これらのフォントは物理フォントですが、ホストオペレーティングシステムには 依存しません。
- バンドルされている物理フォントの使用: アプリケーションで TrueType フォントをバンドルし、
Font.createFontメソッドを使ってこれらのフォントのインスタンスを作成できます。
ピア AWT コンポーネントを使用するアプリケーションでは、論理フォント名のみ使用できます。
以下に概要を示します。
- 論理フォント名の使用:
- 利点: これらのフォント名は、どこでも動作することが保証されており、少なくともオペレーティングシステムのローカライズ対象言語でのテキストレンダリングは可 能です (大抵は、より広範な言語でのテキストレンダリングが可能)。
- 欠点: テキストレンダリングに使用される物理フォントは、実装、ホストオペ レーティングシステム、およびロケールが異なると変化します。このため、アプリケーションの外観がどこでも同じになることはありません。ま た、マッピング機構がレンダリング可能な文字の範囲を制限することがあります。後者は、JRE 5.0 より前のバージョンでは大きな問題でした。 たとえば、日本語テキストのレンダリングは日本語化されたホストオペレーティングシステムでのみ可能です。日本語のフォントがインストールされている場合 でも、他国語化されたシステムではレンダリングできません。2D フォントレンダリングを使用するアプリケーションでは、JRE 5.0 ほど問題は起こりません。これは、現在のマッピング機構が、サポート対象のすべての書き込みシステムのフォントを認識し、使用できるからです。なお、この ためには、対象フォントがインストールされている必要があります。
- 物理フォント名の使用:
- 利点: この方法を利用すると、利用可能なフォントすべてをアプリケーションで最大限活用して、テキストの外観を変化させたり、利用可能な言語の範囲を最大限拡大 したりすることができます。
- 欠点: この方法では、プログラミングがかなり難しくなります。
- Lucida フォントの使用:
- 利点: これらのフォントを使用するアプリケーションでは、環境が異なってもフォントが存在すれば、共通の外観を提供できます。また これらのフォントは、言語範囲が広範囲に渡るため (特にヨーロッパおよび中近東の言語)、サポート対象の言語用の多言語対応アプリケーションを作成できます。
- 欠点: 一部の JRE では、これらのフォントを使用できない場合があります。また、現在のところ、Unicode 文字セットの範囲を完全にはカバーしていません。特に、中国語、日本語、韓国語はサポートされていません。
- バンドルされている物理フォントの使用:
- 利点: これらのフォントを使用するアプリケーションでは、環境が異なっても共通の外観を提供できます。また、サポートする言語をアプリケーションで完全に制御で きます。
- 欠点: 中国語、日本語、および韓国語をサポートする場合は特に、バンドルされるフォントのサイズがかなり大きくなります。ライセン スの問題を解決する必要もあります。
中国語、日本 語、または韓国語のフォントがインストールされているのに、アプリケーションでこれらの言語の文字が表示されないのはなぜですか。
アプリケーションからのフォントの選択方法によって異なります。上記を参照してください。
- 論理フォント名の使用: 物理フォントを使用する場合、マッピング機構を使ってフォントを選択する必要があります。ピア AWT コンポーネントを使用するアプリケーションでは、中国語、日本語、韓国語のフォントは、これらの言語に合わせて地域対応化されたホストオペレーティングシ ステム上で実行されている Sun の JRE によって選択されます。マッピングを変更するには、フォント構成または font.properties ファイル (以下を参照) を変更する必要があります。
- 物理フォント名の使用: アプリケーションでフォントが適切に選択されていない、または JRE でサポートしていないエンコーディングがフォントで使用されている場合があります。
- Lucida フォントの使用: Sun の JRE に含まれる Lucida フォントは、中国語、日本語、韓国語をサポートしていません。
- バンドルされている物理フォントの使用: アプリケーションにバンドルされているフォントが、これらの言語をサポートしていない可能性があります。
フォント構成ファ イルと font.properties ファイルについて教えてください。
フォント構成ファイルは、論理フォント名と物理フォントのマッピングに使用されます。Sun の JRE 5.0 より前のバージョンでは、フォント構成ファイルの代わりに font.properties ファイルが使用されていました。ホストオペレーティングシステムのバージョンに応じて、異なるマッピン グをサポートする複数のファイルが存在します。ファ イルの位置は、JRE のインストール先の lib ディレクトリです。
フォント構成ファイルと font.properties ファイルは実装に依存しています。Java プラットフォームの実装すべてでこのファイルが使用されるわけではありません。また、その内容と形式は実行環境およびリリースにより異なります。
論理 フォントのマッピングに物理フォントを追加する方法を教えてください。
論理フォントから物理フォントへのマッピングは実装に 依存しているため、複数の回答が存在します。Sun の JRE 5.0 では、JRE の lib/fonts/fallback ディレクトリにフォントをインストールする方法が一番簡単です。このディレクトリにインストールされたフォントは、すべての論理フォントの 2D レンダリング用フォールバックフォントとして追加されます。AWT では、場合によって、フォント構成ファイルを変更する必要がありま す。 詳細は、「Font Configuration Files」の Web ページを参照してください。Sun の以前のバージョンの JRE では、font.properties ファイルを編集する必要があります。詳細については、J2SE 1.4.2 および J2SE 1.3.1 の「font.properties ファイル」を参照してください。ただし、これらのファイルを編集すると JRE が変更される点、Sun は変更後の JRE をサポートしない点に注意してください。ほかの実装については、該当するドキュメントを参照してください。
Swing コンポーネントでは表示されるある文字が、ピア AWT コンポーネントでは表示されません。なぜですか。
Swing ユーザインタフェースコンポーネントが使用するテキストのレンダリング機構は、ピア AWT コンポーネントが使用するレンダリング機構とは異なります。Swing コンポーネントは、Graphics.drawString メソッドを使用します。このメソッドでは、一般に論理フォント名が指定されます。次に論理フォント名から物理フォントセットへのマッピングが実行されて、 広範囲の文字がカバーされます。一方、ピア AWT コンポーネントは、ホストオペレーティングシステムのコンポーネントを使って実装されます。ホストオ ペレーティングシステムのコンポーネントでは、Unicode がサポートされていないことがよくあります。このため、ホストオペレーティングシステムおよびロケールに基づき、テキストが別の文字エンコーディングに変 換されます。これらのエンコーディングでは、論理フォント名の実装に使用される物理フォントに比べて、カバーする文字範囲が狭くなることがよくあります。 た とえば、日本語 Windows 98 システムでは、アクセント記号付きの欧文文字の多くは Swing コンポーネントで Arial フォントに割り当てられますが、テキストをピア AWT コンポーネント用の Shift_JIS エンコーディングに変換すると、これらの文字は失われてしまいます。
Solaris および Linux の J2SE 5.0 から提供されるようになった XAWT ツールキットのコンポーネントは、Graphics.drawString メソッドを使用します。したがって、これらのテキストレンダリングの動作は、Swing コンポーネントの動作とよく似ています。
Unicode フォントをインストールしましたが、アプリケーションですべての Unicode 文字を表示できません。なぜですか。
上記の「中国語/日本語/韓国語の場合」で説明したように、 原因は、Unicode フォントを使ってテキストが全く、または一部しかレンダリングされないことにあります。アプリケーションが物理フォント名を使っ て Unicode フォントを選択していても、すべての文字をレンダリングできない場合、その Unicode フォントが実はすべての Unicode 文字セットをカバーしていない可能性があります。あるフォントの提供するテーブルが Unicode 文字エンコーディングをサポートしているだけで、そのフォントが Unicode フォントと呼ばれる場合があります。
Sun の JRE がサポートするフォントについて教えてください。
J2SE 5.0 および J2SE 1.4.2 の「サポートされているフォント」を参照してください。
Sun の JRE で複数の言語を表示することはできますか。
簡単に言えば、それは可能です。詳しい説明としては、同時に表示する言語、およびアプリケーションで フォントを選択する方法を調査する必要があります。
- いくつかの言語が、ある小規模の文字セットを共有するのはごく一般的なこと です。たとえば、西ヨー ロッパ言語は、ISO-8859-1 文字セットでの記述が可能です。この種のグループ内だけで言語を表示する場合、そのままの状態で機能するため、特に 操作は必要ありません。
- 表示する言語がすべて Lucida フォントファミリによりサポートされている場合、およびこのフォントファミリを含む JRE 上でのみアプリケーションを実行する場合、このフォントファミリのフォントを使用するだけで十分です。
- 別の文字範囲を使用する言語をサポートする必要がある場合、アプリケーションが論理フォント名を使ってフォントを選択すると、JRE のバージョン間で表示がまちまちになります。
- J2SE 5 で 2D フォントレンダリングを使用する場合、マッピング機構は、サポート対象のすべての書き込みシステムをカバーする複数の物理フォントを使用します。ピア AWT コンポーネントを使用する場合は、すべての言語をサポートするフォント構成ファイルを作成する必要があります。詳細は、Web ページ「font.properties ファイル」を参照してください。
- 以前のバージョンでは、必要な言語をすべてサポートする font.properties ファイルを作成する必要があります。詳細については、J2SE 1.4.2 および J2SE 1.3.1 の「font.properties ファイル」を参照してください。
- 異なる文字範囲をサポートする必要がある場合、およびアプリケーションでのフォントの選択に物 理名を使用する場合、フォントの選択を、フォントがサポートする文字範囲の情報を使って行う必要があります。
Sun の JRE では、タイ語、ラオ語、ビルマ語、またはインド語派の文字体系のテキストレンダリングが可能ですか。
Sun の JRE では、バージョン 1.4 から、南アジアおよび東南アジア言語の文字のうちタイ文字とデヴァーナーガリ文字がサポートされるようになりました。サポート対象のすべての書き込みシス テムの一覧については、J2SE 5.0、J2SE 1.4.2 および J2SE 1.3.1 の「サポートするロケール」または「サポートされているロケール」を参照してください。 その他の書記体系のサポートは、今後のリリースで追加される可能性があります。
|
Sun の JRE では、どのユーザインタフェースを使ってコンポーネントの向きを設定しますか。
コンポーネントの向きのプロパティは、Swing コンポーネントとレイアウトマネージャでのみ考慮されます。ピア AWT コンポーネントでは考慮されません。このプロパティはホストオペレーティングシステムには依存しません。J2SE 5.0 および J2SE 1.4.2 でコンポーネントの向きをサポートするのは、以下のクラスです。
| java.awt.BorderLayout | javax.swing.JFrame | javax.swing.JRadioButtonMenuItem |
J2SE 1.3.1 では、上記の表に含まれるクラスのうち、コンポーネントの向きをサポートしないものがあります。該当するクラスは、 java.awt.GridBagLayout、javax.swing.BoxLayout、javax.swing.JColorChooser、 javax.swing.JComboBox、javax.swing.JFileChooser、javax.swing.JOptionPane です。
|
JSP ベースのアプリケーションを使用しています。応答文字エンコーディングを設定しても変更されてしまうのはなぜですか。
Web アプリケーションで応答文字エンコーディング (コンテンツ形式の charset の値に対応) を設定しても、ブラウザに送信される Web ページのエンコーディングが異なる場合があります。これは、Servlet 2.3 ベースのコンテナと JavaServer Pages Standard Tag Library を同時に使用する場合に起こりうる問題です。以下に、イベントの順序を示します。
- アプリケーションにより、charset 値を含むコンテンツ形式が設定されます。これにより、応答文字エンコーディングが設定されます。
- アプリケーションにより、リソースバンドルにアクセスする JSTL タグが使用されます。
- JSTL により、検出されたリソースバンドルへ送信されるロケールが応答ロケールとして設定されます。
- コンテナにより、応答ロケールに適した応答文字エンコーディングが設定されます。この応答文字エンコーディングは、以前に設定した文字エン コーディングとは異なる可能性があります。
Servlet 2.4 仕様では、明示的な文字エンコーディングの指定と暗黙的な文字エンコーディングの指定が区別されるようになったため、この問題は解決されました。明示的な 文字エンコーディングの指定とは、コンテンツ形式や新しいメソッド ServletResponse.setCharacterEncoding を使った指定のことです。暗黙的な文字エンコーディングの指定とは、ロケール設定から文字エンコーディングが判断されることです。暗黙的な指定が明示的な 指定より優先されることはありません。よって、上記のイベント 4 は発生しません。
アプリケーションに以前の仕様に準拠したコンテナとの互換性を持たせる必要がある場合は、明示的に文字エンコーディングを指定したあと、文字エン コーディングを暗黙的に決定するようなカスタムアクションを実行する前に、ServletResponse.flushBuffer を呼び出して文字エンコーディングを凍結します。
JSP ベースのアプリケーションの国際化について詳しく学べる参考資料を教えてください。
注意するべき事柄の多くは、『Designing Enterprise Applications with the J2EE Platform』の「Internationalization and Localization」の章と、「JavaServer Pages 技術による多言語 Web アプリケーションの開発」という記 事に紹介されています。
0 件のコメント:
コメントを投稿