JPH11512543A - ユニコード・コンバータ - Google Patents

Abstract

(57)【要約】 ユニコード・コンバータが開示されている。さらに具体的には、ラウンドトリップ忠実度を備えると共に、その結果の文字コードが他のプラットフォームと互換性をもつことを保証し、文字をソース文字コード化からターゲット文字コードに変換するとき方向および／またはコンテキストを考慮に入れ、変換のために受信したソース文字列が、そのソース文字列が変換対象のソース文字列を格納している入力バッファの長さを越えたときでも別のターゲット文字コード化に正確に変換されることを保証するコード変換および／または切り捨て処理手法が開示されている。このコード変換システムは単一のソース文字列または文字の列を単一のターゲット文字列またはターゲット文字のシーケンスにマッピング（対応づけること）する機能を備えている。ラウンドトリップ忠実度により、ソース・テキストはターゲット・テキストに変換し、再びオリジナル・ソース・テキストに戻るように変換できるので、標準ターゲット文字の使用を最大限にし、プライベート文字の使用を最小限にすることによって互換性を保証している。コード変換は他の文字セットからユニコード文字に変換したり、ユニコード文字から他の文字セットに変換したりするとき利用すると、特に便利である。変換される文字の方向（向き）を判断することにより、および／または文字のコンテキストを判断することにより、コード変換システムは判断または解決された文字の方向を利用してターゲット文字コード化への正しいマッピングが得られることを保証する。切り捨て処理手法は入力バッファに置かれているソース文字列の一部を切り捨てて、切り捨てられた部分が、ソース文字列の中の後続文字に影響されることなくターゲット文字コード化に変換されることを可能にするように作用する。

Description

