JP2013544395A - 双方向テキストチェッカー - Google Patents

Abstract

ウェブページ内にあるようなテキストコンテンツ内の双方向テキストをチェックするための方法およびシステムが提供される。双方向テキストをチェックするための方法は、テキストコンテンツの固有および宣言テキスト方向を決定することを含み得る。本方法はまた、固有のテキスト方向と宣言テキスト方向との間の不一致に基づいた双方向テキストエラーを生成することを含み得る。双方向テキストエラーが報告され得る。システムは、ウォーカー、双方向テキストチェッカー、および双方向エラー報告器を含み得る。

Description

本分野は、ウェブページを含むアプリケーションドキュメントのテキスト分析に関する。

（背景）
テキストドキュメントページおよびウェブページはコンテンツを異なる言語で表示する。ヘブライ語、アラビア語、および種々のその他の言語は、右から左のスクリプトで書かれている。アプリケーションにとって、これらのスクリプトに書かれている言語のうちの一つもしくは複数の言語にローカライズされることは、共通の要求である。アプリケーションはまた、ページ全体が左から右（もしくはこの逆）の言語にローカライズされている場合でも、入力テキストをこれらの言語で表示することおよび得ることが可能であることを要求される。その上、右から左のテキストを、ページ全体が左から右（もしくはこの逆）にローカライズされているように表示もしくは入力として取得する場合、アプリケーションはそのようなテキストの方向を明示的に宣言しなければならない。なぜなら、そのような明示的な方向宣言がなければ、テキストは正確に表示されない可能性があるからである。これらの方向の要求はしばしば、ｂｉｄｉサポートと呼ばれる（「ｂｉｄｉ」は、「双方向」の短縮である）。ｂｉｄｉサポートをインプリメントするために、アプリケーションのページはページおよびテキストの方向を宣言および制御するために、マークアップおよび／もしくは特殊フォーマッティング文字を使用しなければならない。

アプリケーションにとって、ｂｉｄｉサポートをインプリメントすることは非常に困難であり得る。具体的には、ｂｉｄｉサポートのインプリメントは、方向がページ全体のものとは潜在的に反対となり得るデータアイテムを表示する、もしくはそのようなデータアイテムを入力することをユーザーに許可するすべての点において、特殊な操作を要求する。その結果、新しい特徴を研究する開発者がしばしばテキスト方向を扱うことを単に忘れ、そのため新しい特徴に要求される操作を追加しないため、アプリケーションのｂｉｄｉサポートは常に退化の危険にある。しばしば、双方向テキストを有するアプリケーションおよびページは、エラー付きでそのようなコンテンツを示す。

（簡単な概要）
実施形態はウェブページのコンテンツのようなテキストコンテンツ内の双方向テキストエラーをチェックすることに関する。テキストコンテンツはまた、任意のその他のドキュメントもしくはドキュメントの一部分を含み得る。一実施形態に従うと、双方向テキストをチェックするための方法は、テキスト部分の固有のテキスト方向を決定することを含む。テキスト部分は文字、単語、文、もしくはテキストの区分であり得る。テキスト部分はまた、ユーザー入力、ツールチップ（例えば、吹き出しテキスト）として、またはテキストの宣言方向もしくは固有の方向の変化により識別され得る。その他のテキスト部分は数字、日付、およびテキスト見出しを含み得る。本方法はさらに、テキスト部分と関連した宣言テキスト方向を決定することを含む。本方法はまた、固有のテキスト方向と宣言テキスト方向との間の不一致に基づいた双方向テキストエラーを生成することを含む。双方向テキストエラーが報告される。テキストコンテンツは、各テキスト部分がチェックされるテキスト部分へと分けられ得る。

もう一つの実施形態に従うと、テキストコンテンツ内の双方向テキストをチェックするためのシステムはテキスト部分の固有のテキスト方向および宣言テキスト方向を決定するように構成されたウォーカーを含む。本システムはまた、固有のテキスト方向と宣言テキスト方向との間の不一致に基づいた双方向テキストエラーを生成するように構成された双方向テキストチェッカーを含む。本システムはさらに、双方向テキストエラーを報告するように構成された双方向エラー報告器を含む。

本発明のさらなる実施形態、特徴、および利点は、本発明の種々の実施形態の構造および動作と同様に、添付の図面を参照して下に詳細に記述される。

（図の簡単な記述）
本発明の実施形態は、添付の図面を参照して記述される。図面において、同様の参照番号は同一もしくは機能的に類似の要素を示し得る。要素が最初に現れる図面は、概して対応する参照番号の一番左の桁により示される。
図１は、双方向テキストを有する例示的なウェブページを示す。 図２は、双方向テキストの不正確な表示の例を説明する。 図３は、一実施形態に従ったテキストコンテンツにおける双方向テキストをチェックするためのシステムのアーキテクチャ図を説明する。 図４は、一実施形態に従った双方向テキストチェッカーのアーキテクチャ図を説明する。 図５は、一実施形態に従ったテキストコンテンツにおける双方向テキストをチェックするための方法を説明するフロー図である。

（詳細な記述）
本発明は本明細書において具体的なアプリケーションの例示的な実施形態を参照して記述されるが、本発明はそれに限定されないことが理解されるべきである。本明細書で提供される教示にアクセスした当業者は、その範囲内で追加の改変、アプリケーション、および実施形態、そして本発明が有意に有益となり得る追加の分野を認識する。

アプリケーションにとって、双方向テキストを正確に示すことは非常に難しくあり得る。適切なテキスト方向の宣言は、テキスト部分にとって不正確であるかもしくは欠如しているかのいずれかであり得る。その結果として、双方向テキストを含むテキストコンテンツは、双方向エラー付きで表示され得る。例えば、図１は、右から左に書かれているアラビア語のテキスト部分を含む探索ウェブページの表示ビュー１００を示す。しかしながら、双方向テキストの不正確表示１０２が生じている。図２において、テキスト部分１０２は、「Ａ Ｓｐａｃｅ Ｏｄｙｓｓｅｙ」部分２０２が「２００１」部分２０４よりも前にあると示しており、それは不正確である。

以下に記述される実施形態は、ウェブページ、マークアップファイル、ＸＭＬファイル、平文ストリング、もしくはエラーのためのテキストを含む他のドキュメントフォーマット内のエラーのために、双方向テキストをチェックする能力を提供する。例えば、ウェブページは、方向のマークアップもしくはフォーマッティング文字が欠如しているかもしくは不正確に使用されている箇所を捜すためにスキャンされ得る。双方向テキストエラーは、ウェブページコンテンツを適切に表示するために訂正が行われ得るように報告され得る。

