文字列検索
この文書の詳細
Copyright © 2016-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2016-2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、より高い相互運用性を可能にするため、Web における文字列検索操作について説明します。 文字列検索とは、Web ブラウザーの "検索" コマンドのような自然言語の文字列照合を指します。 この文書は、Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD] および Character Model for the World Wide Web 1.0: String Matching [CHARMOD-NORM] に含まれる概念に基づき、 仕様の著者、ソフトウェア開発者、およびコンテンツ開発者が、グローバルな利用者に適した検索機能を記述し実装するために必要な情報を提供します。
この節では、この文書の公開時点における状態を説明します。 現在の W3C 公開文書の一覧と、この技術報告書の最新版は、 https://www.w3.org/TR/ の W3C 技術 報告書索引で確認できます。
注意: 作業中
この文書は、国際化ワーキンググループによって現在積極的に開発されているものではありません。 これは、他の I18N 文書では扱いにくかった自然言語テキストにおける部分文字列照合に関する情報を収集し、 Web における部分文字列照合の問題についての議論で、すぐ参照できる資料として役立てるために作成されました。
読者は、ここにある資料が "検索" 機能の実装または仕様化のための完全な指針を表しているとは期待すべきではありません。
この文書は、国際化 ワーキンググループにより、 ノートトラックを使用した グループ草案ノートとして公開されました。
グループ草案ノートは、 W3C またはその会員によって承認されたものではありません。
これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 作業中のもの以外としてこの文書を引用することは不適切です。
W3C 特許 ポリシーは、 この文書に対して、いかなるライセンス要件またはコミットメントも課しません。
この文書は、 2023年11月3日 W3C プロセス文書に従います。
この文書は、文字列検索操作の仕様化または実装に関する問題、要件、および考慮事項を説明します。 文字列検索の一般的な例は、Web ブラウザーの "検索" コマンドですが、仕様が定義したいと考える検索には、 ほかにも多くの形式があります。
この文書は、Character Model for the World Wide Web: Fundamentals [CHARMOD] および Character Model for the Word Wide Web: String Matching [CHARMOD-NORM] を基礎としています。 この文書を正しく理解し適用できるようになるには、それらの文書に含まれる概念を理解することが重要です。
この仕様の主な対象読者は、何らかの形式の search または find アルゴリズムを定義する必要のある W3C 仕様開発者です。その目的は、必要な概念、用語、および要件への安定した参照を提供することです。
この文書で説明する概念は、仕様の著者、ソフトウェア開発者、およびコンテンツ開発者に、 World Wide Web における一貫した相互運用可能なテキスト検索のための共通の参照を提供します。 これら 3 つのグループが協力することで、世界中からアクセスできる Web を構築できます。
この文書には、他の仕様のためのベストプラクティスおよび要件に加えて、実装者およびコンテンツ著者への 推奨事項が含まれています。仕様向けのこれらのベストプラクティス（およびその他のもの）は、 国際化ワーキンググループの文書 Internationalization Best Practices for Spec Developers [INTERNATIONAL-SPECS] にも含まれており、 これは W3C 仕様におけるすべての国際化ベストプラクティスの一般的な参照として役立つことを意図しています。
この文書では、[RFC2119] のキーワードが 大文字のイタリック体で示されている場合、通常の意味を持ちます。また、次のような様式上の慣例を使用します。
定義は、このように異なる背景色と 装飾で表示されます。
ベストプラクティスは、このように異なる背景色と 装飾で表示されます。
課題、ギャップ、および今後の 作業に対する推奨事項は、このように異なる背景色と装飾で表示されます。
この節には、この文書に固有の用語が含まれます。
この文書を理解するために必要な用語の多くは、Internationalization Glossary [I18N-GLOSSARY] によって提供されています。 一部の用語は [CHARMOD-NORM] でも定義されており、 その文書の Terminology and Notation 節で確認できます。
Unicode は、 Universal Character Set とも呼ばれ、Web 文書を世界中のあらゆる書記体系、 用字系、または言語で、任意のコンピューティングプラットフォーム上で作成し、 その後、世界中の Web 利用者によって交換、読解、検索できるようにします。Unicode Standard [Unicode] の最初の数章は、有用な背景知識を提供します。 また、検索に関する章を含む Unicode Collation Algorithm [UTS10] も参照してください。
コーパス 利用者が検索したい文書または文書群に含まれる自然言語テキスト。
セグメンテーション 自然言語テキストを個別の単語や句に分割する処理。 これには、しばしば "固有表現認識"（たとえば、3 語からなる並び Dr. Jonas Salk が 人名であると認識すること）のような操作が含まれます。
ステミング 単語をその "stem" すなわち語根へ縮約する処理または操作です。たとえば、runs、 ran、および running という語は、いずれも語幹 run を共有します。 これは、より正式には lemmatization と呼ばれることがあり、stem は lemma と呼ばれることもあります。
全文 検索とは、テキスト文書または文書群の内容全体を処理する検索を指します。全文クエリーは、 英語や日本語など特定の言語の規則に基づいて単語や句を操作することにより、全文索引内の テキストデータに対して言語的な検索を行います。全文クエリーには、単純な単語や句、または 単語や句の複数の形を含めることができます。
多くの場合、これは 全文検索が索引と自然言語処理を用いることを意味します。 検索エンジンを使用しているとき、あなたは全文検索の一形態を使用しています。全文検索では、自然言語テキストを 単語または句に分割することがよくあります（これはセグメンテーションと呼ばれます）。また、単語の意味的な "root" 値を得るために複雑な処理を適用する場合があります（これはステミングと呼ばれます）。これらの処理は、 言語、文脈、およびテキスト上の変異の多くの側面に影響されます。
自然 言語処理（NLP）とは、 人間の言語（すなわち自然 言語）を理解、処理、操作するよう設計されたソフトウェアの領域を指します。これは非常に広範な用語です。 単語のトークン化のような比較的単純な問題から、テキストから "意味" を導出すること、 品詞を認識すること、正確な翻訳を行うことなど、より複雑な振る舞いまで含むことができます。
Web の利用者は、行ごとに読むことなく、文書または文書集合内の特定のテキストを検索したいと考えることがよくあります。 仕様では、この要望を支援するため、Web プラットフォームにおいてテキスト検索を公開しようとすることがあります。
文書検索にはさまざまな種類があります。その 1 つは全文検索と呼ばれ、 検索エンジンのようなアプリケーションで最もよく見られる種類の検索です。この種類の検索は複雑で、 リソースを多く消費する場合があり、しばしば特定の検索要求の範囲外にある処理に依存します。
より限定的な形式のテキスト検索（そしてこの文書の主題）は、部分文字列照合
です。
部分文字列照合の身近な形式の 1 つは、ブラウザーやその他の種類のユーザーエージェントの
検索
機能です。物理キーボードを備えたユーザーエージェントでは、この機能は多くの場合、
Cmd+F や Ctrl+F のようなキーの組み合わせで利用されます。このような機能は、
現在まだ完全には標準化されていない API window.find、または提案されている
[SCROLL-TO-TEXT-FRAGMENT] のような機能を通じて Web
に公開される可能性があります。
find 操作は、照合動作を改善または調整するための任意の仕組みを提供できます。たとえば、 大文字小文字の区別を追加（または削除）する機能、 ワイルドカード文字など正規表現言語のさまざまな側面をその機能がサポートするかどうか、 または照合を単語全体に限定するかどうかなどです。
部分文字列照合が通常全文検索と異なる点の 1 つは、 テキスト上の変異を抑制または無視しようとしてさまざまなアルゴリズムを使用する場合はあるものの、 通常は、ステミングやその他のNLP処理から生じるような、追加または未指定の文字列、 単語、または句を含む一致を生成しないことです。
部分文字列照合を標準化しようとするとき、仕様の著者は、コンピューターシステムにおける 自然言語の符号化に内在する複雑さに しばしば苦労します。これには、[Unicode] 標準で文字を符号化するために用いられるさまざまな仕組みが含まれます。
非常によくあることですが、利用者の入力は、検索対象の文書で使用されている符号位置の並びと完全には同じでないにもかかわらず、 利用者は一致が起こることを期待します。これはさまざまな理由で起こりえます。検索対象のテキストが、利用者には予測できない形で 変化しているためである場合もあります。別の場合には、利用者のキーボードまたは入力方式が、必要なテキスト上の変異へすぐに アクセスできる手段を提供していないためです。さらに、利用者がテキストを正確に入力する手間をかけたくないだけである場合さえあります。
この節では、部分文字列照合 API または機構を仕様化する際に仕様の著者が考慮する必要のある、 私たちが把握しているさまざまな一般的な事例を検討します。
検索語が文書またはコーパスの特定部分に一致するかどうかに関する利用者の期待は、ときに利用者の言語、 文書の言語、またはその両方に依存します。また、特定のデバイスでどのキーボードまたは入力方式が利用可能かといった、 その他の要因が関係することもあります。これは、大文字小文字の畳み込みなど、検索の一部であるさまざまな操作がロケールの影響を受けるため、 または、人間の言語と文化の複雑さを考えると、一致に関する期待や、さまざまな文字列の使用および解釈に関する期待が、 特定の用字系の内部でさえ異なるためである可能性があります。 同様に、アクセント、代替の用字系、または文字符号化（書記素 クラスターの形成における変異など）の扱いは、対象となるテキストの特定の言語に結び付いています。
ここで私たちが意味しているのは用字系ではなく、言語であることを強調しておくことが重要です。 同じ用字系を共有する多くの異なる言語が、それぞれ異なる処理を適用したり、異なる期待を含意したりします。
"検索" 機能の実装は、多くの場合、利用者の入力だけ、または実行時環境におけるさまざまな "手がかり"、 たとえばオペレーティング環境のロケール、ユーザーエージェントのローカライズ、アクティブなキーボードの言語などに基づいて、 利用者が意図した言語を推測しなければなりません。これらの手がかりは、よくても利用者の意図の代用にすぎず、 特に利用者がこれらのいずれにも一致しない文書を検索している場合や、検索対象の文書に複数の言語が含まれている場合にはそうです。
利用者は、小文字で入力した語が大文字の等価形に一致することを期待する場合があります（また、その逆も期待するかもしれません）。 ブラウザーの "検索" コマンドのような部分文字列照合機能は、多くの場合、入力の大文字小文字をテキストのものと一致させるかどうかについて、 利用者が選択できるオプションを提供します。
大文字小文字の畳み込みに関する概観については、[CHARMOD-NORM] の こちらの議論を参照してください。
Unicode は文字間の正準関係および互換関係を定義しており、それが文字列検索に対する利用者の認識に影響することがあります。 Unicode 正規化形式に関する詳細な議論については、[CHARMOD-NORM] の 2.2 節、および Unicode Normalization Forms [UAX15] にある定義を参照してください。
多くの複雑な用字系では、文字または母音記号を複数の方法で符号化できる場合がありますが、 それらの代替形は正準等価です。
一部の言語は複数の用字系で書かれます。文書を検索する利用者は、ある用字系でテキストを入力しても、 両方の用字系で等価なテキストを見つけたいと思う場合があります。
一部の互換文字は、レガシー文字 エンコーディングにおける単一バイトまたは複数バイト表現を考慮するため、または東アジアの言語における特定のレイアウト動作との 互換性のために Unicode に符号化されました。
多くの用字系は、0 から 9 までの数字について独自の数字文字を持っています。一部の Web アプリケーションでは、 表示目的のために、見慣れた ASCII 数字がローカルな数字の字形に置き換えられます。別の場合には、 テキストが実際にローカルな数字の Unicode 文字を含んでいることがあります。文書を検索しようとする利用者は、 ある形式の数字を入力すれば、等価な数字を見つけられることを期待するかもしれません。
一部の言語には、地域または方言によって異なる正書法の伝統があったり、同じ語の異なる綴りを許容したりします。 検索およびスペルチェックは、これらの変異について知る必要がある場合があります。
インド系文字の言語には、この種の問題が多く存在します。これらは綴りの誤りである場合もありますが、 別の場合には複数の綴りが許容されます。
たとえば、ベンガル語（言語タグ bn）は、
言語によって許される綴りの変異が非常に多いことで知られています。ベンガル語の単語のほぼ 80% には、
少なくとも 2 つの綴りがあります。多くの語には 3、4、またはそれ以上の変異があり、少なくとも 1 つの語には
16 の異なる有効な綴りがあります。
他のインド系文字は、特定の音を表すための代替機構を提供しており、多くの場合、どちらの表現も同等に有効と見なされます。 この最も一般的な例は、音節末鼻音の表現に関係します。
たとえば、ヒンディー語で snake を表す語に含まれる /n/ 音は、 ँ [U+0901 DEVANAGARI SIGN CANDRABINDU] または ं [U+0902 DEVANAGARI SIGN ANUSVARA] のいずれかを使って書くことができます。次の 2 つはいずれも有効な綴りとして可能です:
この話にさらにひねりを加えると、ここでは異なる符号位置を持つ 2 つの発音区別記号を使用できます。 前の例では、鼻音を表すために ं [U+0902 DEVANAGARI SIGN ANUSVARA ] を使用しました。これは、付随する母音記号が吊り下げ基線より上に上がるためです。もし母音記号が吊り下げ基線より上に 上がらないものであれば、通常は代わりに ँ [U+0901 DEVANAGARI SIGN CANDRABINDU ] を使用します。 これら 2 つの発音区別記号の機能は同じですが、符号位置は異なります。
音節末鼻音に対して文字または発音区別記号のいずれかを代替的に使用することは、
ほかのいくつかのインド系言語にも共通しています。ヒンディー語（言語タグ hi）や
マラーティー語（言語タグ mr）などの言語を書くために使われるデーヴァナーガリーに加えて、マラヤーラム文字、
グジャラーティー文字、オディア文字などの用字系も同様の綴りの選択肢を提供します。
一部の言語では空白を使って単語、文、または段落を分離しますが、そうしない言語もあります。 部分文字列照合を行う際には、[Unicode] にある さまざまな形式の空白を正規化して、一致が成功するようにしなければなりません。
利用者は、検索語を入力する際に、ラテン文字のようなさまざまな発音区別記号を使用する用字系で、 アクセントや発音区別記号を含む文字を扱うとき、自分の入力を変えることがあります。これは、検索対象のテキストには 追加の記号が含まれている場合であっても起こります。これは特にモバイルキーボードで当てはまり、 これらの文字を入力するには追加の手間が必要になることがあります。このような場合、利用者は一般に、 必要な追加の手間をかけなかったことを補うために、検索操作がより "寛容" であることを期待します。
この効果は文脈によっても異なる場合があります。たとえば、物理キーボードを使っている人はアクセント付き文字へ 直接アクセスできる場合がありますが、仮想キーボードまたはオンスクリーンキーボードでは、同じ文字へアクセスして選択するために 追加の手間が必要になることがあります。
一部の正書法では、異なる文字数を持つ文字列を一致させる必要があります。
この代表的な例は、アブジャドにおける母音発音区別記号に関係します。 たとえば、アラビア文字およびヘブライ文字を使用する一部の言語では、利用者が短母音を入力することは必須ではありません （ただし任意で許可されます）。（これらの用字系を使う他の一部の言語では、短母音を含めることは任意ではありません。） 入力されるテキストまたは検索対象のテキストに母音が存在するかどうかは、利用者がそれらを入力しない、または入力すべきことを 知らない場合に、一致を妨げる可能性があります。
場合によっては、視覚的に類似または同一の字形パターンが、異なる符号位置列から作られることがあります。 これは意図的な場合もあり、変異は Unicode 正規化によって除去できます。しかし、類似して見える書記素が正規化によって同一にならず、 意味的にも等価ではない場合もあります。
アラビア文字を使用する一部の言語にも、複数の方法で符号化できる書記素があります。 場合によっては、これらの変異はUnicode 正規化によって処理されますが、別の場合には、視覚的には同一に見えても、 Unicode によって等価とは見なされません。これらの変異は、有効な綴りの変異と見なされることもあります。 別の場合には、利用者の誤った認識の結果です。
英語やアラビア語のように、単語間に空白を使用する言語もあります。中国語、 日本語、タイ語のように、そうしない言語もあります。一部の言語では、句など他のテキスト単位を分離するために 空白を使用します。単語間に空白を使用しない言語では、"単語全体" の照合を計算するには、 境界そのものがテキストに符号化されていない場合に、単語境界を判定する能力に依存することがよくあります。
この節は、文書全体の再設計の一環として、文書化が必要な新しい領域として特定されました。 ここにあるテキストは不完全であり、さらに開発する必要があります。コミュニティからの貢献を歓迎します。
実装者は単純な "テキスト検索" アルゴリズムを提供する必要があることが多く、仕様ではしばしば これらの必要性をサポートする API を定義しようとします。テキストに対する検索操作は、文書形式や プロトコルに必要な絶対的な同一性照合とは異なる利用者の期待を生み出すため、異なる要件を持ちます。 ドメイン固有の要件が追加の制約を課したり、ここで示す考慮事項を変更したりする可能性があることに注意することが重要です。
利用者による入力労力の増加は、より選択的な照合に反映されるべきです。
利用者が入力により多くの労力を費やす場合、たとえば Shift キーを使用して大文字を生成したり、 基本文字だけでなく発音区別記号付きの文字を入力したりする場合、検索結果がそのより具体的な入力に （のみ）一致することを期待するかもしれません。
文字列検索 API またはアルゴリズムを作成する際、次のテキスト上のオプションが利用者にとって有用な場合があります:
W3C 国際化ワーキンググループおよびインタレストグループ、 ならびにその他の人々から、多くのコメントと提案が提供されました。ワーキンググループは、 長年にわたる Character Model シリーズ文書の開発に貢献したすべての人々に感謝します。
この例の例は、Henri Sivonen が作成したページから取られたものであり、 この課題に彼が記録した多くの概念やアイデアも同様です。