【発明の詳細な説明】 ユニコード・コンバータ 説明 技術分野 本発明は記述または表示されるテキストの文字コード間で変換を行うシステム に関し、さらに具体的には、ある文字セットと別の文字セット間で変換を行うコ ード・コンバータに関する。背景技術 コンピュータや他のエレクトロニック・デバイスはテキストを使用してユーザ と対話するのが一般的である。テキストはモニタや他のタイプの表示デバイスか ら表示されるのが普通である。テキストはコンピュータや他のエレクトロニック ・デバイスの内部ではディジタル形式で表現しなければならないので、文字セッ ト・コード化を使用しなければならない。一般的には、文字セット・コード化は 文字セットの各文字を固有のディジタル表現でコード化するように働く。文字（ コード化される）は文字、数字および種々のテキスト・シンボルに対応し、コン ピュータや他のエレクトロニック・デバイスで使用される数値コードが割り当て られている。コンピュータや他のエレクトロニック・デバイスで使用されている 最もよく知られた文字セットは情報交換用米国標準コード(American National S tandard Code for Information Exchange - ＡＳＣＩＩ）である。ＡＳＣＩＩは そのコード化のために７ビット・シーケンスを使用している。他の国では、異な る文字セットが使用されている。ヨーロッパでは、支配的な文字コード化標準は 国際標準化機構(International Standards Organization - ＩＳＯ）によって開 発されたＩＳＯ ８８５９−Ｘ、特にＩＳＯ ８８５９−１（「Ｌａｔｉｎ−１ 」と呼ばれている）である。日本では、支配的な文字コード化標準はＪＩＳ Ｘ ０２０８であり、ここでＪＩＳとは日本情報標準(Japanese Information Standa rd）のことであり、日本標準協会（Japan Standards Association - ＪＳＡ）によって開発されたものである。その他の既存文字セッ トの例としては、Ｍａｃ（登録商標）ＯＳ Ｓｔａｎｄａｒｄ Ｒｏｍａｎコー ド化（Apple Computer，Inc 開発）、Ｓｈｉｆｔ−ＪＩＳ（日本）、Ｂｉｇ５（ 台湾）、その他多くがある。 ビジネスとネットワークのグローバル化に伴い、コンピュータや他のエレクト ロニック・デバイスが複数の文字コード化を処理する能力をもつことが重要にな っている。例えば、同じコンピュータやエレクトロニック・デバイスは、コンピ ュータや他のエレクトロニック・デバイスと異なる言語で対話することを望んで いる異なる国籍の人達で使用されることがある。このような各言語では、異なる 文字セット・コード化が必要になるのが通常である。しかし、文字セットは同じ 言語の場合でも、異なることがある。 もう１つの要求は、ある文字セット・コードから別の文字セット・コード化へ の変換ができることである。例えば、ＩＳＯ ８８５９−１を使用するフランス のユーザは、電子メール・メッセージをＩＳＯ ８８５９−８を使用するイスラ エルのユーザにフランス語で送りたい場合がある。送信者と受信者は異なる文字 セット・コード化を使用しているので、メッセージの中の非ＡＳＣＩＩ文字は、 イスラエルのユーザには誤って伝えられることになる。理想的なことは、コンピ ュータまたはエレクトロニック・デバイスの１つがある文字セットから別の文字 セットに変換することである。このことは、限られた範囲でいくつかの文字セッ ト間ですでに達成されているが、最新のコンピュータやエレクトロニック・デバ イスでもほとんど不可能である。コード変換を困難にしているのは、異なる文字 標準が多数存在し、各国の標準が矛盾し、または不統一であることがよくあるた めである。 Ｕｎｉｃｏｄｅ（登録商標）標準（以下では、単にユニコードまたはユニコー ド標準という）は国際的文字コード化標準となるために開発されたものである。 ユニコード標準の設計者はより効率的で、柔軟性のある文字識別方法を必要とし て、提供したものである。ユニコード標準には、１９９０年１２月３１以前に承 認され、公表されたすべての主要国際標準のすべての文字が含まれている他に、 以前の標準になかった他の文字も含まれている。これらの文字は重複することな くユニコード標準にコード化されている。ユニコード標準に含まれるコードは１ ６ビット（または２バイト）幅である。 ユニコード標準などの文字セット標準はコード変換を容易にし、テキスト・デ ータに働きかける有用なプロセスのインプリメンテーションを可能にしている。 例えば、上記の例によれば、フランス国内のコンピュータや他のエレクトロニッ ク・デバイスはユニコード文字を送信することができ、イスラエル国内のコンピ ュータや他のエレクトロニック・デバイスは受信したユニコード文字を、イスラ エル国内のコンピュータや他のエレクトロニック・デバイスと互換性のあるヘブ ライ語の文字に変換することができる。 以下では、ユニコード標準の概要について説明する。なお、ユニコード標準の 詳細は、例えば、「The Unicode Standard，Worldwide Character Encoding，Ve rsion 1.0，Addision-Wesley 1991 」に記載されている（バージョン１．１にも 詳細が記載されている）。これらのどちらのバージョンも、その全体は引用によ り本明細書の一部を構成するものである。 ユニコード・コード化方式の設計は方向性を除き、基本的テキスト処理アルゴ リズムの設計から独立している。ユニコード・インプリメンテーションは適当な テキスト処理および／またはレンダリング・アルゴリズムを含んでいるものと想 定されている。便宜上、ユニコード標準のすべてのコードは言語および機能のカ テゴリ別に分類されているが、ユニコード標準のすべてのコードは等しくアクセ ス可能になっている。「ユニコード標準のコード・スペースは６つのゾーンに分 割されている。すなわち、一般的スクリプト（アルファベットおよび相対的に小 さな文字セットをもつ他のスクリプト）、シンボル（記号）、ＣＪＫ（中国語、 日本語および朝鮮語）補足文字、ＣＪＫ表意文字、プライベート使用および互換 性である。一般的スクリプト・ゾーンはラテン、キリル、ギリシア、ヘブライ、 アラビア、デーヴァナーガリーおよびタイなどのアルファベットまたは音節スク リプトを含んでいる。シンボル・ゾーンは句読点、数学、化学、読者の注意をひ く記号などの、様々な種類の文字を含んでいる。ＣＪＫ補足ゾーンは句読点、シ ンボル、カナ文字、Ｂｏｐｏｍｏｆｏ文字、および単一および複合ハングル文字 を含んでいる。ＣＪＫ表意文字ゾーンには、２０，０００個以上の表意文字また は他のスクリプトからの文字のためのスペースが用意されている。プライベート 使用ゾーンはユーザまたはベンダ固有のグラフィック文字を定義するために使用 される。互換性ゾーンはユニコード・コード化で他の規範的表現をもつ、幅広く 使用されている企業および国内標準からの文字を含んでいる。」（上記標準バー ジョン１．０の１３ベージから引用）。 ユニコード標準は文字特性と制御文字を含んでいる。文字特性はユニコード・ コード化に含まれるコード・ポイントに関する意味論的知識を必要とする解析、 ソート、および他のアルゴリズムで利用すると便利である。ユニコード標準で指 定されている文字特性には、ディジット、数字、スペース文字、非スペース・マ ーク、および方向がある。ユニコード文字は文字特性に基づいてグループ化され ている。ディジット、数字およびスペース文字は周知である。非スペース・マー ク・グループは非スペース・マークを収容し、方向グループは方向文字を収容し ている。 非スペース・マーク（例えば、ギリシアとローマ・スクリプトにおけるアクセ ント・マーク、アラビアとデーヴァナーガリーにおける母音マーク）は最終的に レンダリングされたテキストには線形的に現れない。ユニコード文字コード・シ ーケンスでは、このような文字はすべて、その文字で修正されたベース文字、ま たはその後に音声順に分節される文字のあとに置かれている（例えば、ローマ文 字の“Ａ”は事前構成形式でストアされないとき“Ａ′”としてストアされる） 。これらの文字（つまり、非スペース・マーク）はレンダリングされるとき、そ の前に置かれたベース文字に対してなんらかの方法で位置付けられることを目的 とし、これらの文字自体はスペース位置を占めない。制御文字はユニコード標準 でコード化されているが、制御文字自体はグラフィック文字ではない。これらの 制御文字は、例えば、水平タブを示したり、フォーマッティング属性または構造 などのテキストに関する追加情報を提供したり、方向性フォーマッティングによ って制御したりするために使用される。ユニコード標準は双方向文字配列も用意 しているので、ユニコード・コード化方式には、方向の変更を指定する文字も含 まれている。例えば、ギリシア語、ローマ語およびタイ語では、左から右への方 向が支配的になっているのに対し、アラビア語とヘブライ語では、右から 左への方向が支配的になっている。制御文字を使用して方向を変更することは、 例えば、左から右への文字を右から左への順序で表示したいときに、ユーザまた はシステムによって要求されることがある。 従来のコード・コンバータには、１つの問題がある。それは、コンバータが１ つのソース文字しか１つのターゲット文字に変換できないことである。この種の 変換はある種の文字セットでは有効に働くが、多数の非スペース文字セットを含 むある種の文字セット（例えば、ユニコード）の場合や、通常他の文字と関連づ けられていないマークを結合するときに十分ではない。また、従来のコード・コ ンバータは複数の文字に関連するシンボル、合字(ligature)または表意文字との 間で変換できる機能を備えていない。 その結果として、従来のコード・コンバータにはラウンドトリップ忠実度(rou nd trip fidelity)がない。ラウンドトリップ忠実度とは、コード・コンバータ が変換し、そのあと変換を戻してオリジナルの入力文字列を再現できる能力のこ とである。これが重要になるのは、コード・コンバータをある文字コードから別 の文字コードに変換するときのハブとして使用するときである。 従って、複数のソース文字から単一ターゲット文字へ、あるいは単一ソース文 字から複数のターゲット文字へ変換して、ラウンドトリップ文字コード変換の忠 実度を保証するようなコード・コンバータが望まれている。 従来のコード・コンバータには、もう１つ問題がある。それは、ソース文字セ ットの文字をターゲット文字セットの文字に変換するとき方向を考慮に入れない ことである。方向を考慮に入れないと、ある文字は左から右へ配列されるのに対 し、他の文字は右から左へ配列されるので変換にエラーを生じることになる。こ れが起こる代表例として、ある与えられたソース・コード化に対して２つの等価 文字をもつターゲット文字に変換し、違いが方向だけのときである。このような 場合には、正しいターゲット文字をマッピングするために、ソース文字の方向が 分かっていなければならない。また、従来のコード・コンバータが不十分である のは、左から右へ配列されている（方向性）言語だけでなく、右から左へ配列さ れている言語にも対応する文字を含んでいるある種の文字セット（例えば、ユニ コード）を取り扱えるだけの柔軟性がないためである。例えば、文字の配列ま たは方向性がユニコード文字列内で変化するようなユニコード文字は、従来のコ ード・コンバータが文字列全体の方向が一定であることを前提としているので従 来のコード・コンバータでは正しく変換されないことになる。 従って、文字の方向を考慮に入れながら、ソース文字セットの文字をターゲッ ト文字セットの文字に変換することができるようなコード・コンバータが望まれ ている。 ある種の従来のコード・コンバータには、以下のようなとき起こる別の問題が ある。ネットワークからテキストを受信するとき、そのテキストに関連するデー タはデータ・ブロックで到着するのが代表的である。データが完全な形で受信さ れるのは、データを構成するすべてのブロックが受信されたあとだけである。受 信データはバッファに置かれ、そこでデータは文字コードの変換を待っている。 しかし、バッファは、多くの場合、データ・ストリーム全体を格納する能力もな ければ、その１ブロックさえも格納する能力をもっていないこともある。いずれ の場合も、スキャナ４０８によって後でテキスト要素と判断されるはずのものの 途中でバッファの終わり（つまり、バッファ内の最後の文字）が現れることがあ る。テキスト要素の途中でバッファの終わりが現れると、スキャナ４０８は、後 続文字が最後のテキスト要素に影響したり、その一部であることがあるので最後 のテキスト要素を正しく得ることができなくなる。 大部分のコード・コンバータには、別の問題がある。それは、あるソース文字 セットの文字をあるターゲット文字セットの文字に変換するときコンテキストを 考慮に入れないことである。ある種の文字セット（例えば、ユニコード）では、 文字セットにはコンテキスト表現形式が異なるごとに別々の文字コードが含まれ ているの対し、別の時では、単一文字コードだけが用意され、コンテキストは表 現形式を判断するために使用されている。しかし、従来のコード・コンバータは コードをそのコンテキストに従って変換することができない。コンテキスト・ベ ースのコード変換が特に問題となるのは、変換の対象となる文字セット（例えば 、ユニコード）が文字コンテキストを受け入れるために、いくつかの手法を組み 合わせて利用するときである。 従って、文字のコンテキストを考慮に入れながら、ソース文字セットの文字を ターゲット文字セットの文字に正確かつ柔軟に変換できるようなコード・コンバ ータが望まれている。発明の概要 概要を説明すると、本発明はコード変換および／または切り捨て処理手法に関 するものである。 本発明の第１側面では、コード変換手法によれば、ラウンドトリップ忠実度が 得られると共に、その結果の文字コードが他のプラットフォームと互換性をもつ ことが保証される。コード変換システムは単一ソース文字または文字シーケンス を単一ターゲット文字またはターゲット文字シーケンスのどちらかにマッピング する能力をもっている。ラウンドトリップ忠実度によれば、ソース・テキストは ターゲット・テキストに変換し、その後オリジナル・ソース・テキストに再び戻 るように変換することが可能である。互換性は標準ターゲット文字の使用を最大 限にし、プライベート文字の使用を最小限にすることにより保証される。コード 変換は他の文字セットからユニコード文字へ、ユニコード文字から他の文字セッ トへ変換するとき利用すると、特に便利である。ユニコード文字シーケンスをタ ーゲット文字セット内の単一文字にマッピングすることは、従来は提供されてい なかった。本発明は、オペレーションだけでなく、データ保管においても大幅な 柔軟性が得られる強力な解決法を提供している。本発明は様々な態様で実現する ことができる。つまり、方法、装置またはシステムとして実現することもコンピ ュータ可読メディア上に実現することも可能である。 ソース文字列をターゲット文字列に変換する方法としては、本発明の第１側面 による本発明の実施例は、第１文字コード化をもつソース文字列を受信し、ソー ス文字列をテキスト要素に順次に分割し（各テキスト要素はソース文字列の１つ または複数の文字を含んでいる）、テキスト要素の各々ごとに第２文字コード化 に関連する変換コードをマッピング・テーブルで調べ（ルックアップ）、テキス ト要素の変換コードを結合して第２文字コード化のターゲット文字列を形成する オペレーションを実行する。 さらに、本発明の第１側面によれば、マッピング・テーブルにはレギュラ・ マッピングとフォールバック・マッピングを含めることが可能であり、ルックア ップ・オペレーションは、レギュラ・マッピングを使用するテキスト要素の変換 コードがマッピング・テーブルにないとき、フォールバック・マッピングを使用 するテキスト要素の各々の変換コードを判断することが可能である。また、好ま しいことは、文字の各々にそれぞれに関連する文字クラスをもたせ、少なくとも その一部がソース文字列内の文字の文字クラスに基づいてソース文字列の分割が 行われるようにすることである。 ソース文字列をターゲット文字列に変換するコード変換システムとしては、本 発明の第１側面による本発明の実施例は、第１文字コード化をもつソース文字列 を第２文字コード化をもつターゲット文字列に変換することを制御するコンバー タ、ソース文字列をテキスト要素（各テキスト要素はソース文字列の１つまたは 複数の文字を含んでいる）に分割するスキャナ、ソース・コード化のテキスト要 素に対するターゲット・コード化をストアしておくマッピング・テーブルおよび テキスト要素の各々ごとに第２文字コード化に関連する変換コードをマッピング ・テーブルで調べる（ルックアップ）ルックアップ・テーブルとを含んでいる。 本発明の第１側面によるコード変換システムには、さらに、フォールバック・ ハンドラとスキャナ・テーブルを含めることが可能である。フォールバック・ハ ンドラは、ルックアップ・ハンドラが１つまたは複数のテキスト要素の変換コー ドを提供することができないような、特殊な場合にフォールバック変換コードを 提供する。フォールバック変換コードはテキスト要素内の文字と正確には等価で はないが、類似したグラフィック外観をもつターゲット・コード化内の１つまた は複数のコード・ポイントを含んでいる。スキャナ・テーブルは、入力文字列内 の個別文字を現在のテキスト要素内に含めるべきか、それとも新しい次のテキス ト要素を開始すべきかをスキャナが判断するのを支援するものである。 入力文字列をスキャンするスキャニング・システムとしては、本発明の第１側 面による本発明の実施例は、入力文字を入力文字列から取得する入力デバイス（ 入力文字列は文字コード化をもち、入力文字列の各文字は文字クラスをもってい る）、入力文字の属性を提供する属性テーブルおよびステート・マシンの次の 状態と次のアクションの両方を、入力文字の次の状態とステート・マシンの現在 状態に従って判断するステート・マシンを含んでいる。スキャニング・システム は入力文字列の入力文字を現在のテキスト要素内に含めるべきか、現在のテキス ト要素を終わらせて次のテキスト要素を開始させるかを、ステート・マシンが判 断したアクションに基づいて判断する。好ましくは、属性には、入力文字の文字 クラスが含まれおり、ステート・マシンは入力文字の文字クラスとステート・マ シンの現在状態に基づいて次の状態と次のアクションを判断する。 ソース文字列をターゲット文字列に変換するためのプログラム命令を収めてお くコンピュータ可読メディアとしては、本発明の第１側面による本発明の実施例 は、第１文字コード化をもつソース文字列を受信することをコンピュータに実行 させるように構成されたコンピュータ可読コード、ソース文字列をテキスト要素 （各テキスト要素はソース文字列の１つまたは複数の文字を含んでいる）に分割 することをコンピュータに実行させるように構成されたコンピュータ可読コード 、テキスト要素の各々ごとに第２文字コード化に関連する変換コードを調べる（ ルックアップ）ことをコンピュータに実行させるように構成されたコンピュータ 可読コード、およびテキスト要素の変換コードを結合して第２文字コード化のタ ーゲット文字列を形成することをコンピュータに実行させるように構成されたコ ンピュータ可読コードを含んでいる。 本発明の第２側面では、コード変換システムはソース文字コード化からの文字 をターゲット文字コード化に変換するとき方向を考慮に入れる。 本発明の第２側面によるコード変換システムは単一ソース文字または文字シー ケンスを単一ターゲット文字またはターゲット文字シーケンスのどちらかにマッ ピングする能力を備えている。変換される文字の方向を判断または解明すること により、コード変換システムは判断または解明された文字の方向を利用して、タ ーゲット文字・コード化への正しいマッピングが利用されることを保証する。従 って、本発明によれば、ソース文字列内の文字の方向性が変化したときでも正し いコード変換が達成される。本発明は様々な態様で実現することが可能である。 方法、装置またはシステムとして実現することも、コンピュータ可読メディア上 に実現することも可能である。 ソース文字列をターゲット文字列に変換するコード変換システムとしては、本 発明の第２側面による本発明の実施例は、ソース文字コード化をもつ入力文字列 をターゲット文字コード化をもつターゲット文字列（入力文字列は複数の文字を 含んでいる）に変換することを制御するコンバータ、入力文字列内の文字を判断 するスキャナ、ソース・コード化の文字に対するターゲット・コード化をストア しておくマッピング・テーブル、および入力文字列内の文字の各々ごとにターゲ ット文字コード化に関連する変換コードを、入力文字列内の文字の方向とソース ・コード化に基づいてマッピング・テーブルで調べるルックアップ・ハンドラを 含んでいる。好ましくは、スキャナはさらに入力文字列をテキスト要素（各テキ スト要素は入力文字列の１つまたは複数の文字を含んでいる）に分割し、スキャ ナはテキスト要素の方向を判断し、マッピング・テーブルはソース・コード化に 対するターゲット・コード化をストアしており、ルックアップ・ハンドラはテキ スト要素の各々ごとにターゲット文字コード化を、テキスト要素内の文字の方向 とソース・コード化に基づいて調べる。この実施例には、前記ルックアップ・ハ ンドラが１つまたは複数の変換コードを提供できないような、特定な場合にはフ ォールバック変換コードを提供するフォールバック・ハンドラを含めることも可 能である。 ソース文字列をターゲット文字列に変換する方法としては、本発明の第２側面 による本発明の実施例は、第１文字コード化をもつソース文字列を受信し（ソー ス文字列は複数のソース文字を含んでいる）、ソース文字列のソース文字の方向 を判断し、ソース文字の各々ごとに第２文字コード化に関連する変換コードを、 第１文字コード化と判断された方向に基づいてマッピング・テーブルで調べ、ソ ース文字の変換コードを結合して第２文字コード化のターゲット文字列を形成す るオペレーションを実行する。 ソース文字列をターゲット文字列に変換するためのプログラム命令を収めてお くコンピュータ可読メディアとしては、本発明の第２側面による本発明の実施例 は、第１文字コード化をもつソース文字列を受信することをコンピュータに実行 させるように構成されたコンピュータ可読コード、ソース文字列内のソース文字 の各々の方向を判断し、ソース文字列をテキスト要素（各テキスト要素はソース 文字列の１つまたは複数の文字を含んでいる）に分割することをコンピュータに 実行させるように構成されたコンピュータ可読コード、テキスト要素の各々ごと に第２文字コード化に関連する変換コードを調べることをコンピュータに実行さ せるように構成されたコンピュータ可読コード、およびテキスト要素の変換コー ドを結合して第２文字コード化のターゲット文字列を形成することをコンピュー タに実行させるように構成されたコンピュータ可読コードを含んでいる。 本発明の第３側面では、コード変換システムはソース文字コード化からの文字 をターゲット文字コード化に変換するときコンテキストを考慮に入れる。 本発明の第３側面によるコード変換システムは単一ターゲット文字またはター ゲット文字シーケンスを単一ターゲット文字またはターゲット文字シーケンスの どちらかに変換する能力を備えている。変換される文字のコンテキストを判断す ることにより、コード変換システムは判断された文字のコンテキストを利用して ターゲット文字コード化への正しいマッピングが利用されることを保証する。従 って、本発明によれば、文字のコンテキストが異なるターゲット・コード化に導 くときでも正しいコード変換が達成される。本発明は様々な態様で実現すること が可能である。方法、装置またはシステムとして実現することも、コンピュータ 可読メディア上に実現することも可能である。 ソース文字列をターゲット文字列に変換するコード変換システムとしては、本 発明の第３側面による本発明の実施例は、ソース文字コード化をもつ入力文字列 （入力文字列は複数の文字を含んでいる）をターゲット文字コード化をもつター ゲット文字列に変換することを制御するコンバータ、入力文字列内の文字の各々 のコンテキストを判断するスキャナ、ソース・コード化の文字に対するターゲッ ト・コード化をストアしておくマッピング・テーブル、および入力文字列内の文 字の各々ごとにターゲット文字コード化に関連する変換コードを、コンテキスト と入力文字列内の文字のソース・コード化に基づいて前記マッピング・テーブル で調べるルックアップ・ハンドラを含んでいる。好ましくは、スキャナはさらに 入力文字列をテキスト要素（各テキスト要素は入力文字列の１つまたは複数の文 字を含んでいる）に分割する。この実施例には、ルックアップ・ハンドラが１つ または複数のテキスト要素の変換コードを提供できないような、特定の場合には フォールバック変換コードを提供するフォールバック・ハンドラを含めることも 可能である。 ソース文字列をターゲット文字列に変換するコード変換システムとしては、本 発明の第３側面による本発明の実施例は、ソース文字コード化をもつソース文字 列をターゲット文字コード化をもつターゲット文字列に変換することを制御する コンバータ手段、ソース内の文字の各々のコンテキストを判断するステート・マ シン、ソース文字コード化の文字に対するターゲット文字コード化をストアして おくマッピング手段、およびソース文字列内の文字の各々ごとにターゲット文字 コード化に関連する変換コードを前記マッピング手段で調べるルックアップ・ハ ンドラ手段を含んでいる。 ソース文字列をターゲット文字列に変換する方法としては、本発明の第３側面 による本発明の実施例は、第１文字コード化をもつソース文字列を受信し（ソー ス文字列は複数のソース文字を含んでいる）、ソース文字列のソース文字の各々 のコンテキストを判断し、ソース文字の各々ごとに第２文字コード化に関連する 変換コードを、第１文字コード化とソース文字について判断されたコンテキスト に基づいてマッピング・テーブルで調べ、ソース文字の変換コードを結合して第 ２文字コード化のターゲット文字列を形成するオペレーションを実行する。 ソース文字列をターゲット文字列に変換するためのプログラム命令を収めてお くコンピュータ可読メディアとしては、本発明の第３側面による本発明の実施例 は、第１文字コード化をもつソース文字列を受信することをコンピュータに実行 させるように構成されたコンピュータ可読コード、ソース文字列内のソース文字 の各々のコンテキストを判断し、ソース文字列をテキスト要素（各テキスト要素 はソース文字列の１つまたは複数の文字を含んでいる）に分割することをコンピ ュータに実行させるように構成されたコンピュータ可読コード、テキスト要素の 各々ごとに第２文字コード化に関連する変換コードを調べることをコンピュータ に実行させるように構成されたコンピュータ可読コードおよびテキスト要素の変 換コードを結合して第２文字コード化のターゲット文字列を形成することをコン ピュータに実行させるように構成されたコンピュータ可読コードを含んでいる。 本発明の第４側面では、切り捨て処理手法は、変換のために受信されたソース 文字列が、そのソース文字列が変換のためにソース文字列を格納している入力バ ッファの長さを越えたときでも、異なるターゲット文字コード化に正確に変換さ れることを保証する。 本発明の第４側面による切り捨て処理は、入力バッファに置かれているソース 文字列の一部を切り捨て、その切り捨てられた部分がソース文字列内の後続文字 に影響されることなくターゲット文字コード化に変換されるように作用する。当 然のことながら、入力バッファに置かれていて、切り捨てが行われた後のソース 文字列の部分（切り捨てられた部分）は最大限にしておくと、コード変換が効率 よく行えるようになる。本発明は、入力ソース文字列がネットワーク経由で受信 されるデータであるときに特に便利である。例えば、データはインターネット経 由で電子的に転送されるテキスト・データにすることができる。いずれの場合も 、本発明は種々の態様で実現することが可能である。方法、装置またはシステム として実現することも、コンピュータ可読メディア上に実現することも可能であ る。 ソース文字列をターゲット文字列に変換するコード変換システムとしては、本 発明の第４側面による本発明の実施例は、第１文字コード化をもつソース文字列 を第２文字コード化をもつターゲット文字列に変換することを制御するコンバー タ、ソース文字列の一部を一度に受け入れるバッファ（ソース文字列は１つまた は複数の文字を含んでいる）、ソース文字列の一部を切り捨てるトランケータ、 ソース文字列の切り捨てられた部分をテキスト要素（各テキスト要素はソース文 字列の切り捨てられた部分の１つまたは複数の文字を含んでいる）に分割するス キャナ、ソース・コード化のテキスト要素に対するターゲット・コード化をスト アしておくマッピング・テーブル、およびテキスト要素の各々ごとに第２文字コ ード化に関連する変換コードをマッピング・テーブルで調べるルックアップ・ハ ンドラを含んでいる。 ソース文字列を切り捨ててターゲット文字列に文字変換するための第１方法と しては、本発明の第４側面による本発明の実施例は、ソース文字列のバッファ部 分をバッファに受け入れ（ソース文字列は２つ以上のバッファ部分を含んでい る）、ソース文字列の後続バッファ部分に影響されることなくターゲット文字列 に変換することができる、ソース文字列のバッファ部分のサブパートを判断し、 ソース文字列のバッファ部分のサブパートをターゲット・コード化に変換するオ ペレーションを実行する。好ましくは、第１方法は、変換対象となるバッファ部 分の残余部分がサブパートと一緒になったときバッファ部分に等しい場合には、 その残余部分を次のバッファ部分またはそのサブパートと一緒に格納するオペレ ーションも実行する。 ソース文字を切り捨ててターゲット文字列に文字変換するための第２方法とし ては、本発明の第４側面による本発明の実施例は、ソース文字列の一部をバッフ ァに受け入れ、ソース文字列のその部分内のテキスト要素（各テキスト要素はソ ース文字列の１つまたは複数の文字を含んでいる）を判断し、テキスト要素が完 成しているかどうかを判断し、テキスト要素が完成しているときソース文字列の 切り捨てられた部分にテキスト要素を挿入し、ソース文字列の部分が完全に考慮 されるまでテキスト要素の判断を繰り返し、そのあと文字変換のためにソース文 字列の切り捨てられた部分を出力するオペレーションを実行する。好ましくは、 この第２方法は、バッファに受け入れられたソース文字列の次の部分と一緒に使 用するために、ソース文字列の残余部分を格納しておくオペレーションも実行す る。 ソース文字列をターゲット文字列に変換するためのプログラム命令を格納して おくコンピュータ可読メディアとしては、本発明の第４側面による本発明の実施 例は、第１文字コード化をもつソース文字列の一部をバッファに受け入れること をコンピュータに実行させるように構成されたコンピュータ可読コード、ソース 文字列の一部を切り捨てることをコンピュータに実行させるように構成されたコ ンピュータ可読コード、ソース文字列の切り捨てられた部分をテキスト要素（各 テキスト要素はソース文字列の切り捨てられた部分の１つまたは複数の文字を含 んでいる）に分割することをコンピュータに実行させるように構成されたコンピ ュータ可読コード、テキスト要素の各々ごとに第２文字コード化に関連する変換 コードを調べることをコンピュータに実行させるように構成されたコンピュータ 可読コード、およびテキスト要素の変換コードを結合して第２文字コード化の ターゲット文字列を形成することをコンピュータに実行させるように構成された コンピュータ可読コードを含んでいる。 本発明のその他の側面および利点は、本発明の原理を例示している添付図面を 参照して以下に詳述している説明の中で明らかにする。図面の簡単な説明 本発明の理解を容易にするために、以下では、添付図面を参照して本発明を詳 しく説明する。なお、図面において、類似する構成要素は類似の参照符号を付け て示されている。 図１は、本発明による代表的なコンピュータ・システムを示すブロック図であ る。 図２は、ユニコード文字コード化のフォーマットを示す図である。 図３は、ソース文字列を受信し、ターゲット文字列を出力する本発明による基 本的ユニコード・コード変換システムを示すブロック図である。 図４は、本発明の実施例によるユニコードからのコード変換システムの実施例 を示すブロック図である。 図５は、ユニコード・コード変換システムのマッピング・テーブルの好ましい 配列を示す概略図である。 図６Ａは、本発明の実施例によるユニコード・コード変換システムを利用する アプリケーション・プログラムによって実行される処理を示すフローチャートで ある。 図６Ｂは、本発明の実施例による切り捨て処理を示すフローチャートである。 図７は、本発明の実施例によるユニコード・コンバータ処理を示すフローチャ ートである。 図８は、本発明の実施例による更新オフセット処理を示すフローチャートであ る。 図９Ａおよび図９Ｂは、本発明の実施例による次のテキスト要素処理を示すフ ローチャートである。 図１０Ａ、図１０Ｂおよび図１０Ｃは、本発明の実施例による次のテキスト要 素処理を示すフローチャートである。 図１１は、本発明の実施例によるスキャナを示すブロック図である。 図１２は、図１０に示す属性テーブルの好ましいフォーマットを示す概略図で ある。 図１３は、本発明の実施例による属性ルックアップ処理を示すフローチャート である。 図１４Ａおよび図１４Ｂは、本発明の好適実施例による次のアクションを判断 するためにスキャナによって利用されるスキャナ・テーブルを示す概略図である 。 図１５は、本発明の実施例による好ましいレイアウトと、スキャナ・テーブル にストアされる情報の両方を表しているテーブルである。 図１６Ａおよび図１６Ｂは、本発明の好適実施例による好ましいレイアウトと 、スキャナ・テーブルにストアされる情報の両方を表しているテーブルである。 図１７Ａは、本発明の実施例による方向解明処理を示すフローチャートである 。 図１７Ｂないし図１７Ｄは、本発明による双方向状態テーブルの好ましいレイ アウトを表しているテーブルである。 図１８は、本発明の実施例による初期方向処理を判断するためのフローチャー トである。 図１９は、本発明の実施例によるルックアップ・テキスト要素処理を示すフロ ーチャートである。 図２０は、本発明の実施例によるチェーン・フォーマット処理を示すフローチ ャートである。 図２１は、本発明の実施例による範囲フォーマット処理を示すフローチャート である。 図２２は、本発明の実施例によるリスト・フォーマット処理を示すフローチャ ートである。 図２３Ａおよび図２３Ｂは、本発明の実施例によるセグメント配列フォーマッ ト処理を示す図である。 図２４は、本発明の実施例による変形リスト・サーチ処理を示すフローチャー トである。 図２５Ａおよび図２５Ｂは、本発明の実施例による変形リスト処理に関連する テーブルとデータ・フォーマットを示す概略図である。 図２６Ａ、図２６Ｂおよび図２６Ｃは、本発明の実施例による出力シーケンス へのルックアップ・ターゲットのマッピング処理を示すフローチャートである。 図２７は、本発明の実施例による本発明の処理に従うフォールバック・ハンド リング処理を示すフローチャートである。 図２８は、本発明の実施例によるデフォルト処理を示すフローチャートである 。 図２９は、本発明の実施例によるユニコードへのコード変換の実施例を示すブ ロック図である。発明の最良の実施形態 以下、図１ないし図２９を参照して本発明の実施例について説明する。なお、 この分野の精通者ならば理解されるように、これらの図を参照して以下に詳述す る説明は本発明の理解を容易にすることを目的とし、本発明は以下に説明する実 施例に限定されるものではない。 本発明の第１側面によるコード変換システムはソース文字を異なるコード化の ターゲット文字に変換するものである。本発明によるコード変換システムはラウ ンドトリップ忠実度を備えていると共に、その結果の文字コードが他のプラット フォームと互換性をもつことを保証する。コード変換システムは単一ソース文字 または文字シーケンスを単一ターゲット文字またはターゲット文字シーケンスの どちらかにマッピングする機能を備えている。ラウンドトリップ忠実度により、 ソース・テキストはターゲット・テキストに変換し、そのあとオリジナル・ソー ス・テキストに戻すように再変換することができる。その結果の文字コードが他 のプラットフォームと互換性をもつことは、標準ターゲット文字の使用を最大限 にし、プライベート文字の使用を最小限にすることによって保証される。コード 変換システムは他の文字セットからユニコード文字に変換し、ユニコード文字を 他の文字セットに変換するときに利用すると、特に便利である。ユニコード文字 シーケンスをターゲット文字セット内の単一文字にマッピングすることは従来に はなかったものである。 コード変換システムはコンピュータ・システムや他のエレクトロニック・デバ イスにしてこれらのコード変換オペレーションを行うことができる。このコンピ ュータ・システムは必要とする目的だけに使用するように構築することも、コン ピュータ・プログラムに従って動作する汎用コンピュータにすることも可能であ る。以下に説明する処理はどのコンピュータ・システムや他のエレクトロニック ・デバイスにも適用可能である。具体的には、種々の汎用コンピューティング・ マシンは以下に教示する説明に従って書かれたソフトウェアと共に使用すること ができるが、もっと特殊化されたエレクトロニック・デバイスを構築すると、必 要とするオペレーションを実行できるので好都合である。 本発明の第２側面によるコード変換システムはソース文字コード化からの文字 をターゲット文字コード化に変換するとき方向を考慮に入れる。このコード変換 システムは単一ソース文字または文字シーケンスを単一ターゲット文字またはタ ーゲット文字シーケンスにマッピングする機能を備えている。変換される文字の 方向を判断または解明することにより、コード変換システムは判断または解明さ れた文字の方向を利用してターゲット文字コード化への正しいマッピングが得ら れることを保証する。従って、本発明によれば、ソース文字列内の文字の方向が 変化するときでも正しいコード変換が達成される。 本発明がアラビアまたはヘブライ・ベースの文字セットが使用されるときに特 に便利であるのは、これらの文字が右から左への方向をもっているからである。 本発明によれば、どちらかの方向を取り扱うときの柔軟性が得られるだけでなく 方向を途中で変更できるという機能も得られる。方向を途中で変更できることは アラビア文字および／またはヘブライ文字が左から右への方向が最も普通である 他の文字セットと一緒に使用されるような場合に重要である。異なる方向をもつ 文字の使用例として、スペース文字がある。ユニコードでは、コード化は１つだ けであり、固有の方向をもっていない。他方、ＭａｃＡｒａｂｉｃでは、左から 右へのスペース文字と右から左へのスペース文字の２種類がある。 変換されるソース文字の方向を判断または解明することは、方向解明手法によ って達成されるが、この手法についてはソース文字を異なるコード化のターゲッ ト文字に変換するコード変換システムと関連づけて以下で詳しく説明する。 本発明の第３側面によるコード変換システムはソース文字コード化からの文字 をターゲット文字コード化に変換するときコンテキストを考慮に入れる。このコ ード変換システムは単一ソース文字または文字シーケンスを単一ターゲット文字 またはターゲット文字シーケンスのどちらかにマッピングする機能を備えている 。文字のコンテキストを判断することにより、コード変換システムは判断された 文字のコンテキストを利用してターゲット・コード化への正しいマッピングが得 られることを保証する。従って、本発明によれば、文字のコンテキストがターゲ ット・コード化へのマッピングに影響するときでも正しいコード変換が達成され る。 ある種の文字セットでは、文字が使用されているコンテキストによって文字が 異なる表現形態をもつことになる。これらの文字の表現形態は絵文字(glyphs)で ある。異なる表現形態は表示されるとき異なって現れる。文字が使用されている コンテキストによって表現形態が決まる。アラビア文字はそのコンテキストに応 じて異なる表現形態をもつ言語である。 アラビア・スクリプトはアラビア語を書くために使用される。アラビア・スク リプトはその印刷形体においても筆写体（カーシブ）である。その結果として、 同じ文字はそれが隣の文字とどのように結合されるかに応じて異なった形体で書 かれることがある。このような文字の例として、アラビア文字“ＨＥＨ”（ユニ コード文字ではｕ０６４７とコード化される）がある。例えば、ユニコードでの アラビア文字はＤＯＳアラビア文字の４つの異なる表現形態の１つをコンテキス トに応じてマッピングされる場合がある。その結果、本発明によるコード変換シ ステムはユニコード・ストリーム内のアラビア文字のコンテキストを判断し、正 しいマッピングが得られるように動作する。 変換されるソース文字のコンテキストの判断はコンテキスト処理によって達成 されるが、このコンテキスト処理はソース文字を異なるコード化のターゲット文 字に変換するコード変換システムと関連づけて以下で詳しく説明する。 本発明の第２および第３側面によれば、コード変換システムはソース文字を異 なるコード化のターゲット文字に変換する。本発明によるコード変換システムは ラウンドトリップ忠実度を提供すると共に、その結果の文字コードが他のプラッ トフォームと互換性をもつことを保証する。コード変換システムは単一ソース文 字または文字シーケンスを単一ターゲット文字またはターゲット文字シーケンス のどちらかにマッピングする機能を備えている。ラウンドトリップ忠実度による と、ソース・テキストはターゲット・テキストに変換し、そのあとオリジナル・ ソース・テキストに戻るように再変換することができる。その結果の文字コード と他のプラットフォームとの互換性は標準ターゲット文字の使用を最大限にし、 プライベート文字の使用を最小限にすることによって保証される。コード変換シ ステムは他の文字セットからユニコード文字に変換し、ユニコード文字を他の文 字セットに変換するときに利用すると、特に便利である。ユニコード文字シーケ ンスをターゲット文字セット内の単一文字にマッピングすることは従来にはなか ったものである。 コード変換システムはコンピュータ・システムや他のエレクトロニック・デバ イスにしてこれらのコード変換オペレーションを行うことができる。このコンピ ュータ・システムは必要とする目的だけに使用するように構築することも、コン ピュータ・プログラムに従って動作する汎用コンピュータにすることも可能であ る。以下に説明する処理はどのコンピュータ・システムや他のエレクトロニック ・デバイスにも適用可能である。具体的には、種々の汎用コンピューティング・ マシンは以下に教示する説明に従って書かれたソフトウェアと共に使用すること ができるが、もっと特殊化されたエレクトロニック・デバイスを構築すると、必 要とするオペレーションを実行できるので好都合である。 本発明の第４側面では、切り捨て処理手法は変換のために受信されたソース文 字列が、そのソース文字列が変換のためにソース文字列を格納している入力バッ ファの長さを越えたときでも、異なるターゲット文字コード化に正確に変換され ることを保証する。切り捨て処理手法は入力バッファに置かれているソース文字 列の一部を切り捨てて、切り捨てられた部分がソース文字列内の後続文字に影響 されることなくターゲット文字コード化に変換されるように作用する。当然のこ とであるが、入力バッファに置かれていて、切り捨てられた後のソース文字列の 部分（切り捨てられた部分）を最大限にすると、コード変換を効率よく実行する ことができる。 本発明による切り捨て処理手法はソース文字を異なるコード化のターゲット文 字に変換するコード変換システムと関連づけて以下で詳しく説明する。 図１は本発明による代表的なコンピュータ・システム１００を示すブロック図 である。コンピュータ・システム１００は中央処理ユニット（ＣＰＵ）１０２を 装備し、このＣＰＵは双方向にランダムアクセス・メモリ（ＲＡＭ）１０２と、 単方向にリードオンリ・メモリ（ＲＯＭ）１０６と結合されている。代表例とし て、ＲＡＭ１０４はプログラミング命令とデータを格納し、この中には現在ＣＰ Ｕ１０２上で実行中のプロセスに対する他のデータや命令のほかに、以下で説明 するテーブルが含まれている。代表例として、ＲＯＭ１０６はコンピュー タ・システムがその機能を実行するために使用する基本的操作命令、データおよ びオブジェクトを格納している。そのほかに、ハードディスク、ＣＤ ＲＯＭ、 磁気光学（フロプチカル）ドライブ、テープ・ドライブなどの大量記憶装置１０ ８は双方向にＣＰＵ１０２と結合されている。大量記憶装置１０８は一般的にＣ ＰＵによって活発に使用されることがない追加のプログラミング命令、データお よびテキスト・オブジェクトを収容しているが、アドレス空間は例えば仮想メモ リなどのためにＣＰＵによってアクセス可能である。上述したコンピュータの各 々はさらに入出力ソース１１０を含んでおり、その代表例として、キーボードや ポインタ・デバイス（例えば、マウスやスタイラス）などの入力メディアがある 。コンピュータ・システム１００はデータと命令を転送できるネットワーク接続 １１２を含むこともできる。追加の大量記憶装置（図示せず）をネットワーク接 続１１２を経由してＣＰＵ１０２に接続することも可能である。コンピュータ・ システム１００はさらに、コンピュータ・システム１００によって生成または表 示されたテキストおよびイメージ（画像など）を見るための表示スクリーン１１ ４を含んでいる。 ＣＰＵ１０２はオペレーティング・システム（図示せず）と一緒になって、コ ンピュータ・コードを実行するように動作する。コンピュータ・コードはＲＡＭ １０４、ＲＯＭ１０６、または大量記憶装置１０８に置いておくことができる。 また、コンピュータ・コードはポータブル・プログラム・メディア１１６に置い ておき、必要時にコンピュータ・システム１００にロードまたはインストールす ることも可能である。ポータブル・プログラム・メディア１１６の例としては、 ＣＤ−ＲＯＭ、ＰＣカード・デバイス、ＲＡＭデバイス、フロッピディスク、磁 気テープなどがある。Ｉ．定義 １．コード・ポイント：コード・ポイントとは、特定のコード化におけるビッ ト・パターンである。通常、ビット・パターンは１または２バイト以上の長さに なっている。ユニコードのコード・ポイントは常に１６ビットまたは２バイトで ある。 ２．コード化：コード化とは、文字セットとコード・ポイントのセットとを１ 対１で対応づけたもの（マッピング）である。例えば、ＡＳＣＩＩコード化はａ −ｚ、Ａ−Ｚ、および０−９を含むセットをコード・ポイントｘ００−ｘ７Ｆに 対応づけている。 ３．テキスト要素：テキスト要素は特定のオペレーションで１つの単位として 扱われる１つまたは２つ以上のコード・ポイントのシーケンスである。例えば、 ＬＡＴＩＮ ＣＡＰＩＴＡＬ ＬＥＴＴＥＲ Ｕとその後に続くＮＯＮ−ＳＰＡ ＣＩＮＧ ＤＩＡＥＲＥＳＩＳは本発明によるコード変換オペレーションの対象 となるテキスト要素である（例えば、この例では、２つの隣り合う文字）。 ４．絵文字：文字を可視的に表現した表示形態。例えば、イタリックの“ａ” とローマン字の“ａ”は同じ基礎文字を表現する２つの異なる絵文字である。 ５．表現形態：表現形態はコンテキストに応じてその可視形体を変化させる絵 文字である。ある種のコード化はコンテキストから独立している抽象文字だけを マッピングするのに対し、他のコード化は表現形体だけをマッピングする。例え ば、“ｆｉ”のような合字は、ＬＡＴＩＮ ＣＡＰＩＴＡＬ ＬＥＴＴＥＲ Ｆ とその後に続くＬＡＴＩＮ ＣＡＰＩＴＡＬ ＬＥＴＴＥＲ Ｉの文字シーケン スの表現形態である。 ６．フォールバック：フォールバックはソース・コードに正確に等価ではない が、オリジナルの情報の一部を残しているターゲット・コード化内の１つまたは 能なフォールバックである。 ７．デフォルト：デフォルトはターゲット・コード化内にソース・コード・ポ イントに類似したものがないとき使用されるターゲット・コード化内の１つまた は２つ以上のコード・ポイントのシーケンスである。II ．ユニコード・コンバータ 本発明による一般的変換手法はソース文字を異なるコード化のターゲット文字 に変換する。好ましくは、ソース文字またはターゲット文字のどちらかはユニ コード文字になっている。 ユニコード標準は開発されたいくつかの文字コード化を汎用国際的文字コード 化標準に統一化したものである。図２はユニコード文字コード化のフォーマット を示す図である。具体的には、ユニコード標準に用意されているコードは、図２ に示すフォーマット２００で示すように１６ビット幅になっている。本明細書で は、ユニコード文字は頭にｕを付けた１６進数で表され（例えば、ｕ００１）、 他のコード化内の文字は頭にｘを付けた１６進数で表されている（例えば、ｘ４ １は１バイト文字を表し、ｘ８１４０は２バイト文字を表している）。 図３は、ソース文字列３０２を受信し、ターゲット文字列３０４を出力する本 発明による基本的ユニコード・コード変換システム３００を示すブロック図であ る。ユニコード・コード変換システム３００はソース文字列３０２の文字を、タ ーゲット・ストリーム内にあって、文字コード化がソース文字列で使用されたコ ード化と異なっている１つまたは複数の文字に変換するように動作する。好まし くは、ユニコード・コード変換システム３００はユニコードから異なるターゲッ ト・コード化に変換するか（ユニコードから）、あるいは異なるソース・コード から変換する（ユニコードへ）。 図４は本発明によるユニコード・コード変換システム４００の実施例を示すブ ロック図である。本発明の第４側面では、トランケータ４０７とバッファ４０５ が存在し、適用されているが、第１、第２または第３側面では、これらは必ずし も存在する必要がないので、必ずしも適用されるとは限らない。 本発明の第１、第２および第３側面によれば、ユニコード・コード変換システ ム４００はユニコード文字列４０４を受信し、ターゲット文字列４０６を出力す るユニコードからのコンバータ４０２を含んでいる。ユニコードからのコンバー タ４０２は本発明に従ってコード変換プロセスを実行する。その際に、ユニコー ドからのコンバータ４０２はスキャナ４０８とやりとりする。スキャナ４０８は スキャナ・テーブル４０８と一緒に使用されて、ユニコード文字列をスキャンし テキスト要素を特定する。そのあと、ユニコードからのコンバータ４０２はルッ クアップ・ハンドラ４１２を使用して、スキャナ４０８によって特定されたテキ スト要素のターゲット・コード化内の１つまたは複数の文字を調べる。ルック アップ・ハンドラ４１２はマッピング・テーブル１４を使用してテキスト要素の ターゲット・コード化内の１つまたは複数の文字を取得する。さらに、ユニコー ドからのコンバータ４０２はフォールバック・ハンドラ４１６を使用することも 可能である。フォールバック・ハンドラ４１６はマッピング・テーブル４１４と 一緒に使用され、ルックアップ・ハンドラ４１２がテキスト要素のターゲット・ コード化内の１つまたは複数の文字を特定できなかった場合に、ターゲット・コ ード化内にあって、テキスト要素のフォールバック・マッピングとして使用でき る１つまたは複数の文字を特定するように動作する。状態管理機構(state admin istrator)４１８は変換の現在状態に関する情報を維持し、あるいはストアして いる。この情報の例としては、シメトリック・スワッピングのコンテキスト、方 向および状態がある。 本発明の第４側面によれば、ユニコード・コード変換システム４００はユニコ ード文字列４０４を受信し、ターゲット文字列４０６を出力するユニコードから のコンバータ４０２を含んでいる。ユニコード文字列はバッファ４０５にストア される。トランケータ４０７はバッファ４０５にストアされたユニコード文字列 ４０４の長さを切り捨てて、正確な変換が行われることを保証する。 ユニコードからのコンバータ４０２はコード変換の全体的オペレーションを制 御する。その際に、ユニコードからのコンバータ４０２はスキャナ４０８とやり とりする。スキャナ４０８はスキャナ・テーブル４０８と一緒に使用されて、切 り捨てられたユニコード文字列４０４（トランケータ４０７から与えられたもの ）をスキャンしテキスト要素を特定する。そのあと、ユニコードからのコンバー タ４０２はルックアップ・ハンドラ４１２を使用して、スキャナ４０８によって 特定されたテキスト要素のターゲット・コード化内の１つまたは複数の文字を調 べる。ルックアップ・ハンドラ４１２はマッピング・テーブル１４を使用してテ キスト要素のターゲット・コード化内の１つまたは複数の文字を取得する。さら に、ユニコードからのコンバータ４０２はフォールバック・ハンドラ４１６を使 用することも可能である。フォールバック・ハンドラ４１６はマッピング・テー ブル４１４と一緒に使用され、ルックアップ・ハンドラ４１２がテキスト要素の ターゲット・コード化内の１つまたは複数の文字を特定できなかった 場合に、ターゲット・コード化内にあって、テキスト要素のフォールバック・マ ッピングとして使用できる１つまたは複数の文字を特定するように動作する。状 態管理機構(state administrator)４１８は変換の現在状態に関する情報を維持 し、あるいはストアしている。この情報の例としては、シメトリック・スワッピ ングのコンテキスト、方向および状態がある。この種の情報は、切り捨てられた ユニコード文字列がブロックの終わりで終わっていない非ブロック区切り変換を 行うとき必要になるものである。そのような場合には、変換の現在状態に関する 情報をストアしておくと、コード変換プロセスは入力文字列４０４がバッファ４ ０５のサイズよりも大きいときでも、正確なコード変換を行うことができる。Ａ．スキャナおよびスキャナ・テーブル スキャナ４０８はスキャナ・テーブル４１０と一緒に使用されて、ユニコード 文字列４０４をスキャンし、ルックアップ・ハンドラ４１２が必要とする次のテ キスト要素と追加情報を戻す。追加情報には、方向情報、コンテキスト情報、お よび種々の状態インジケータの１つまたは２つ以上が含まれている。以下では、 スキャナ４０８の一般的オペレーションについて説明する。スキャナ４０８は入 力ユニコード文字列４０４の文字をスキャンして行く。ターゲット・コード化の ために方向情報が必要であれば、テキスト要素内の各文字ごとに文字方向が取得 される。また、ターゲット・コード化のために文字コンテキスト情報が必要であ れば、テキスト要素内の各文字ごとに文字コンテキスト情報が取得される。その あと、スキャナ４０８が文字の各々をスキャンしていくとき、スキャナ４０８は スキャナ・テーブル４１０に入っている情報に従って文字に対するアクションを とる。スキャナ４０８がどのようなアクションをとるかは、状態と文字クラスに 基づいて判断される。スキャナ４０８がとることができるアクションとしては、 現在の文字にマークを付けること、シメトリック・スワッピング・ビットをセッ トまたはクリアすること、テキスト要素のコンテキスト形式を記録すること、テ キスト要素が再配列を必要とすることを示すフラグをセットすること、テキスト 要素の終わりを示すこと、などがある。シメトリック・スワッピング・ビット、 コンテキストおよび方向はスキャナの状態に関する情報として状態管理機構４１ ８によってセーブされる。戻す前に、スキャナ４０８はテキスト要素のコンテキ スト情報をセーブしておく。スキャナ４０８はテキスト要素（入力文字列内の各 テキスト要素）とその属性を返却する。属性には次のものがある。方向、クラス 、優先順位、シメトリック・スワッピング状態、サブセットおよびコンテキスト である。スキャナ４０８がテキスト要素を判断したあと、文字を標準形順序に再 配列する必要が起こる場合がある。１つの例として、テキスト要素内の文字の再 配列はユニコードで定義されている標準形順序になっていない非スペース・マー クがテキスト要素に含まれているときに行われる。 好ましくは、スキャナ４０８はスキャナ・テーブル４１０と一緒に、並列に動 作するペアのステート・マシンとして実現されている。第１ステート・マシンは 文字方向を解明し、第２ステート・マシンは該当する場合には、テキスト要素と 文字形式コンテキスト情報を計算し、シメトリック・スワッピング状態も記録し ておく。別々になった２つのステート・マシンを使用すると、ユニコード・コー ド変換システム４００の設計と保守が容易化される。第１および第２ステート・ マシンは状態とクラスによってインデックスされる２次元配列（またはテーブル ）として実現することができる。スキャナ４０８がとるべきアクションが文字方 向によって決まる場合には、ステート・マシン・エントリは各方向についてスキ ャナ４０８がとるべき該当アクションを収めている別のテーブルまでのインデッ クスである。 スキャナ４０８の機能は入力ユニコード文字列４０４をテキスト要素に変換し 、テキスト要素とその属性を戻すことである。スキャナ４０８はテキスト要素の ある種の特性をセーブしておく必要があり、そうすれば、ターゲット・コード化 で正しく変換されることになる。すなわち、特性には、方向、コンテキストおよ びシメトリック・スワッピング状態がある。しかし、スキャナ４０８は、そのオ ペレーションが特定のターゲット・コード化から独立しているので、どのような ターゲット・コード化であるかを知っている必要はない。それにもかかわらず、 ユニコード変換システム４００は、テイスト要素の定義（つまり、チャンク行動 ）が、スキャナ・テーブル４１０を変更するだけでターゲット・コード化と 共に変化できるように実現されていることが好ましい。 文字の方向性は文字を表示するために使用される。例えば、アラビアまたはヘ ブライ文字が表示スクリーンに表示されるとき、これらは右から左への順序にな っている。大部分のユニコード文字は黙示的方向をもっている（ユニコード・バ ージョン１．０の４０７ページ（セクション４．６）および６１１ページ（付録 Ａ）を参照）。ユニコード標準に用意されている暗黙的方向クラスとその値には 次のものがある。左から右へ（０）、右から左へ（１）、ヨーロッパ数字（２） 、ヨーロッパ数字セパレータ（３）、ヨーロッパ数字ターミネータ（４）、アラ ビア数字（５）、共通数字セパレータ（６）、ブロック・セパレータ（７）、セ グメント・セパレータ（８）、ホワイトスペース（９）およびその他の数字であ る。スキャナ４０８はテキスト要素の文字の方向クラスを調べる。次に、その方 向クラスはテキスト要素の方向を解明するために使用される。また、方向性をオ ーバライドまたは埋め込ませる特殊なユニコード文字もある。これらの特殊なユ ニコード文字はスキャナ４０８によって単一文字テキスト要素として扱われる。 テキスト要素を形成するときスキャナ４０８が従う基本的ルールがいくつかあ る。ベース・ルールでは、適用されるルールがなければ、テキスト要素は単一ユ ニコード文字とされる。別のルールでは、ベース文字に続く非スペースまたは結 合マークはそのベース文字と一緒に単一テキスト要素として分類される。さらに 別のルールでは、シンボル（つまり、朝鮮ハングル・ジャモス文字）、合字また は表意文字に関連する文字が見つかると、これらはテキスト要素に結合される。 さらに別のルールでは、フラクション・スラッシュの両側が１つまたは複数の１ ０進数のシーケンスで囲まれていると、これらは数字フラクション・テキスト要 素として結合される。 以下では、非スペースまたは結合マークに関するルールについて詳しく説明す る。ユニコード標準によれば、非スペース・マークはベース文字のあとに置かれ ている。従って、ベース文字のあとに置かれた非スペース文字はベース文字を含 むテキスト要素の一部となる（ユニコード標準バージョン１．０、４０３ページ （セクション４．３）を参照）。例えば、単一の非スペース文字の後に非スペー ス文字でない文字が続いているときは、その非スペース文字は直前の文字と一緒 にテキスト要素として結合される。その場合、テキスト要素の長さは２であり、 テキスト要素の属性はベース文字によって定義されている。前に置かれた文字が なければ、非スペース文字は単一テキスト要素として渡されるだけである。複数 の非スペース文字もこのようにして結合することができる。 以下では、朝鮮ハングル・ジャモス文字について詳しく説明する。各ハングル 文字は暗黙値を持ち、これは次のクラスの１つになっている。Ｃｈｏｓｅｏｎｇ （初期）、Ｊｕｎｇｓｅｏｎｇ（中間）またはＪｏｎｇｓｅｏｎｇ（最終）であ る。ユニコード標準バージョン１．１（セクション５）はこれらの文字のコード と許容される組み合わせをリストしている。スキャナ４０８はこれらの文字の許 容される組み合わせに従って朝鮮ジャモス文字をグループ化する。入力が許容さ れない組み合わせのときは、スキャナ４０８は文字を単一テキスト要素として返 却する。前述したように、ハングル分節のあとに結合マークが付いているときは 、その結合マークはハングル分節のテキスト要素内に挿入される。 次に、数字フラクションに関するルールについて詳しく説明する。スキャナ４ ０８は最初にフラクション・スラッシュ数字の各文字を、それらが単一文字テキ スト要素であるものとして取り扱う。しかし、完全なフラクション・スラッシュ ・シーケンスが見つかったときは、スキャナ４０８はそのシーケンスに関連する 文字を単一テキスト要素になるように結合する。ディジットが結合マークと一緒 に見つかったときは、そのディジットと結合マークはフラクション・スラッシュ の一部となることができないが、ディジットと結合マークは一緒にテキスト要素 を形成することができる。 非スペース文字を除き、すべてのアラビア文字は単一テキスト要素としてスキ ャナ４０８を通過する。アラビア形式のシェーピング状態文字も、単一テキスト 要素としてスキャナを通過する。方向フォーマッティング・コードは単一テキス ト要素としてスキャナ４０８を通過する。Ｂ．ルックアップ・ハンドラ、マッピング・テーブルおよびフォールバック・ハ ンドラ マッピング・テーブル４１４は１つまたは複数のユニコード文字の入力シーケ ンスをターゲット・コード化における１つまたは複数の出力シーケンスと突き合 わせるためにルックアップ・ハンドラ４１２によって使用される。ユニコード・ シーケンス（つまり、テキスト要素）自体のほかに、入力シーケンスに関するあ る種の追加情報が得られ（例えば、方向、今テキスト、シメトリック・スワッピ ング状態、垂直形式要求、フォールバック要求、許容範囲、変種）、ある種のテ ーブルはこの情報を利用している。好ましくは、マッピング・テーブル４１４は フォールバック・ハンドラ４１６が必要とするデータもストアしているが、別の テーブルを用意してフォールバック・ハンドラ４１６に使用させることも可能で ある。 図５はユニコード・コード変換システム４００のマッピング・テーブル４１４ の好ましい配列を示す概略図である。マッピング・テーブル４１４は好ましくは ヘッダ部分５００を含み、マッピング・テーブル４１４のデータのセグメントは テキスト要素内の文字数に基づいて分割されている。ヘッダ部分５００の内容は 以下で詳しく説明する。図５に示すマッピング・テーブル４１４は１からＮ文字 までのテキスト要素のコード化をサポートしている。ルックアップ・ハンドラ４ １２が１文字テキスト要素のターゲット・コード化を探すためにマッピング・テ ーブル４１４をサーチするとき、マッピング・テーブル４１４のセグメント５０ ２が使用される。同様に、テキスト要素が２文字幅であれば、セグメント５０４ が使用され、テキスト要素がＮ文字幅であれば、セグメント５０６が使用される 。図４と図５は単一マッピング・テーブル４１４を示しているが、ユニコード・ コード変換システム４００は複数の異なるマッピング・テーブル４１４を使用す る。つまり、各ターゲット文字セットごとに１つのマッピング・テーブルを使用 する。各マッピング・テーブルは複数のサブテーブルを含んでいる。 マッピング・テーブル４１４はサイズと全体的変換速度要件を考慮に入れて設 計されている。マッピング・テーブル４１４はルックアップ時間を重大に低下さ せることなく可能な限り小さくしておくべきであり、ルックアップ時間はテーブ ル・サイズを大幅に大きくすることなく可能な限り高速にしておくべきである。 ユニコード・コード変換システム４００は複数のテーブル・フォーマットをサポ ートしているので、各サブテーブルごとに異なるフォーマットにすることが可能 である。そのようにすると、速度とサイズのトレードオフを特定のテーブルに合 わせて必要時に調整することができる。好ましくは、マッピング・テーブル４１ ４の設計は単一ユニコード文字からターゲット・コード化内の単一文字にマッピ ングするのを可能な限り高速化するものでなければならないが、これは最も普通 の使い方であるからである。 マッピング・テーブル４１４の設計は、テーブルがフォールバック・ハンドラ ４１６の要求の少なくとも一部をサポートし、複数のマッピング許容範囲をサポ ートし、複数のターゲット文字セットの変種をサポートするようになっている。 テーブル・フォーマットは１つまたは複数のユニコード文字シーケンスをゼロま たは１個以上の文字の出力シーケンスにマッピングすることもできる。マッピン グ・テーブル４１４は単一入力シーケンスに対して起こり得る複数の出力シーケ ンスを指定することが可能であり、特定の出力シーケンスは方向、コンテキスト およびシメトリック・スワッピング状態などの属性によって判断される。本発明 の第３側面に関しては、中心となるのは出力シーケンスの１つをコンテキストに 基づいて選択することである。マッピング・テーブルは容易に拡張することがで きるので、ユニコード・コード変換システム４００のコード化の振舞を容易にカ ストマイズすることができる。 マッピング・テーブル４１４が必要とする情報には次のものがある。スキャナ ４０８からのテキスト要素（つまり、結合マークを標準形順序にして変換される 入力文字シーケンス）、垂直形式が使用可能なときに水平形式の代わりに使用す るかどうか、解明されたテキスト要素の方向、テキスト要素の文字形式コンテキ スト情報（初期、中間、最終、または隔離）、シメトリック・スワッピングの現 在状態、どのレベルのルックアップを起動させるかの情報（許容レベル（厳格ま たは緩和）とフォールバック（オンまたはオフ））、および特定のコード化変種 の識別子である。ルックアップ・レベルに関する情報はコールまたはユニコード ・コード変換システム４００をコールするアプリケーション・プログラムから 与えられる。方向およびコンテキストが重要でない言語または文字では、解明さ れた方向とコンテキスト情報は必要でない。 変種の定義、ユニコード・シーケンスからターゲット・シーケンスへの実際の マッピング、およびこれらにアクセスするために使用されるテーブル・フォーマ ットはマッピング・テーブル４１４の設計によって変更可能である。従って、正 確性および若干であるが、パフォーマンスとサイズとのトレードオフはマッピン グ・テーブル４１４の設計に大きく依存している。好ましいことは、マッピング ・テーブル４１４が厳格および緩和マッピング、フォールバック・マッピング、 およびデフォルト・マッピングをサポートすることである。 厳格マッピングはラウンドトリップ忠実度が保証されるコード変換である。ユ ニコードからターゲット文字セットへの厳格マッピングはその文字セットからユ ニコードへのユニコードへのマッピングとは逆である。ユニコードからターゲッ ト文字セットへの緩和マッピングはターゲット文字セット内の文字の定義または 隔離された用途の範囲に属する追加マッピングである。緩和マッピングは正しく マッピングされるように見えるが、若干のあいまいさがある。例えば、多くの文 字セットでは、単一文字は、明示的定義、あいまいな定義、または確立された用 法のいずれかによって複数の意味を持つことがある。例えば、Ｓｈｉｆｔ−ＪＩ Ｓ文字ｘ８１６１は２つの意味を持つように規定されている。すなわち、「２重 垂直線」と「平行」である。これらの意味の各々は異なるユニコード文字ｕ２０ １６「２重垂直線」とｕ２２２５「に平行」に対応している。Ｓｈｉｆｔ−ＪＩ Ｓからユニコードにマッピングするときは、コード変換システムはこれらのユニ コード文字の１つ、つまり、２重垂直線を選択しなければならない。ユニコード からＳｈｉｆｔ−ＪＩＳにマッピングするときは、コード変換システムは両方の ユニコード文字を同一Ｓｈｉｆｔ−ＪＩＳ文字にマッピングすることができ、そ のようにするのが通常である。しかし、これらのユニコードからのマッピングの １つだけはユニコードへのマッピングとは逆になっている。 厳格マッピングと緩和マッピングの比較例 ・ ユニコードｕ０００ＤがＡＳＣＩＩｘ０Ｄ「キャリッジリターン」に厳格 にマッピングされていれば、ユニコードｕ２０２９「パラグラフ・セパ レータ」はＡＳＣＩＩｘ０Ｄにゆるやかにマッピングすることができ る。 ・ ユニコードｕ００２Ｄ「ハイフン−マイナス」がＡＳＣＩＩｘ２Ｄ「ハイ フン−マイナス」に厳格にマッピングされていれば、ユニコード ｕ２０１０「ハイフン」とｕ２２１２「マイナス記号」は ＡＳＣＩＩｘ２Ｄにゆるやかにマッピングすることができる。 ・ ユニコードｕ００ＥＯ「グラーブ付きのラテン小文字Ａ」が ＩＳＯ ８８５９−１ｘＥＯ「アクサングラーブ付きの小文字ａ」に厳格 にマッピングされていれば、２文字のユニコード・シーケンス ｕ００６１＋ｕ０３００「ラテン小文字Ａ」＋「結合アクサングラーブ」 はＩＳＯ ８８５９−１ｘＥＯにゆるやかにマッピングすることができ る。 ・ Ｓｈｉｆｔ−ＪＩＳは半幅文字と全幅文字を区別しているので、 Ｓｈｉｆｔ−ＪＩＳの緩和マッピングもこれらを区別しておかなければな らない。つまり、ユニコードｕＦＦ４０「全幅アクサングラーブ」は Ｓｈｉｆｔ−ＪＩＳｘ８１４Ｄ「アクサングラーブ（全幅）に厳格にマッ ピングされており、これはＳｈｉｆｔ−ＪＩＳｘ６０「アクサングラー ブ（半幅）と区別されている。ユニコード・シーケンスｕ３０００＋ ｕ０３００「表意文字スペース」＋「結合アクサングラーブ」は Ｓｈｉｆｔ−ＪＩＳｘ８１４Ｄにゆるやかにマッピングすることができ る。しかし、ユニコード・シーケンスｕ００２０＋ｕ０３００「スペー ス」＋「結合アクサングラーブ」はＳｈｉｆｔ−ＪＩＳｘ８１４Ｄにゆる やかにマッピングしてはならない。これはＳｈｉｆｔ−ＪＩＳｘ６０に マッピングされるべきである。 本発明の第１側面によれば、ユニコードからある種の他の文字にマッピングし 再び元に戻すマッピング（ラウンドトリップ・マッピング）は、他の文字への厳 格なマッピングが存在しているユニコード文字だけを使用するとき可能である。 さらに、本発明の第１から第５までの側面によれば、フォールバック・マッピ ングはユニコード文字の意味または同一性を保存していないユニコードからのマ ッピングである。つまり、これらはユニコード文字（または文字シーケンス）を その定義または用途がユニコード文字の意味または用途を含んでいないターゲッ ト文字セット内の文字（または文字シーケンス）にマッピングする。これに対し て、フォールバック・マッピングによると、ユニコード文字（または文字シーケ ンス）に最も近く対応しているターゲット・コード化内の文字（または文字シー ケンス）が得られる。 フォールバック・マッピングの例 ・ ユニコード文字ｕ０３００「結合アクサングラーブ」はフォールバック・ マッピングとしてＡＳＣＩＩｘ６０「アクサングラーブ［スペース］）に マッピングすることができる。違いは、ユニコード文字が結合マーク（非 スペース）であるのに対し、ＡＳＣＩＩ文字はスペース・マークであるこ とである。 ・ ユニコード文字ｕ０１Ｃ０「ラテン文字デンタル・クリック」はフォール バック・マッピングとしてＡＳＣＩＩｘ７Ｃ「垂直線」にマッピングする ことが可能である。 ・ ユニコード文字ｕ２００１「ＥＭ ＱＵＡＤ」はフォールバック・マッピ ングとしてＡＳＣＩＩｘ２０「スペース」にマッピングすることが可能で ある。 従って、上記の例に示すように、フォールバック・マッピングはユニコード文 字（またはシーケンス）にグラフィックが近似しているターゲット文字（または シーケンス）を生成するために使用される。 パフォーマンス上の理由により（つまり、コード化をマッピング・テーブルか ら得るときの速度）、マッピング・テーブル４１４までのインデックスにはいく つかのフォーマットがある。可能とされるフォーマットには、セグメント・フォ ーマット、リスト・フォーマット、範囲フォーマット、チェーン・フォーマット がある。文字シーケンスの長さが異なるごとに、別々のインデックスを設けるこ とが好ましい。その結果として、セグメント５０２、５０４、５０６の各々に関 連するインデックスは異なるフォーマットにすることができ、各インデックスの 先頭の情報はそのフォーマットを指定している。フォーマットに関係なく、各イ ンデックスは最終的には、入力シーケンスを直接に出力シーケンスにマッピング するか、あるいは出力シーケンスが長ければ、対応する出力シーケンスのロケー ションを指定しているオフセットにマッピングする。 マッピング・テーブル４１４までのインデックスのチェーン・フォーマットに ついては、以下で詳しく説明する。チェーン・フォーマットでは、セクションの 先頭がチェックされ、それがチェーン・フォーマット・テーブルのチェーン・ヘ ッダであるか、他のフォーマットであるかが判断される。チェーン・フォーマッ トは複数のインデックス・テーブルのチェーンを指定し、各々は異なるフォーマ ットになっている場合がある。必要とするマッピングが最初のインデックス・テ ーブルに見つからなければ、ルックアップ・ハンドラ４１２は２番目のインデッ クス・テーブルを調べ、以下同様である。チェーン・フォーマットは、例えば、 あるインデックス・フォーマット（これは空間的および／または時間的に効率的 である）が入力シーケンスのすべてではないが、大部分をマッピングすることが できるのに対し、別の非効率なインデックス・フォーマットは少数の残りのシー ケンスを処理できるときに利用すると、便利である。チェーン・メカニズムがな いと、インデックス・シーケンスのすべてに非効率のフォーマットを使用しなけ ればならないことになる。チェーン・フォーマットは変種と許容レベルが異なる たびに、異なるサブテーブルが必要になるときにも便利である。チェー ン内の各サブテーブルは、現在取り扱われているマッピング許容範囲と変種に基 づいてそれを含めるか、除外させるビット・フラグをもっている。本発明の第２ 、第３および第４側面によれば、ルックアップ・ハンドラ４１２がターゲット・ コード化のマッピング・テーブル４１４をサーチするときは、含められたサブテ ーブルだけが考慮される。 さらに、本発明の第１から第４までの側面によれば、各サブテーブルに関連す るこれらのビット・フラグはサブテーブル・マスクを形成している。また、呼び 出し側要求（例えば、コード化の変種と許容範囲）と判断された属性（例えば、 解明された方向とコンテキスト）は選択マスクを形成している。サブテーブル・ マスクと選択マスク内のビット割当ては同じである。従って、特定のサブテーブ ルを含めるかどうかの判断はサブテーブル・マスクと選択マスクのビットワイズ ＡＮＤをとり、そのあと結果をサブテーブル・マスクと比較することによって行 われる。ビットワイズＡＮＤの結果がサブテーブルのサブテーブル・マスクと同 じであれば、そのサブテーブルが含められる。そうでなければ、それは含められ ない。 マッピング・テーブル４１４のヘッダ５００は好ましくは次のものを収めてい る。 ・ 一般的識別情報−フォーマット、長さ、チェックサムおよびバージョン。 ・ 最小ターゲット文字サイズ（バイト数）（文字サイズともいう）。 ・ 一般的フラグ（例えば、そのルップアップ・テーブルが方向またはコンテ キスト・データを必要としているかどうか）。 ・ そのテーブルによって処理される最大入力シーケンス長、および１からこ の最大長までの入力シーケンス長を処理するテーブルを指定しているオフ セット／長さのペアのリスト。 ・ そのユニコードからのマッピングのデフォルト・フォールバック文字また は文字シーケンス。 ・ そのテーブルによってサポートされる変種のカウントとリスト。各変種ご とに、１つまたは２つ以上の関連ビット・マスクが指定される。単一の変 種に複数のビット・マスクがある場合は、属性情報（方向、コンテキス ト、および垂直形式の要求）はどのビット・マスクが使用されるかを判断 するために使用される。ビット・マスクで「１」にセットされたビットは 異なる変種をサポートするために種々のサブテーブルをオンにするために 使用される。 ・ 可能とされる４つの許容範囲設定値（厳格／緩和、フォールバック・オ ン／オフ）の各々に関連する追加のビット・マスクのセット。該当する許 容範囲レベル・マスクは変種マスクとＯＲがとられて、サブテーブルを使 用可能または使用禁止にするために使用されるビット・マスクを形成す る。Ｃ．コード変換処理 以下では、ユニコード・コード変換システム４００の好適実施例によって実行 される処理について詳しく説明する。 図６Ａはユニコード・コード変換システム４００を利用するアプリケーション （つまり、呼び出し側アプリケーション・プロセスまたはプログラム）によって 実行される処理６００を示すフローチャートである。具体的には、図６Ａはユニ コードからの処理に関係しているが、当然に理解されるように、類似のオペレー ションを実行して他方の方向に変換することも可能である（ユニコードへの処理 ）ユニコードからのコンバータ４０２は全体的変換プロセスを制御する。 最初に、処理６００は新しい状態インスタンスと変換のための制御情報を作成 し、初期化する（６０２）。処理６００はインスタンスを設定するので、複数の スキャン・オペレーションを進行中にし、そのインスタンスによって区別するこ とが可能である。次に、切り捨てが必要であるかどうかの判断６０４が行われる 。切り捨てが必要な場合には、トランケータ４０７が起動される（６０６）。切 り捨てが必要になるのは、入力データ・ストリームが、変換のためのデータを収 めている受入れバッファ４０５の容量を越えたときである。切り捨てが必要でな ければ、あるいは切り捨てが必要な場合には、ブロック６０６に続いて、ユニコ ードからのコンバータ４０２がコールされ（６０８）ユニコード文字列４０４を 変換する。ユニコードからのコンバータ４０２の機能は、テキスト要素を取得 し、そのためのターゲット・マッピングを調べることである。これについては、 以下で詳しく説明する。変換機能から戻ると、処理６００はユニコードからのコ ンバータ４０２からターゲット文字列４０６を受け取る。 次に、処理６００は変換が失敗したかどうかを判断する。変換が失敗していれ ば、エラーが処理される（６１４）。他方、変換が正常に行われていれば、変換 が完了したかどうかの判断６１６が行われる。ユニコード文字列４０４の文字が ターゲット・コード化に変換されたとき変換は完了する。変換が完了していれば 、処理６００は完了し、ターゲット文字列４０６はコード変換を要求したプロセ スまたはアプリケーションに利用可能にされる。さらに、処理６００は状態イン スタンスと変換のための制御情報を破棄する（６１８）。他方、変換がまだ完了 していないと判断６１６されたときは、処理６００は変換が完了するか、エラー が起こるまでブロック６０４〜６１６を繰り返す。 図６Ｂは本発明の第４側面による切り捨て処理６２０を示すフローチャートで ある。切り捨て処理６２０は図６Ａのブロック６０６で起動され、トランケータ ４０７によって実行される。 切り捨て処理６２０は出力長をゼロ（０）に初期化する（６２２）。出力長は バッファの実効長、つまり、バッファの切り捨てられた長さに一致している。次 に、次のテキスト要素が取得される（６２４）。次のテキスト要素の取得（６２ ４）に関連する処理はスキャナ４０８によって行われるが、これについては図９ Ａ〜図９Ｃを参照して以下で詳しく説明する。次に、テキスト要素がバッファの 物理的長さ（バッファ長）を越える可能性があるかどうかの判断６２６が行われ る。テキスト要素がバッファ長を越える可能性がなければ、出力長はそのテキス ト要素を含むように更新される（６２８）。ここでは、実効長はテキスト要素が バッファ長を越える可能性がない限り、テキスト要素単位で大きくなる。ブロッ ク６２８に続いて、考慮すべき追加テキストがバッファに残っているかどうかの 判断６３０が行われる。考慮すべき追加テキストがバッファに残っていれば、処 理はループしてブロック６２４に戻り、切り捨て処理６２０を繰り返す。他方、 考慮すべき追加テキストがバッファに残っていないか、あるいはテキスト要素が バッファ長を越える可能性があるとブロック６２６で判断されていれば、 出力長が戻される（６３２）。戻された出力長（６３２）はバッファの実効長（ つまり切り捨てられた長さ）であるので、バッファは実効的にテキスト要素の終 わり（つまり、バッファ内のテキストの最後のテキスト要素）で終了する。 以上のようにして、切り捨て処理はバッファの実効長（つまり、切り捨てられ た長さ）を判断する。これはバッファの切り捨てられた部分とも呼ばれる。切り 捨ての後バッファに残っている余分のテキストは残余部分と呼ばれる。残余部分 は入力ソース文字列の次のバッファ部分にキャリーオーバされ、その部分と一緒 に考慮される。この処理はテキスト要素が正しく判断されることを保証する。 以下は切り捨て処理の使い方の例である。 例：“．．．ＡＢＣＤ｀ＥＦＧ．．．” バッファに置かれている部分が“Ｄ”の直後で終わっていれば、切り捨て 処理はバッファに置かれている部分を切り捨てて、切り捨てられた長さが“Ｃ” のあとで終わるようにする。バッファに置かれた部分を切り捨てる必要があるの は、そのようにしないと、テキスト要素“Ｄ”がそのあとに置かれた結合マーク “｀”から切り離されることになるからである。切り離されると、テキストはタ ーゲット・コード化に正しく変換されないことになる。残余部分は“Ｄ｀”であ り、次の部分にキャリーオーバされ、“Ｄ｀ＥＦＧ．．”となる。 図７はユニコード・コンバータ処理７００を示すフローチャートである。ユニ コード・コンバータ処理７００は図６Ａのブロック６０８で実行されるオペレー ションと関連づけられている。 ユニコード・コンバータ処理７００は判断７０２から始まる。この判断７０２ は変換すべきテキストがあるかどうかを判断する。変換すべきテキストがなけれ ば、ユニコード・コンバータ処理７００は戻るだけである（または完了する）。 他方、変換すべきテキストがあれば（つまり、ユニコード文字列４０４が完全に 処理されていなければ）、処理７００が続けられる。まず、オフセットがオフセ ット配列に対して更新される（７０４）。オフセット配列入力文字列に関連する オフセット（ポインタ）の配列であり、フォント変更、ライン中断、言語変更 などのある種の変更が、呼び出し側アプリケーションが有意と判断している入力 文字列４０４内のどこで行われたかを示している。オフセット配列の更新７０４ は、異なる文字長に合わせてオフセット（ポインタ）を調節することにより行わ れる。例えば、入力ユニコード文字列４０４のユニコード文字は２バイト長であ るのに対し、ＡＳＣＩＩのターゲット・コード化に関連する文字のサイズは１バ イト長である。ここでは、オフセット配列の更新７０４はオフセットがターゲッ ト・コード化内の対応する文字を指すようにオフセットを更新する。実際には、 入力文字列内のオフセットはコード化が異なっている出力文字列にマッピングさ っる。次に、次のテキスト要素が取得される（７０６）。スキャナ４０８はスキ ャナ・テーブル４１０はユニコード文字列４０４からのテキスト要素を判断する 。次のテキスト要素の取得７０６は以下で詳しく説明する。次に、取得されたテ キスト要素はマッピング・テーブル４１４で調べられ（７０８）、ターゲット・ コード化内のテキスト要素の変換コードが得られる。このルックアップはマッピ ング・テーブル４１４を使用してルックアップ・ハンドラ４１２によって行われ る。変換コートのルックアップ７０８についても以下で詳しく説明する。 次に、テキスト要素の変換コードが見つかったかどうかの判断７１０が行われ る。変換コードが見つかったときは、ユニコード文字列４０４とターゲット文字 列４０６の入力位置ポインタと出力位置ポインタがそれぞれ更新される（７１２ ）。入力位置ポインタは入力文字列４０４がどれだけ変換されたかを示している 。出力位置ポインタはターゲット文字列４０６の長さを示している。ブロック７ １２に続いて、処理７００はユニコード・コンバータ処理７００の先頭に戻り、 変換すべきユニコード文字列４０４の次のテキスト要素（存在する場合）が処理 できるようにする。 しかるに、変換コードがマッピング・テーブル４１４に見つからないと判断７ １０が判断したときは、呼び出し側（例えば、呼び出し側アプリケーション）が フォールバック処理を要求していたかどうかの判断７１４が行われる。呼び出し 側がフォールバック処理を要求していれば、フォールバック処理が実行される（ ７１６）。フォールバック処理はフォールバック・ハンドラ４１６によっ て実行される。これは以下で詳しく説明する。他方、呼び出し側がフォールバッ ク処理を要求していなければ、テキスト要素がルックアップ・ハンドラ４１２に よってターゲット・コード化に変換できなかったのでエラーが通知される（７１ ８）。ブロック７１６と７１８に続いて、ユニコード文字列４０４とターゲット 文字列４０６の入力位置ポインタと出力位置ポインタがそれぞれ更新され（７０ ２）、そのあと処理はユニコード・コンバータ処理７００の先頭に戻り、変換す べきユニコード文字列４０４０の次のテキスト要素（存在する場合）が処理でき るようにする。 図８はオフセット更新処理８００を示すフローチャートである。オフセット更 新処理８００はオフセット配列が更新される図７のブロック７０４と関連してい る。 オフセット更新処理８００は現在入力位置がオフセット配列にあるかどうかを 判断８０２することから始まる。現在入力位置がオフセット配列にあれば、オフ セット配列の内容がブロック８０４に続いて現在出力位置長さに従って更新され る（８０４）、オフセット更新処理８００から戻る。他方、現在入力位置がオフ セット配列にないときは、更新すべきオフセットがないのでオフセット更新処理 ８００から戻る判断８０２が行われるだけである。 図９Ａおよび図９Ｂは本発明の第１、第２および第４側面による次のテキスト 要素処理９００を示すフローチャートである。次のテキスト要素処理９００は次 のテキスト要素を取得するとき図７のブロック７０６で実行されるオペレーショ ンを具体化したものである。好ましくは、次のテキスト要素処理９００はスキャ ナ・テーブル４１０を使用してスキャナ４０８によって行われる。 次のテキスト要素処理９００は状態と再配列フラグを初期化（９０２）するこ とから始まる。次に、マッピング・テーブル４１４が方向情報を必要としている かどうかの判断９０４が行われる。マッピング・テーブル４１４が方向情報を必 要としていれば、ユニコード文字列４０４の方向が解明される（９０６）。本発 明の第２側面では、マッピング・テーブル４１４が方向情報を必要としていれば 、ユニコード文字列４０４の次の入力文字の方向が解明される（９０６）。方向 が解明されると（９０６）、あるいは方向が必要でない場合には判断９０４の 後で、文字のコンテキストに基づく判断９０８が行われる。ユニコード文字列４ ０４内の文字のコンテキストがコード変換（マッピング）に影響する可能性があ るときは、コンテキストが解明される（９１０）。ブロック９１０に続いてまた は判断９０８に続いて、コンテキストが重要でないときは、ユニコード文字がユ ニコード文字列４０４から取得される（９１２）。ここでは、ユニコード文字列 ４０４内の次の文字が取得される。次に、取得されたユニコード文字の属性が調 べられる（９１４）。属性ルックアップ９１４は図１１〜図１３を参照して以下 で詳しく説明する。次に、次のテキスト要素処理９００のアクションが判断され る（９１６）。アクションの判断９１６は図１４Ａ、図１４Ｂおよび図１５を参 照 て以下で詳しく説明する。 次に、アクションが“ＥＮＤ”であるかどうかの判断９１８が行われる。アク ションが“ＥＮＤ”でなければ、アクションは少なくとも“ＡＤＶＡＮＣＥ”で ある。アクションが“ＡＤＶＡＮＣＥ”であるときは、アクションが“ＭＡＲＫ ”でもあるかどうかの判断９２０が行われる。アクションが“ＭＡＲＫ”でもあ るときは、文字がテキスト要素に挿入される（９２２）。さらに、“ＭＡＲＫ” アクションがとられると双方向状態がセーブされる（９２４）。双方向状態は方 向性埋め込みスタックと双方向ステート・マシンの現在状態を含んでいる。ブロ ック９２４に続いてまたはアクションが“ＭＡＲＫ”でもないときは判断ブロッ ク９２０に続いて、アクション修飾子に基づいてスイッチ・オペレーションが実 行される。アクション修飾子はアクションの一部であり、“Ｓ”、“ＩＳＳ”、 “ＡＳＳ”などの修飾子を含んでいる。アクションはどのアクション修飾子もも たないこともできる。アクション修飾子が“Ｓ”であるときは、再配列フラグが セットされる（９２８）。再配列フラグ（セットされたときは）はテキスト要素 内の文字を再配列する必要がないことを示している。アクション修飾子が“ＩＳ Ｓ”（つまり、シメトリック・スワッピング禁止）であるときは、スワップ・フ ラグがオフにセットされる（９３０）。アクション修飾子が“ＡＳＳ”（つまり 、スワッピング禁止活動化）であるときは、スワップ・フラグがオンにセットさ れる（９３２）。スワップ・フラグはシメトリック・スワッピングが必要かどう かを示している。スイッチ９２６は拡張 エリア９３４を使用して追加のアクション修飾子を含むように容易に適応させる ことができる。拡張エリア９３４を使用すると、ユーザはスキャナ４０８の振舞 を変更することができる。また、アクション修飾子がなければ、次のテキスト要 素処理９００はアクション修飾子に関連するどのオペレーションも実行しない。 アクション修飾子オペレーションに続いて、現在文字インデックスが更新される （９３６）。現在文字インデックスは次のテキスト要素処理９００を実行すると きソース文字列をスキャンしていくために使用されるソース文字列を指すポイン タである。次に、次のテキスト要素処理９００はブロック９０４から始まるオペ レーションを繰り返す。処理はアクションが“ＥＮＤ”であると判断９１８が判 断するまでループしてブロック９０４−９３６を繰り返す。アクションが“ＥＮ Ｄ”であると、判断９１８は判断ブロック９３８を実行させる。判断ブロック９ ３８は再配列フラグがセットされているかどうかを判断する。再配列フラグがセ ットされていれば（ブロック９２８）、テキスト要素内の文字は再配列される（ ９４０）。再配列は異種の文字クラスの加重値を提供する優先順位属性を使用し て行うことが好ましい。再配列フラグがセットされていない場合にはブロック９ ３８に続いて、再配列フラグがセットされている場合にはブロック９４０に続い て、次のテキスト要素処理９００は完了し、ユニコード・コンバータ処理７００ に戻る。 図１０Ａ、図１０Ｂおよび図１０Ｃは本発明の第３側面による次のテキスト要 素処理９００を示すフローチャートである。次のテキスト要素処理９００は次の テキスト要素を取得するとき図７のブロック７０６によって実行されるオペレー ションを具体化したものである。好ましくは、次のテキスト要素処理９００はス キャナ・テーブル４１０を使用してスキャナ４０８によって実行される。 次のテキスト要素処理９００は状態と再配列フラグを初期化（９５２）するこ とから始まる。次に、マッピング・テーブル４１４が方向情報を必要としている かどうかの判断９５４が行われる。マッピング・テーブル４１４が方向情報を必 要としていれば、ユニコード文字列４０４の次の入力文字の方向が解明される（ ９５６）。次に、ユニコード文字がユニコード文字列４１４から取得される（９ ５８）。ここでは、ユニコード文字列４０４内の次の文字が取得される （９５８）。次に、取得されたユニコード文字の属性が調べられる（９６０）。 属性ルックアップ９６０は図１１〜図１３を参照して以下で詳しく説明する。次 に、次のテキスト要素処理９００のアクションと次の状態が判断される（９６２ ）。アクションと次の状態の判断は図１４Ａ、図１４Ｂ、図１６Ａおよび図１６ Ｂを参照して以下で詳しく説明する。 次に、アクションが“ＥＮＤ”であるかどうかの判断９６４が行われる。アク ションが“ＥＮＤ”でなければ、アクションは少なくとも“ＡＤＶＡＮＣＥ”で ある。アクションが“ＡＤＶＡＮＣＥ”であるときは、アクションが“ＭＡＲＫ ”でもあるかどうかの判断９６６が行われる。アクションが“ＭＡＲＫ”でもあ るときは、文字がテキスト要素に挿入される（９６８）。さらに、“ＭＡＲＫ” アクションがとられると双方向状態がセーブされる（９７０）。双方向状態は方 向性埋め込みスタックと双方向ステート・マシンの現在状態を含んでいる。ブロ ック９７０に続いてまたはアクションが“ＭＡＲＫ”でもないときは判断ブロッ ク９６６に続いて、アクション修飾子に基づいてスイッチ・オペレーション９７ ２が実行される。アクション修飾子はアクションの一部であり、“Ｓ”、“ＩＳ Ｓ”、“ＡＳＳ”などの修飾子を含んでいる。アクションはどのアクション修飾 子ももたないこともできる。アクション修飾子が“Ｓ”であるときは、再配列フ ラグがセットされる（９７４）。再配列フラグ（セットされたときは）はテキス ト要素内の文字を再配列する必要がないことを示している。アクション修飾子が ”ＩＳＳ”（つまり、シメトリック・スワッピング禁止）であるときは、スワッ プ・フラグがオフにセットされる（９７６）。アクション修飾子が”ＡＳＳ”（ つまり、スワッピング禁止活動化）であるときは、スワップ・フラグがオンにセ ットされる（９８０）。スワップ・フラグはシメトリック・スワッピングが必要 かどうかを示している。スイッチ９７２は拡張エリア９８０を使用して追加のア クション修飾子を含むように容易に適応させることができる。拡張エリア９８０ を使用すると、ユーザはスキャナ４０８の振舞を変更することができる。また、 アクション修飾子がなければ、次のテキスト要素処理９００はアクション修飾子 に関連するどのオペレーションも実行しない。アクション修飾子オペレーション に続いて、現在文字インデッ クスが更新される（９８２）。現在文字インデックスは次のテキスト要素処理９ ００を実行するときソース文字列をスキャンしていくために使用されるソース文 字列を指すポインタである。次に、次のテキスト要素処理９００はブロック９５ ４から始まるオペレーションを繰り替えす。処理はアクションが“ＥＮＤ”であ ると判断９６４が判断するまでループしてブロック９５４〜９８２を繰り返す。 アクションが“ＥＮＤ”であると、判断９６４はコンテキスト処理９８４を実行 させる。コンテキスト処理９８４のあと、判断ブロック９８６は再配列フラグが セットされているかどうかを判断する。再配列フラグがセットされていれば（ブ ロック９７４を参照）、テキスト要素内の文字は再配列される（９８８）。再配 列は異種の文字クラスの加重値を提供する優先順位属性を使用して行うことが好 ましい。再配列フラグがセットされていない場合にはブロック９８６に続いて、 再配列フラグがセットされている場合にはブロック９８８に続いて、次のテキス ト要素処理９００は完了し、ユニコード・コンバータ処理７００に戻る。 次に、図９Ｃを参照してコンテキスト処理９８４について説明する。コンテキ スト処理９８４はここで説明している実施例では、スキャナ・テーブル４１０を 使用するスキャナ４０８によって実現されている。コンテキスト処理９８４は判 断９８５から始まり、アクションがＥｎｄＯｕｔｐｕｔＸｎ（つまり、単独コン テキスト）であるかどうかが判断される。そうであれば、コンテキスト・マスク がセットされ（９８６）、コンテキストが単独であることを示し、コンテキスト 処理９８４は完了し、戻る。他方、アクションがＥｎｄＯｕｔｐｕｔＸｎでなけ れば、アクションがＥｎｄＯｕｔｐｕｔＸｌ（つまり、初期コンテキスト）であ るかどうかが判断９８７で判断される。そうであれば、コンテキスト・マスクが セットされ（９８８）、コンテキストが初期であることを示し、コンテキスト処 理９８４は完了し、戻る。他方、アクションがＥｎｄＯｕｔｐｕｔＸｌでなけれ ば、アクションがＥｎｄＯｕｔｐｕｔＸｒ（つまり、終了コンテキスト）である かどうかが判断９８９される。そうであれば、コンテキスト・マスクがセットさ れ（９９０）、コンテキストが初期であることを示し、コンテキスト処理９８４ は完了し、戻る。他方、アクションがＥｎｄＯｕｔｐｕｔＸｒでなければ、アク ションがｅｎｄＯｕｔｐｕｔＸｍ（つまり、中間コンテキスト）であるかどうか の判断９９１が行われる。そうであれば、コンテキスト・マスクがセットされ（ ９９２）、コンテキストが初期であることを示し、コンテキスト処理９８４は完 了し、戻る。アクションがＥｎｄＯｕｔｐｕｔＸｍでないと判断９９１されたと きは、テキスト要素は関連するコンテキストをもっていないので、コンテキスト ・マストは「無視」にセットされる（９９３）。 以上のように、コンテキスト処理９８４は上記実施例では、テキスト要素とコ ンテキストが一緒に判断されるように実現されている。どちらの判断も、スキャ ナ４０８とスキャナ・テーブル４１０によって先読みスキャンニングを利用して テキスト要素が完成し、入力テキスト・ストリーム内のテキスト要素の内容が分 かるようにしている。コンテキスト・マスクに入っているコンテキスト情報は、 マッピング・テーブル４１４とやりとりして、判断されたコンテキストをもつテ キスト要素の正しいターゲット・コード化を探すときにルックアップ・ハンドラ ４１２によって使用される。コンテキスト処理のオペレーションの詳細は図１６ Ａと図１６Ｂを参照して以下で説明する。 図１１はスキャナ４０８を示すブロック図である。特に、スキャナ４０８は属 性ハンドラ１０００とテキスト要素ハンドラ１００２を含んでいる。テキスト要 素ハンドラ１００２は図９Ａと図９Ｂおよび図１０Ａ〜図１０Ｃを参照して上述 した次のテキスト要素処理９００を実行する。属性ハンドラ１０００は属性テー ブル１００４とやりとりして、次のテキスト要素処理９００が必要とするユニコ ード文字の属性を取得する（図９Ａのブロック９１４と図１０Ａのブロック９６ ０を参照）。属性には次のものがある。つまり、方向、クラス、優先順位、シメ トリック・スワッピング、サブセットおよびコンテキストである。方向属性は方 向を解明するとき使用される（図９Ａのブロック９１４および図１０Ａと図１７ Ａのブロック９５６を参照。クラス属性はアクション（例えば、ＡＤＶＡＮＣＥ 、ＥＮＤ）を判断するためにスキャナ４０８によって使用される。優先順位属性 はテキスト要素内の文字を記録するために使用される（図９Ｂのブロック９４０ と図１０Ａのブロック９８８を参照）。シメトリック・スワッピング属性はシメ トリック・スワッピングが必要であるかどうかを判断するために使用される。コ ンテキスト属性はコンテキストを解明するときに使用される （図９Ａのブロック９１０を参照）。 図１２は図１１の属性テーブル１００４の好ましいフォーマットを示す概略図 である。属性テーブル１００４はヘッダ部分１１００、範囲テーブル部分１１０ ２、および属性テーブル部分１１０４を含んでいる。ヘッダ部分１１００は次の ものに関する情報を含んでいる。つまり、各テーブルの総テーブル・サイズ、チ ェックサム値、バージョン、オフセットおよび要素の数である。範囲テーブル部 分１１０２内の要素は属性が共通にグループ化されている範囲を示し、各グルー プごとに、属性テーブル部分１１０４の該当部分を指すポインタをもっている。 属性テーブル１００４の範囲テーブル部分１１０２のフォーマットは、例えば、 各エントリごとに、範囲値の開始、範囲値の終了、および範囲に関連するデータ ・ワードを含んでいる。属性テーブル１００４の構成は属性情報のコンパクトな ストアを容易にしている。別のストア構成も可能であるが、データ・ストアのコ ンパクトさから見たとき非効率的である。 図１３は属性ルップアップ処理１２００を示すフローチャートである。属性ル ックアップ処理１２００は属性ハンドラ１０００によって実行され、図９Ａのブ ロック９１４または図１０Ａのブロック９６０で次のテキスト要素処理９００に よって開始される。 属性ルックアップ処理１２００は属性テーブル１００４の範囲テーブル部分１ １０２内の範囲を使用してバイナリ・サーチから開始される。該当の範囲がバイ ナリ・サーチで見つかると、その範囲に関連するデータ・ワードが範囲テーブル 部分１１０２から取得される（１２０４）。好ましくは、データ・ワードの最初 のビットは間接ビットである。次に、データ・ワードの間接ビットがセットされ ているかどうかの判断１２０６が行われる。データ・ワードの間接ビットがセッ トされていない場合は、データ・ワード自体は現在の文字の属性を収めているの で、データ・ワードは属性として戻される（１２０８）。他方、データ・ワード の間接ビットがセットされていれば、属性は、範囲テーブル部分１１０２から取 得されたデータ・ワードを属性テーブル部分１１０４までのインデックスまたは オフセットとして使用して属性テーブル部分１１０４から取得される。従って、 この場合のデータ・ワードは範囲内の各文字の属性を収めている配列ま でのインデックスまたはオフセットである。ブロック１２０８または１２１０に 続いて、属性ルックアップ処理１２００は完了し、戻る。 図１４Ａと図１４Ｂは次のアクションを判断するためにスキャナ４０８によっ て使用されるスキャナ・テーブル１３００（４１０）に関連する概略図である。 次のアクションの判断は次のテキスト要素処理９００（図９Ａ）のブロック９１ ６によって起動されるか、ブロック９６２（図１０Ａ）によって起動される。図 １４Ａは本発明で使用されるスキャナ・テーブル１３００の好ましいフォーマッ トを示す図である。スキャナ・テーブル１３００は「現在状態」を１つのインデ ックスとして、「クラス」を別のインデックスとしてもつ２次元配列である。「 クラス」はクラス属性を指している。これらのインデックスはスキャナ・テーブ ル１３００内の代表的な要素１３０２を選択する。図１４Ｂはスキャナ・テーブ ル１３００の代用的な要素１３０２を示す図である。代表的な要素１３０２はス キャナ４０８の次の状態を収めている次の状態部分１３０４を含み、アクション 部分１３０６はスキャナ４０８のアクションを示している。実際には、スキャナ ４０８はスキャナ・テーブル１３００と一緒になって、スキャナをどのように動 作させるかを判断するステート・マシンを実現している。 スキャナ・テーブル１３００は異種の文字コード化に関する異なる次の状態と アクションを収めている。 本発明の第１、第２および第４側面によれば、図１５は好ましいレイアウトと スキャナ・テーブル１３００にストアされる情報の両方を示しているテーブル１ ４００である。このテーブルに関連する表記は次の通りである。 文字クラス： ＣＣ −制御文字 ＯＳ −他のスペース ＮＳ −非スペース ＬＤ −ラテン・ディジット ＦＳ −フラクション・スラッシュ ＪＬ（ｆ）−ジャモス先頭子音（フィラー） ＪＶ（ｆ）−ジャモス母音（フィラー） ＪＴ −ジャモス・トレーラ ＮＵ −有効なユニコード文字でない ＩＳＳ −シメトリック・スワッピング禁止 ＡＳＳ −シメトリック・スワッピング活動化 次の状態： 状態０ −終了。テキスト要素を戻すべきかどうかを、２重および半分音符号 の状態に基づいて判断する。 状態１ −開始状態 状態２ −非スペース（分音符号）の追加 状態３ −数値フラクションの有無チェック 状態７ −朝鮮語ジャモス アクション： Ａｄｖ −［ＡＤＶＡＮＣＥ］次の文字へ進む（現在文字は現在テ キスト要素（ＴＥ）に含まれている場合と含まれていな い場合がある） ＡｄｖＭａｒｋ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ］現在文字に最終文字の マークを付け次の文字へ進む ＡｄｖＭａｒｋＳ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ＋Ｓ］現在文字に最終文字 のマークを付け次の文字へ進み、再配列フラグをセット する ＡｄｖＭａｒｋＡＳＳ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ＋ＡＳＳ］現在文字に 最終文字のマークを付け次の文字へ進み、シメトリッ ク・マッピングを活動化する ＡｄｖＭａｒｋＩＳＳ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ＋ＩＳＳ］現在文字に 最終文字のマークを付け次の文字へ進み、シメトリッ ク・マッピングを禁止する Ｅｎｄ −テキスト要素を最終のマークを付けた文字で終了する 注意：すべての機能は再配列フラグがセットされているかをチェックして確かめ 、非スペース文字を開始ポインタから始めて再配列する。再配列する必要のある 非スペース・マークのセットは複数存在することがあるので、文字列全体をチェ ックするのが最良の方法である。もちろん、文字を再配列すると、再配列フラグ はクリアされる。 本発明の第３側面によれば、図１６Ａと図１６Ｂは好ましいレイアウトと情報 の両方を示すテーブル１４００であり、情報はソース文字列内のテキスト要素と そのコンテキストの両方の判断を容易にするためにスキャナ・テーブル４１０に ストアされるものである。このテーブルに関連する表記は次のとおりである。 文字クラス： ＣＣ −制御文字 ＯＳ −他のスペース ＮＳ −非スペース ＬＤ −ラテン・ディジット ＦＳ −フラクション・スラッシュ ＤＤ −二重分音符号 ＨＤ −半分音符号 ＣＨ −ジャモス先頭子音（フィラー） ＪＯ −ジャモス母音（フィラー） ＪＶ −ジャモス子音トレーラ ＮＵ −有効なユニコード文字でない ＩＳＳ −シメトリック・マッピング禁止 ＡＳＳ −シメトリック・マッピング活動化 ＨＨ −高ハーフゾーン ＬＨ −低ハーフゾーン Ｖ −Ｖｉｒａｍａ ＺＷＮＪ −ゼロ幅の非ジョインダ Ｒ −右リンク Ｄ −２重リンク Ｃ −リンクを引き起こす Ｔ −透過 次の状態： 状態０ −終了。テキスト要素を戻すべきかどうかを２重分音符号と半分音 符号に基づいて判断する 状態１ −開始状態 状態２ −非スペース（分音符号）追加 状態３ −ラテン・ディジット 状態４ −ラテン・ディジット・シーケンス 状態５ −ラテン・ディジット・シーケンスとそのあとに続くフラクション ・スラッシュ 状態６ −ラテン・ディジット・シーケンス、フラクション・スラッシュ、 ラテン・ディジット・シーケンス 状態７ −Ｃｈｏｓｅｏｎｇシーケンス 状態８ −Ｃｈｏｓｅｏｎｇシーケンスとそのあとに続く Ｊｕｎｇｓｅｏｎｇシーケンス 状態９ −Ｃｈｏｓｅｏｎｇシーケンス、Ｊｕｎｇｓｅｏｎｇシーケンス、 Ｊｏｎｇｓｅｏｎｇ 状態１０ −高半文字 状態１１ −高半文字とそのあとに続く低半文字 状態１２ −Ｖｉｒａｍａとそのあとに続くゼロ幅ジョインダまたはゼロ幅非 ジョインダ 状態１３ −コンテキストの特殊開始 状態１４ −右リンク文字（特殊コンテキスト状態） 状態１５ −２重リンク文字（特殊コンテキスト状態） 状態１６ −リンクを引き起こす文字（通常または特殊状態） 状態１７ −右リンク文字（通常状態） 状態１８ −２重リンク文字（通常状態） 次の開始状態：［実際は次の状態のサブセット］ 開始１ −開始状態 開始１３ −コンテキストの特殊開始状態 アクション： Ａｄｖ −［ＡＤＶＡＮＣＥ］次の文字へ進む（現在文字は現在テ キスト要素（ＴＥ）に含まれている場合と含まれていな い場合がある） ＡｄｖＭａｒｋ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ］現在文字に最終文字の マークを付け次の文字へ進む ＡｄｖＭａｒｋＳ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ＋Ｓ］現在文字に最終文字 のマークを付け次の文字へ進み、再配列フラグをセット する ＡｄｖＭａｒｋＡＳＳ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ＋ＡＳＳ］現在文字に 最終文字のマークを付け次の文字へ進み、シメトリッ ク・マッピングを活動化する ＡｄｖＭａｒｋＩＳＳ −［ＡＤＶＡＮＣＥ＋ＭＡＲＫ＋ＩＳＳ］現在文字に 最終文字のマークを付け次の文字へ進み、シメトリッ ク・マッピングを禁止する Ｅｎｄ −テキスト要素を最終のマークを付けた文字で終了する ＥｎｄＯｕｔｐｕｔＸｎ −［ＥＮＤ＋単独コンテキスト］テキスト要素を終 了し、単独コンテキストであることを示す ＥｎｄＯｕｔｐｕｔＸｌ −［ＥＮＤ＋初期コンテキスト］テキスト要素を終 了し、初期コンテキストであることを示す ＥｎｄＯｕｔｐｕｔＸｒ −［ＥＮＤ＋終了コンテキスト］テキスト要素を終 了し、終了コンテキストであることを示す ＥｎｄＯｕｔｐｕｔＸｍ −［ＥＮＤ＋中間コンテキスト］テキスト要素を終 了し、中間コンテキストであることを示す 注意：すべての機能は再配列フラグがセットされているかをチェックして確かめ 、非スペース文字を開始ポインタから始めて再配列する。再配列する必要のある 非スペース・マークのセットは複数存在することがあるので、文字列全体をチェ ックするのが最良の方法である。もちろん、文字を再配列すると、再配列フラグ はクリアされる。 以下では、スキャナ・テーブル１４００の使用例を３つ示して説明する。最初 の２つの例は本発明の第１、第２、第３および第４側面に関係し、最後の例は第 ３側面に関係するものである。 例１：入力文字列“ＡＡＢ” 文字クラスは３文字ともＯＳである。最初の文字“Ａ”が取得される。開始 状態（状態１）から始まり、最初のアクションはＡｄｖＭａｒｋ、次の状態は状 態２である。これにより、最初の文字“Ａ”が現在テキスト要素内に挿入され、 次の文字（２番目の文字“Ａ”）が取得される。次に、状態２では、アクション はＥｎｄ、次の状態は状態０である。従って、テキスト要素は最初のテキスト要 素だけを含んでいる。同じシーケンスはこの特定入力文字列の２番目と３番目の 文字について繰り返される。このようにして、入力 文字列の文字の各々は分離しているが、隣接しているテキスト要素に割り当てら れる。 例２：入力文字列“Ａ｀Ｂ” 文字クラスは入力文字列の最初と最後の文字ではＯＳである。２番目の文字 の文字クラスがＮＳであるのは、これが結合マークであるためである。最初の文 字“Ａ”が取得される。開始状態（状態１）から始まり、最初のアクションはＡ ｄｖＭａｒｋ、次の状態は状態２である。これにより、最初の文字“Ａ”が現在 テキスト要素内に挿入され、次の文字（２番目の文字“｀”）が取得される。次 に、状態２では、アクションはＡｄｖＭａｒｋＳ、次の状態は状態２である。こ れにより、２番目の文字“｀”が現在テキスト要素に挿入される。次に、３番目 の文字が取得される。この時点の状態２のアクションはＥｎｄ、次の状態は状態 ０である。従って、テキスト要素は入力文字列の１番目と２番目の文字を含んで いる。３番目の文字は例１の場合と同じように、自身のテキスト要素に置かれる 。 例３：入力文字列“ＯＳ Ｒ Ｄ ＯＳ ＯＳ”［文字間にスペースがなく、各 文字はその文字クラスで表されている。ＲとＤ文字クラスはコンテキスト・ベー スの表示形態をもつ文字を含んでいるが、ＯＳ文字クラスは含んでいない。］ 最初の文字は文字クラスＯＳである。開始状態（状態１）から始まり、最初 のアクションはＡｄｖＭａｒｋ、次の状態は２、次の開始状態は１である。これ により、最初の文字が現在テキスト要素に挿入され、２番目の文字が取得される 。２番目の文字は文字クラスＲである。次に、状態２では、アクションはＥｎｄ 、次の状態は０、次の開始状態は１である。従って、最初のテキスト要素は最初 の文字だけを含み、コンテキスト・フラグは無視にセットされる。 次のテキスト要素を判断するときは、処理は２番目の文字から始まり、新し い開始状態は１になっている。この時点で、スキャナ・テーブルから得ら れるアクションはＡｄｖＭａｒｋであり、次の状態は１７、次の開始状態は１３ である。これにより、２番目の文字が現在テキスト要素に挿入され、３番目の文 字が取得される。３番目の文字は文字クラスＲである。次に、状態１７では、ア クションはＥｎｄＯｕｔｐｕｔＸｎ、次の状態は０、次の開始状態は１である。 従って、２番目のテキスト要素は２番目の文字だけを含み、コンテキストはＸｎ （単独）である。 次のテキスト要素を判断するときは、処理は３番目の文字から始まり、新し い開始状態は１３になっている。この新しい開始状態は最後の文字についてテー ブルで示された次の開始状態である。ここでは、スキャナ・テーブルから得られ るアクションはＡｄｖＭａｒｋであり、次の状態は１５、次の開始状態は１３で ある。３番目の文字は現在テキスト要素の一部であるので、４番目の文字が取得 される。４番目の文字は文字クラスＯＳである。次に、状態１５では、アクショ ンはＥｎｄＯｕｔｐｕｔＸｒ、次の状態は０、次の開始状態は１である。従って 、３番目のテキスト要素は３番目の文字だけを含み、コンテキストはＸｒ（終了 ）である。 次のテキスト要素を判断するときは、処理は４番目の文字から始まり、新し い開始状態は１３になっている。スキャナ・テーブルから得られるアクションは ＡｄｖＭａｒｋであり、次の状態は２、次の開始状態は１である。これにより、 ４番目の文字が現在テキスト要素に挿入され、５番目の文字が取得される。５番 目の文字は文字クラスＯＳである。次に、状態２では、アクションはＥｎｄ、次 の状態は０、次の開始状態は１である。従って、４番目のテキスト要素は４番目 の文字だけを含み、コンテキスト・フラグは無視にセットされる。 図１７Ａは本発明の第２側面による方向解明処理１５００を示すフローチャー トである。方向解明処理１５００は次のテキスト要素処理９００（図９Ａ）内の ブロック９０６で実行される処理である。方向解明処理１５００は、スキャナ４ ０８のために解明された方向の状態が初期状態にあるかどうかを判断する判断１ ５０２から開始される。初期状態では、スキャナ４０８はテキスト要 素内の文字の方向を知らない。スキャナ４０８のために解明された方向の状態が 初期状態にあれば、入力文字列の初期方向が判断される（１５０４）。初期状態 １５０４の判断１５０４に関連する処理は図１８を参照して以下で詳しく説明す る。他方、スキャナ４０８のために解明された方向の状態が初期状態にな説とき は、初期方向を判断する必要はない。どちらの場合も、ブロック１５０２または ブロック１５０４に続いて、ユニコード文字が入力ストリームから取得される（ １５０６）。次に、ユニコード文字に関連する属性が調べられる（１５０８）。 方向属性は方向解明処理１５００を行うとき重要な属性である。方向解明処理１ ５００のブロック１５０６と１５０８が実行するオペレーションは次のテキスト 要素処理９００のブロック９１２と９１４のそれと同じであるので、これ以上詳 しく説明することは省略する。 次に、方向、次の状態およびアクションが判断される（１５１０）。方向、次 の状態およびアクションは方向属性と現在状態を使用して判断され、テーブル属 性ルップアップ・プロセスを使用して方向テーブルから取得される。方向テーブ ルは方向属性と現在状態によってインデックスされる２次元配列である。インデ ックスが指している方向テーブル内の要素は文字の方向、次の状態、および方向 解明処理１５００がとるべきアクションを含んでいる。方向は次のものの１つで ある。すなわち、左、右、グローバル、およびＮＯ＿ＯＵＴＰＵＴである。取り 得るアクションは、ＮＯ＿ＡＣＴＩＯＮ、ＰＵＳＨ ＲＯ、ＰＵＳＨ ＲＥ、Ｐ ＵＳＨ ＬＥ、ＰＵＳＨ ＬＯ、ＰＯＰ、およびＲＥＳＥＴである。方向は明示 的オーバライド文字により入力文字列の中で変化することがあるので、以前の方 向は方向スタック上にストアされている。従って、「プッシュ」および「ポップ 」の使用はこの分野で周知であるスタック操作コマンドを意味する。“ＲＯ”は 右から左へのオーバライドを意味し、“ＬＯ”は左から右へのオーバライドを意 味し、“ＲＥ”は右から左への埋め込みを意味し、“ＬＥ”は左から右への埋め 込みを意味する。好ましくは、方向テーブルと方向解明処理１５００はステート ・マシンとして動作する。ステート・マシンは基本的にユニコード標準バージョ ン１．０ ６１１−６２１ページ（付録Ａ）に記載されている双方向アルゴリズ ムに従って動作するが、１回のパスだけで結果が得られるのに対し、ユニ コード標準に記載されているアルゴリズムは複数のパスを必要とする。 図１７Ｂ〜図１７Ｄは本発明の第２側面による双方向アルゴリズムの好ましい インプリメンテーションによる双方向状態テーブル１５１１を示している。双方 向状態テーブル１５１１はテーブル駆動型ステート・マシンを実現している。各 カラムは単一状態である。状態はそこに記録される情報を示唆する名前が付けら れている。各行は図１７Ｂ〜図１７Ｄにまたがっており、以下に示す文字クラス 名の１つが付けられている。 ＬＲ 左から右へが主流 ＲＬ 右から左へが主流 ＡＬ アラビア文字（右から左へが主流） ＬＲＥ 左から右への埋め込みマーク ＲＬＥ 右から左への埋め込みマーク ＬＲＯ 左から右へのオーバライド・マーク ＲＬＯ 右から左へのオーバライド・マーク ＰＤＦ ポップ方向フォーマット・マーク ＡＮ アラビア数字 ＥＮ ヨーロッパ数字 ＥＴ ヨーロッパ数字ターミネータ ＥＳ ヨーロッパ数字セパレータ ＣＳ 共通数字セパレータ ＯＮ その他の中立文字 ＢＳ ブロック・セパレータ 双方向状態テーブル１５１１の各セルは関連のアクションと出力を持つ遷移を表 している。これらのセルは新しい状態の名前、とられるオプションのアクション 、および出力（もしあれば）を収めている。新しい状態は現在のグローバル方向 に左右される場合がある。これは新しい状態名に（Ｇ）を入れることで示される 。グローバル方向が未知のときこれらの遷移の１つを行うとエラーになる。取り 得るアクションは次のとおりである。 プッシュ 新しい埋め込み状態を埋め込みスタック上にプッシュする。プッ シュされる実際の値は現れた実際の埋め込み制御によって決ま る。このインプリメンテーションでは、これを処理するアクショ ン動詞は４つある。 ポップ 現在の埋め込み状態をスタックからポップし、スタックの新しい トップを現在の埋め込み状態にする。新しい埋め込みがオーバラ イドであれば、セルに入っているターゲット状態にではなくＯＲ 状態に遷移が行われる。 リセット 埋め込み状態をクリアし、文字を消費することなくＳＴＡＲＴに 移る。すなわち、エプシロン遷移を行う。リセットには出力はな い。 エラー 即時エラーを引き起こす。 出力はそれぞれ左から右へと右から左へを意味するＬまたはＲのどちらか、現在 のグローバル方法の出力を意味するＧ、または出力なしを意味する＊である。マ シンには、小文字の‘ｓ’で始まらない名前を持つ状態で入ることができる。Ｓ ＴＡＲＴ状態は新しいテキスト・ブロックを目的としている。ｓＤＩＲ状態はグ ローバル方向を判断するときのエントリ・ポイントとして使用される。この計算 はメイン・スキャンと同時に行うことが可能であるが、別々にすると単純化され る。 図１５Ａに戻って説明すると、ブロック５１０に続いて、アクションが“ＲＥ ＳＥＴ”であるかどうかの判断１５１２が行われる。アクションが“ＲＥＳＥＴ ”であれば、処理は方向解明処理１５００の先頭に戻る。そうでなければ、方向 解明処理１５００が続行される。つまり、判断１５１２に続いて、アクションが 実行される（１５１４）。 次に、方向（ブロック１５１０で判断されたもの）が“ＮＯ＿ＯＵＴＰＵＴ” であるかどうかの判断１５１６が行われる。方向が“ＮＯ＿ＯＵＴＰＵＴ”に等 しくなければ、方向がコンテキスト（各インスタンスごとに）にセットされ（１ ５１８）、状態が保存される（１５２０）。ブロック１５２０に続いて、方 向解明処理１５００は完了し、戻る。 しかるに、出力が“ＮＯ＿ＯＵＴＰＵＴ”であると判断１５１６で判断された ときは、入力文字列全体が処理されたかどうかの判断１５２２が行われる。入力 文字列全体が処理されていなければ、処理は方向解明処理１５００の先頭に戻り 追加のユニコード文字を取得し、処理できるようにするが、これはテキスト要素 の方向がまだ判断されていないためである。他方、入力文字列全体が処理された と判断１５２２されたときは、処理がテキストの終わりまで達したかどうかが判 断１５２４される。つまり、ターゲット・コード化に変換すべきテキストが方向 解明処理１５００によって完全に処理されたかどうかが判断される。変換すべき 追加テキストがあれば、入力文字列の現在の文字では方向が計算できなかったの でエラーになる（１５２８）。しかし、追加テキストがなければ、ブロック・セ パレータの方向がブロックの全体方向から判断される（１５２６）（１５０４を 参照）。ブロック１５２６に続いて、ブロック１５１８と１５２０が前述したよ うに実行され、そのあと方向解明処理１５００は完了し、戻る。 図１８は本発明の第２側面による初期方向判断処理１６００を示すフローチャ ートである。初期方向判断処理１６００は図１７Ａのブロック１５０４で実行さ れるオペレーションと関連している。 初期方向判断処理１６００は制御フラグに基づくスイッチ・オペレーションか ら開始される。制御フラグは次の１つを示している。すなわち、ＮＯ＿ＯＵＴＰ ＵＴ、Ｌ−ｔｏ−ＲまたはＲ−ｔｏ−Ｌである。これらの制御フラグはユニコー ド・コード変換システム４００を起動するアプリケーションによってセットされ る（つまり、制御フラグはコンバータへの入力である）。制御フラグがＲ−ｔｏ −Ｌを示しているときは、グローバル方向はＲ−ｔｏ−Ｌにセットされる（１６ ０４）。制御フラグがＬ−ｔｏ−Ｒにセットされているときは、グローバル方向 はＬ−ｔｏ−Ｒにセットされる（１６０６）。制御フラグがＮＯ＿ＯＵＴＰＵＴ にセットされているときは、スモール・ループが開始され、方向が判断できるま で入力文字列のユニコード文字をスキャンしていく。ループは状態を“ＳＴＡＲ Ｔ ＳＴＡＴＥ”にセット（１６０８）することから開始される。次に、ユニコ ード文字が入力文字列から取得される（１６１０）。ユニ コード文字の属性が次に調べられる（１６１２）。属性は図９Ａのブロック９１ ４で使用され、図１２に詳しく説明されているものと同じ方法を用いて調べられ る（１６１２）。次にユニコード文字の方向が属性（つまり、方向属性）を使用 して判断される（１６１４）。方向が“ＮＯ＿ＯＵＴＰＵＴ”に等しいかどうか がの判断１６１６が行われる。方向が“ＮＯ＿ＯＵＴＰＵＴ”であれば、入力文 字列の終わりまで達したかどうかの判断１６１８が行われる。入力文字列の終わ りまで達していなければ、処理は戻り、ブロック１６１０〜１６１８を繰り返す 。文字列の終わりまで達していると、判断１６１８は方向を見つけることなく特 殊方向スキャニング・ループを終わらせる（例えば、ＮＯ＿ＯＵＴＰＵＴ）。そ うでなければ、スキャニング・ループは判断１６１６が方向を判断したとき終了 する。 いずれの場合も、スイッチ・オペレーション１６０２に関連する方向処理に続 いて、スイッチ・オペレーション１６２０は判断に基づいて起動される。判断さ れた方向が２ＮＯ＿ＯＵＴＰＵＴ”であるときは、現在レベルは埋め込みボトム にセットされる（１６２２）。他方、方向がＬ−ｔｏ−Ｒであれば、現在レベル はゼロにセットされ、前のレベルはボトムにセットされ、オーバライド状況は中 立にセットされる（１６２４）。方向がＲ−ｔｏ−Ｌであるときは、現在レベル は１にセットされ、前のレベルはボトムにセットされ、オーバライド状況は中立 にセットされる（１６２６）。レベルとは、ユニコード標準に記載されている埋 め込みレベルのことである。初期方向判断処理１６００の特殊方向スキャニング ・ループ（例えば、１６１０〜１６１８）は図１８に別ループとして示されてい るが、総システム処理効率は特殊方向スキャニング・ループをメイン方向スキャ ニング・ループ内に組み入れると向上することができる。 図１９はテキスト要素ルックアップ処理１６３０を示すフローチャートである 。テキスト要素ルックアップ処理１６３０はルックアップ・ハンドラ４１２によ って実行され、ユニコード・コンバータ処理７００（図７）内のブロック７０８ によって起動される。 テキスト要素ルックアップ処理１６３０は変種リストをサーチし、実際の属性 と要求された変種に一致するエントリを見つけることから開始される。変種の サーチ１６３２は図２４を参照して以下で詳しく説明する。次に、一致するもの が見つかったかどうかの判断１６３４が行われる。一致するものが見つからなけ れば、エラーになる（１６３６）。他方、一致するものが見つかれば、対応する ビット・マスクが変種リストから取得される（１６３８）。好ましくは、変種リ ストは３つのフィールド、つまり、変種識別子、属性のセット、およびビット・ マスクをもっている。変種リスト内の変種識別子と属性セットが実際の属性およ び要求された変種と一致していれば、対応するビット・マスクが変種リストから 選択される。ブロック１６３８に続いて、ビット・マスクは許容範囲ビット・マ スクと結合され（１６４０）選択フラグが得られる。選択フラグは上述したよう にマッピング・テーブル４１４のサブテーブルを選択するとき使用される選択マ スクを形成する。好ましくは、本発明の第２側面では、結合１６４０はビットワ イズ・オペレーションである。好ましくは、本発明の第１、第３および第４側面 では、結合１６４０はビットワイズＯＲオペレーションである。次に、現在テキ スト要素の長さのためのテーブルがマッピング・テーブル４１４内にあるかどう かの判断１６４２が行われる。なければ、エラーになる（１６４４）。他方、現 在テキスト要素の長さのためにテーブルがあれば、ルックアップ・テーブルとそ のフォーマットが現在テキスト要素の長さのために取得される（１６４６）。次 に、スイッチ・オペレーション１６４８がフォーマットに基づいて実行される。 このインプリメンテーションで利用できるフォーマットはリスト、セグメント配 列、範囲およびチェーンである。フォーマットがリスト・フォーマットであれば 、リスト・フォーマット処理１６５０が実行される。フォーマットがセグメント 配列であれば、セグメント配列フォーマット処理１６５２が実行される。フォー マットが範囲であれば、範囲フォーマット処理１６５４が実行される。フォーマ ットがチェーンであれば、チェーン・フォーマット処理１６５６が実行される。 ブロック１６５０−１６５６に続いて、結果が戻され（１６５８）、これにより テキスト要素ルックアップ処理１６３０は完了する。 本発明の第１側面によれば、図２０はチェーン・フォーマット処理１６６０を 示すフローチャートである。チェーン・フォーマット処理１６６０は図１９に示 すチェーン・フォーマット処理１６３５によって実行される処理である。 チェーン・フォーマット処理１６６０はチェーン内のテーブル数のチェーン・ カウントを取得する（１６６２）。そのあと、現在のカウントはゼロにセットさ れる（１６６４）。次に、現在のカウントがチェーン・カウントより大であるか 等しいかどうかの判断１６６６が行われる。現在のカウントがチェーン・カウン トより大または等しければ、チェーン・フォーマット処理１６６０は戻り（１６ ６８）、結果が見つからなかったのでエラーを通知する。他方、現在のカウント がチェーン・カウントより大でも等しくもなければ、現在のルックアップ・テー ブルとそのフォーマットが取得される（１６７０）。このインプリメンテーショ ンで使用されるフォーマットは図１９で使用されたものと同じである。そのあと スイッチ・オペレーション１６７２がフォーマットに基づいて実行される。フォ ーマットがリストであれば、リスト・フォーマット処理１６７４が実行される。 フォーマットがセグメント配列であれば、セグメント配列フォーマット処理１６ ７６が実行される。フォーマットが範囲であれば、範囲フォーマット処理１６８ ０が実行される。フォーマットがチェーンであれば、チェーン・フォーマット処 理１６８２が実行される。ブロック１６１４〜１６２２に続いて、現在のカウン トがインクリメントされる（１６８４）。次に、結果が見つかったかどうかの判 断１６８６が行われる。結果が見つからなければ、チェーン・フォーマット処理 １６６０はループして判断ブロック１６６６に戻り、テーブル・チェーン内の次 のルックアップ・テーブルを調べていく。しかるに、結果が見つかったと判断１ ６８６されたときは、結果が戻され（１６８８）、これによりチェーン・フォー マット処理１６６０は完了する。 本発明の第１側面によれば、図２１は範囲フォーマット処理１７００を示すフ ローチャートである。範囲フォーマット処理１７００は図１９のブロック１６５ ４と巣２０のブロック１６７８によって実行される処理である。範囲フォーマッ トはデルタ値が各フィールドと関連づけられている文字の範囲リストである。 範囲フォーマット処理１７００はそのサブテーブルのサブセット・フラグが選 択フラグに一致しているかどうかを判断（１７０２）することから始まる。選択 フラグは選択マスクに対するもので、サブセット・フラグはサブテーブル・マ スクに対するものである。一致していなければ、範囲フォーマット処理は戻り（ １７０４）、結果が見つからなかったことをエラー・コードで通知する。他方、 そのサブテーブルのサブセット・フラグが選択フラグに一致していることを判断 １７０２が示していれば、テキスト要素の長さが１より大であるかどうかの判断 １７０６が行われる。テキスト要素の長さが１より大であれば、このフォーマッ トは誤って選択されたことになる。この特定インプリメンテーションでのマッピ ング・テーブルの構成は範囲フォーマットが長さ１のテキスト要素だけを目的と するようになっているためである。従って、テキスト要素が１より大であれば、 ブロック１７０４が実行されて戻り、結果が見つからなかったことを通知する。 他方、テキスト要素の長さが１より大でなければ、範囲フォーマット処理１７０ ０は続行される。範囲フォーマットをもつサブテーブルは範囲配列をもち、各範 囲はそれぞれに関連づけられたデルタ値をもっている。次に、範囲配列がサーチ され（１７０８）、変換されるユニコード文字の該当する範囲が見つけられる。 範囲が見つかったかどうかの判断１７１０が行われる。範囲が見つからなければ 、範囲フォーマット処理１７００は戻り（１７０４）、結果が見つからなかった ことをエラー・コードで通知する。しかるに、結果が見つかったときは、その範 囲の対応するデルタ値が取得される（１７１２）。次に、このデルタ値はユニコ ード値に加えられる（１７１４）。そのあと、その結果は出力シーケンスにマッ ピングされる（１７１６）。結果を出力シーケンスにマッピングする処理は図２ ２Ａ〜図２２Ｃを参照して以下で詳しく説明する。ブロック１７１６に続いて、 範囲フォーマット処理は完了し、戻る。 本発明の第１側面によれば、図２２はリスト・フォーマット処理１８００を示 すフローチャートである。リスト・フォーマット処理１８００は図１９のブロッ ク１６５０と図２０のブロック１６７４によって実行される処理である。リスト ・フォーマットはテキスト要素が配列されたリストであり、この配列リストまで のインデックスｉは対応するルックアップ・ターゲット・リストまでのインデッ クスである。 リスト・フォーマット処理１８００はそのサブテーブルのサブセット・フラグ が選択フラグに一致しているかどうかの判断１８０２から始まる。一致していな ければ、リスト・フォーマット処理１８００は戻り（１８０４）、マッピングが 見つからなかったことをエラー・コードで通知する。他方、そのサブテーブルの サブセットフラグが選択フラグに一致していれば、リスト内のテキスト要素に基 づいて最適化バイナリ・サーチが行われる（１８０６）。次に、サーチがリスト 内のテキスト要素を見つけたかどうかの判断１８０８が行われる。見つからなけ れば、再びリスト処理は戻り（１８０４）、マッピングが見つからなかったこと を通知する。しかし、テキスト要素が見つかれば、テキスト要素が見つかった個 所のインデックスｉが取得される（１８１０）。このインデックスｉはルックア ップ・ターゲットを取得する（１８１２）ために使用される。次に、ルックアッ プ・ターゲットは出力シーケンスにマッピングされる（１８１４）。これでリス ト・フォーマット処理は完了し、戻る。 本発明の第１側面によれば、図２３Ａと図２３Ｂはセグメント配列フォーマッ ト処理１９００を示している。セグメント配列フォーマット処理１９００は図１ ９のブロック１６５２と図２０のブロック１６７６によって実行される処理であ る。セグメント配列フォーマットは第１テキスト要素配列、最終テキスト要素配 列、およびｎ個のオフセット配列を含んでいる。オフセット配列内のオフセット は種々のルックアップ・ターゲット・リストを指している。 セグメント配列フォーマット処理１９００はそのサブテーブルのサブセット・ フラグが選択フラグに一致しているかどうかの判断１９０１から始まる。サブセ ット・フラグが選択フラグに一致していれば、最適化サーチが行われる（１９０ ２）。最適化サーチは最終テキスト要素配列内にあって、探索していたテキスト 要素よりも大であるか等しい最小エントリを見つけ、そのエントリのインデック スｉを取得する。次に、第１テキスト要素配列内のｉ番目のエントリが探索して いたテキスト要素より小であるか等しいかどうかの判断１９０４が行われる。そ うでなければ、セグメント配列フォーマット処理１９００は戻り（１９０６）、 マッピングが見つからなかったことをエラー・コードで知らせる。また、判断１ ９０１が失敗した場合には、ブロック１９０６も実行される。他方、最初のテキ スト要素配列内のｉ番目のエントリが探索していたテキスト要素より小であるか 等しいことを判断１９０４が示しているときは、ｉ番目のエン トリは探索していたテキスト要素に対応することが分かる。そのあと、ルックア ップ・ターゲット・リストがオフセット配列内のｉ番目のエントリを通して取得 される（１９０８）。すなわち、オフセット配列内のｉ番目のエントリに入って いるオフセットはルックアップ・ターゲット・リストを示している。ルックアッ プ・ターゲット・リストまでのインデックスｊが次に判断される。インデックス ｊは探索していたテキスト要素の値から、取得（１９０８）したルックアップ・ ターゲット・リスト（または範囲）内の第１テキスト要素を引いた値が与えられ る。インデックスｊをもつルックアップ・ターゲットが次にルックアップ・ター ゲット・リストから取得される（１９１２）。次に、ルックアップ・ターゲット がゼロに等しいかどうかの判断１９１４が行われる。ルックアップ・ターゲット がゼロに等しければ、セグメント配列フォーマット処理は戻り、マッピングが見 つからなかったことをエラー・コードで通知する。他方、ルックアップ・ターゲ ットがゼロに等しくなければ、ルックアップ・ターゲットは出力シーケンスにマ ッピングされる（１９１８）。ブロック１９１８に続いて、セグメント配列フォ ーマット処理１９００は完了し、戻る。 図２４はサーチ変種リスト処理２０００を示すフローチャートである。サーチ 変種リスト処理２０００は図１９のブロック１６３２によって実行される処理で ある。言い換えれば、サーチ変種リスト処理２０００はマッピング・テーブル４ １４を使用してルックアップ・ハンドラ４１２によって実行されるルックアップ ・テキスト要素処理１６３０の一部である。 サーチ変種リスト処理２０００は変種リスト内の要素の総カウントを取得する （２００２）。そのあと、現在のカウントがゼロに初期化される（２００４）。 現在のカウントが総カウントより大であるか等しいかどうかの判断２００６が行 われる。現在のカウントが総カウントより大または等しければ、サーチ変種リス ト処理２０００は戻り（２００８）、変種が見つからなかったことをエラー・コ ードで通知する。他方、現在のカウントが総カウントより大または等しくなけれ ば、変種リスト内にあって、現在のカウントに関連するエントリが実際の属性お よび要求された変種に一致しているかどうかの判断２０１０が行われる。一致し ていれば、変種リスト内のエントリからの変種フラグが戻される（２０１２）。 一致していなければ、現在のカウントはインクリメントされ（２０１４）、その あと処理はブロック２００６に戻り、変種の１つが一致するか、あるいは変種の すべてが考慮されるまでループを続けて変種リスト内の使用可能な変種を見つけ る。 図２５Ａおよび図２５Ｂは変種リスト２１００を示す概略図である。図２５Ａ に示すように、変種リスト２１００は変種領域２１０２、所望属性領域２１０４ および変種フラグ領域２１０６を含んでいる。図２５Ｂは好ましいインプリメン テーションによる実際属性ビット・マスクを示す図である。実際属性ビット・マ スク２１０８は３２ビット変数であり、シメトリック・スワッピング状態を示す 第１部分２１１０（ビット０と１）、垂直または水平形式を示す第２部分（ビッ ト２と３）、解明方向を示す第３部分（ビット８と９）、およびコンテキストを 示す第４部分（ビット１６〜１９）をもっている。本発明の第３側面によれば、 第４部分２１１６のビットはコンテキスト処理９８４（図１０Ｃ）で判断された コンテキスト・マスクによってセットされる。さらに、本発明の第１ないし第４ 側面によれば、部分内の各ビットはフラグを表している。ビットはフラグが未知 であるか、あるいはセットされていなければ、値が“０”であり、セットされて いるときは値は“１”になっている。呼び出し側は第２部分２１１０をセットし 、スキャナ４０８は第１、第２および第４部分２１１０、２１１４および２１１ ６をセットする。 所望属性ビット・マスクは実際属性ビット・マスクと同じフォーマットである が、ビットは属性のどれが特定テーブルおよび変種の正しいマッピングを得るた めに重要であるかに応じてセットされる（これはマッピング・テーブル４１４の 設計によって決まる）。所望属性ビット・マスク内のビットはマッピング判断の 際に考慮される各属性には“１”がセットされ、ある部分のすべてのビットが“ １”にセットされていれば、属性はマッピング期間には無視される。例えば、ビ ット０が“１”で、ビット１が“０”ならば、シメトリック・スワッピングはオ ンであり、マッピングが行われるとき考慮される。他方、ビット０と１が共に“ １”であれば、シメトリック・スワッピングは完全に無視される。所望属性ビッ ト・マスクの残りの未使用ビットは“１”にセットされ、必要ならばあとで値を 割り当てることができる。以下、所望属性ビット・マスクの例をいくつか示して 説明する。 方向が左から右へであり、他の属性はいずれも重要でないとする。そうすると 所望属性ビット・マスクはｘＦＦＦＦＦＤＦＦとなる。これに対して、方向が右 から左へであり、シメトリック・スワッピングがオンであるとすると、所望属性 ビット・マスクはｘＦＦＦＦＦＥＦＤとなる。方向が右から左へで、シメトリッ ク・スワッピングがオフであれば、所望属性ビット・マスクはｘＦＦＦＦＦＥＦ Ｅとなる。上記の異種所望属性ビット・マスクの各々によると、異なる変換コー ドを選択することができる。例えば、ユニコード文字ｕ００２８をＭａｃＡｒａ ｂｉｃにマッピンすると、所望属性ビット・マスクｘＦＦＦＦＦＤＦＦではｘ２ ８が、所望属性ビット・マスクｘＦＦＦＦＦＥＦＤではｘＡ８が、所望属性ビッ ト・マスクｘＦＦＦＦＦＥＦＥではｘＡ９が得られる。 本発明の第１側面によれば、図２６Ａ、図２６Ｂおよび図２６Ｃはルックアッ プ・ターゲットの出力シーケンスへのマッピング処理２２００を示すフローチャ ートである。ルックアップ・ターゲットの出力シーケンスへのマッピング処理２ ２００は図２２のブロック１８１４および図２３Ａのブロック１９１８に関連し ている。 ルックアップ・ターゲットの出力シーケンスへのマッピング処理２２００は間 接が許されるかどうかの判断２２０２から始まる。間接が許されなければ、ルッ クアップ・ターゲットはｃｈａｒｓｉｚｅの断片で出力シーケンスにコピーされ る（２２０４）。ｃｈａｒｓｉｚｅとは、ターゲット・コード化内の文字の最小 サイズのことであり、マッピング・テーブル４１４のヘッダ５００に指定されて いる。ブロック２２０４に続いて、処理２００は完了し、結果が見つかったとの 通知を出して戻る（２２０６）。他方、間接が許されると判断２２０２が判断し たときは、ルップアップ・ターゲットの上位ビットが１に等しいかどうかの判断 ２２０８が行われる。上位ビットが１に等しくなければ、第１バイトがヌル出力 シーケンス（つまり、長さが０の出力シーケンス）を示しているかどうかの判断 ２２１０が行われる。第１バイトがｘ７Ｆを示していれば、ヌル出力シーケンス が示される（２２１２）（一致するものが見つかったが、文字は出力シーケンス に追加されない）。他方、第１バイトがヌル出力シーケンスを示していないとき は、ｃｈａｒｓｉｚｅの断片が出力シーケンスにコピーされる（２２１４）。そ の場合には、第１バイトは出力シーケンスの長さを示していることが好ましい。 ブロック２２１２と２２１４に続いて、ブロック２２０６が実行され、これによ り処理は完了し、結果が見つかったことを通知して戻る。 しかるに、ルックアップ・ターゲットの上位ビットが１に等しいと判断２２０ ８が判断した場合には、ルックアップ・ターゲットは所望の出力シーケンスを間 接的に参照しているので追加の処理が必要になる。具体的には、間接シーケンス までのオフセットがルックアップ・ターゲットの残余部分を使用して指定される （２２１６）。ルックアップ・ターゲットの残余部分の上位ビットが１に等しい かどうかの判断２２１８が行われる。等しくなければ、ｃｈａｒｓｉｚｅの断片 が出力シーケンスにコピーされ（２２２０）、そのあと処理２２００はマッピン グが見つかったとの通知を戻して（２２００）完了する。他方、ルックアップ・ ターゲットの残余部分の上位ビットが１に等しいと判断されていれば（２２１８ ）、順次チェーン内のシーケンスのカウントが取得され（２２２４）、リニア・ サーチがシーケンスを通るように行われ、マッピングが特定される。ブロック２ ２２６に続いて、前述したブロック２２２０と２２２２が実行される。 図２６Ｃは図２６Ｂのブロック２２２６によって実行されるオペレーションの 詳細図である。すでに説明したように、図２６Ｃのブロック２２２６はシーケン スを通るリニア・サーチを実行する。最初に、現在のカウントがゼロにセットさ れる（２２２８）。現在のカウントがシーケンス・カウントより大であるか均か どうかの判断２２２８が行われる。現在のカウントがシーケンス・カウントより 大または等しければ、ルックアップ・ターゲットの出力シーケンスへのマッピン グ処理２２００はマッピングが見つからなかったとの通知と共に戻る（２２３２ ）。他方、現在のカウントがシーケンス・カウントより大または等しくなければ 、次の出力シーケンスとそのシーケンス・マスクが取得される（２２３４）。シ ーケンス・マスクは複数の出力シーケンスの１つを選択するために使用されるマ スクである。次に、サブセット・フラグが使用中であるかどうかの判断２２３６ が行われる。サブセット・フラグが使用中でなければ、シーケンス・マスクと論 理ＡＮＤがとられた実際属性が実際属性にビットワイズに等しいかどうかの判断 ２２３８が行われる。そうであれば、マッピングが見つかったので処理は上述し たブロック２２２０と２２２２を実行する。他方、サブセット・フラグが使用中 であると判断（２２３６）されたときは、シーケンス・マスクと論理ＡＮＤがと られた選択フラグがビットワイズにシーケンス・マスクと等しいかどうかの判断 ２２４０が行われる。そうであれば、マッピングが見つかったので前述したブロ ック２２２０と２２２２が実行される。従って、ブロック２２３８と２２４０は 異なった方法で正しい出力シーケンスを取得する。他方、どちらかの判断ブロッ ク２２３８または２２４０が現在のシーケンスが正しいマッピングでないと示し ていれば、現在のカウントはインクリメントされ（２２４２）、処理はブロック ２２３０に戻ってチェーン内の次のシーケンスのオペレーションを続ける。 図２７は本発明によるフォールバック・ハンドリング処理２３００を示すフロ ーチャートである。フォールバック・ハンドリング処理２３００はフォールバッ ク・ハンドラ４１６によって実行され、図７に示すユニコード・コンバータ処理 ７００のブロック７１６によって起動される処理である。 フォールバック・ハンドリング処理２３００はフォールバック・オプションを 使用してテキスト要素を調べる（２３０２）。ルックアップ２３０２は図１９を 参照して上述したテキスト要素ルックアップ処理１６３０に類似している。唯一 の重要な違いは、変化した選択フラグを通して追加サブセットが考慮されるよう にフォールバック・オプションがセットされていることである。次に、テキスト 要素の変換コードが見つかったかどうかの判断２３０４が行われる。変換コード が見つかっていれば、変換またはマッピングを取得するときにどのフォールバッ クが使用されたかを示すようにエラー・コードがセットされる（２３０６）。ブ ロック２３０６に続いて、フォールバック・ハンドリング処理２３００は完了し 、戻る。 他方、判断２３０４が変換コードが見つからなかったと示しているときは、フ ォールバック・オプションに基づいてスイッチ・オペレーション２３０８が実行 される。フォールバック・オプションには、次のものがある。すなわち、デフォ ルト、呼び出し側定義、呼び出し側定義を伴うデフォルト、またはデフォルトを 伴う呼び出し側定義である。フォールバック・オプションがデフォルトであれば 、スイッチ・オペレーション２３０８はデフォルト処理２３１０を実行させる。 フォールバック・オプションが呼び出し側定義であれば、スイッチ・オペレーシ ョン２３０８は呼び出し側定義のオペレーションを２３１２を実行させる。フォ ールバック・オプションが呼び出し側定義を伴うデフォルトであれば、スイッチ ・オペレーション２３０８はデフォルト処理を実行させ（２３１４）、続いて判 断２３１６と呼び出し側定義の処理を実行させる（２３１８）。判断２３１６は デフォルト処理が正常に行われると、呼び出し側定義処理２３１８をバイパスす るように働く。フォールバック・オプションがデフォルト処理を伴う呼び出し側 定義であれば、スイッチ・オペレーション２３０８は呼び出し側定義処理を実行 させ（２３２０）、続いて判断２３２２とデフォルト処理をを実行させる（２３ ２４）。判断２３２２は、呼び出し側定義処理２３２０が正常に行われたときは 、デフォルト処理２３２４をバイパスするように働く。スイッチ・オペレーショ ン２３０８に関連する処理に続いて、フォールバック処理２３００がマッピング または変換コードを正常に特定していたかどうかの判断２３２６が行われる。フ ォールバック処理２３００が失敗していれば、文字セットのデフォルト・フォー ルバック文字シーケンスが取得される（２３２８）。デフォルト・ フォールバック文字シーケンスとは、フォールバック・ルックアップ２３０２が 変換コードを特定するのに失敗したとき使用される変換コードである。好ましく は、デフォルト・フォールバック文字シーケンスはマッピング・テーブル４１４ のヘッダに収められている。例えば、ＡＳＣＩＩでは、デフォルト・フォールバ ック文字シーケンスは“？”であるのが普通である。そのあと、ブロック２３２ ８に続いて、またはフォールバック処理がマッピングまたは変換コードを取得す るのに成功したときはブロック２３２６に続いて、フォールバック・オプション が使用されたことを示すエラー・コードがセットされ（２３０６）、フォールバ ック・ハンドリング処理２３００は完了し、戻る。 図２８はデフォルト処理２４００を示すフローチャートである。デフォルト処 理は図２７のブロック２３１０、２３１４および２３２４で実行される処理と関 連している。 デフォルト処理２４００は最初に現在のカウントをゼロにセットする（２４０ ２）。次に、現在のカウントがテキスト要素の長さより大であるか等しいかの判 断２４０４が行われる。そうであれば、デフォルト処理２４００は完了し、戻る 。そうでなければ、フォールバック・フラグがセットされた単一ユニコード文字 に対してルックアップ処理が実行される（２４０６）。ここでは、ルックアップ はテキスト要素の個別文字に対するものであるが、以前（ブロック３２０２）で は、ルックアップはテキスト要素全体に対するものであった。そのあと、単一ユ ニコード文字の変換コードが見つかったかどうかの判断２４０８が行われる。見 つからなければ、ユニコード文字で使用でいる個別マッピングがなかったことを エラー・コードで通知してデフォルト処理２４００は戻る（２４１０）。他方、 変換コードが見つかっていれば、現在のカウントがインクリメントされ（２４１ ２）、処理はテキスト要素内の次のユニコード文字の処理を行うためにブロック ２４０４に戻る。 上述した図４〜図２８はユニコードからターゲット・コード化への変換（ユニ コードから）に関するものであるが、上述したように、ユニコード・コード変換 システム３００は異なるソース・コード化からユニコードに変換する（ユニコー ドへ）機能も等しく備えている。ユニコードへはユニコードからの処理と類似し ているが、実質的には複雑度が軽減されている。ユニコードへの処理はターゲッ ト・コード化を判断するときテキスト要素を探すためにスキャンしたり、複数の 文字シーケンスを調べたりする必要がないのが通常である。ユニコードへの処理 はソース文字列を個々の文字に分割し、そのあとでユニコードの対応するコード ・ポイントを見つけるだけである。しかし、文字のマッピングがそのあとに続く 文字に影響されるようなまれな場合には（例えば、デーヴァナーガリーのような インド・スクリプト）、上述したようにスキャンが行われる場合がある。 図２９は本発明によるユニコード・コード変換システム２５００の実施例を示 すブロック図である。ユニコード・コード変換システム２５００はユニコードへ の変換を行う（つまり、ユニコードへの処理）。ユニコード・コード変換システ ム２５００はユニコードへのコンバータ２５０２を含み、このコンバータはソー ス文字列２５０４を受信し、ユニコード文字列２５０６を出力する。ユニコード へのコンバータ２５０２はスキャナ２５０８とやりとりするユニコードへのコン バータを通してコード変換プロセスを実行する。スキャナ２５０８はスキャナ・ テーブル２５１０を使用して、ソース文字列２５０４をスキャンしソース文字列 ２５０４を文字に分断する。ここでは、ユニコードからの場合と異なり、ソース 文字列は個々の文字に分割されるだけである。次に、ユニコードへのコンバータ ２５０２はルックアップ・ハンドラ２５１２を使用して個別文字を調べそのユニ コード・コード化を取得する。ルックアップ・ハンドラ２５１２はマッピング・ テーブル２５１４を使用してユニコードの文字を取得する。さらに、ユニコード へのコンバータ２５０２はフォールバック・ハンドラ２５１６を使用することも できる。フォールバック・ハンドラ２５１６はマッピング・テーブル２５１４と 一緒に動作して、ルックアップ・ハンドラ２５１２がユニコード文字を特定でき なかった場合に、テキスト要素のフォールバック・マッピングとして使用できる ターゲット・コード化内の１つまたは複数の文字を特定する。 スキャナ２５０８、スキャナ・テーブル２５１０、ルックアップ・テーブル２ ５１２、マッピング・テーブル２５１４、フォールバック・ハンドラ２５１６、 状態管理機構２５１８は図４の対応するデバイスと類似しているが、実質的には 複雑度が軽減されている。従って、これらのデバイスはユニコードへ とユニコードからの両方の処理を実現するように設計することができる。さらに 、与えられたコンピュータ・システムや他のエレクトロニック・デバイスがユニ コードへとユニコードからの両方の処理を実行する機能を備えているときは、そ のコンピュータ・システムや他のエレクトロニック・デバイスはハブとして動作 することができる。このハブはユニコードがサポートする種々の各国語文字間で 変換を行うように動作することができる。例えば、ソースの各国語文字セットは まずユニコードに変換され、次にターゲットの各国語文字セットに変換される。 本発明の第１側面によれば、上述したテーブルは、好ましくは、上述したフォ ーマットを使用してテーブルにストアすべきデータの圧縮を行う。さらに、本発 明の第１側面によれば、圧縮を重視している。例えは、圧縮すると、属性テーブ ルは５０倍（５０対１）に小さくなる。しかし、本発明の第１側面によれば、こ の分野の精通者ならば理解されるように、テーブルのフォーマットは多数の形体 をとることができるので、あるテーブルは他のテーブルよりも実現が容易になる 。最も容易な実現はどの圧縮も使用しないテーブルであるが、そのためには最大 のデータ記憶装置が必要になる。さらに、本発明の第１側面によれば、テーブル は上述したインプリメンテーションで使用されているが、これらのテーブルで引 き起こされる振舞を直接にコーディングすることも可能である。しかし、直接コ ーディングはコード変換システムのオペレーションの変更を困難にするのに対し 、テーブルを使用すると、そのような変更を取り入れるためにテーブルだけを変 更するだけで済むのが普通である。 本発明の多数の特徴および利点は上述してきた説明で明らかにした通りであり 、本発明のかかる特徴と利点はすべて請求の範囲に記載されている。さらに、本 発明はこの分野の精通者が容易に理解されるように、種々態様に変更することが 可能であるので、本発明は上述してきた正確な構造とオペレーションに限定され るものではない。従って、すべての適当な変更および等価技術は本発明の範囲に 属するものである。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０８／５２７，８３１ (32)優先日 1995年９月13日 (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ０８／５２７，８３７ (32)優先日 1995年９月13日 (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ， ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，Ｇ Ｅ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ， ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ， ＶＮ (72)発明者 マコンネル，ジョン，アイ. アメリカ合衆国 94025 カリフォルニア 州 メンロパーク マッケンドリー ドラ イブ 222 (72)発明者 タン，ユン−フォン，フランク アメリカ合衆国 94082 カリフォルニア 州 サニーヴェイル イースト ホームス テッド ロード 175 アパートメント ナンバー８ (72)発明者 ダニエルズ，アンドリュー，エム. アメリカ合衆国 94025 カリフォルニア 州 メンロパーク ハイト ストリート 123 【要約の続き】 からユニコード文字に変換したり、ユニコード文字から 他の文字セットに変換したりするとき利用すると、特に 便利である。変換される文字の方向（向き）を判断する ことにより、および／または文字のコンテキストを判断 することにより、コード変換システムは判断または解決 された文字の方向を利用してターゲット文字コード化へ の正しいマッピングが得られることを保証する。切り捨 て処理手法は入力バッファに置かれているソース文字列 の一部を切り捨てて、切り捨てられた部分が、ソース文 字列の中の後続文字に影響されることなくターゲット文 字コード化に変換されることを可能にするように作用す る。

Claims (1)

1. 【特許請求の範囲】 １．ソース文字列をターゲット文字列に変換する方法において、 （ａ）第１の文字コード化を有する前記ソース文字列を受け取り、 （ｂ）前記ソース文字列をテキスト要素に順次分割し、各前記テキスト要素は 、前記ソース文字列の文字を１または複数含み、 （ｃ）各前記テキスト要素の第２の文字コード化に関する変換コードをマッピ ング・テーブルでルックアップし、 （ｄ）前記第２の文字コード化の前記ターゲット文字列を形成するように前記 テキスト要素の前記変換コードを結合する ことを特徴とする方法。 ２．請求項１に記載の方法において、前記変換コードは、前記第２の文字コード 化における１または複数の文字からなることを特徴とする方法。 ３．請求項１に記載の方法において、前記テキスト要素は、お互いに隣接し、２ 個以上の文字を含む各前記テキスト要素について、前記文字は前記ソース文字列 において隣接することを特徴とする方法。 ４．請求項１に記載の方法において、前記マッピング・テーブルは、レギュラ・ マッピングとフォールバック・マッピングを含み、 前記ルックアップ（ｃ）は、前記マッピング・テーブルが、前記テキスト要素 についての前記レギュラ・マッピングを使用した変換コードを含まない場合は、 前記フォールバック・マッピングを使用して各前記テキスト要素の前記変換コー ドを決定することを特徴とする方法。 ５．請求項１に記載の方法において、各前記文字は自分に関する文字クラスを有 し、 前記分割（ｂ）は、少なくとも部分的には、前記ソース文字列中の前記文字の 前記文字クラスに基づくことを特徴とする方法。 ６．請求項１に記載の方法において、前記分割（ｂ）は、 （ｂ１）前記ソース文字列から次のソース文字を獲得し、 （ｂ２）獲得した前記ソース文字を現在のテキスト要素内に含めるべきか、あ るいはまた、新たな次のテキスト要素を始めるかを決定し、 （ｂ３）前記決定（ｂ２）に従い、獲得した前記ソース文字を前記現在のテキ スト要素内または前記新たな次のテキスト要素内に配置し、 （ｂ４）前記ソース文字列をテキスト要素内に完全に配置するまで、（ｂ１） から（ｂ３）までを繰り返す ことを特徴とする方法。 ７．請求項６に記載の方法において、前記決定（ｂ２）は、 （ｉ）前記ソース文字に関する属性をルックアップし、前記属性は少なくとも クラス・インディケータを含み、 （ii）クラス・インディケータに基づき、獲得した前記ソース文字を前記現在 のテキスト要素内に含めるべきか、あるいはまた、新たな次のテキスト要素を始 めるかを決定する ことを特徴とする方法。 ８．請求項６に記載の方法において、前記決定（ｂ２）は、 （ｉ）前記ソース文字に関する属性をルックアップし、前記属性は少なくとも クラス・インディケータを含み、 （ii）複数の状態を有するステート・マシンを提供し、前記ステート・マシン は、前記クラス・インディケータおよび前記ステート・マシンの現在の状態に基 づき、獲得した前記ソース文字を前記現在のテキスト要素内に含めるべきか、あ るいはまた、新たな次のテキスト要素を始めるかを決定するのに使用され、 （iii）前記ステート・マシンの前記現在の状態を更新する ことを特徴とする方法。 ９．請求項１に記載の方法において、前記第１の文字コード化および前記第２の 文字コード化の一つは、ユニコード標準に従うことを特徴とする方法。 １０．請求項１に記載の方法において、前記結合（ｄ）は、 （ｄ１）前記第２の文字コード化に対するターゲット文字サイズを決定し、 （ｄ２）ルップアップされた前記テキスト要素の前記変換コードを、前記ター ゲット文字サイズの単位で前記ターゲット文字列にコピーすることにより前記タ ーゲット文字列を形成する ことを特徴とする方法。 １１．請求項１０に記載の方法において、ルックアップ（ｃ）された前記変換コ ードは、間接コード化シーケンスまでのオフセットを特定することを特徴とする 方法。 １２．請求項１に記載の方法において、さらに、 （ｅ）前記分割（ｂ）後、前記ルップアップ（ｃ）前に、特定の文字がテキス ト要素内に存在する場合は、各前記テキスト要素の前記特定の文字を再配列する ことを特徴とする方法。 １３．請求項１２に記載の方法において、前記再配列は、異なる文字クラスに対 する加重値を利用して適切に実行されることを特徴とする方法。 １４．ソース文字列をターゲット文字列に変換するコード変換システムにおいて 、 第１の文字コード化を有する前記ソース文字列から第２の文字コード化を有す る前記ターゲット文字列への変換を制御するコンバータと、 前記コンバータに動作するよう結合され、前記ソース文字列をテキスト要素に 分割するスキャナであって、各前記テキスト要素は前記ソース文字列の文字を１ または複数含み、 前記ソース・コード化のテキスト要素に対するターゲット・コード化を記憶す るマッピング・テーブルと、 前記コンバータおよび前記マッピング・テーブルに動作するよう結合され、各 テキスト要素の第２の文字コード化に関する変換コードをマッピング・テーブル でルックアップするルックアップ・ハンドラと を備えることを特徴とするシステム。 １５．請求項１４に記載のコード変換システムにおいて、さらに、 前記コンバータに動作するよう結合され、前記ルックアップ・ハンドラが１ま たは複数のテキスト要素に対し変換コードを提供できない場合は、フォールバッ ク変換コードを提供するフォールバック・ハンドラを備え、前記フォールバック 変換コードは、前記テキスト要素内の前記文字と完全に等しいわけではないが類 似するグラフィカル外観を有する、前記ターゲット・コード化における１または 複数のコード・ポイントを含む ことを特徴とするシステム。 １６．請求項１５に記載のコード変換システムにおいて、さらに、 前記入力文字列中の個々の文字を現在のテキスト要素内に含めるべきか、ある いはまた、新たな次のテキスト要素を始めるかの決定について前記スキャナを支 援するスキャナ・テーブル手段 を備えることを特徴とするシステム。 １７．請求項１４に記載のコード変換システムにおいて、さらに、 前記スキャナに動作するよう結合され、前記入力文字列中の個々の文字を現在 のテキスト要素内に含めるべきか、あるいはまた、新たな次のテキスト要素を始 めるかの決定について前記スキャナを支援するスキャナ・テーブル を備えることを特徴とするシステム。 １８．請求項１７に記載のコード変換システムにおいて、前記ソース文字列の前 記文字は自分に関する文字クラスを有し、 前記スキャナ・テーブルは要素の配列を備え、前記配列は文字クラスによりイ ンデックス付けされていることを特徴とするシステム。 １９．請求項１４に記載のコード変換システムにおいて、前記ソース文字列中の 前記文字は、ユニコード文字であることを特徴とするシステム。 ２０．請求項１４に記載のコード変換システムにおいて、前記ターゲット文字列 中の前記文字は、ユニコード文字であることを特徴とするシステム。 ２１．ソース文字列をターゲット文字列に変換するコード変換システムにおいて 、 第１の文字コード化を有する前記入力文字列から第２の文字コード化を有する 前記ターゲット文字列への変換を制御するコンバータ手段と、 前記ソース文字列をテキスト要素に分割するステート・マシンであって、各テ キスト要素は前記ソース文字列の文字を１または複数含むステート・マシン手段 と、 前記ソース・コード化のテキスト要素に対するターゲット・コード化を記憶す るマッピング手段と、 各前記テキスト要素の第２の文字コード化に関する変換コードを前記マッピン グ手段でルックアップするルックアップ・ハンドラ手段と を備えることを特徴とするシステム。 ２２．請求項２１に記載のコード変換システムにおいて、さらに、 前記入力文字列中の個々の文字を現在のテキスト要素内に含めるべきか、ある いはまた、新たな次のテキスト要素を始めるかの決定について前記スキャナを支 援するスキャナ・テーブル手段 を備えることを特徴とするシステム。 ２３．請求項２２に記載のコード変換システムにおいて、さらに、 前記ルックアップ・ハンドラ手段が１または複数のテキスト要素に対し変換コ ードを提供できない場合は、フォールバック変換コードを提供するフォールドバ ック・ハンドラ手段を備え、前記フォールバック変換コードは、前記テキスト要 素内の文字と完全に等しいわけではないが、類似するグラフィカル外観を有する 、前記ターゲット・コード化における１または複数のコード・ポイントを含む ことを特徴とするシステム。 ２４．入力文字列をスキャンするスキャニング・システムにおいて、 前記入力文字列から入力文字を獲得する入力装置であって、前記入力文字列は 文字コード化を有し、前記入力文字列の各文字は文字クラスを有する入力装置と 、 前記入力文字の属性を提供する属性テーブルと、 前記入力文字の前記属性および前記ステート・マシンの現在の状態に従って、 前記ステート・マシンの次の状態および次のアクションの両方を決定するステー ト・マシンとを備え、 前記ステート・マシンが決定した前記次のアクションに基づいて、前記スキャ ニング・システムは、前記入力文字列の前記入力文字を現在のテキスト要素内に 含めるべきか、あるいはまた、前記現在のテキスト要素を終え新たなテキスト要 素を始めるかを決定する ことを特徴とするシステム。 ２５．請求項２４に記載のスキャニング・システムにおいて、前記属性は少なく とも前記入力文字の文字クラスを含み、 前記ステート・マシンは、前記入力文字の前記文字クラスおよび前記ステート ・マシンの前記現在の状態に従って、前記次の状態および前記次のアクションを 決定することを特徴とするシステム。 ２６．ソース文字列をターゲット文字列に変換するプログラム命令を含むコンピ ュータ読み取り可能な媒体において、 第１の文字コード化を有するソース文字列をコンピュータが受け取るように構 成されたコンピュータ読み取り可能なコードと、 前記ソース文字列をテキスト要素にコンピュータが分割するように構成され、 各テキスト要素は前記ソース文字列の文字を１または複数含むコンピュータ読み 取り可能なコードと、 各前記テキスト要素に対する第２の文字コード化に関する変換コードをコンピ ュータがルックアップするように構成されたコンピュータ読み取り可能なコード と、 前記第２の文字コード化の前記ターゲット文字列を形成するように前記テキス ト要素の前記変換コードをコンピュータが結合するように構成されたコンピュー タ読み取り可能なコードと を備えることを特徴とするコンピュータ読み取り可能な媒体。 ２７．ソース文字列をターゲット文字列に変換する方法において、 （ａ）第１の文字コード化を有するソース文字列を受け取り、前記ソース文字 列は複数のソース文字を含み、 （ｂ）前記ソース文字列の前記ソース文字の方向を決定し、 （ｃ）前記第１の文字コード化および決定された前記方向に基づき、各前記ソ ース文字に対する第２の文字コード化に関する変換コードをマッピング・テーブ ルでルックアップし、 （ｄ）前記第２の文字コード化のターゲット文字列を形成するように、前記ソ ース文字の前記変換コードを結合する ことを特徴とする方法。 ２８．請求項２７に記載の方法において、各ソース文字の前記方向は、左から右 への方向および右から左への方向の一つであることを特徴とする方法。 ２９．請求項２７に記載の方法において、前記決定（ｂ）は、 （ｂ１）前記方向が不適切かどうかを決定し、 （ｂ２）前記方向が適切な場合は、方向が、左から右への方向および右から左 への方向の一つを決定する ことを備えることを特徴とする方法。 ３０．請求項２７に記載の方法において、前記決定（ｂ）は、前記ソース文字列 の１または複数の文字の前記方向に基づき、前記ソース文字列のすべてまたは一 部の前記方向を決定することを特徴とする方法。 ３１．請求項２７に記載の方法において、前記決定（ｂ）は、 （ｉ）前記ソース文字に関する属性をルックアップし、前記属性は少なくとも クラス・インディケータを含み、 （ii）前記クラス・インディケータに基づき前記ソース文字の前記方向を決定 する ことを備えることを特徴とする方法。 ３２．請求項２７に記載の方法において、前記決定（ｂ）は、 （ｉ）前記ソース文字に関する属性をルックアップし、前記属性は少なくとも クラス・インディケータを含み、 （ii）複数の状態を有するステート・マシンを提供し、前記ステート・マシン は、前記クラス・インディケータおよび前記ステート・マシンの状態に基づき、 前記ソース文字の方向を決定するために使用され、 （iii）前記ステート・マシンの状態を更新する ことを備えることを特徴とする方法。 ３３．請求項３２に記載の方法において、前記ステート・マシンは、さらに、前 記クラス・インディケータおよび前記ステート・マシンの現在の状態に基づいて 、前記ソース文字を現在のテキスト要素内に含めるべきか、あるいはまた、新 たな次のテキスト要素を始めるかを決定することを特徴とする方法。 ３４．請求項３２に記載の方法において、前記決定（ｂ）は、前記現在のテキス ト要素の前記方向を決定することを特徴とする方法。 ３５．請求項２７に記載の方法において、さらに、（ｅ）前記ソース文字列をテ キスト要素に順次分割し、各テキスト要素は前記ソース文字列の文字を１または 複数含むことを備え、 前記決定（ｂ）は、前記テキスト要素の前記方向を決定し、 前記ルックアップ（ｃ）は、前記テキスト要素の前記１または複数のソース文 字の前記第１の文字コード化および前記テキスト要素の前記方向に基づき、各前 記テキスト要素の第２の文字コード化に関する変換コードを前記マッピング・テ ーブルでルックアップすることを特徴とする方法。 ３６．請求項３５に記載の方法において、前記マッピング・テーブルは、レギュ ラ・マッピングとフォールバック・マッピングを含み、 前記ルックアップ（ｃ）は、前記マッピング・テーブルが、前記レギュラ・マ ッピングを使用する前記テキスト要素に対する変換コードを含まない場合は、前 記フォールドバック・マップングを使用して前記テキスト要素の前記変換コード を決定することを特徴とする方法。 ３７．請求項３５に記載の方法において、各前記ソース文字は、自分に関する文 字クラスを有し、 前記分割（ｅ）は、少なくとも部分的には、前記ソース文字列中の前記ソース 文字の前記文字クラスに基づくことを特徴とする方法。 ３８．請求項２７に記載の方法において、前記第１の文字コード化および前記第 ２の文字コード化の一つは、ユニコード標準に従うことを特徴とする方法。 ３９．ソース文字列をターゲット文字列に変換するコード変換システムにおいて 、 ソース文字コード化を有する入力文字列からターゲットの文字コード化を有す るターゲット文字列への前記変換を制御するコンバータであって、前記入力文字 列は複数の文字を含むコンバータと、 前記コンバータに動作するよう結合され、前記入力文字列中の前記文字の方向 を決定するスキャナと、 前記ソース・コード化の文字に対するターゲット・コード化を記憶するマッピ ング・テーブルと、 前記コンバータおよび前記マッピング・テーブルに動作するよう結合され、前 記方向および前記入力文字列中の前記文字に対する前記ソース・コード化に基づ き、前記入力文字列中の各前記文字についてのターゲット文字コード化に関する 変換コードを前記マッピング・テーブルでルックアップするルックアップ・ハン ドラと を備えることを特徴とするシステム。 ４０．請求項３９に記載のコード変換システムにおいて、 前記スキャナは、さらに、前記入力文字列をテキスト要素に分割し、各前記テ キスト要素は前記入力文字列の文字を１または複数含み、 前記スキャナは、前記テキスト要素の前記方向を決定し、 前記マッピング・テーブルは、前記ソース・コード化のテキスト要素に対する ターゲット・コード化を記憶し、 前記ルックアップ・ハンドラは、前記方向および前記テキスト要素内の前記文 字についての前記ソース・コード化に基づき、各前記テキスト要素に対する前記 ターゲット文字コード化をルックアップすることを特徴とするシステム。 ４１．請求項４０に記載のコード変換システムにおいて、さらに、 前記コンバータに動作するよう結合され、前記ルックアップ・ハンドラが１ま たは複数のテキスト要素に対し変換コードを提供できない場合は、フォールバッ ク変換コードを提供するフォールバック・ハンドラを備え、前記フォールバック 変換コードは、前記テキスト要素内の文字と完全に等しいわけではないが、類似 するグラフィカル外観を有する、前記ターゲット・コード化における１または複 数のコード・ポイントを含む ことを特徴とするシステム。 ４２．請求項４１に記載のコード変換システムにおいて、さらに、 前記入力文字列の前記文字の前記方向の決定、および、前記入力文字列中の個 々の文字を現在のテキスト要素内に含めるべきか、あるいはまた、新たな次のテ キスト要素を始めるかの決定について前記スキャナを支援するスキャナ・テーブ ル手段 を備えることを特徴とするシステム。 ４３．請求項３９に記載のコード変換システムにおいて、前記入力文字列の前記 文字は、自分に関する文字クラスを有し、 前記スキャナ・テーブルは、要素の配列を備え、前記配列は、文字クラスによ りインデックス付けされていることを特徴とするシステム。 ４４．請求項３９に記載のコード変換システムにおいて、前記ソース文字列中の 前記文字は、ユニコード文字であることを特徴とするシステム。 ４５．請求項３９に記載のコード変換システムにおいて、前記ターゲット文字列 中の前記文字は、ユニコード文字であることを特徴とするシステム。 ４６．ソース文字列をターゲット文字列に変換するコード変換システムにおいて 、 ソース文字コード化を有する前記ソース文字列からターゲット文字コード化を 有するターゲット文字列への前記変換を制御するコンバータ手段と、 前記ソース文字列中の各前記文字の方向を決定するステート・マシン手段 と、 前記ソース文字コード化の文字に対するターゲット文字コード化を記憶するマ ッピング手段と、 前記決定された方向を考慮しつつ、前記ソース文字コード化に従い、前記ソー ス文字列中の各前記文字に対するターゲット文字コード化に関する変換コードを 前記マッピング手段でルックアップするルックアップ・ハンドラ手段と を備えることを特徴とするシステム。 ４７．請求項４６に記載のコード変換システムにおいて、前記ステート・マシン 手段は、さらに、前記ソース文字列をテキスト要素に分割し、各前記テキスト要 素は、前記ソース文字列の文字を１または複数含むことを特徴とするシステム。 ４８．請求項４７に記載のコード変換システムにおいて、さらに、 前記ルックアップ・ハンドラ手段が１または複数のテキスト要素に対し変換コ ードを提供できない場合は、フォールバック変換コードを提供するフォールバッ ク・ハンドラ手段を備え、前記フォールバック変換コードは、前記テキスト要素 内の前記文字と完全に等しいわけではないが、類似するグラフィカル外観を有す る、前記ターゲット・コード化における１または複数のコード・ポイントを含む ことを特徴とするシステム。 ４９．ソース文字列をターゲット文字列に変換するプログラム命令を含むコンピ ュータ読み取り可能な媒体において、 第１の文字コード化を有するソース文字列をコンピュータが受け取るように構 成されたコンピュータ読み取り可能なコードと、 前記ソース文字列中の各前記ソース文字の方向をコンピュータが決定し、前記 ソース文字列をテキスト要素にコンピュータが分割するように構成され、各前記 テキスト要素はソース文字列の文字を１または複数含むコンピュータ読み取り可 能なコードと、 各前記テキスト要素の第２の文字コード化に関する変換コードをコンピュータ がルックアップするように構成されたコンピュータ読み取り可能なコードと、 前記第２の文字コード化のターゲット文字列を形成するように前記テキスト要 素の変換コードをコンピュータが結合するように構成されたコンピュータ読み取 り可能なコードと を備えることを特徴とするコンピュータ読み取り可能な媒体。 ５０．ソース文字列をターゲット文字列に変換する方法において、 （ａ）第１の文字コード化を有するソース文字列を受け取り、前記ソース文字 列は複数のソース文字を含み、 （ｂ）前記ソース文字列中の各前記ソース文字のコンテキストを決定し、 （ｃ）前記第１の文字コード化および各前記ソース文字の決定された前記コン テキストに基づき、各前記ソース文字の第２の文字コード化に関する変換コード をマッピング・テーブルでルックアップし、 （ｄ）前記第２の文字コード化のターゲット文字列を形成するように前記ソー ス文字の前記変換コードを結合する ことを備えることを特徴とする方法。 ５１．請求項５０に記載の方法において、各ソース文字の前記コンテキストは、 前記ソース文字列中の自分と隣接するソース文字に依存することを特徴とする方 法。 ５２．請求項５０に記載の方法において、前記決定（ｂ）は、 （ｂ１）コンテキストが不適切かどうかを決定し、 （ｂ２）コンテキストが適切な場合は、コンテキストが、初期、中間、終了ま たはアローンの一つであるかどうかを決定する ことを備えることを特徴とする方法。 ５３．請求項５２に記載の方法において、前記決定（ｂ２）を実行する際に、特 別なソース文字の前記コンテキストの決定に関し、隣接のソース文字が前記特別 なソース文字のコンテキストに対し影響するように、前記ソース文字列は一文字 ずつスキャンされることを特徴とする方法。 ５４．請求項５０に記載の方法において、前記決定（ｂ）は、 （ｉ）前記ソース文字に関する属性をルックアップし、前記属性は少なくとも クラス・インディケータを含み、 （ii）前記クラス・インディケータに基づき、前記ソース文字の前記コンテキ ストを決定する ことを備えることを特徴とする方法。 ５５．請求項５０に記載の方法において、前記決定（ｂ）は、 （ｉ）前記ソース文字に関する属性をルックアップし、前記属性は少なくとも クラス・インディケータを含み、 （ii）複数の状態を有するステート・マシンを提供し、前記ステート・マシン は前記クラス・インディケータおよび前記ステート・マシンの状態に基づき、前 記ソース文字の前記コンテキストを決定するために利用され、 （iii）前記ステート・マシンの状態を更新する ことを備えることを特徴とする方法。 ５６．請求項５５に記載の方法において、前記ステート・マシンは、さらに、前 記クラス・インディケータおよび前記ステート・マシンの現在の状態に基づいて 、前記ソース文字を現在のテキスト要素内に含めるべきか、あるいはまた、新た な次のテキスト要素を始めるかを決定することを特徴とする方法。 ５７．請求項５０に記載の方法において、さらに、 （ｅ）前記ソース文字列をテキスト要素に順次分割し、各テキスト要素は前記 ソース文字列の文字を１または複数含むことを備え、 前記ルックアップ（ｃ）は、各前記テキスト要素の前記第２の文字コード化に 関する変換コードを前記マッピング・テーブルでルックアップし、ルックアップ された変換コードの１つを選択し、前記結合（ｄ）は、前記第２の文字コード化 による前記ターゲット文字列を形成するように前記テキスト要素に対する前記変 換コードを結合することを特徴とする方法。 ５８．請求項５７に記載の方法において、前記マッピング・テーブルは、レギュ ラ・マッピングとフォールバック・マッピングを含み、 前記ルックアップ（ｃ）は、前記マッピング・テーブルが、前記レギュラ・マ ッピングを使用する前記テキスト要素に対する変換コードを含まない場合は、前 記フォールバック・マッピングを使用して各前記テキスト要素の前記変換コード を決定することを特徴とする方法。 ５９．請求項５７に記載の方法において、各前記ソース文字は、自分に関する文 字クラスを有し、 前記分割（ｅ）は、少なくとも部分的には、前記ソース文字列中の前記ソース 文字の前記文字クラスに基づくことを特徴とする方法。 ６０．請求項５７に記載の方法において、前記分割（ｅ）は、 （ｅ１）前記ソース文字列から次のソース文字を獲得し、 （ｅ２）獲得した前記ソース文字を現在のテキスト要素内に含めるべきか、あ るいはまた、新たな次のテキスト要素を始めるかを決定し、 （ｅ３）前記決定（ｅ２）に従い、獲得した前記ソース文字を前記現在のテキ スト要素内または前記新たな次のテキスト要素内に配置し、 （ｅ４）前記ソース文字列をテキスト要素内に完全に配置するまで、（ｅ１） から（ｅ３）までを繰り返す ことを備えることを特徴とする方法。 ６１．請求項６０に記載の方法において、前記決定（ｅ２）は、 （ｉ）前記ソース文字に関する属性をルックアップし、前記属性は少なくとも クラス・インディケータを含み、 （ii）複数の状態を有するステート・マシンを提供し、前記ステート・マシン は、前記クラス・インディケータおよび前記ステート・マシンの現在の状態に基 づき、獲得した前記ソース文字を前記現在のテキスト要素内に含めるべきか、あ るいはまた、新たな次のテキスト要素を始めるかを決定するのに利用され、 （iii）前記ステート・マシンの前記現在の状態を更新する ことを備えることを特徴とする方法。 ６２．請求項５７に記載の方法において、前記第１の文字コード化および前記第 ２の文字コード化の一つは、ユニコード標準に従うことを特徴とする方法。 ６３．請求項５７に記載の方法において、前記結合（ｄ）は、 （ｄ１）前記第２の文字コード化のターゲット文字サイズを決定し、 （ｄ２）ルップアップされた前記テキスト要素の前記変換コードを前記ターゲ ット文字サイズの単位で前記ターゲット文字列にコピーすることにより前記ター ゲット文字列を形成する ことを備えることを特徴とする方法。 ６４．ソース文字列をターゲット文字列に変換するコード変換システムにおいて 、 ソース文字コード化を有する前記入力文字列からターゲット文字コード化を有 する前記ターゲット文字列への前記変換を制御するコンバータであって、前記入 力文字列は複数の文字を含むコンバータと、 前記コンバータに動作するよう結合され、前記入力文字列中の各前記文字のコ ンテキストを決定するスキャナと、 前記ソース・コード化の文字に対するターゲット・コード化を記憶するマッピ ング・テーブルと、 前記コンバータおよび前記マッピング・テーブルに動作するよう結合され、前 記コンテキストおよび前記入力文字列中の前記文字に対する前記ソース・コード 化に基づき、前記入力文字列中の各前記文字に対するターゲット文字コード化に 関する変換コードを前記マッピング・テーブルでルックアップするルックアップ ・ハンドラと を備えることを特徴とするシステム。 ６５．請求項６４に記載の方法において、 前記スキャナは、さらに、前記入力文字列を前記テキスト要素に分割し、各テ キスト要素は前記入力文字列の文字を１または複数含み、 前記マッピング・テーブルは、前記ソース・コード化のテキスト要素に対する ターゲット・コード化を記憶し、 前記ルックアップ・ハンドラは、前記コンテキストおよび前記テキスト要素内 の前記文字に対する前記ソース・コード化に基づき、各テキスト要素に対する前 記ターゲット・文字コード化を選択することを特徴とする方法。 ６６．請求項６５に記載のコード変換システムにおいて、さらに、 前記コンバータに動作するよう結合され、前記ルックアップ・ハンドラが１ま たは複数のテキスト要素に対し変換コードを提供できない場合は、フォールバッ ク変換コードを提供するフォールバック・ハンドラを備え、前記フォールバック 変換コードは、前記テキスト要素内の文字と完全に等しいわけではないが、類似 するグラフィカル外観を有する、ターゲット・コード化における１または複数の コード・ポイントを含むことを特徴とするシステム。 ６７．請求項６６に記載のコード変換システムにおいて、さらに、 前記入力文字列中の個々の文字を現在のテキスト要素内に含めるべきか、ある いはまた新たな次のテキスト要素を始めるかの決定について前記スキャナを支援 するスキャナ・テーブル手段 を備えることを特徴とするシステム。 ６８．請求項６４に記載のコード変換システムにおいて、前記入力文字列の前記 文字は、自分に関する文字クラスを有し、 前記スキャナ・テーブルは、要素の配列を備え、前記配列は、前記文字クラス によりインデックス付けされていることを特徴とするシステム。 ６９．請求項６４に記載のコード変換システムにおいて、前記ソース文字列中の 前記文字は、ユニコード文字であることを特徴とするシステム。 ７０．請求項６４に記載のコード変換システムにおいて、前記ターゲット文字列 中の前記文字は、ユニコード文字であることを特徴とするシステム。 ７１．ソース文字列をターゲット文字列に変換するコード変換システムにおいて 、 ソース文字コード化を有する前記ソース文字列からターゲット文字コード化を 有する前記ターゲット文字列への前記変換を制御するコンバータ手段と、 前記ソース中の各前記文字のコンテキストを決定するステート・マシン手段と 、 前記ソース文字コード化を有する文字に対するターゲット文字コード化を記憶 するマッピング手段と、 前記ソース文字列中の各前記文字についてのターゲット文字コード化に関する 変換コードを前記マッピング手段でルックアップするルックアップ・ハンドラ手 段と を備えることを特徴とするシステム。 ７２．請求項７１に記載のコード変換システムにおいて、前記ステート・マシン 手段は、さらに、前記ソース文字列をテキスト要素に分割し、各テキスト要素は 、前記ソース文字列の文字を１または複数含むことを特徴とするシステム。 ７３．請求項７２に記載のコード変換システムにおいて、さらに、 前記ルックアップ・ハンドラ手段が１または複数のテキスト要素に対し変換コ ードを提供できない場合は、フォールバック変換コードを提供するフォールバッ ク・ハンドラ手段を備え、前記フォールバック変換コードは、前記テキスト要素 内の前記文字と完全に等しいわけではないが、類似するグラフィカル外観を有す る、前記ターゲット・コード化における１または複数のコード・ポイントを含む ことを特徴とするシステム。 ７４．ソース文字列をターゲット文字列に変換するプログラム命令を含むコンピ ュータ読み取り可能な媒体において、 第１の文字コード化がなされた前記ソース文字列をコンピュータが受け取るよ うに構成されたコンピュータ読み取り可能なコードと、 前記ソース文字列中の各前記ソース文字のコンテキストをコンピュータが決定 し、前記ソース文字列をテキスト要素にコンピュータが分割するように構成され 、各テキスト要素は前記ソース文字列の文字を１または複数含むコンピュータ読 み取り可能なコードと、 各前記テキスト要素の第２の文字コード化に関する変換コードをコンピュータ がルックアップするように構成されたコンピュータ読み取り可能なコードと、 前記第２の文字コード化によるターゲット文字列を形成するように前記テキス ト要素の前記変換コードをコンピュータが結合するように構成されたコンピュー タ読み取り可能なコードと を備えることを特徴とするコンピュータ読み取り可能な媒体。 ７５．ソース文字列をターゲット文字列に変換するコード変換システムにおいて 、 第１の文字コード化を有する前記ソース文字列から第２の文字コード化を有す る前記ターゲット文字列への前記変換を制御するコンバータと、 前記ソース文字列の部分の１つを一度に受け取るためのバッファであって、前 記ソース文字列は部分を２つ以上含むバッファと、 前記ソース文字列の前記部分を切り捨てるトランケータと、 前記コンバータに動作するよう結合され、前記ソース文字列の切り捨てられた 部分をテキスト要素に分割するスキャナであって、各テキスト要素は、前記ソー ス文字列の前記切り捨てられた部分の文字を１または複数含むスキャナと、 前記ソース・コード化の前記テキスト要素に対するターゲット・コード化を記 憶するマッピング・テーブルと、 前記コンバータおよび前記マッピング・テーブルに動作するよう結合され、各 前記テキスト要素の第２の文字コード化に関する変換コードを前記マッピング・ テーブルでルックアップするルックアップ・ハンドラと を備えることを特徴とするシステム。 ７６．請求項７５に記載のコード変換システムにおいて、前記トランケータは、 前記スキャナとともに、前記ソース文字列の前記部分を通してスキャンして前記 部分内の前記テキスト要素を決定し、前記切り捨てられた部分を、完全なテキス ト要素からなる前記ソース文字列の部分のサブパートとして決定することを特徴 とするシステム。 ７７．請求項７５に記載のコード変換システムにおいて、前記トランケータは、 前記切り捨てられた部分を、前記ソース文字列の後続の部分に影響を受けること なく前記ターゲット文字列に変換できる、前記ソース文字列の部分のサブパート として決定することを特徴とするシステム。 ７８．請求項７５に記載のコード変換システムにおいて、前記ソース文字列はテ キスト文字列であり、前記ターゲット文字列はテキスト文字列であることを特徴 とするシステム。 ７９．請求項７５に記載のコード変換システムにおいて、さらに、 前記コンバータに操作的に接続され、前記ルックアップ・ハンドラが１または 複数のテキスト要素に対し変換コードを提供できない場合は、フォールバック変 換コードを提供するフォールバック・ハンドラを備え、前記フォールバック変換 コードは、前記テキスト要素内の前記文字と完全に等しいわけではないが、類似 するグラフィカル外観を有する、前記ターゲット・コード化における１または複 数のコード・ポイントを含む ことを特徴とするシステム。 ８０．請求項７５に記載のコード変換システムにおいて、さらに、 前記入力文字列中の個々の文字を現在のテキスト要素内に含めるべきか、ある いはまた、新たな次のテキスト要素を始めるかの決定について前記スキャナを支 援するスキャナ・テーブル手段 を備えることを特徴とするシステム。 ８１．請求項７５に記載のコード変換システムにおいて、さらに、 前記スキャナに動作するよう結合され、前記入力文字列中の個々の文字を現在 のテキスト要素内に含めるべきか、あるいはまた、新たな次のテキスト要素を始 めるかの決定について前記スキャナを支援するスキャナ・テーブル を備えることを特徴とするシステム。 ８２．請求項８１に記載のコード変換システムにおいて、前記ソース文字列の前 記文字は自分に関する文字クラスを有し、 前記スキャナ・テーブルは要素の配列を備え、前記配列は文字クラスによりイ ンデックス付けされていることを特徴とするシステム。 ８３．請求項７５に記載のコード変換システムにおいて、前記ソース文字列中の 前記文字は、ユニコード文字であることを特徴とするシステム。 ８４．請求項７５に記載のコード変換システムにおいて、前記ターゲット文字列 中の前記文字は、ユニコード文字であることを特徴とするシステム。 ８５．ターゲット文字列への文字変換のためにソース文字列を切り捨てる方法に おいて、 （ａ）バッファ内のソース文字列のバッファ部分を受け取り、前記ソース文字 列は２個以上のバッファ部分を含み、 （ｂ）後続の前記ソース文字列のバッファ部分に影響を受けることなくターゲ ット文字列に変換できる、前記ソース文字列の前記バッファ部分のサブパートを 決定し、 （ｃ）前記ソース文字列の前記バッファ部分の前記サブパートをターゲット・ コード化に変換する ことを特徴とする方法。 ８６．請求項８５に記載の方法において、さらに、 （ｄ）次のバッファ部分またはそのサブパートとともに変換するために前記バ ッファ部分の残り部分をセーブし、前記残り部分はサブパートとともに前記バッ ファ部分と等しい ことを特徴とする方法。 ８７．請求項８５に記載の方法において、前記ソース文字列はテキスト文字列で あり、前記ターゲット文字列はテキスト文字列であることを特徴とする方法。 ８８．ターゲット文字列への文字変換のためにソース文字列を切り捨てる方法に おいて、 （ａ）バッファ内のソース文字列の部分を受け取り、 （ｂ）前記ソース文字列の前記部分内のテキスト要素を決定し、各前記テキス ト要素は前記ソース文字列の文字を１または複数含み、 （ｃ）前記テキスト要素が完全かどうかを決定し、 （ｄ）前記テキスト要素が完全であれば、前記テキスト要素を前記ソース文字 列の切り捨てられた部分内に含め、 （ｅ）前記ソース文字列の前記部分が完全に考慮されるまで、ステップ（ｂ） 〜（ｄ）を繰り返し、 （ｆ）その後、文字変換のために前記ソース文字列の前記切り捨てられた部分 を出力する ことを特徴とする方法。 ８９．請求項８８に記載の方法において、さらに、 （ｇ）前記バッファ内に受け取られた前記ソース文字列の次の部分とともに使 用するために、前記ソース文字列のすべての残りの部分をセーブする ことを特徴とする方法。 ９０．請求項８９に記載の方法において、前記ソース文字列はテキスト文字列で あり、前記ターゲット文字列はテキスト文字列であることを特徴とする方法。 ９１．ソース文字列をターゲット文字列に変換するプログラム命令を含むコンピ ュータ読み取り可能な媒体において、 第１の文字コード化がなされた前記ソース文字列をバッファにコンピュータが 受け取るように構成されたコンピュータ読み取り可能なコードと、 ソース文字列の部分をコンピュータが切り捨てるように構成されたコンピュー タ読み取り可能なコードと、 前記ソース文字列の切り捨てられた部分をテキスト要素にコンピュータが分割 するように構成され、各前記テキスト要素は前記ソース文字列の切り捨てられた 部分の文字を１または複数含むコンピュータ読み取り可能なコードと、 各前記テキスト要素の第２の文字コード化に関する変換コードをコンピュータ がルックアップするように構成されたコンピュータ読み取り可能なコードと、 前記第２の文字コード化によるターゲット文字列を形成するように前記テキス ト要素の前記変換コードをコンピュータが結合するように構成されたコンピュー タ読み取り可能なコードと を備えることを特徴とするコンピュータ読み取り可能な媒体。 ９２．請求項９１に記載のコンピュータ読み取り可能な媒体において、ソース文 字列の部分をコンピュータが切り捨てるように構成されたコンピュータ読み取り 可能なコードは、前記切り捨てられた部分を、後続のソース文字列の前記部分に 影響を受けることなく前記ターゲット文字列に変換できる、前記ソース文字列の 部分のサブパートとして決定することを特徴とするコンピュータ読み取り可能な 媒体。