図３は、一実施形態に従った例示的な双方向テキストチェックシステム３００のアーキテクチャ図である。双方向テキストチェックシステム３００、もしくはその構成要素の任意の組み合わせは、コンピューティングデバイスの一部であり得るかもしくはコンピューティングデバイスにインプリメントされ得る。コンピューティングデバイスの例は、限定されることはないが、コンピュータ、ワークステーション、分散コンピューティングシステム、コンピュータクラスター、組み込みシステム、スタンドアロン電子デバイス、ネットワーク接続されたデバイス、モバイルデバイス（例えば、モバイル電話、スマートフォン、ナビゲーションデバイス、タブレットもしくはモバイルコンピューティングデバイス）、ラックサーバー、セットトップボックス、もしくは少なくとも一つのプロセッサおよびメモリを有するその他のタイプのコンピュータシステムを含む。そのようなコンピューティングデバイスは、ソフトウェア、ファームウェア、ハードウェア、もしくはこれらの組み合わせを含み得る。ソフトウェアは、一つもしくは複数のアプリケーションおよび一つのオペレーティングシステムを含み得る。ハードウェアは、限定されることはないが、プロセッサ、メモリ、およびユーザーインタフェースディスプレイを含み得る。

双方向テキストチェックシステム３００は、双方向テキストスキャナ３１０を含み得る。一部の場合において、スキャナ３１０は、表示のためにウェブページを表示もしくは準備するウェブページディスプレイデバイス３２０に結合され得る。ウェブページはウェブブラウザ内に表示され得る。一実施形態に従うと、スキャナ３１０はウォーカー３１２、双方向テキストチェッカー３１４、および双方向エラーレポーター３１６を含む。

一実施形態に従うと、スキャナ３１０は、ウェブページに含まれるすべてのフレームに対して再帰的に行うことを含め、ウェブページの一つもしくは複数のＤＯＭ（ドキュメントオブジェクトモデル）をスキャンするように構成され得る。ウェブページは複数のフレームで構成され得、各フレームは独自のＤＯＭを有する。次にフレームは、他のフレームなどを含み得る。説明を目的として、「ＤＯＭ」の各使用は単一のページもしくはフレームのＤＯＭを表し得る。出会ったＤＯＭごとに、スキャナ３１０はウォーカー３１２および双方向テキストチェッカー３１４を起動し得る。ＤＯＭコンテンツスキャニングは、事象駆動型アーキテクチャの内部に構成され得る。

ウォーカー３１２は、一実施形態に従うと、ＤＯＭをトラバースし、事象のシリーズへと変換もしくは要約するように構成され得る。ウォーカー３１２は、ＤＯＭを異なる方法で要約し、そして異なるタイプの事象を実行するように構成され得る。双方向テキストチェッカー３１４は、図４で示されているように、複数の検出器を含むように構成され得る。検出器は関心のあるタイプの事象に注意を払い、双方向エラーのような、検出器が検出するように構成されている側面を記録する。ウォーカー３１２は、双方向テキストチェッカー３１４と協働するように構成され得る。ウォーカー３１２はまた、各ＤＯＭ上で作動するように構成され得る。

一実施形態に従うと、ウォーカー３１２は単一のＤＯＭをトラバースし、そして次の４つのタイプの事象のシリーズをディスパッチするように構成され得る：マークアップタグの開始に出会うときのスタートタグ、マークアップタグの終了に出会うときのエンドタグ、テキストのブロックと出会うときのテキストノード、およびＤＯＭの終わりに達するときのエンドオブドム。ウォーカー３１２は、ＤＯＭ内の各ノードの現在の宣言テキスト方向性（左から右もしくは右から左）を追跡し得る。ウォーカー３１２はまた、ＤＯＭにより直接含まれる任意のフレームのリストを集め得る。

一実施形態に従うと、ウォーカー３１２は宣言テキスト方向を決定するように構成され得る。宣言テキスト方向は、左から右（「ｌｔｒ」）、右から左（「ｒｔｌ」）、左から右オーバーライド（「ｌｒｏ」）、右から左オーバーライド（「ｒｌｏ」）、および「不明」のうちの一つであり得る。オーバーライド値は、いずれの固有テキスト方向もオーバーライドされ、無頓着に左から右もしくは右から左のいずれかに宣言されることを意味する。そのようにして、ｌｒｏおよびｒｌｏは不一致エラーの結果を生じず、そしてウォーカーは実際はｌｒｏ、ｒｌｏ、および不明の値の間を区別しない可能性がある。ウォーカー３１２はまた、宣言ページ方向コンテキストを決定するように構成され得る。

さらなる実施形態に従うと、ウォーカー３１２は単一のＤＯＭをトラバースし得、ＤＯＭの同一のブロックレベル要素内で、テキストの同一方向性順番を表す事象のシリーズ（ＤｉｒＣｈｕｎｋとして公知）をディスパッチする。宣言方向性が変化する場合、もしくは新しいブロックレベル要素が現れる場合はいつでも、新しいＤｉｒＣｈｕｎｋがディスパッチされる。

一実施形態に従うと、システム３００は、ドキュメントのテキストコンテンツを意味のあるテキスト部分へと分け、そして固有のテキスト方向がその宣言テキスト方向と矛盾する部分を報告するように構成され得る。宣言方向コンテキストは、テキスト部分の予想される方向を示す。テキストの一部分は、ドキュメントがそれを意味のあるユニットであると識別することによるか、もしくは単にその固有の方向特性によるかのいずれかにより、意味があり得る。例えば、ＨＴＭＬドキュメント内の入力要素の値は、すべてＨＴＭＬ要素により識別された一テキスト部分である。

固有のテキスト方向は、テキスト部分文字が左から右を示すユニコード値を有する場合に左から右方向を識別すること、およびテキスト部分文字が右から左を示すユニコード値を有する場合に右から左方向を識別することにより、決定され得る。文字のユニコードｂｉｄｉクラスがＥＮもしくはＡＮである場合、その文字は数字である。文字のユニコードｂｉｄｉクラスがＥＳ、ＥＴ、ＣＳ、もしくはＯＮである場合、その文字はニュートラルである。文字のユニコードｂｉｄｉクラスがＷＳである場合、その文字は空白である。

もう一つの例においては、ドキュメントのテキストコンテンツはテキスト部分のセットへと分けられ得、上述のユニコード双方向アルゴリズムのアプリケーションは、テキスト部分内のすべての文字に偶数埋め込みレベル、もしくはテキスト部分内のすべての文字に奇数埋め込みレベルのいずれかを割り当て、上述のアルゴリズムのアプリケーションにより定義されているように、いずれのテキスト部分も異なるパラグラフに属する文字を有しないようにする。テキストコンテンツは可能な限り小さい数のテキスト部分に分けられ得、固有のテキスト方向と宣言テキスト方向との間に不一致を有するいずれのテキスト部分も、数字、ニュートラル、もしくは空白の文字で開始もしくは終了しない。テキスト部分は以下を含み得る：
１．単一のＬＲＥ、ＲＬＥ、ＬＲＯ、ＲＬＯ、もしくはＰＤＦ文字。
２．すべての文字の双方向（ｂｉｄｉ）クラスがＬＲＥ、ＲＬＥ、ＬＲＯ、ＲＬＯ、ＰＤＦ、Ｒ、ＡＬ、もしくはＬでないストリング。
３．すべての文字のｂｉｄｉクラスがＬＲＥ、ＲＬＥ、ＬＲＯ、ＲＬＯ、ＰＤＦ、Ｒ、もしくはＡＬでなく、およびｂｉｄｉクラスがＬの文字で開始および終了するストリング。
４．すべての文字のｂｉｄｉクラスがＬＲＥ、ＲＬＥ、ＬＲＯ、ＲＬＯ、ＰＤＦ、もしくはＬでなく、およびｂｉｄｉクラスがＲもしくはＡＬの文字で開始および終了するストリング。

