字符串搜索
关于本文档的更多详细信息
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 浏览器中的“查找”命令。 本文档基于 万维网字符模型 1.0： 基础[CHARMOD] 和 万维网字符模型 1.0：字符串匹配 [CHARMOD-NORM] 中的概念，为 规范作者、软件开发者和内容开发者提供描述和实现适合全球受众的搜索功能所需的信息。
本节描述了本文档在发布时的状态。当前 W3C 出版物列表以及本技术报告的最新修订版可在 W3C 技术 报告索引中找到，网址为 https://www.w3.org/TR/。
注意：仍在进行中的工作
本文档目前并非由国际化工作组积极开发。它的创建是为了收集关于 自然语言文本中子字符串匹配的信息， 这些信息在其他 I18N 文档中不属于主题范围，同时也作为讨论 Web 上子字符串匹配问题时的便捷参考。
读者不应期望此处的材料代表关于“查找”功能的实现或规范制定的完整指导。
本文档由国际化 工作组通过 说明轨道作为 小组草案说明发布。
小组草案说明未得到 W3C 或其成员的认可。
这是一份草案文档，可能随时被其他文档更新、替换或废止。 除了作为进行中的工作之外，不宜引用本文档。
W3C 专利 政策 不对本文档附带任何许可要求或承诺。
本文档受 2023年11月3日 W3C 流程文档管辖。
本文档描述了字符串搜索操作的规范制定或实现方面的问题、需求和考虑事项。字符串搜索的一个常见例子是 Web 浏览器中的“查找”命令，但规范可能希望定义的搜索还有许多其他形式。
本文档基于万维网字符模型：基础 [CHARMOD] 和 万维网字符模型：字符串匹配 [CHARMOD-NORM]。 理解这些文档中的概念，对于成功理解和应用本文档很重要。
本规范的主要目标受众是需要定义某种搜索或查找算法的 W3C 规范开发者：其目标是为所需的概念、术语和需求提供稳定参考。
本文档中描述的概念为规范作者、软件开发者和内容开发者提供一个共同参考，以便在万维网上实现一致、 可互操作的文本搜索。通过这三个群体的协同工作，可以构建一个全球可访问的 Web。
本文档包含面向其他规范的最佳实践和需求，以及面向实现和内容作者的建议。这些面向规范（以及 其他对象）的最佳实践也可以在国际化工作组的文档 规范开发者国际化最佳实践 [INTERNATIONAL-SPECS] 中找到， 该文档旨在作为 W3C 规范中所有国际化最佳实践的一般参考。
在本文档中，[RFC2119] 中以 大写斜体形式出现的关键词具有其通常含义。我们还使用以下样式约定：
定义会以不同的背景色和 装饰显示，如此处所示。
最佳实践会以不同的背景色和 装饰显示，如此处所示。
议题、缺口以及未来工作的建议 会以不同的背景色和装饰显示，如此处所示。
本节包含本文档特有的术语。
理解本文档所需的大部分术语由国际化术语表 [I18N-GLOSSARY] 提供。一些术语也由 [CHARMOD-NORM] 定义，并可在该文档的 术语和记法 一节中找到。
Unicode，也称为 通用 字符集，允许在任何计算平台上用世界上任何书写系统、 文字或语言来创作 Web 文档，然后由世界各地的 Web 用户交换、阅读和搜索。Unicode 标准 [Unicode] 的前几章提供了有用的背景阅读材料。另请参阅 Unicode 排序算法 [UTS10]，其中包含关于 搜索的一章。
语料 用户希望搜索的、由一个文档或一组 文档包含的自然语言文本。
分词 将自然 语言文本拆分为不同词和短语的过程。这通常包括诸如“命名实体 识别”之类的操作（例如识别三词序列 Dr. Jonas Salk 是一个 人名）。
词干提取 一种 将词还原为其“词干”或词根的过程 或操作。例如，单词 runs、 ran 和 running 都共享词干 run。这 有时（更正式地）称为词形还原，而词干有时称为 词元。
全文 搜索 指处理文本文档或一组 文档的全部内容的搜索。全文查询通过根据特定语言（例如英语或日语）的规则、 基于词和短语进行操作，对全文索引中的文本数据执行语言搜索。 全文查询可以包括简单的词和短语，也可以包括词或短语的多种形式。
这通常意味着全文搜索会使用索引和自然语言 处理。使用搜索引擎时，您使用的就是一种全文搜索。全文 搜索通常会将自然语言文本拆分为词或短语（这称为分词），并可能应用复杂处理来取得词的 语义“词根”值（这称为词干提取）。这些过程对 语言、上下文以及文本变体的许多其他方面都很敏感。
自然 语言处理（NLP）指的是 为理解、处理和操纵人类语言（即自然 语言）而设计的软件领域。这是一个范围非常广的术语。它可以涵盖相对简单的问题，例如 词语标记化，也可以涵盖更复杂的行为，例如从文本中推导“意义”、识别词性、 执行准确翻译等等。
Web 用户经常希望在一个文档或一组文档中搜索特定文本，而不必 逐行阅读。规范有时会试图通过在 Web 平台中暴露文本搜索来支持这种需求。
文档搜索有不同类型。一种类型称为全文搜索，是 搜索引擎等应用中最常见的搜索类型。这种搜索 很复杂，可能会消耗大量资源，并且通常依赖于给定搜索 请求范围之外的过程。
一种更受限制的文本搜索形式（也是本文档的主题）是子字符串匹配
。一种
熟悉的子字符串匹配形式是浏览器和其他类型
用户代理的 查找
功能。对于带有物理键盘的用户代理，此功能通常通过
Cmd+F 或 Ctrl+F 等按键
组合访问。这样的功能可能通过 API window.find 暴露到 Web，
该 API 目前尚未完全标准化；也可能通过所提议的
[SCROLL-TO-TEXT-FRAGMENT] 等能力暴露。
查找操作可以提供可选机制，用于改进或定制匹配行为。例如，添加（或移除） 大小写敏感性的能力，该功能是否支持正则表达式语言的 不同方面（例如通配符），或者是否将匹配限制为完整词。
子字符串匹配通常不同于全文搜索的一种方式是，虽然它可能 使用各种算法来尝试抑制或忽略文本变体，但它通常不会产生 包含额外或未指定字符序列、词或短语的匹配，例如由 词干提取或其他NLP过程产生的结果。
在尝试标准化子字符串匹配时，规范作者经常会遇到计算机 系统中自然语言编码所固有的复杂性， 包括 [Unicode] 标准中用于编码字符的不同机制。
很多时候，用户输入并不由与正在搜索的文档中所使用的完全相同的码位序列组成， 但用户仍然期望发生匹配。这可能出于多种原因。有时是因为被搜索的文本以用户无法 预见的方式发生变化。在其他情况下，这是因为用户的键盘或输入法无法方便地 输入所需的文本变体。甚至可能是因为用户懒得准确输入文本。
在本节中，我们考察我们所知的各种常见情况，规范作者在指定子字符串匹配 API 或机制时 需要将这些情况纳入考虑。
用户对于其搜索词是否匹配文档或语料中给定部分的期望，有时取决于用户的语言、文档的语言， 或二者兼有。它还可能涉及其他因素，例如给定设备上可用的键盘或输入法。 这可能是因为搜索中的各种操作（例如大小写折叠）会受到区域设置影响；也可能是因为， 鉴于人类语言和文化的复杂性，对于匹配以及各种字符序列的使用和解释的期望有所不同， 即使在给定文字系统内部也是如此。 类似地，重音符号、替代文字系统或字符编码（例如字素 簇形成方式的变体）的处理，与相关文本的具体语言相关。
需要强调的是，我们在这里指的是语言，而不是文字系统。许多共享同一文字系统的 不同语言会应用不同的处理方式，或暗示不同的期望。
“查找”功能的实现通常必须仅根据用户输入，或根据运行时环境中的各种“提示”来猜测用户所意图的 语言，例如操作环境区域设置、用户代理的本地化，或当前活动键盘的语言。 这些提示至多只是用户意图的代理，尤其是在用户搜索的文档与这些提示都不匹配， 或被搜索文档包含多种语言时。
用户可能期望以小写输入的词匹配其大写等价形式（也许反之亦然）。子字符串匹配功能， 例如浏览器的“查找”命令，通常提供一个可由用户选择的选项，用于匹配（或不匹配） 输入与文本的大小写。
关于大小写折叠的综述，请参阅 [CHARMOD-NORM] 中这里的讨论。
Unicode 定义了字符之间的规范关系和兼容关系，这些关系可能影响用户对字符串搜索的感知。 关于 Unicode 规范化形式的详细讨论，请参阅 [CHARMOD-NORM] 第 2.2 节， 以及 Unicode 规范化形式 [UAX15] 中的定义。
在许多复杂文字系统中，字母或元音符号可以用不止一种方式编码，但这些替代形式在规范上等价。
一些语言使用不止一种文字系统书写。用户搜索文档时，可能输入一种文字系统的文本， 但希望找到两种文字系统中的等价文本。
一些兼容字符被编码到 Unicode 中，是为了处理旧式字符 编码中的单字节或多字节表示，或为了与东亚语言中的某些排版行为兼容。
许多文字系统都有自己表示 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 也不认为它们等价。有时这些变体被认为是有效的拼写变体。 在其他情况下，它们是用户错误感知的结果。
一些语言（例如英语或阿拉伯语）在词之间使用空格。其他语言（例如中文、 日语或泰语）则不使用。一些语言使用空格来分隔其他文本单元，例如短语。在 那些不在词之间使用空格的语言中，计算“完整词”匹配通常取决于 在边界本身未编码到文本中时确定词边界的能力。
作为本文档整体重新架构的一部分，本节被确定为一个需要补充文档的新领域。 此处文本尚不完整，需要进一步开发。欢迎社区贡献。
实现者通常需要提供简单的“查找文本”算法，而规范也经常尝试定义 API 来支持这些需求。文本上的查找操作会产生不同的用户期望，因此与文档格式和协议所需的 绝对同一性匹配相比，它们有不同的需求。需要注意的是，特定领域的需求可能会施加额外限制， 或改变此处提出的考虑事项。
用户输入努力程度的增加应该通过更 有选择性的匹配来体现。
当用户在输入上花费更多努力——例如使用 Shift 键生成大写字母，或输入带变音符号的 字母而不只是基本字母——他们可能期望搜索结果（仅）匹配其更具体的输入。
在创建字符串搜索 API 或算法时，以下文本选项可能对用户有用：
W3C 国际化工作组和兴趣组以及其他人 提供了许多评论和建议。工作组希望感谢：多年来为字符模型系列文档 的发展作出贡献的所有贡献者。