字符串搜索
关于本文档的更多详细信息
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 浏览器中的“查找”命令。 本文档基于 万维网字符模型 1.0： 基础 和 万维网字符模型：字符串 匹配 中的概念，为规范作者、软件开发者和内容 开发者提供描述和实现适用于全球 受众的搜索功能所需的信息。
本节描述本文档 发布时的状态。当前 W3C 出版物的列表以及本技术报告的最新修订版 可在 W3C 标准与草案 索引中找到。
注意：尚在进行中的工作
国际化工作组目前并未积极 开发本文档。创建本文档是为了记录 自然语言 文本中子字符串匹配的信息， 这些信息超出了其他 I18N 文档的范围，同时也为讨论 Web 上的子字符串匹配问题提供便于查阅的参考。
读者不应期望此处的材料能够为 “查找”功能的实现或规范制定提供完整指导。
本文档由 国际化 工作组以 小组说明草案的形式发布，采用 说明 流程。
小组说明草案未经 W3C 及其成员认可。
本文档是一份草案，可能随时被其他 文档更新、替换或废止。引用本文档时， 只能将其视为尚在进行中的工作。
该 W3C 专利 政策 不对本文档规定任何许可要求或 承诺。
本文档受以下文件约束： 2025 年 8 月 18 日的 W3C 流程文档。
W3C 国际化工作组和兴趣 小组以及其他人士提供了许多意见和建议。工作组在此感谢： 在字符模型系列文档多年的制定过程中 作出贡献的所有人士。
本文档描述为字符串搜索操作制定规范或 实现这些操作时涉及的问题、要求和注意事项。字符串搜索的一个常见示例是 Web 浏览器中的“查找” 命令，但规范可能还希望定义许多其他形式的 搜索。
本文档基于 万维网字符模型：基础 [CHARMOD] 和 万维网字符模型：字符串匹配 [CHARMOD-NORM]。 理解这些文档中的概念，对于成功理解和应用 本文档至关重要。
本规范的主要目标受众是需要定义某种搜索或查找算法的 W3C 规范开发者：其目标是 为所需的概念、术语和要求提供稳定的参考。
本文档描述的概念为规范编写者、软件开发者和 内容开发者提供了共同的参考，以便在万维网上实现一致且可互操作的 文本搜索。这三个群体通力合作，便能构建全球用户均可访问的 Web。
本文档包含面向其他规范的最佳实践和要求，以及 面向实现和内容作者的建议。这些面向规范的最佳实践（以及 其他最佳实践）也可在国际化工作组的文档 规范开发者国际化最佳实践 [INTERNATIONAL-SPECS] 中找到， 该文档旨在为 W3C 规范中的所有国际化最佳实践提供通用参考。
在本文档中，以大写斜体显示的 [RFC2119] 关键词 具有其通常含义。我们还使用以下样式约定：
定义以不同的背景颜色和 此处所示的装饰样式呈现。
最佳实践以不同的背景颜色和 此处所示的装饰样式呈现。
议题、缺漏以及对未来 工作的建议以不同的背景颜色和此处所示的装饰样式呈现。
本节包含本文档特有的术语。
理解本文档所需的许多术语由 国际化 术语表 [I18N-GLOSSARY] 提供。还有一些术语定义于 [CHARMOD-NORM]，可以 在该文档的术语与记法 一节中找到。
Unicode，也称 为通用 字符集，允许在任何计算平台上使用世界上任何书写系统、 文字体系或语言编写 Web 文档，然后由世界各地的 Web 用户交换、阅读和搜索这些文档。Unicode 标准 [Unicode] 的前几章提供了有用的背景阅读材料。另请参阅 Unicode 排序算法 [UTS10]，其中包含 关于搜索的一章。
语料库 用户希望搜索的文档或文档集合中 包含的自然语言文本。
敏感或 不敏感。指搜索操作根据搜索词或语料库文本中存在的特征， 区分搜索词与语料库中文本之间差异的程度。 当搜索为敏感时，搜索词与 语料库之间的某种差异或变化会导致无法匹配；当搜索为不敏感时，这些 差异会被忽略（因此搜索词能够在语料库中匹配）。各种 敏感性的示例可见于 2.2 确定等价性时的问题，例如大小写 敏感性、重音符号/变音符号敏感性或文字体系敏感性。
分词 将自然 语言文本拆分为独立单词和短语的过程。这通常包括“命名实体 识别”等操作（例如，识别出由三个词组成的序列 Dr. Jonas Salk 是一个 人名）。
词干提取 将单词 还原为其“词干”或词根的过程或操作。例如，单词 runs、 ran 和 running 都具有相同的词干 run。这 有时被（更正式地）称为词形还原，而词干有时被称为 词元。
全文 搜索是指处理整个文本文档或文档集合全部内容的 搜索。全文查询依据特定语言（例如英语或日语）的规则， 对单词和短语进行操作，从而对全文索引中的文本数据执行语言学搜索。 全文查询可以包含简单的单词和短语，也可以包含单词或短语的多种形式。
这通常意味着全文搜索会使用索引和自然语言 处理。当你使用搜索引擎时，使用的就是一种全文搜索。全文 搜索通常会将自然语言文本拆分为单词或短语（这称为分词），并且可能应用复杂的处理来获取 单词在语义上的“词根”值（这称为词干提取）。这些过程对 语言、上下文以及文本变化的许多其他方面都很敏感。
自然 语言处理 (NLP) 是指 旨在理解、处理和操纵人类语言（即自然 语言）的软件领域。这是一个涵盖范围很广的术语。它可以涵盖相对简单的问题，例如 单词切分，也可以涵盖更复杂的行为，例如从文本中推导“含义”、识别 词性、进行准确翻译以及许多其他行为。
表意文字变体序列是指一种变体序列， 它注册于表意文字变体 数据库。表意文字变体序列的基字符必须是表意 字符，并且使用 U+E0100..U+E01EF 范围内的变体选择符。“表意文字 变体序列”这一术语有时缩写为“IVS”。另请参阅 Unicode 定义和 [UTS37]。
对于汉字和其他表意文字，不可能建立一个能够同时满足所有用户全部需求的 单一变体序列集合。学者、 政府和出版商的要求差异过大，无法由单一集合满足。相反，可以 通过多个独立的集合来满足这些要求。Unicode 定义了表意文字变体数据库 [UTS37]，以确保每个 给定的变体序列都有唯一的定义，从而使使用此类变体 序列的文本能够可靠地交换。
Web 用户经常希望在文档或文档集合中搜索特定文本，而 无须逐行阅读。规范有时会通过在 Web 平台中提供文本搜索 来满足这一需求。
文档搜索有不同的类型。其中一种称为全文搜索，它是 搜索引擎等应用中最常见的搜索类型。这种搜索 较为复杂，可能消耗大量资源，并且通常依赖于给定搜索 请求范围之外的处理过程。
一种范围更有限的文本搜索形式（也是本文档的主题）是子字符串匹配
。一种
熟悉的子字符串匹配形式是浏览器及其他类型用户代理的查找
功能。对于具有实体键盘的用户代理，通常通过
Cmd+F 或 Ctrl+F 等组合键访问此功能。此类功能可能通过
目前尚未完全标准化的 API window.find，或通过
已提出的 [SCROLL-TO-TEXT-FRAGMENT] 等能力在 Web 上提供。
查找操作可以提供可选机制，以改进或调整匹配行为。例如， 能否启用（或禁用）大小写敏感性、该功能是否 支持正则表达式语言的不同特性（例如通配符），或者是否将 匹配限制为全词。搜索关注此类 差异的程度就是其搜索敏感性，详见搜索 敏感性。
子字符串匹配与全文搜索通常存在的一个区别是，尽管它可能 使用各种算法尝试消除或忽略文本差异，但它通常不会产生 包含额外或未指定的字符序列、单词或短语的匹配，而此类结果可能 由词干提取或其他NLP 过程产生。
在尝试将子字符串匹配标准化时，规范编写者常常难以应对 计算机系统中自然语言编码所固有的 复杂性，包括 [Unicode] 标准为编码字符而采用的不同机制。
搜索操作对文本差异的关注程度有所不同。不区分大小写的搜索
会忽略 a
和 A
之间的差异；忽略变音符号的搜索会将
cote
与 côte
匹配；要求精确匹配的搜索则不会忽略这些差异中的任何一种。
搜索操作区分此类差异的程度就是其搜索敏感性。
下文描述的文本差异类型以及搜索注意事项，给出了在 未选择任何选项时，搜索默认采用何种敏感性的建议。这样的默认值并不妨碍 实现或 API 提供其他敏感性级别。
向用户提供搜索功能的实现应当允许用户获得比默认行为更敏感的 匹配，包括区分大小写和区分变音符号的匹配。
当规范向作者提供搜索功能时，匹配的 敏感性应当可由作者在调用该功能时配置。
内容作者无法配置用户代理直接
向用户呈现的搜索功能的敏感性，例如浏览器的查找
命令。作者确实可以通过其他方式影响
匹配：提供文本语言等信息（参见由语言引起的匹配差异），或者实现
自己的搜索功能。
实现者常常需要提供简单的“查找文本”算法，而 规范也经常尝试定义 API 来支持这些需求。对文本执行的查找操作会引发 不同的用户期望，因此其要求不同于文档格式和协议所需的 绝对相同匹配。需要注意的是，特定领域的 要求可能施加额外限制，或改变此处提出的注意事项。
用户投入更多输入操作应当体现为 更具选择性的匹配。
当用户在输入时付出更多努力——使用 Shift 键输入大写字母，或输入 带有变音符号的字母而非仅输入基字母——他们可能期望搜索结果 （仅）匹配其更具体的输入。
用户输入的码点序列往往并不与被搜索 文档中使用的序列完全相同，但用户仍然期望能够匹配。这可能出于多种 原因。有时是因为被搜索的文本存在用户无法 预料的变化。其他情况下，则是因为用户的键盘或输入法无法方便地 输入所需的文本变体。甚至可能只是因为用户懒得准确地输入 文本。
本节考察我们已知的各种常见情况，规范编写者在定义 子字符串匹配 API 或机制时需要将它们纳入考虑。
用户对于其搜索词是否能匹配文档或语料库中某个部分的期望，有时取决于用户的语言、 文档的语言，或者两者。它还可能涉及其他因素，例如给定设备上有哪些键盘或输入法 可用。这可能是因为搜索过程中包含的各种操作， 例如大小写折叠，会受到区域设置的影响；也可能是因为人类 语言和文化的复杂性，使得人们对于匹配或各种 字符序列的使用和解释有不同的期望，即便是在同一种文字体系中也是如此。同样，对于 重音符号、替代文字体系或字符编码（例如字素 簇构成方式的变化）的处理，也与相关文本的具体语言有关。
需要强调的是，此处我们所指的是语言，而非文字体系。共用一种文字体系的许多不同语言 会采用不同的处理方式，或隐含不同的期望。
“查找”功能的实现常常只能根据用户输入，或者运行时环境中的各种 “提示”，来猜测用户意图使用的语言，例如运行 环境的区域设置、用户代理的本地化语言或当前键盘的语言。这些 提示充其量只是用户意图的间接指标，尤其是在用户搜索的 文档与这些提示都不相符，或被搜索的文档包含多种 语言时。
默认情况下，字符串搜索应当 不区分大小写。
用户可能期望以小写输入的搜索词能够匹配大写的等价形式（反过来可能也 如此）。浏览器“查找”命令等子字符串匹配功能，通常会提供 用户可选的选项，用于决定是否要求输入与文本的大小写一致。
有关大小写折叠的概述，请参阅 此处在 [CHARMOD-NORM] 中的讨论，以及 [Unicode] 第 5 章中 标题为大小写映射的一节。
不区分大小写的字符串搜索应当默认使用 Unicode 完整大小写折叠。
Unicode 为每个码点定义了默认的大小写折叠。对于大多数字符，默认折叠会将
一个字符转换为另一个单独的字符；Unicode 将这些映射称为通用映射（状态
C）。少量字符会折叠为两个或更多字符；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，而不应用时，搜索会漏掉该
单词。
然而，应用特定于语言的定制并不适合作为默认行为。正在匹配的两个字符串 可能使用不同语言，而且还可能出现在第三种语言的上下文中； 搜索词或一段文本的语言往往未知或不可靠，如上文 由语言引起的匹配差异所述。
Unicode 定义了字符之间的规范关系和兼容关系，这些关系可能影响用户 对字符串搜索的理解。有关 Unicode 规范化形式的详细讨论，请参阅 [CHARMOD-NORM] 的第 2.2 节， 以及 Unicode 规范化形式 [UAX15] 中的定义。
在许多复杂文字体系中，字母或元音符号可以用多种方式编码，但这些 替代形式在规范上是等价的。
有些语言使用多种文字体系书写。搜索文档的用户可能使用 一种文字体系输入文本，却希望找到两种文字体系中的等价文本。
搜索时，字符全角形式与半角形式之间的差异应当被忽略，除非用户另有指定。
一些兼容字符被编码进 Unicode，是为了兼顾 传统字符 编码中的单字节或多字节表示，或者兼容东亚语言中的某些排版行为。
Unicode 包含一些变体选择符，用于 为前面的字符指定字形变体。
例如，单个表意字符可以具有多个
变体，具体取决于所使用的变体选择符（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）视为一个
单独的单元，并使用第一个码点作为处理基准。
如果可能，同时支持“模糊”和“精确”搜索模式，以满足不同用户的需求。
除 IVS 外，其他语言也有变体选择符。
用户代理可以在字符串搜索操作中，将表示数值的 字符映射到其 ASCII 形式（0-9）。
许多文字体系对于 0 到 9 都有自己的数字字符。在某些 Web 应用中， 为了显示，熟悉的 ASCII 数字会被替换为当地的数字字形。在其他 情况下，文本实际上可能包含当地数字的 Unicode 字符。尝试 搜索文档的用户可能期望，输入一种形式的数字能够找到等价的数字。
有些语言具有随地区或方言而变化的不同正字法传统，或者允许 同一个单词采用不同的拼写。搜索和拼写检查可能需要了解这些 差异。
使用印度系文字的语言中存在许多此类问题。有时它们是拼写 错误，但在其他情况下，多种拼写都是可接受的。
例如，孟加拉语（语言标签 bn）
以允许大量拼写变体而闻名：近 80%
的孟加拉语单词至少有两种拼写。许多单词具有 3、4 种或更多变体——其中
至少有一个单词具有 16 种不同的有效拼写。
其他印度系文字提供了表示特定语音的不同机制，而在 大多数情况下，两种表示都被视为同样有效。最常见的此类情况 涉及音节末尾鼻音的表示。
例如，印地语中表示蛇的单词里的 /n/ 音 可以用 ँ [U+0901 DEVANAGARI SIGN CANDRABINDU] 或 ं [U+0902 DEVANAGARI SIGN ANUSVARA] 书写。以下两种都可能是有效的拼写：
使这一情况更加复杂的是，此处可以使用两个具有不同码点的变音符号。 在前面的示例中，我们使用 ं [U+0902 DEVANAGARI SIGN ANUSVARA ] 来表示鼻音，因为与之相伴的元音符号高于悬挂 基线。如果元音符号不高于悬挂基线，我们 通常会改用 ँ [U+0901 DEVANAGARI SIGN CANDRABINDU ]。这两个变音符号的 功能相同，但码点不同。
交替使用字母或变音符号来表示音节末尾鼻音的做法，也常见于
其他几种印度语言。除了用于书写印地语
（语言标签 hi）或马拉地语（语言标签 mr
等语言的天城文外，马拉雅拉姆文、古吉拉特文、奥里亚文等文字体系也提供
类似的拼写选择。
某些语言使用空白字符分隔单词、句子或段落，而另一些语言则不使用。在 执行子字符串匹配时，[Unicode] 中不同形式的空白字符 必须被规范化，以便成功匹配。
不包含变音符号的搜索词应当 匹配语料库中包含变音符号的文本，除非用户对搜索 另有配置。
包含变音符号的搜索词应当仅匹配 包含等价变音符号的文本。
需要区分带有变音符号的字母与其不带符号形式的用户，可以要求 更敏感的匹配，如搜索敏感性所述。
使用带有各种变音符号的文字体系（例如拉丁文字）输入搜索词时，用户在处理含重音符号或变音 符号的字母时，有时会改变其输入， 即使被搜索的文本包含这些附加符号。在移动设备键盘上尤其如此， 因为输入这些字符可能需要额外操作。在这些情况下， 用户通常期望搜索操作更加“宽泛”，以弥补他们未 付出所需的额外输入操作。
这种影响也可能随上下文而变化。例如，使用实体键盘的人 可能可以直接输入带重音符号的字母，而虚拟键盘或屏幕键盘可能需要额外 操作才能访问和选择相同的字母。
在某些正字法中，需要匹配字符数量不同的字符串。
一个典型的例子涉及辅音音素文字中的元音附加符号。例如，某些 使用阿拉伯文字和希伯来文字的语言并不要求用户输入短 元音（但允许选择输入）。（对于使用这些文字体系的其他一些语言，短元音的加入并不是 可选的。）如果用户没有输入或不知道要输入元音，那么输入文本或被搜索文本中 元音的有无可能妨碍匹配。
在某些情况下，不同的码点序列可以产生视觉上相似或相同的 字形图案。有时这是有意为之，并且可以通过 Unicode 规范化消除差异。 但在其他情况下，外观相似的字素不会因 规范化而变得相同，而且它们在语义上也不等价。
一些使用阿拉伯文字的语言也有可以采用多种方式编码的字素。 在某些情况下，这些差异由 Unicode 规范化处理，但在其他情况下，Unicode 并不 认为它们等价，即便它们看起来完全相同。有时，这些 差异被视为有效的拼写变体。在其他情况下，它们则源于 用户的错误认识。
某些语言，例如英语或阿拉伯语，会在单词之间使用空格。其他语言，例如汉语、 日语或泰语，则不会。有些语言使用空格分隔短语等其他文本单元。在 不使用空格分隔单词的语言中，计算“全词”匹配通常依赖于 在文本本身并未编码单词边界时确定这些边界的能力。