一部の実施形態においては、システム３００もしくはウォーカー３１２はテキストコンテンツを複数のテキスト部分へと分けるように構成される。例えば、テキストコンテンツは複数のテキスト部分へと分けられ得、各テキスト部分において、テキスト部分のすべての文字は同一の明示埋め込みレベルおよびオーバーライドステータスを有する。もう一つの例においては、テキストコンテンツは複数のテキスト部分へと分けられ、ユニコード双方向アルゴリズムを、習慣的にこのタイプのコンテンツに適用される任意のよりハイレベルなプロトコルと共にチェックされるコンテンツに適用することにより定められるように、いずれのテキスト部分も異なるパラグラフに属する文字を有しないようにする。ユニコード双方向アルゴリズム（ＵＢＡ）は、テキストをパラグラフへと分離すること、方向文字タイプを初期化すること、埋め込みレベルおよび方向文字タイプのリストにルールのシリーズを適用すること、そして表示のためにテキストを並び替えることを含む、標準のアルゴリズムである。

もう一つの例においては，テキストコンテンツは複数のテキスト部分に分けられ、テキスト部分が、ＬＲＥおよびＲＬＥ文字のような埋め込み方向宣言もしくはＨＴＭＬドキュメント内のテキスト入力要素のような方向を示すマークアップを含むことが予想されないもしくは適当に含むことができないテキストコンテンツの一部分でない限り、いずれのテキスト部分も混合した固有のテキスト方向を有さない。

さらなる例においては、テキストコンテンツは複数のテキスト部分へと分けられ、テキスト部分の数はテキスト部分により覆われているテキストコンテンツの部分を減らすことなく、可能な限り少なくなる。

一実施形態に従うと、双方向テキストチェッカー３１４は以下のようにテキストストリングの固有の方向を決定するように構成され得る。ＬＲＥ、ＲＬＥ、ＬＲＯ、もしくはＲＬＯで開始し、ＰＤＦもしくはストリングの終わりのいずれかで終了し、かつその間にＬＲＥ、ＲＬＥ、ＬＲＯ、ＲＬＯ、もしくはＰＤＦを含まないいずれの部分もストリングから取り除かれる。この除去は、結果として生じるストリングにおいて可能な限り何度も繰り返される。左から右スクリプトに属する文字はユニコードｂｉｄｉクラスＬであると決定され、そして右から左スクリプトに属する文字はユニコードｂｉｄｉクラスＲもしくはＡＬであると決定される。例えば、テキストコンテンツにユニコード双方向アルゴリズムのバージョン６．０．０を、習慣的にこのタイプのコンテンツに適用される任意のよりハイレベルなプロトコルと共に適用する場合、文字は左から右スクリプトに属するように決定される。そしてこの適用において、次のルールではなく、アルゴリズムのルールをＸ８を含みＸ８まで完了させることは、文字方向文字タイプにＬを割り当てる。テキストコンテンツにユニコード双方向アルゴリズムのバージョン６．０．０を、習慣的にこのタイプのコンテンツに適用される任意のよりハイレベルなプロトコルと共に適用する場合、文字は右から左スクリプトに属するように決定される。そしてこの適用において、次のルールではなく、アルゴリズムのルールをＸ８を含みＸ８まで完了させることは、文字方向文字タイプにＲもしくはＡＬを割り当てる。結果がＬ、Ｒ、もしくはＡＬ文字を含まなければ、その方向は「ニュートラル」である。句読点および空白はニュートラルとみなされる。そうでなければ、結果がＬ文字を含まなけば、方向は「ｒｔｌ」である。そうでなければ、結果がＲもしくはＡＬ文字を含まなければ、方向は「ｌｔｒ」である。そうでなければ、右から左方向、左から右方向もしくはニュートラル方向が識別されない場合、方向は「混合」である。

もう一つの実施形態に従うと、双方向テキストチェッカー３１４は、テキスト部分が左から右スクリプトに属する少なくとも一つの文字を含むが右から左スクリプトに属する文字を含まない場合に左から右方向を識別する。双方向テキストチェッカー３１４はまた、テキスト部分が右から左スクリプトに属する少なくとも一つの文字を含むが左から右スクリプトに属する文字を含まない場合に右から左方向を識別する。

一実施形態に従うと、ウォーカー３１２は、いくつかのドキュメントタイプのためのドキュメントのテキストコンテンツ内にある任意の文字のための宣言テキスト方向を決定するように構成され得る：
プレーンテキストユニコードストリングに関しては、ストリング内の文字の宣言テキスト方向は、ストリング内の文字の前にある最も近いＬＲＥ、ＲＬＥ、ＬＲＯ、およびＲＬＯ文字（もしあれば）により決定され、整合ＰＤＦ文字は（もしあれば）ストリング内の文字の後ろにある。そのような文字がなければ、宣言テキスト方向もしくは方向コンテキストは「不明」である。そうでなければ、ＬＲＥに関しては「ｌｔｒ」、ＲＬＥに関しては「ｒｔｌ」、ＬＲＯに関しては「ｌｒｏ」、およびＲＬＯに関しては「ｒｌｏ」である。

ＨＴＭＬおよびＸＭＬドキュメントに関しては、そのテキストノードもしくは属性内の任意の文字の宣言テキスト方向は、以下のように決定され得る：
・属性内の文字に関しては、属性値のためのプレーンテキスト方向コンテキストを計算する。不明であれば、そのテキスト方向は不明であるかニュートラルである。

・テキストノードのもしくは属性の宣言テキスト方向を、下で定義されているように見つける。

・ＸＭＬにおいて、宣言テキスト方向要素は、ｄｉｒ属性もしくは異なる態様でルート要素を有する最も近い先行要素である。コンテキスト要素の方向コンテキストは、そのｄｉｒ属性値と、もしくはｄｉｒ属性がなければ「ｌｔｒ」と等しい。

