このページには、International Components for Unicode や国際化の基本事項の内容について、よく出される質問が収録されています。次のセクションから構成されています。
NumberFormat
これらのクラスがどうして必要なのか。
ICU4J の NumberFormat と標準の NumberFormat にはどのような違いがあるか。
ICU4J NumberFormat に、認識済みの制限があるか。
ICU4J NumberFormat を使用する場合にはどのような必要条件があるか。
RuleBasedNumberFormat
どうしてわたしの国の言語に対する規則がないのか。
どうしてわたしの国の言語で負の数 (または分数) が正しく表示されないのか。
わたしの国の言語で 20,000 もの単語のスペルが間違っている。よく知らなかったのだろうか。
日本語を表示しているときに、テキスト領域をスクロールしたり、テキストを編集できないのはなぜか。
ヘブライ語のスペルがすべて逆になっている。どうしてか。
文字の代わりにボックス (または疑問符) が続けて表示されるのはどうしてか。
このプログラムがわたしのブラウザーで正しく動作しないのはどうしてか。
International Calendars
これらのクラスがどうして必要なのか。
日本の暦のうち、サポートされているものはどれか。
本当にイスラム暦をサポートしているのか。
わたしの国の言語に対するリソース・データがないのはどうしてか。
中国の暦をサポートしていないのはどうしてか。
デモ版でヘブライ語とアラビア語のテキストが正しく表示されないのはどうしてか。
StringSearch
このコードではどうして JDK 1.2 が必要なのか。
では、JDK 1.1 の場合はどうなるのか。
StringSearch を使用する場合に Collator について知っておくべきことがあるか。
検索を実行するときに使用するアルゴリズムは何か。
RuleBasedBreakIterator
どうして BreakIterator を作成し直さなかったのか。前のバージョンは動作しなかったのか。
パフォーマンスの改善とはどういう意味か。わたしには、速度が遅くなったように思える。
これには、前の BreakIterator のときとまったく同じバグがある。どうして代わりにこれを使う必要があるのか。
どうしてデモ版がないのか。
この DictionaryBasedBreakIterator とは何か。
どうしてタイ語の辞書があるのに、実際にそれを使えるリソース・データがないのか。
この BreakIteratorRules_en_US_TEST とは何か。
独自の辞書ファイルを作成するにはどうしたらよいか。
1. これらのクラスがどうして必要なのか。
標準 JDK の NumberFormat クラスでも大抵の場合は問題ありませんが、いくつかの制限があります。BigInteger 数や BigDecimal 数をサポートする必要がある場合、解析後の文字列の正確な値を必要とする場合、新しい機能 (浮動小数、埋め込み、丸め) を必要とする場合は、ICU4J の NumberFormat が必要です。
2. ICU4J の NumberFormat と標準の NumberFormat にはどのような違いがあるか。
ICU4J の NumberFormat パッケージには、標準 JDK クラス NumberFormat、DecimalFormat、DecimalFormatSymbols、および内部クラスの修正バージョンが入っています。修正バージョンのクラスは、標準クラスが実行することをすべて行ってから、別のことを行います。
- AlphaWorks の NumberFormat は、double 型値と long 型値だけでなく、BigInteger 型と BigDecimal 型の書式設定と解析も行います。
- JDK 1.2 では long 型がオーバーフローすると double 型になります。たとえば、Long.MAX_VALUE のような値をパーセント書式で設定した場合、値は double 型にキャストされるので、精度は低下します。AlphaWorks の NumberFormat では、BigInteger 型にオーバーフローするので、情報が失われることはありません。
- long 型の書式設定のパフォーマンスが高くなります。
- 解析時には、非整数値を表す Double オブジェクトではなく BigDecimal オブジェクトが戻されます。Double オブジェクトが戻されるのは、BigDecimal に格納できない値を表す場合だけです。つまり、NaN、Infinity、-Infinity、および -0 の場合です。それ以外の値はすべて、Long 型値、BigInteger 型値、または BigDecimal 型値として戻されます。前に特定の型があるかどうかを ("instanceof Double" を使ったり、Double をキャストすることで) 確認したクライアントは、コードを変更して Number.doubleValue() メソッドを使う必要があります。
- 浮動小数をサポートします。
- 丸めをサポートします。
- 指定された幅へのパディングをサポートします。
- JDK 1.2 には各種のバグ・フィックスが組み込まれましたが、JDK 1.1.x ではまだ修正されていません。
3. ICU4J NumberFormatに、認識済みの制限があるか。
- 丸めの増分は 18 桁 (long で完全に表現できる桁数)に制限されています。
- すべてのパディング構成を 1 つのパターンで表すことはできません。言い換えれば、API 呼び出しを行って、パディングのあるパターンをセットアップすることは可能です。
しかし、その書式に対するパターンを作成しても、パディングパラメーターを完全に表していることにはなりません。これは一般に、多くの書式設定クラスの多くの属性にも実際に当てはまります。
- すべての丸め構成を 1 つのパターンで表すことはできません。
4. AlphaWorks NumberFormat を使用する場合にはどのような必要条件があるか。
- ICU4J NumberFormat は JDK 1.1.x または JDK 1.2 で動作します。
1. どうしてわたしの国の言語に対する規則がないのか。
このコードはまだ正式な IBM 製品の一部ではないので、IBM のローカライズ・プロセス全体を適用しているわけではありません。ここに示される規則は、アルゴリズムを作成する際に使用したサンプルを表すことを目的としたものであって、100% 完全なものでも 100% 正確なものでもありません。遅くても、1999 年初めから半ばまでに JDK でサポートされるすべてのロケールに対する完全で正確なデータを用意するつもりです。不足している情報を提供していただければ、幸いです。
2. どうしてわたしの国の言語で負の数 (または分数) が正しく表示されないのか。
前述の質問 1 の答えを参照してください。当プロジェクトの最初の研究では、英語以外の言語での負の数や分数部を持つ数の書式設定に関する情報が不足していました。不足している情報を提供していただければ、うれしく思います。
3. わたしの国の言語で 20,000 もの単語のスペルが間違っている。よく知らなかったのだろうか。
知りませんでした。質問 1 の答えを参照してください。修正していただける場合は、ご連絡ください。
4. 日本語を表示しているときに、テキスト領域をスクロールしたり、テキストを編集できないのはなぜか。
JDK 1.1 におけるテキスト表示機能は完全には完成していないため、Windows の米国英語バージョンでローマ字以外のテキストは正しく表示されません。すべてのシステムでローマ字以外のテキストを表示できるようにいろいろとやってみましたが、できるのはテキストを表示することだけで、スクロールや編集は行えませんでした。JDK 1.2 では、これらの制限は解決されているはずなので、JDK 1.2 の最終版や最終版に近い版が出荷されたら、その機能を利用する最新バージョンのデモ版を発行する予定です。
5. ヘブライ語のスペルがすべて逆になっている。どうしてか。
質問 5 の答えを参照してください。表示問題については、双方向の順序変更を実現できるほど高度な解決策が見つかっていないので、現時点では、どのシステムがこれをネイティブにサポートするかということさえわかっていません。ヘブライ語の Windows バージョンを実行している場合は、固有のテキスト編集機能を使えるようにデモ・プログラムをかなり簡単に変更できます。前にも説明したように、この問題は JDK 1.2 では修正されるはずです。
6. 文字の代わりにボックス (または疑問符) が続けて表示されるのはどうしてか。
ローマ字以外のテキストを表示する場合は、適切なフォントがインストールされている必要があり、そのフォントを認識するように font.properties ファイルを修正しなければなりません。これを実現する一番簡単な方法は、Bitstream Cyberbit フォントをダウンロードしてインストールする方法です。このリンクに従ってフォントのコピーをダウンロードし、font.properties ファイルを修正する説明を参照してください。JDK 1.2 のストック・バージョン (最終バージョンの出荷後) には、大半のローマ字以外のスクリプトを正しく表示できる機能が含まれているはずです。
7. このプログラムがわたしのブラウザーで正しく動作しないのはどうしてか。
このデモ版が正しく実行されるブラウザーを調査中です。このデモ・プログラムは、Symantec と Sun JVM の両方の環境で、JDK 1.1.4 上でテストしました。本ページの執筆時では、Netscape も MSIE も最新バージョンの JDK に更新されていません。Java 開発キットの最新バージョンは Sun から直接入手できます。実際の RuleBasedNumberFormat フレームワークは、JDK 1.1 バージョンで動作するはずです。
1. これらのクラスがどうして必要なのか。
アプリケーションで日付と時刻を表示、操作する場合や、アプリケーションを北米および西欧以外の国で実行したい場合は、世界の一部地域で今なお使われている伝統的な暦をサポートする必要があります。これらのクラスは、標準 Java Calendar API に準拠する一方でこのサポートを提供し、国際的な暦に従ってアプリケーションをコーディングし、動作させることができます。
2. 日本の暦のうち、サポートされているものはどれか。
良い質問です。現時点では、JapaneseCalendar は、年と年代名で伝統的な規約に従っている点を除き、グレゴリオ暦とほとんど同じです。近代では、各天皇の治世を 1 つの時代として扱い、年はその時代の開始から番号が割り振られています。歴史的には、各天皇の治世は複数の時代、すなわち元号に分かれていました。現在、この時代データは、西暦 645 年に始まった大化まで拡張されています。その他のすべての点で (月と日付、すべての時刻フィールドなど)、JapaneseCalendar クラスの結果は GregorianCalendar と同じです。
日本では、中国の暦のような太陰暦が使われていた時代もありましたが、現在は一般に使われていません。日本の太陰暦が実際には必要である場合、特に中国の暦とどのように異なるのか参考までにご存じの場合は、お知らせください。
3.本当にイスラム暦をサポートしているのか。
イスラム暦は厳密に太陰暦であり、日没時に新月の三日月が水平線の上に現れたときに、月が始まります。月が見えるかどうかは、観測者の場所や天候、観測者の視力などによって異なるので、この暦を 100% の精度で事前に計算することは不可能です。ただし、かなり一般的に受け入れられている基準はあるので (太陽と月の角度、月と水平線の角度、月の弓の部分の位置など)、それを使えば、天候の要因を除き、非常に高い精度で所定の月の始まりを予測することができます。現時点では、かなり大ざっぱな概算を使用していますが、それでも比較的正確であり、前回の 40 年代の奇数年における 1 つの月を除くすべての月で、正式なサウジ暦に対応しています。これは、クラスの今後のバージョンで改善される予定です。
つまり簡単に言えば、IslamicCalendar クラスは、イスラム暦を予測する上でかなり正確であり、計算を目的とする場合は、ほとんどの場合、十分に対応できます。ただし、宗教上の目的の場合は、もちろん、モスクなどの当局に問い合わせることが必要です。
4. わたしの国の言語に対するリソース・データがないのはどうしてか。
ある程度までどうにか収集してきた文字列リソース・データはすべて取り込みました。現在提供している言語は、アラビア語、オランダ語、英語、フィンランド語、フランス語、ヘブライ語、ハンガリー語、日本語、およびタイ語です。ただし、それぞれの言語ですべての暦がサポートされているわけではありません。他の言語の文字列翻訳に興味がある場合は、lwerner@us.ibm.com まで E メールをお寄せください。このデータの収集に使った調査資料をお送りいたします。
5. 中国の暦をサポートしていないのはどうしてか。
答えは「非常に複雑だから」です。中国の太陰暦は、至点、新月、太陽の経度の計算に基づいた複雑な規則に準拠しているので、イスラム暦やユダヤ暦よりも実装はかなり難しくなります。ただし、ChineseCalendar クラスの作成作業を始めており、作成でき次第、International Calendars パッケージに追加する予定です。
6. デモ版でヘブライ語とアラビア語のテキストが正しく表示されないのはどうしてか。
おそらく JDK 1.2 ではなく JDK 1.1 でデモ版を実行しているためです。現在のほとんどのブラウザー (1999 年初めの時点) は、JDK 1.2 をサポートしていません。デモ版を正しく表示させるには、JDK 1.2 をまだインストールしていない場合はマシンにインストールし、このパッケージをダウンロードして、JDK 1.2 でデモ版を実行してください。詳細については、次を参照してください。
アラビア語とヘブライ語は両方とも右から左に読む言語です。テキストの各行は、ページの右から左に向かって読みます。右から左に読むテキストを英語などの左から右に読む言語で使うと (たとえば、アラビア語の月名の後に 10 進数の年を挿入するなど)、コンテキストに基づいて文字の順序を変更する複雑な規則を持つ、双方向 (略してbidi) テキストとなってしまいます。JDK 1.2 およびそれ以降では、IBM での作業のおかげで、双方向テキストを正しくサポートしています。ただし、JDK 1.1.x は bidi テキストそのものをサポートしておらず、ベースとなる OS に単にテキスト文字列を渡すだけです。bidi をサポートしている OS 環境の場合は (アラビア語バージョンの Windows など)、テキストは問題なく表示されますが、それ以外の環境では、おそらく表示の順序は逆になります。
さらに、アラビア語テキストでは連字が多用されています。ほとんどの文字は、コンテキストによって異なる各種の形式で表示することができ、連字を使って隣の文字と結合されます。JDK 1.2 は、これを直接サポートしていますが、初期バージョンのサポートは完全なものではなく、ベースとなるプラットフォーム OS によって異なります。
1. このコードではどうして JDK 1.2 が必要なのか。
StringSearch は Boyer-Moore 検索アルゴリズムを使用しています。このアルゴリズムでは、テキストの後方検索と前方検索の両方を繰り返し行える機能が必要です。
この機能は JDK 1.1 には用意されておらず、StringSearch は、JDK 1.2 で CollationElementIterator に追加されたいくつかの新しい API メソッドに依存しています。
2. では、JDK 1.1 の場合はどうなるのか。
もちろん、JDK 1.1 の API を使って文字列を検索することは可能です。残念ながら、この簡単なアプローチは、1.2 では不必要な文字列の大量コピーが発生するため、処理速度が非常に遅くなり、アルゴリズムを高速化するには、検索テキストでバックアップを実行できる非常に巧妙なバッファー・スキームが必要です。時間が許す場合は、これを実装して AlphaWorks にポストすることもできますが、今のところはっきりとした計画はありません。
3. StringSearch を使用する場合に Collator について知っておくべきことがあるか。
StringSearch は RuleBasedCollator を使って検索の言語に依存する面を処理するので、照合のしくみを理解しておくと便利です。しかし、Collator API の中で、本当に知っておく必要があるのは、検索時に大文字/小文字やアクセントを無視するかどうかを指定する、照合強度値の PRIMARY、SECONDARY、TERTIARY だけです。
4. 検索を実行するときに使用するアルゴリズムは何か。
StringSearch は、Unicode に対応するように修正された、Boyer-Moore 検索アルゴリズムのバージョンを使用しています。比較やシフト・テーブルで Unicode 文字値をそのまま使うのではなく、このアルゴリズムは、範囲が小さくなるように「ハッシュ」された照合要素を使って、テーブルを適切なサイズに縮小します。このアルゴリズムを詳しく説明した記事は、1999 年 2 月発行のJava Report に掲載される予定です。
1. どうして BreakIterator を作成し直さなかったのか。古いバージョンは動作しなかったのか。
動作しましたが、設計上の制約が多すぎました。break-data テーブルはハード・コーディングされており、テーブル・セットは 1 つしかありませんでした。つまり、BreakIterator の振る舞いをカスタマイズしたり、相互に排他的な分割規則を持つ言語に対応することができませんでした (たとえば、日本語と中国語とでは、単語の分割規則が異なります)。また、ハード・コーディングされたテーブルは非常に複雑で、維持するのが難しく、簡単に壊れてしまうので、不思議なバグが発生することもありました。
オリジナルのバージョンには、BreakIterator をサブクラス化して実装する方法がなかったので、異なる振る舞いが必要な場合は、最初から全体を作成し直さなければなりませんでした。このプロジェクトに着手したのは、こうした問題をすべて修正し、今後の開発でプラットフォーム環境を改善するためです。さらに、新しいバージョンからは、パフォーマンスが著しく向上するようにしました。
2. パフォーマンスの改善とはどういう意味か。わたしには、速度が遅くなったように思える。
著しく遅いものの 1 つが構築です。この原因は、テキスト記述を解析することで実行時にテーブルを構築することにあります。前のバージョンでは、テーブルはハード・コーディングされていたため、初期設定の必要はありませんでした。これが原因でトラブルが発生する場合は、BreakIterators の作成と破棄の回数が多すぎることが考えられます。たとえば、テキスト・エディターでドキュメントをワード・ラップするコードを作成し、処理する行ごとに新しい BreakIterator の作成と破棄を繰り返すと、パフォーマンスは驚くほど低下します。
作成を内側のループの外に移動し、新しい BreakIterator の作成をワード・ラップ操作またはドキュメントあたり 1 回だけにすれば、パフォーマンスは劇的に向上するでしょう。これでもまだ問題が残る場合は、修正しなければならないバグがあることが考えられます。
3. これには、前の BreakIterator のときとまったく同じバグがある。どうして代わりにこれを使う必要があるのか。
なぜなら、修正できるからです。このパッケージ内のリソース・データは、オリジナルの BreakIterator クラスの振る舞いにできる限り近づくように模倣して作られました (JDK 1.2 現在)。新しいイテレーターが以前のテストに全て合格することを確認するにあたり変更を最小にするために意図的にそのようにしたわけです。どのバージョンにどのフィックスが含まれているかを追跡することは大変なので、それ以降、更新していません。これが将来の JDK バージョンに追加されることを期待します。そのときには、間違った場所での分割に関連する主なバグはすべて修正されるでしょう。その間に、リソース・データをカスタマイズして、希望どおりに動作するように修正することができます。
4. どうしてデモ版がないのか。
この機能のデモ版を作成する時間がありませんでした。今後、追加する予定です。
5. この DictionaryBasedBreakIterator とは何か。
これは、JDK にはない新しい機能です。DictionaryBasedBreakIterator は、単語と単語の間にスペースが入らない言語 (タイ語など) や、単語と単語の間にスペースは入るが、複数の単語を組み合わせて長い複合単語にできる言語 (ドイツ語など) で使うことを目的としています。テキスト内で、単語の終わりを示す文字のシーケンスを探すのではなく、テキストを認識済みの単語のリストと比較し、このイテレーターを使って境界が入る場所を判別します。ここで使うアルゴリズムは、高速で、正確であり、かつエラー・トレラントです。
6. どうしてタイ語の辞書があるのに、実際にそれを使えるリソース・データがないのか。
必要な研究がまだ完全には終わっていません。現時点では、タイ語で正常に動作することを証明するために使用できる適切なテスト・ケースがなく、この辞書にあまり自信がありません。これについてご存じの場合は、お知らせ頂きたいと思います。
7. この BreakIteratorRules_en_US_TEST とは何か。
これは、"english.dict" 辞書と共に、辞書ベースの分割イテレーターをテストする場合に使ったリソース・ファイルです。スペースが取り除かれた英語のテキストで、単語の境界を探します (SimpleBITest プログラムがこれをデモンストレーションします)。しかし、この辞書に業界で通用する力はありません。適切なテストに役立つ程度の単語は含めましたが、決して完全ではなく、辞書にはほど遠いものです。
8. 独自の辞書ファイルを作成するにはどうしたらよいか。
今のところは、独自の辞書ファイルを作成することはできません。まったくの未完成で、速度も非常に遅いため、辞書ファイルを作成する際に使ったツールは含めませんでした。また、辞書ファイルの書式が将来的に変更させる可能性もかなりあります。どうしても独自の辞書ファイルを作成したい場合は、ご連絡ください。ご協力いたします。
| 
