文字列検索
この文書の詳細
Copyright © 2016-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Copyright © 2016-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書では、より高い相互運用性を実現するために、Web における文字列検索操作について説明します。 文字列検索とは、Web ブラウザーの "検索" コマンドのような自然言語文字列の照合を指します。 この文書は、World Wide Web の文字モデル 1.0: 基礎およびWorld Wide Web の文字モデル: 文字列 照合で示されている概念を基礎として、仕様の著者、ソフトウェア開発者、およびコンテンツ 開発者が、世界中の利用者に適した検索機能を記述し実装するために必要な情報を提供します。
この節では、この文書の 公開時点でのステータスについて説明します。現在のW3C 刊行物の一覧およびこの技術報告書の最新の改訂版は、 次の W3C標準および草案の 索引で参照できます。
注意: 作業中
この文書は、国際化ワーキンググループによる 活発な開発の対象ではありません。他のI18N文書では主題から外れていた、自然言語テキストにおける 部分文字列照合に関する情報を収集するとともに、Web上での部分文字列照合の問題について 議論する際にすぐに参照できる資料として作成されました。
読者は、ここにある資料が「検索」機能の実装や仕様策定に関する 包括的な指針を示していると期待すべきではありません。
この文書は、国際化 ワーキンググループにより、 グループノート草案として ノート トラックを用いて公開されました。
グループノート草案は、 W3Cおよびその会員による承認を受けていません。
これは草案文書であり、他の文書によっていつでも 更新、置換、または廃止される可能性があります。この文書を作業中の文書以外のものとして 引用することは不適切です。
この文書には、 W3C 特許 ポリシー に基づくライセンス要件または確約は 適用されません。
この文書は、次の文書に従います: 2025年8月18日付のW3Cプロセス文書。
W3Cの国際化ワーキンググループとインタレスト グループ、およびその他の方々から、多くのコメントや提案が寄せられました。ワーキンググループは、 文字モデルの一連の文書の長年にわたる開発に貢献してくださった すべての方々に感謝します。
この例に含まれる例は、Henri Sivonenが作成したページから引用しました。また、彼がこの課題に記録した多くの概念やアイデアも取り入れました。
この文書では、文字列検索操作の仕様策定または 実装に関する問題、要件、考慮事項について説明します。文字列検索の一般的な例は、Webブラウザーの「検索」 コマンドですが、仕様で定義することが考えられる検索の形態は、ほかにも 数多くあります。
この文書は、World Wide Webの文字モデル: 基礎 [CHARMOD] および World Wide Webの文字モデル: 文字列照合 [CHARMOD-NORM] に基づいています。 この文書を適切に理解して適用するためには、これらの文書の概念を 理解することが重要です。
この仕様の主な対象読者は、何らかの検索アルゴリズムを定義する必要のあるW3C 仕様の開発者です。その目標は、 必要な概念、用語、要件について安定した参照資料を提供することです。
この文書で説明する概念は、仕様の作成者、ソフトウェア開発者、 コンテンツ開発者に対し、World Wide Webで一貫性と相互運用性のあるテキスト検索を行うための 共通の参照資料を提供します。この3つのグループが協力することで、世界中からアクセスできるWebを構築できます。
この文書には、他の仕様に対するベストプラクティスと要件に加え、 実装やコンテンツ作成者への推奨事項も含まれています。これらの仕様向けのベストプラクティス （およびその他のもの）は、国際化ワーキンググループの文書 仕様開発者のための国際化ベストプラクティス [INTERNATIONAL-SPECS] にも掲載されています。 この文書は、W3C仕様における国際化のあらゆるベストプラクティスの総合的な参照資料となることを目的としています。
この文書では、[RFC2119] のキーワードが 大文字の斜体で示されている場合、通常の意味を持ちます。また、次の表記規約も使用します:
定義は、このように異なる背景色と 装飾で表示されます。
ベストプラクティスは、このように異なる背景色と 装飾で表示されます。
課題、不足事項、今後の作業に対する推奨事項は、 このように異なる背景色と装飾で表示されます。
この節には、この文書に固有の用語を示します。
この文書を理解するために必要な用語の多くは、国際化 用語集 [I18N-GLOSSARY] で提供されています。一部の用語は、 [CHARMOD-NORM] でも定義されており、 その文書の用語と表記法の 節で参照できます。
Unicodeは、 国際 符号化文字集合とも呼ばれ、あらゆるコンピューティングプラットフォーム上で、世界中のどの表記体系、 用字系、言語でもWeb文書を作成し、その文書を世界中のWeb利用者が 交換し、読み、検索できるようにします。Unicode標準 [Unicode] の最初の数章は、有用な背景資料です。また、 Unicode照合アルゴリズム [UTS10] も参照してください。これには、 検索に関する章が含まれています。
コーパス 利用者が検索したい文書または文書群に 含まれる自然言語のテキスト。
区別するまたは 区別しない。検索語と、コーパス内のテキストとの間の違いを、 いずれかに見られる特徴に基づいて検索操作が区別する程度。 検索語とコーパスに何らかの相違や変異があるために一致しない場合、その検索は区別するといい、 コーパスとのそのような相違を無視する場合は区別しないといいます （その結果、検索語はコーパス内で一致します）。さまざまな種類の 区別の例は、2.2 等価性の判定に関する問題にあります。たとえば、大文字・小文字の 区別、アクセント記号や発音区別符号の区別、用字系の区別などです。
分割 自然言語の テキストを個々の単語や句に分ける処理。これには、「固有表現認識」 （たとえば、Dr. Jonas Salkという3語の並びが 人名であると認識すること）などの操作が含まれることがよくあります。
語幹抽出 単語を その「語幹」または語根に還元する処理や操作。たとえば、runs、 ran、runningという単語は、すべてrunという語幹を共有します。これは、 （より正式には）見出し語化と呼ばれることもあり、語幹は 見出し語と呼ばれることもあります。
全文 検索とは、テキスト文書または文書群の内容全体を 処理する検索を指します。全文検索クエリーは、英語や日本語などの特定の言語の規則に基づいて 単語や句を処理することで、全文索引内のテキストデータに対して言語学的な検索を実行します。 全文検索クエリーには、単純な単語や句、または単語や句の複数の形態を含めることができます。
これは多くの場合、全文検索が索引と自然言語 処理を使用することを意味します。検索エンジンを使うときは、ある種の全文検索を使っています。全文 検索では、多くの場合、自然言語のテキストを単語や句に分けます（これは分割と呼ばれます）。さらに、単語の意味上の「語根」を得るために 複雑な処理を適用することもあります（これは語幹抽出と呼ばれます）。これらの処理は、 言語、文脈、およびテキストの変異に関する多くの側面に左右されます。
自然 言語処理（NLP）とは、 人間の言語（すなわち、自然 言語）を理解し、処理し、操作するために設計されたソフトウェアの分野を指します。これは非常に広範な用語です。 単語のトークン化のような比較的単純な問題から、テキストからの「意味」の導出、品詞の 認識、正確な翻訳の実行など、より複雑な動作まで、さまざまなものを含みます。
表意文字異体字シーケンスとは、異体字シーケンスのうち、 表意文字異体字 データベースに登録されているものを指します。表意文字異体字シーケンスの基底文字は、表意 文字でなければならず、U+E0100..U+E01EFの範囲の異体字セレクターを使用します。表意文字異体字 シーケンスという用語は、「IVS」と略されることもあります。Unicodeの 定義および[UTS37] も参照してください。
漢字やその他の表意文字の場合、すべての利用者のあらゆるニーズを同時に満たす単一の異体字 シーケンスのコレクションを構築することは不可能です。学者、 政府、出版社の要件は異なりすぎているため、単一のコレクションでは対応できません。代わりに、 複数の独立したコレクションを設けることで対応できます。Unicodeは、表意文字異体字データベース [UTS37] を定義しています。これは、 個々の異体字シーケンスに対して単一の定義が存在することを保証し、そのような異体字 シーケンスを使用するテキストの交換の信頼性を確保するためです。
Webの利用者は、文書または文書群を1行ずつ読むことなく、 特定のテキストを検索したいと考えることがよくあります。仕様では、Webプラットフォームでテキスト検索を 公開することによって、この要望に応えようとする場合があります。
文書の検索には、さまざまな種類があります。その1つである全文検索は、 検索エンジンなどのアプリケーションで最もよく見られる検索です。この種類の検索は 複雑で、大量のリソースを必要とすることがあり、個々の検索要求の範囲外にある処理に 依存することもよくあります。
より限定的なテキスト検索の形態（そしてこの文書の主題）が、部分文字列照合
です。
よく知られた部分文字列照合の形態として、ブラウザーやその他の種類のユーザーエージェントの検索
機能が
あります。物理キーボードを備えたユーザーエージェントでは、この機能は多くの場合、
Cmd+FやCtrl+Fなどのキーの組み合わせで利用できます。このような機能は、
現時点で完全には標準化されていないAPIであるwindow.findや、
提案中の[SCROLL-TO-TEXT-FRAGMENT] などの機能を通じてWebに公開される可能性があります。
検索操作では、照合動作を改善または調整するための任意の仕組みを提供できます。たとえば、 大文字・小文字の区別を有効（または無効）にする機能、その機能が ワイルドカード文字などの正規表現言語のさまざまな側面をサポートするかどうか、あるいは 一致を単語全体に限定するかどうかなどです。検索がこのような変異にどの程度注意を払うかを、 検索の感度といいます。これについては、検索の 感度で説明します。
部分文字列照合が通常、全文検索と異なる点の1つは、 テキストの変異を抑制または無視しようとしてさまざまなアルゴリズムを使用することはあっても、 通常は、追加の、または指定されていない文字シーケンス、単語、句を含む一致を 生成しないことです。そのような一致は、語幹抽出やその他のNLP処理によって生じるものです。
部分文字列照合を標準化しようとする際、仕様の作成者は、コンピューターシステムで 自然言語を符号化することに内在する 複雑さに苦慮することがよくあります。これには、[Unicode] 標準で文字を符号化するために採用されているさまざまな仕組みも含まれます。
検索操作は、テキストの変異にどの程度注意を払うかという点で異なります。大文字・小文字を区別しない検索では、
a
とA
の違いを無視します。発音区別符号を無視する検索では、
cote
とcôte
が一致します。完全一致を要求する検索では、これらの違いをどれも無視しません。
検索操作がこのような変異を区別する程度を、その検索の感度といいます。
以下で説明するテキストの変異の種類と、検索に関する考慮事項では、 オプションが選択されていない場合に検索が既定で適用する感度を推奨しています。このような既定値は、 実装やAPIが異なる感度の水準を提供することを妨げません。
利用者に検索機能を提供する実装には、次のことが推奨されます: 利用者が既定の動作よりも感度の高い照合を得られるようにすること。 これには、大文字・小文字や発音区別符号を区別する照合が含まれます。
仕様が作成者に検索機能を公開する場合、その機能の呼び出し時に作成者が照合の感度を 設定できることが推奨されます。
コンテンツ作成者は、ブラウザーの検索
コマンドなど、ユーザーエージェントが
利用者に直接提供する検索機能の感度を設定できません。作成者は、別の方法で照合に
影響を与えます。テキストの言語などの情報を提供する方法（言語による照合の違いを参照）や、独自の検索
機能を実装する方法があります。
実装者は単純な「テキスト検索」アルゴリズムを提供する必要があることが多く、 仕様ではその必要性を満たすAPIを定義しようとすることがよくあります。テキストの検索操作は、 文書形式やプロトコルで必要とされる厳密な同一性の照合とは異なる利用者の期待を生むため、 要件も異なります。特定の分野の 要件によって、追加の制約が課されたり、ここで示す考慮事項が変わったりする可能性があることに注意する必要があります。
利用者が入力により多くの手間をかける場合、推奨されるのは、 それをより選択的な照合に反映することです。
利用者が、Shiftキーを使って大文字を入力したり、基底文字だけでなく 発音区別符号を伴う文字を入力したりするなど、入力により多くの手間をかける場合、 そのより具体的な入力に（だけ）検索結果が一致することを期待するかもしれません。
利用者の入力が、検索対象の文書で使われているものと完全に同じ符号位置のシーケンスで 構成されていなくても、利用者が一致を期待することはよくあります。これにはさまざまな 理由があります。検索対象のテキストが、利用者には予測できなかった形で 異なっているためである場合もあります。利用者のキーボードや入力方式では、 必要なテキストの変異を容易に入力できないためである場合もあります。利用者が テキストを正確に入力する手間をかけたくないためであることさえあります。
この節では、部分文字列照合のAPIや仕組みを規定する際に仕様の作成者が 考慮する必要のある、私たちが把握しているさまざまな一般的な事例を検討します。
検索語が文書またはコーパスの特定の部分と一致するかどうかについての利用者の期待は、利用者の言語、 文書の言語、またはその両方に依存する場合があります。特定の機器で利用できるキーボードや入力方式など、 その他の要因が関係する場合もあります。これは、ケースフォールディングなど、検索の一部となる さまざまな操作がロケールの影響を受けるためである可能性があります。また、人間の 言語や文化の複雑さを考慮すると、照合や、さまざまな文字シーケンスの使用と解釈に関する 期待が、同じ用字系の中でさえ異なるためである可能性もあります。同様に、 アクセント記号、代替の用字系、文字符号化（書記素 クラスターの構成の違いなど）の扱いは、対象のテキストの具体的な言語と結び付いています。
ここでいうのは言語であって、用字系ではないことを強調する必要があります。同じ用字系を 共有する多くの異なる言語では、適用する処理や想定される期待が異なります。
「検索」機能の実装は、多くの場合、利用者の入力だけ、あるいは 動作環境のロケール、ユーザーエージェントのローカライズ、現在使用中のキーボードの言語など、 実行時環境のさまざまな「手掛かり」だけを基に、利用者が意図した言語を推測しなければなりません。これらの 手掛かりは、あくまで利用者の意図を間接的に示すものにすぎません。特に、利用者が検索する 文書の言語がこれらのいずれとも一致しない場合や、検索対象の文書に複数の 言語が含まれている場合はそうです。
既定では、文字列検索に推奨される動作は、 大文字・小文字を区別しないことです。
利用者は、小文字で入力した検索語が、それと等価な大文字の形に一致すること（そして場合によっては その逆も）を期待するかもしれません。ブラウザーの「検索」コマンドなどの部分文字列照合機能では、 入力とテキストの大文字・小文字を一致させるかどうかを利用者が選択できるオプションを提供することがよくあります。
ケースフォールディングの概説については、こちらの[CHARMOD-NORM] の説明、および [Unicode] の第5章にある 大文字・小文字の対応付けという節を参照してください。
大文字・小文字を区別しない文字列検索では、推奨されるのは、既定でUnicodeの 完全なケースフォールディングを使用することです。
Unicodeは、各符号位置に対して既定のケースフォールディングを定義しています。ほとんどの文字では、既定の処理は
1つの文字を別の1つの文字に対応付けます。Unicodeでは、これらの対応付けを共通（ステータス
C）と呼びます。少数の文字は、2つ以上の文字に対応付けられます。Unicodeでは、
これらの対応付けを完全（ステータスF）と呼びます。共通の対応付けと完全な対応付けを
併用すると、Unicodeの完全なケースフォールディングになります。これはUnicode全体の既定のケースフォールディング
です。たとえば、共通の対応付けでは、ケルビン記号KU+212A KELVIN SIGNが
k
に一致する一方、完全な対応付けでは、ドイツ語の文字ßU+00DF LATIN SMALL LETTER SHARP Sがシーケンスss
に一致します。
対応付けとそのステータスを示す文字は、CaseFolding.txtで
定義されています。このファイルは、Unicode文字データベース[UAX44] に含まれます。
ケースフォールディングだけでは、文字の全角形と半角形を一致させることはできません:
ＫU+FF2B FULLWIDTH LATIN CAPITAL LETTER Kは、ケースフォールディングによって
全角のｋ
に対応付けられ、半角のk
には対応付けられません。これらの形を一致させるには、
東アジアの文字幅で説明する追加の処理が必要です。
実装では、推奨されない動作として、ケースフォールディングに言語固有の 調整を既定で適用することが挙げられます。
実装では、任意で、トルコ語やアゼルバイジャン語で使用されるテュルク語用の対応付けなど、 ケースフォールディングに言語固有の調整を適用してもかまいません。ただし、検索語の言語が 判明している場合に限ります。
Unicodeの既定のケースフォールディングは言語に依存しません。どの言語でも、大文字のI
を
小文字のi
に対応付けます。これはテュルク諸語の利用者が期待する動作ではありません。これらの言語では、
I
とı
（ıU+0131 LATIN SMALL LETTER DOTLESS I）が大文字・小文字だけの異なる組であり、
İ
とi
も同様だからです。Unicode文字データベースは、これらの文字に対して個別の
対応付け（ステータスT）を提供しています。これらは、Unicodeが定義する唯一の
言語固有のケースフォールディングです。この調整を行うと、
ILIK
のような検索語はılıkという単語に一致しますが、調整しなければ、検索でその
単語が見落とされます。
ただし、言語固有の調整を適用することは、既定の動作としては適切ではありません。照合する2つの文字列が 異なる言語であり、さらに別の第3の言語の文脈に現れる可能性があります。また、 上記の言語による照合の違いで説明したように、 検索語やテキスト全体の言語は、不明であったり、信頼できなかったりすることがよくあります。
Unicodeは、文字間の正準的な関係と互換性の関係を定義しており、これらは文字列検索に対する 利用者の認識に影響する可能性があります。Unicodeの正規化形式の詳細については、 [CHARMOD-NORM] の第2.2節、および Unicode正規化形式 [UAX15] の定義を参照してください。
多くの複雑な用字系では、文字や母音記号を複数の方法で符号化できますが、 それらの表現は正準的に等価です。
複数の用字系で書かれる言語もあります。文書を検索する利用者は、ある用字系でテキストを入力しても、 両方の用字系で等価なテキストを見つけたいと考えるかもしれません。
全角と半角の文字形の違いについて推奨されるのは、利用者が別途指定しない限り、検索時に無視することです。
一部の互換文字は、従来の文字 符号化方式における1バイトまたは複数バイトの表現に対応するため、あるいは東アジア言語の特定のレイアウト動作との互換性のために、Unicodeに符号化されました。
Unicodeには、先行する文字の異体字形を指定するために使用される、いくつかの異体字セレクターが 含まれています。
たとえば、1つの表意文字は、
使用される異体字セレクター（VS）によって複数の異体字を持つことがあります。たとえば、龍U+9F8D CJK UNIFIED IDEOGRAPH-9F8Dの後に、
U+E0100 VARIATION SELECTOR-17や
U+E0101 VARIATION SELECTOR-18などの異なる異体字セレクターを続けると、異なる字形を表す場合があります:
| 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|
| 龍󠄀 | 龍󠄁 | 龍󠄂 | 龍󠄅 | 龍󠄆 |
| VS-17 | VS-18 | VS-19 | VS-22 | VS-23 |
| 龍󠄈 | 龍󠄉 | 龍󠄊 | 龍󠄋 | 龍󠄌 |
| VS-25 | VS-26 | VS-27 | VS-28 | VS-29 |
文字列検索操作では、表意文字だけを対象として照合を行うのか、 表意文字異体字シーケンス（IVS）全体を対象とするのかを考慮する必要があります。
文字列検索を実行するときは、IVS（たとえば、龍󠄀U+9F8D CJK UNIFIED IDEOGRAPH-9F8D + U+E0100 VARIATION SELECTOR-17）を
1つの単位として扱い、最初の符号位置を処理の基準として使用してください。
可能であれば、異なる利用者のニーズに対応するため、「あいまい」と「厳密」の両方の検索モードをサポートしてください。
IVSのほかにも、他の言語に異体字セレクターがあります。
ユーザーエージェントは、任意で、数値を表す文字を、 文字列検索操作において対応するASCIIの形（0-9）に対応付けてもかまいません。
多くの用字系には、0から9までの数を表す固有の数字があります。一部のWebアプリケーションでは、 表示のために、よく知られたASCII数字を地域固有の数字の字形に置き換えます。他の 場合には、テキストに地域固有の数字のUnicode文字が実際に含まれていることがあります。文書を 検索しようとする利用者は、ある形の数字を入力すると、等価な数字が見つかることを期待するかもしれません。
言語によっては、地域や方言によって正書法の伝統が異なったり、 同じ単語に異なる綴りが認められたりします。検索や綴りの検査では、これらの 変異を把握する必要があるかもしれません。
インド系文字を用いる言語には、この種の問題の事例が数多くあります。綴りの 誤りである場合もありますが、複数の綴りが許容される場合もあります。
たとえば、ベンガル語（言語タグbn）は、
言語として許容される綴りの変異が幅広いことで知られています。ベンガル語の単語の約80%には、
少なくとも2つの綴りがあります。多くの単語には3つ、4つ、あるいはそれ以上の変異があり、
少なくとも1つの単語には、16種類の異なる正しい綴りがあります。
他のインド系文字では、特定の音を表すための代替の仕組みが提供されており、 ほとんどの場合、どちらの表現も同じように正しいと見なされます。この最も一般的な事例は、 音節末の鼻音の表記に関するものです。
たとえば、ヒンディー語で蛇を意味する単語の/n/という音は、 ँ [U+0901 DEVANAGARI SIGN CANDRABINDU] またはं [U+0902 DEVANAGARI SIGN ANUSVARA] のいずれかを使って書けます。次のどちらも正しい綴りとして使用できます:
さらにこの話を複雑にする点として、ここでは異なる符号位置を持つ2つの発音区別符号を 使用できることがあります。前の例では、ं [U+0902 DEVANAGARI SIGN ANUSVARA ]を使って 鼻音を表しました。これは、付随する母音記号が、文字を吊り下げる 基準線より上に突き出しているためです。母音記号がこの基準線より上に突き出さないものであれば、 通常は、代わりにँ [U+0901 DEVANAGARI SIGN CANDRABINDU ]を使います。これらの 発音区別符号はどちらも同じ機能を持ちますが、符号位置は異なります。
音節末の鼻音に文字または発音区別符号のいずれかを使用することは、
他のいくつかのインドの言語にも共通しています。ヒンディー語
（言語タグhi）やマラーティー語（言語タグmrなどを書くのに使用されるデーヴァナーガリー文字に加え、マラヤーラム文字、グジャラート文字、オリヤー文字などの用字系も、
同様の綴りの選択肢を提供しています。
単語、文、段落を区切るために空白を使う言語もあれば、使わない言語もあります。 部分文字列照合を実行するときは、[Unicode] にある異なる形の空白を、一致が成功するように正規化する必要があります。
発音区別符号を含まない検索語について推奨されるのは、 利用者が検索を別のように設定していない限り、コーパス内の発音区別符号を含むテキストに 一致することです。
発音区別符号を含む検索語について推奨されるのは、 等価な発音区別符号を含むテキストだけに一致することです。
発音区別符号を伴う文字を、符号のない形と区別する必要のある利用者は、 検索の感度で説明したように、より感度の高い照合を求めることができます。
ラテン文字など、さまざまな発音区別符号を使う用字系で検索語を入力するとき、 利用者は、アクセント記号や発音区別符号を伴う文字の入力を変えることがあります。 検索対象のテキストにそのような追加の記号が含まれていてもそうです。特に、 これらの文字の入力に追加の手間がかかることのあるモバイル端末のキーボードでは、この傾向が顕著です。このような場合、 利用者は一般に、必要な追加の手間をかけなかったことを補うため、 検索操作がより「寛容」であることを期待します。
この影響は、状況によっても異なる可能性があります。たとえば、物理キーボードを使う人は、 アクセント付きの文字を直接入力できるかもしれませんが、仮想キーボードや画面上のキーボードでは、同じ文字に アクセスして選択するために追加の手間が必要になるかもしれません。
一部の正書法では、文字数の異なる文字列を一致させる必要があります。
その代表的な例が、アブジャドにおける母音の発音区別符号です。たとえば、 アラビア文字やヘブライ文字を使う一部の言語では、利用者による短母音の入力は 必須ではありません（ただし任意で入力できます）。（これらの用字系を使う別の言語の一部では、短母音を含めることは 任意ではありません。）入力されるテキストや検索対象のテキストに母音があるかないかによって、 利用者が母音を入力しない場合や、入力する必要があることを知らない場合に、一致が妨げられる可能性があります。
異なる符号位置シーケンスから、視覚的に類似または同一の字形パターンを 作れる場合があります。これは意図的な場合もあり、その違いはUnicode正規化によって取り除けます。 しかし、外見が似ている書記素が、正規化によって同じ形にはならず、 意味的にも等価でない場合もあります。
アラビア文字を使用する一部の言語にも、複数の方法で符号化できる書記素があります。 これらの変異がUnicode正規化によって処理される場合もありますが、 視覚的に同一に見えても、Unicodeでは等価と見なされない場合もあります。これらの 変異が正しい綴りの変異と見なされる場合もあれば、 利用者の誤った認識によって生じる場合もあります。
英語やアラビア語などの言語では、単語間に空白を使います。中国語、 日本語、タイ語などの言語では使いません。句など、別のテキスト単位を区切るために空白を使う言語もあります。 単語間に空白を使わない言語では、「単語全体」の照合を計算するには、 境界自体がテキストに符号化されていない場合に単語の境界を判定できることが必要となる場合がよくあります。