・ＨＴＭＬにおいて、方向コンテキストは、計算された「ユニコード−ｂｉｄｉ」スタイル特性値が「普通」以外である最も近い先行要素である。これは通常は＜ｂｄｏ＞要素、ブロック要素、もしくはｄｉｒ属性を有する要素のいずれかである。なぜならこれらすべてのユニコード−ｂｉｄｉスタイル特性がデフォルトＣＳＳルール（＜ｂｄｏ＞に関しては「オーバーライド」、およびその他には「埋め込み」、一方でユニコード−ｂｉｄｉスタイルはまたＣＳＳルールもしくはインラインＣＳＳにより直接セットされ得る）によりセットされるからである。コンテキスト要素の方向コンテキストはその後要素の計算された「方向」スタイル特性値であり、それはコンテキスト要素の計算された「ユニコード−ｂｉｄｉ」スタイル特性値が「オーバーライド」であれば「ｌｔｒ」から「ｌｒｏ」へとおよび「ｒｔｌ」から「ｒｌｏ」へとバンプされる。要素の計算された「方向」スタイル特性は通常はｄｉｒ属性を経由してもしくは継承のいずれかによりセットされ、一方でこれもまたＣＳＳルールもしくはインラインＣＳＳにより直接セットされ得る。ルート要素がｄｉｒ属性を有さず、かついずれのＣＳＳルールもしくはインラインＣＳＳもその「方向」スタイル特性をセットしなければ、その計算された基本方向は「ｌｔｒ」である。

・テキストノード内の文字に関しては、プレーンテキスト方向コンテキストは、コンテキスト要素の後続テキストノードの間順走査により構築されたテキストストリングのために決定され得る。それが「ニュートラル」でなければ、それがその方向コンテキストである。そうでなければ、方向コンテキストはコンテキスト要素のものである。

一実施形態に従うと、テキスト部分の宣言テキスト方向は、テキストコンテンツにユニコード双方向アルゴリズムのバージョン６．０．０を、習慣的にこのタイプのコンテンツに適用される任意のよりハイレベルなプロトコルと共に適用する場合、左から右であると決定される。そしてこの適用において、次のルールではなく、アルゴリズムのルールをＸ８を含みＸ８まで完了させることは、テキスト部分の文字に偶数であって最も低い埋め込みレベルを割り当てる。テキスト部分の宣言テキスト方向は、テキストコンテンツにユニコード双方向アルゴリズムのバージョン６．０．０を、習慣的にこのタイプのコンテンツに適用される任意のよりハイレベルなプロトコルと共に適用する場合、右から左であると決定される。そしてこの適用において、次のルールではなく、アルゴリズムのルールをＸ８を含みＸ８まで完了させることは、テキスト部分の文字に奇数であって最も低い埋め込みレベルを割り当てる。

双方向テキストチェッカー３１４は、テキスト部分の固有のテキスト方向とその宣言テキスト方向との間の不一致に基づいた双方向テキストエラーを生成するように構成され得る。例えば、固有の方向およびその宣言テキスト方向は、一方が「ｌｔｒ」であって一方が「ｒｔｌ」であれば不一致となる（従って、「ｌｒｏ」、「ｒｌｏ」、「不明」、「ニュートラル」、および「混合」はいずれの値とも矛盾しない。）。

さらなる実施形態に従うと、固有のテキスト方向もしくは宣言方向のいずれかが左から右もしくは右から左でない場合、不一致は識別されない。また、テキスト部分がニュートラル、混合、不定もしくはその他であると決定される場合、不一致は識別されない。

双方向テキストチェッカー３１４は、一実施形態に従うと、テキスト方向を決定するように構成され得る。双方向テキストチェッカー３１４はまた、一実施形態に従うと、所与のタイプの双方向エラーを見つけることのような特定の目的のために、テキストの意味のある部分を識別するためにウォーカー３１２からの事象に注意を払うように構成され得る。一部の場合において、検出器インスタンスは特定のドキュメント（ＤＯＭ）のコンテキスト内でスキャンのために使用され得、そして再び使用されることはない。それゆえに、フレームを含むページがスキャンされる場合、トップレベルページのためのものと同様に各フレームには別個の検出器がある。

図４において説明されているように、一実施形態に従うと、双方向テキストチェッカー３１４は非宣言方向検出器４０２、ページ方向検出器４０４、およびスピルオーバー検出器４０６を含み得る。一実施形態に従うと、非宣言方向検出器４０２は非宣言反対方向性テキストエラーを決定するように構成され得る。非宣言方向検出器４０２は、テキスト方向と宣言テキスト方向との間の比較に基づいた双方向テキストエラーのような双方向テストメッセージを生成するように構成され得る。非宣言方向検出器４０２は、固有のテキスト方向が宣言テキスト方向と一致しない場合、双方向テキストエラーを生成し得る。例えば、宣言方向コンテキストが左から右である一方で固有のテキスト方向は右から左であり得、そしてこの逆もまた同様である。

一部の実施形態に従うと、双方向テキストチェッカー３１４もしくは非宣言方向検出器４０２は以下のシナリオに基づいて双方向テキストエラーを決定するように構成され得る：
１．左から右の、オーバーライドでない基本方向を有するコンテキスト内の、固有の右から左テキストコンテンツ文字（ＲＬＭ／ＲＬＥ／ＲＬＯ以外）のラン。
２．右から左の、オーバーライドでない基本方向を有するコンテキスト内の、固有の左から右テキストコンテンツ文字（ＬＲＭ／ＬＲＥ／ＬＲＯ以外）のラン。
３．左から右の、オーバーライドでない基本方向を有し、その値が強い方向性の右から左文字を含みかつ強い方向性の左から右文字を含まないテキスト＜入力＞。強い方向性のテキスト文字は、固定された方向を有するアルファベットの文字を含み得る。弱い方向性のテキスト文字は、それ自体は左から右であるがその方向性を自身のコンテキストに与えない、数字のような文字を含み得る。
４．右から左の、オーバーライドでない基本方向を有し、その値が強もしくは弱い方向性の左から右文字を含みかつ強い方向性の右から左文字を含まないテキスト＜入力＞。

ページ方向検出器４０４は、一実施形態に従うと、ＤＯＭのルート要素の全体の方向性が予想と異なった場合にエラーを生成するように構成され得る。例えば、ページテキスト方向宣言はウォーカー３１２により決定され得る。呼び出しコードにより指定された予想のページ方向が宣言ページ方向コンテキストと異なると、エラーが生成され得る。

双方向テキストチェッカー３１４は、一実施形態に従うと、テキスト部分の強い方向性のテキスト文字を決定するように構成され得る。双方向テキストチェッカー３１４はさらに、テキスト要素の強い方向性のテキスト文字がテキスト部分の方向コンテキストとマッチしない場合に双方向テキストエラーを生成するように構成され得る。

一実施形態に従うと、宣言テキスト方向と関連した、テキスト部分の終了テキスト方向コンテキストが決定され得る。終了テキスト方向コンテキストのすぐ後に続く数字テキスト部分はその後決定され得る。双方向テキストエラーは、終了テキスト方向コンテキストが数字テキスト部分より前にある場合に生成され得る。双方向テキストエラーは、開始テキスト方向コンテキストもしくはブロックレベル要素が終了テキスト方向コンテキストと数字テキスト部分との間で検出される場合、保留され得る。双方向テキストエラーはまた、終了テキスト方向コンテキストがテキスト方向の方向を変化させない場合、保留され得る。

もう一つの実施形態に従うと、スピルオーバー検出器４０６は、テキスト部分の後にインラインで続く数字テキスト部分を決定するように構成され得る。宣言テキスト方向は、数字テキスト部分のコンテキストと反対の方向を、間に強い方向性のテキストコンテンツなしで宣言し得る。スピルオーバー検出器４０６は、周囲のコンテキストと反対の宣言方向性を有するテキストであって、別個の方向性宣言のない数字テキスト部分がインラインで後に続き、その間にはニュートラルのみがあるテキストを検出するように構成され得る。スピルオーバー検出器４０６はテキスト部分をスピルオーバー候補としてみなすように構成され得る。例えば、「ｄｉｒ」属性を有する要素が終了しこの終了が現在の方向性に変化を生じさせると、テキスト部分はスピルオーバー候補となる。（ニュートラル文字のみが前にある）数字を含むテキスト部分に出会うと、これもまた候補となり得る。スピルオーバー検出器４０６が、例えば強い方向性の文字、もしくは「ｄｉｒ」属性のような宣言テキスト方向コンテキストを有する要素の開始、もしくは現在の方向性を変化させない「ｄｉｒ」属性を有する要素の終了、もしくはブロックレベル要素の開始もしくは終了を含むテキスト部分と出会うと、スピルオーバー候補は保留されるかもしくはキャンセルされる。

具体的な詳細が、検出器により識別された双方向テキストエラーと関連づけられ得る。例えば：双方向テキストエラーのページ上の構造位置、双方向テキストエラーが現れるページ上のテキスト、ページ上の隣接テキスト、エラータイプおよびその重大度のレベルの推定である。重大度値は一つもしくは複数の要因（エラーの可能性を含む）に基づいて割り当てられ得る。例えば、テキスト部分が句読点のようなニュートラル文字に隣接すると、エラーは終止符もしくは感嘆符がテキスト部分の異なる側にあるなど重大となり得る。エラーは検出器により生成され得、そして処理のために呼ぶ側へと返され得、そして（オプションで）対話型グラフィカルインタフェースを使用してページ上に表示され得る。

もう一つの例において、重大度値は、一つもしくは複数の数字もしくはニュートラル文字から成るストリングで開始する、終了する、そのようなストリングがインラインで前にくる、もしくはインラインで後に続く、これらのいずれかに基づいて双方向テキストエラーに割り当てられ得る。ストリングはまた空白文字を含み得る。

スキャナ３１０はウォーカー３１２および双方向テキストチェッカー３１４を起動するように構成され得る。一部の場合において、スキャナ３１０は、ＪａｖａＳｃｒｉｐｔ（登録商標）のようなウェブページの一つもしくは複数のＤＯＭ（ドキュメントオブジェクトモデル）をウォークスルーするスクリプト言語スクリプトにインプリメントされ得る。双方向テキストチェッカー３１４はウェブアプリケーションによる双方向テキストハンドリングにおけるエラーの発生である可能性がある構造を識別するように構成され得る。ウォーカー３１２は、ページ上にあるようなテキストコンテンツ内のテキストノードの各セグメントもしくはテキストの一部分の現在の宣言方向性をたどり得る。双方向テキストチェッカー３１４は、１）不正確に宣言された全体ページ方向コンテキスト、２）テキストの一部分の宣言方向コンテキストとテキスト文字の実際のテキスト方向との間の不一致、そして３）典型的に文字化けしたレンダリングを引き起こす、数字が後に続く反対方向性テキスト、を含む一つもしくは複数のタイプのエラーをチェックするように構成され得る。テキストメッセージ（エラーを含む）は生成され得、そして双方向エラー報告器３１６によりユーザーもしくは双方向エラーを探索するようスキャナ３１０に命令した構成要素へと報告され得る。

スキャナ３１０は種々の方法で起動され得る。例えば、スキャナ３１０はＪａｖａＳｃｒｉｐｔ（登録商標）に基づいた試験項目群から直接起動され得る。代替的に、スキャナ３１０はＪａｖａ（登録商標）統合レイヤを経由してＪａｖａ（登録商標）に基づいた試験項目群から起動され得る。このことは、呼ぶ側がＪａｖａ（登録商標）内のウェブドライバライブラリのようなライブラリを使用してウェブページへとナビゲートされ、Ｊａｖａ（登録商標）関数呼び出しを経由してスキャナ３１０を起動することを可能にする。内部構造において、Ｊａｖａ（登録商標）コードはライブラリのＪａｖａＳｃｒｉｐｔ（登録商標）起動メカニズムを使用してスキャナ３１０をウェブページ内へと埋め込み得る。スキャナ３１０は起動され得、そして結果をＪａｖａ（登録商標）ＡＰＩへと報告し得る。

例えば、スキャナ３１０はウェブページが有効になる前に、双方向エラーをチェックするために自動化された試験項目群から呼び出され得る。図１内のテキスト要素のためのサンプルテストは以下のようにインプリメントされ得る：
ｐｕｂｌｉｃ ｖｏｉｄ ｔｅｓｔＲｉｇｈｔＴｏＬｅｆｔＷｅｂＳｅａｒｃｈＨｏｍｅ（） ｛
ＢｉｄｉＣｈｅｃｋｅｒ ｂｉｄｉＣｈｅｃｋｅｒ ＝ ｎｅｗ ＢｉｄｉＣｈｅｃｋｅｒ（）；
ＷｅｂＤｒｉｖｅｒ ｄｒｉｖｅｒ ＝ ｎｅｗ Ｂｕｉｌｄｅｒ（）．ｂｕｉｌｄ（）；
Ｓｔｒｉｎｇ ｑｕｅｒｙ ＝ ”＆ｑ＝２００１：＋Ａ＋Ｓｐａｃｅ＋Ｏｄｙｓｓｅｙ”； ／／ Ｅｎｇｌｉｓｈ ｓｅａｒｃｈ ｓｔｒｉｎｇ．
ｄｒｉｖｅｒ．ｇｅｔ（”ｈｔｔｐ：／／ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ／ｓｅａｒｃｈ？ｈｌ＝ａｒ” ＋ ｑｕｅｒｙ）； ／／ Ａｒａｂｉｃ ＵＩ．
ＢｉｄｉＣｈｅｃｋｅｒ．Ｅｒｒｏｒｓ ｂｉｄｉＥｒｒｏｒｓ ＝ ｂｉｄｉＣｈｅｃｋｅｒ．ｃｈｅｃｋＰａｇｅ（ｄｒｉｖｅｒ，
ＢｉｄｉＣｈｅｃｋｅｒ．Ｄｉｒ．ＲＴＬ）； ／／ Ａｒａｂｉｃ ｐａｇｅ ｓｈｏｕｌｄ ｈａｖｅ ＜ｂｏｄｙ ｄｉｒ＝”ｒｔｌ”＞．
ＭｏｒｅＡｓｓｅｒｔｓ．ａｓｓｅｒｔＥｍｐｔｙ（ｂｉｄｉＥｒｒｏｒｓ）； ／／ Ｎｏ ＢｉＤｉ ｅｒｒｏｒｓ！
｝
もう一つの実施形態において、ＵＲＬを受け入れ、ブラウザを開始し、スキャナ３１０をランし、そしてメッセ―ジもしくはエラーをコンソールへと出力する、コマンドライン実行可能ファイル内へとＪａｖａ（登録商標）ＡＰＩをパッケージするコマンドラインツールが提供され得る。

スキャナ３１０はまた、テスト下のウェブページを、エラーをページ上のそれぞれの位置で視覚的にハイライトするために修正するインブラウザＧＵＩと関連付けられ得、ユーザーがそれらを一つずつブラウズすることもしくはそれらを同時に見ることを可能にする。このＧＵＩはコマンドラインツール、ＪａｖａＳｃｒｉｐｔ（登録商標）のようなスクリプト言語、もしくはＪａｖａ（登録商標） ＡＰＩのようなＡＰＩを経由して起動され得る。さらなる実施形態に従うと、偽陽性はエラーの特性に基づいてフィルタリング、保留もしくは抑制され得る。

検出器は不一致値、各発生が発生の近くのテキストコンテンツ文字のような種々の基準に基づいてどこまで疑わしいか、および発生の方向コンテキストがどれだけ「遠く」で最もすぐに宣言されるかのような重大度の指示を提供し得る。例えば、基準はブロック要素が発生の位置とその方向が宣言された先行要素の間との経路上に介在するかどうかを含み得る。

報告器３１６は仕様を満たす疑わしい発生を、それらの疑わしさの度合、それらのテキストコンテンツ、およびそれらが発生する要素の特性（ページ内のその位置を含む）のような種々の特性に基づいて無視するメカニズムを提供し得る。これは、公知のバグと同様に実の問題を表さない偽陽性をフィルタリングで除くことに有用である。

スキャナ３１０は、一実施形態に従うと、ページ内に直接疑わしい発生を表示するために、テストされているページを修正するための特徴を提供し得る。スキャナ３１０はブラウザにより露呈されるページのＤＯＭをスキャンすることによりインプリメントされ得る。スキャナ３１０はまた、ブラウザ内をランするスクリプト内にインプリメントされ得る。スクリプトはウェブページの外部にあり得、しかしまた一方ではウェブページ内へと挿入され得る。これで、宣言テキスト方向を決定するためにブラウザのインフラストラクチャが利用可能となる。スキャナ３１０は、特定の自動化されたウェブアプリケーションテスティングフレームワークと共に使用される、ブラウザページ内にＤＯＭスキャンをインプリメントするスクリプトの挿入を簡単にし、それを実行し、そして結果を回収する能力を提供する（一つもしくは複数の）構成要素を有し得る。

スキャナ３１０は所与のＵＲＬでページをスキャンするスタンドアロンのコマンドラインユーティリティとしてパッケージされ得る。一部の場合において、コマンドラインアプリケーションは、そのページ自体でエラーの位置をハイライトするインブラウザＧＵＩと協力してターミナルへとエラーを出力し得る。

図５は、一実施形態に従った、テキストコンテンツ内の双方向テキストをチェックするための例示的な方法５００のフロー図である。テキストコンテンツはドキュメントもしくはウェブページのコンテンツの全体もしくは一部分を含み得る。方法５００は本発明の一実施形態に関係して記述されるが、方法５００を限定する意味はなく、その他のアプリケーションにおいて使用され得る。例において、方法５００は図３のスキャナ３１０を使用して、テキストコンテンツ内の双方向テキストをチェックするために使用され得る。しかしながら、方法５００はスキャナ３１０に限定される意味はない。図５において示されているように、例示的な方法５００はテキストコンテンツのテキスト部分の固有のテキスト方向が決定されるステップ５０２で始まる。このステップは、例えば、双方向テキストチェッカー３１４により実行され得る。ステップ５０４で、テキスト部分と関連した宣言テキスト方向が決定される。このステップは、例えば、ウォーカー３１２により実行され得る。一部の場合において、ステップ５０４はステップ５０２の前に実行され得る。

ステップ５０６で、双方向テキストエラーは固有のテキスト方向と宣言テキスト方向との間の不一致に基づいて生成される。例えば、双方向エラーは固有のテキスト方向が宣言テキスト方向とマッチしない場合に生成され得る。例えば、固有の右から左テキスト部分は左から右の宣言テキスト方向とマッチしない可能性があり、そしてこの逆もまた同様である。ニュートラルもしくは混合テキスト部分は不一致とみなされない可能性がある。一部の場合において、宣言方向コンテキストもしくはインジケータが存在しない可能性がある。そのようなテキスト部分はその親の要素のテキスト方向もしくはそのウェブページのテキスト方向を継承する。

ステップ５０８で、双方向テキストエラーが報告される。この報告は報告器３１６により実行され得る。エラーはそれらそれぞれの位置で強調もしくはハイライトされ得る。エラーはまた、エラータイプに基づいて報告のために選択される可能性も選択されない可能性もある。一部の場合において、特定のエラー特性のセットを有する双方向テキストエラーのみが報告され得る。そのような特性はエラー位置もしくはエラー重大度を含み得る。ステップ５０２−５０８はソフトウェア、ハードウェア、ファームウェア、もしくはこれらの任意の組み合わせでインプリメントされ得る。

もう一つの実施形態に従うと、ウォーカー３１２はステップ５０２の前にテキストコンテンツを複数のテキスト部分へと分ける。一部の場合において、テキストコンテンツは複数のテキスト部分へと分けられ、各テキスト部分に対して、ルールＸ８を含みＸ８までのユニコード双方向アルゴリズムのアプリケーションはテキスト部分内のすべての文字に偶数埋め込みレベル、もしくはテキスト部分内のすべての文字に奇数埋め込みレベルのいずれかを割り当てる。ステップ５０２−５０８は各テキスト部分に対して実行される。

その他の実施形態に従うと、スキャナ３１０がＪａｖａＳｃｒｉｐｔ（登録商標）でインプリメントされる代わりに、それはブラウザのＤＯＭ内へと統合された一部のその他のプログラミング言語でインプリメントされ得るか、もしくは任意のプログラミング言語でウェブページのソース（ＨＴＭＬファイルなど）をスキャンするようにインプリメントされ得る。ソースをスキャンすることは、しかしながら、それが動的ウェブページ（ＡＪＡＸ）と上手く相互運用しない可能性があるため多少限定的となる。ＪａｖａＳｃｒｉｐｔ（登録商標）はまた、一部のその他のソフトウェアシステムによりエラーのためにスキャンされるために、動的ウェブページのＤＯＭをテキストのフォーマットへとエクスポートするように使用され得る。

ＪａｖａＳｃｒｉｐｔ（登録商標）でスキャナ３１０をインプリメントすることは、それが任意の追加のモジュールとの統合を必要とすることなく任意のウェブブラウザから簡単に起動されることを可能にする。Ｊａｖａ（登録商標）／ウェブドライバ、もしくはその他のシステムに任意選択のＡＰＩを提供することは、それらのプラットフォームを既に使用しているソフトウェア試験項目群内へのスキャナ３１０の統合を促進する。スキャナ３１０、もしくはウォーカー３１２、双方向テキストチェッカー３１４もしくは双方向エラー報告器３１６は、チェックされるテキストコンテンツを含むウェブページ内へと挿入されているＪａｖａＳｃｒｉｐｔ（登録商標）のような外部のスクリプト言語スクリプトから呼び出され得る。

一部の場合において、スキャナ３１０はユーザーがスキャンされるＵＲＬを提出することを含むオンラインサービスとして提供され得る。その他の場合において、スキャナ３１０はブラウザから対話方式で起動されるためにブラウザ拡張機能としてパッケージされ得る。一部の実施形態において、ページ上の双方向テキストエラーを識別するためのその他のアルゴリズムがあり得る。例えば、テキストをそれらの宣言方向性によりセグメントへと区切る代わりに、スキャナ３１０は方向性が変化するところの文字位置の別個のインデックスを生成し得、そして任意の所与の位置で方向性を探索するためにそれを使用し得る。エラー報告のための有用なインブラウザＧＵＩもしくはフィルタリングメカニズムを設計する種々の方法があり得る。

例示的なシステム３００と４００および／もしくは方法５００もしくはその任意の（一つもしくは複数の）部分もしくは（一つもしくは複数の）機能のための実施形態の側面は、ハードウェア、ソフトウェア、モジュール、ファームウェア、命令が記憶されている実体のあるコンピュータ読み取り可能もしくはコンピュータ使用可能記憶媒体、もしくはこれらの組み合わせを使用してインプリメントされ得、かつ一つもしくは複数のコンピュータシステムもしくはその他の処理システム内にインプリメントされ得る。コンピュータ使用可能媒体の例は、限定されることはないが、一次記憶デバイス（例えば、任意のタイプのランダムアクセスメモリ）、二次記憶デバイス（例えば、ハードドライブ、フロッピー（登録商標）ディスク、ＣＤ ＲＯＭ、ＺＩＰディスク、テープ、磁気記憶デバイス、および光記憶デバイス、ＭＥＭＳ、ナノテクノロジー記憶デバイスなど）を含む。

コンピュータ命令は一つもしくは複数のプロセッサを使用して実行され、そして不揮発性記憶媒体もしくは記憶デバイス内に記憶され得る。不揮発性記憶はハードディスクドライブ、フラッシュメモリ、そしてコンピュータプログラム命令およびデータをコンピュータ読み取り可能媒体上に記憶し得る同様のデバイスのうちの一つもしくは複数を含み得る。一つもしくは複数の不揮発性記憶デバイスは取り外し可能な記憶デバイスであり得る。メモリデバイスは、ランダムアクセスメモリ（これに限定されることはないが）のような一つもしくは複数の揮発性記憶デバイスを含み得る。

実施形態は具体的な機能のインプリメンテーションおよびその関連を説明する機能的なビルディングブロックを用いて上で記述されている。これらの機能的なビルディングブロックの境界は、記述の便宜性のために本明細書中で独断的に定められる。代替の境界は、具体的な機能およびその関連が適切に実行される限り定められ得る。

具体的な実施形態の前述の記述は、本発明の一般的な本質を非常に十分に明瞭にし、他者は当該分野の知識を適用することにより、過度な実験をすることなくかつ本発明の一般的な概念から逸れることなく、そのような具体的な実施形態を容易に改変および／もしくは種々の適用に適合し得る。従って、そのような適合および改変は本明細書内に示される教示および手引きに基づく、開示される実施形態の均等物の意味および範囲内にあることが意図される。本明細書内の語法もしくは用語は限定する目的ではなく記述のための目的があることが理解され、本明細書の用語もしくは語法は本教示および手引きの観点から当業者により解釈される。

本発明の広さおよび範囲は上述の例示的な実施形態のいずれによっても限定されることはなく、以下の特許請求の範囲およびその均等物に従ってのみ定義され得る。

Claims (24)

1. テキストコンテンツ内の双方向テキストをチェックするためにコンピュータにインプリメントされた方法であって、該方法は、
   該テキストコンテンツ内の複数のテキスト部分の各テキスト部分に対して：
   該テキスト部分の固有のテキスト方向を決定することと、
   該テキスト部分と関連した宣言テキスト方向を決定することと、
   コンピューティングデバイスを使用して、該固有のテキスト方向と該宣言テキスト方向との間の不一致に基づいた双方向テキストエラーを生成することと、
   該双方向テキストエラーを報告することと、
   を含む、方法。
2. 前記テキストコンテンツを前記複数のテキスト部分へと分けることをさらに含む、請求項１に記載の方法。
3. 固有のテキスト方向を決定することが、
   テキスト部分が左から右スクリプトに属する少なくとも一つの文字を含むが右から左スクリプトに属する文字を含まない場合に左から右方向を識別することと、
   テキスト部分が右から左スクリプトに属する少なくとも一つの文字を含むが左から右スクリプトに属する文字を含まない場合に右から左方向を識別することと、
   を含む、請求項１に記載の方法。
4. 文字がユニコードｂｉｄｉクラスＬであると決定される場合に該文字が左から右スクリプトに属すると決定され、文字がユニコードｂｉｄｉクラスＲもしくはＡＬであると決定される場合に該文字が右から左スクリプトに属すると決定される、請求項３に記載の方法。
5. 双方向テキストエラーを生成することが、前記固有のテキスト方向が左から右であり前記宣言テキスト方向が右から左である場合もしくは前記固有のテキスト方向が右から左であり前記宣言テキスト方向が左から右である場合に不一致を識別することを含む、請求項１に記載の方法。
6. 前記固有のテキスト方向もしくは前記宣言方向のいずれかがニュートラル、混合、不定または左から右もしくは右から左以外、のうちの少なくとも一つである場合に不一致が識別されない、請求項５に記載の方法。
7. 前記宣言テキスト方向を決定することが、
   ユニコード双方向アルゴリズムを前記テキスト部分に、習慣的にこのタイプのコンテンツに適用される任意のよりハイレベルなプロトコルと共に適用することと、
   該ユニコード双方向アルゴリズムにより該テキスト部分の任意の文字に割り当てられた最も低い明示埋め込みレベルと、該ユニコード双方向アルゴリズムが該最も低い明示埋め込みレベルを有する任意の文字にニュートラルオーバーライドステータスを割り当てたかどうかとを注意することと、
   を含み、
   該最も低い明示埋め込みレベルが偶数であってかつニュートラルオーバーライドステータスを有した場合に該宣言方向が左から右であり、該最も低いオーバーライドステータスが奇数であってかつニュートラルオーバーライドステータスを有した場合に該宣言方向が右から左であり、そうでなければ該宣言を不定と宣言する、
   請求項１に記載の方法。
8. 前記テキストコンテンツを前記複数のテキスト部分へと分けることにより、各テキスト部分において該テキスト部分のすべての文字が同一の明示埋め込みレベルおよびオーバーライドステータスを有するようにすることをさらに含む、請求項７に記載の方法。
9. 前記テキストコンテンツを前記複数のテキスト部分へと分けることにより、該テキストコンテンツにこのタイプのコンテンツに対応するよりハイレベルなプロトコルと共に前記ユニコード双方向アルゴリズムを適用することにより定義されるようにいずれのテキスト部分も異なるパラグラフに属する文字を有さないようにすることをさらに含む、請求項８に記載の方法。
10. 前記テキストコンテンツを前記複数のテキスト部分へと分けることにより、該テキスト部分がＬＲＥおよびＲＬＥ文字のような埋め込み方向宣言もしくはマークアップ指示方向を含むと予想されない該テキストコンテンツの一部分でない限りいずれのテキスト部分も混合の固有のテキスト方向を有さないようにすることをさらに含む、請求項９に記載の方法。
11. 前記テキストコンテンツを前記複数のテキスト部分へと分けることにより、該テキスト部分の数を該テキスト部分により覆われている該テキストコンテンツの部分を減らすことなく、可能な限り少なくするようにすることをさらに含む、請求項７に記載の方法。
12. 報告することがエラー特性のセットを有する双方向テキストエラーを報告することを含む、請求項１に記載の方法。
13. 報告することが前記双方向テキストエラーに、以下の一つ：
    （ａ）前記テキスト部分が一つもしくは複数の数字またはニュートラル文字、および０もしくは１つ以上の空白文字から成るストリングで開始もしくは終了する、
    （ｂ）該テキスト部分が、同一のパラグラフに属しかつ前記ユニコード双方向アルゴリズムにより定義されているように同一の明示埋め込みレベルおよびオーバーライドステータスを有するテキスト部分により先行され、該先行のテキスト部分が一つもしくは複数の数字またはニュートラル文字、および０もしくは１つ以上の空白文字から成るストリングで終了する、
    （ｃ）該テキスト部分に、同一のパラグラフに属しかつ該ユニコード双方向アルゴリズムにより定義されているように同一の明示埋め込みレベルおよびオーバーライドステータスを有するテキスト部分が後に続き、該後に続くテキスト部分が一つもしくは複数の数字またはニュートラル文字、および０もしくは１つ以上の空白文字から成るストリングで開始する、
    が適用する場合に重大度値を割り当てることを含む、請求項１２に記載の方法。
14. 前記決定するステップを、チェックされる前記テキストコンテンツを含むウェブページ内へと挿入されている外部のスクリプト言語スクリプトから呼び出すことをさらに含む、請求項１に記載の方法。
15. テキストコンテンツ内の双方向テキストをチェックするためのシステムであって、該システムは、
    ウォーカーであって、該ウォーカーは、
    該テキストコンテンツ内の複数のテキスト部分の各テキスト部分に対して該テキスト部分の固有のテキスト方向を決定することと、
    該テキスト部分の宣言テキスト方向を決定することと、
    を行うように構成されているウォーカーと、
    コンピューティングデバイスと共にインプリメントされた、該固有のテキスト方向と該宣言テキスト方向との間の不一致に基づいた双方向テキストエラーを生成するように構成された双方向テキストチェッカーと、
    該双方向テキストエラーを報告するように構成された双方向エラー報告器と、
    を含む、システム。
16. 前記ウォーカーが前記テキストコンテンツを前記複数のテキスト部分へと分けるようにさらに構成される、請求項１５に記載のシステム。
17. 前記ウォーカーは、
    テキスト部分が左から右スクリプトに属する少なくとも一つの文字を含むが右から左スクリプトに属する文字を含まない場合に左から右方向を識別することと、
    テキスト部分が右から左スクリプトに属する少なくとも一つの文字を含むが左から右スクリプトに属する文字を含まない場合に右から左方向を識別することと、
    を行うようにさらに構成されている、請求項１５に記載のシステム。
18. 文字がユニコードｂｉｄｉクラスＬであると決定される場合に該文字が左から右スクリプトに属すると決定され、文字がユニコードｂｉｄｉクラスＲもしくはＡＬであると決定される場合に該文字が右から左スクリプトに属すると決定される、請求項１５に記載のシステム。
19. 前記双方向テキストチェッカーが、前記固有のテキスト方向が左から右であってかつ前記宣言テキスト方向が右から左である場合、もしくは前記固有のテキスト方向が右から左であってかつ前記宣言テキスト方向が左から右である場合に不一致を識別するようにさらに構成される、請求項１５に記載のシステム。
20. 前記固有のテキスト方向もしくは前記宣言方向のいずれかがニュートラル、混合、不定または左から右もしくは右から左以外、のうちの少なくとも一つである場合に不一致が識別されない、請求項１９に記載のシステム。
21. 前記ウォーカーは、前記テキストコンテンツを前記複数の前記テキスト部分へと分けることにより、各テキスト部分において該テキスト部分のすべての文字が同一の明示埋め込みレベルおよびオーバーライドステータスを有するようにするようにさらに構成される、請求項１５に記載のシステム。
22. 前記ウォーカーは、前記テキストコンテンツを前記複数のテキスト部分へと分けることにより、該テキスト部分にこのタイプのコンテンツに対応するよりハイレベルなプロトコルと共に前記ユニコード双方向アルゴリズムを適用することにより定義されるようにいずれのテキスト部分も異なるパラグラフに属する文字を有さないようにするようにさらに構成される、請求項２１に記載のシステム。
23. 前記ウォーカーは、前記テキストコンテンツを前記複数のテキスト部分へと分けることにより、該テキスト部分がＬＲＥおよびＲＬＥ文字のような埋め込み方向宣言もしくはマークアップ指示方向を含むと予想されない該テキストコンテンツの一部分でない限りいずれのテキスト部分も混合の固有のテキスト方向を有さないようにするようにさらに構成される、請求項２２に記載のシステム。
24. テキストコンテンツ内の双方向テキストをチェックするためにコンピュータにインプリメントされた方法であって、該方法は、
    テキスト部分の固有のテキスト方向を決定することと、
    該テキスト部分と関連した宣言テキスト方向を決定することと、
    コンピューティングデバイスを使用して、該固有のテキスト方向と該宣言テキスト方向との間の不一致に基づいた双方向テキストエラーを生成することと、
    該双方向テキストエラーを報告することと、
    を含む、方法。

Images