Help:CirrusSearch

注意：当您编辑本页面时，即同意以CC0协议授权您的贡献。您可以在公有领域帮助页面找到更多信息。

在维基项目寻找信息最快的方法是直接检索。 在每一页上都有一个搜索框。

CirrusSearch是一个使用Elasticsearch，来在默认MediaWiki搜索上提高增强功能的MediaWiki扩展。 维基媒体基金会已在所有维基媒体项目上使用了CirrusSearch。 此页面叙述CirrusSearch的功能。 如果你的疑问并未得到解答，请在讨论页提问，热心用户将会为你解答。

更多有关MediaWiki扩展的信息，请参见Extension:CirrusSearch 。

有关调试的信息，请参阅Help:CirrusSearch/Debug 。

工作原理

输入关键字或短语，然后按回车键或点击放大镜图标、搜索或像是Skin:MonoBook 等舊主題中的「Go」按钮。

如果一个页面具有与您输入的标题相同的标题，您将会直接转到相关页面。 否则，它会搜索维基上所有页面，并展现和你搜索的内容相关的文章列表，或者提示你没有找到与关键字相关的页面。

如果你直接点击“搜索”按钮而没有填写任何内容，你将被帶到Special:Search，它會为你提供额外的搜索选项（在任何的搜索结果页面中也會有）。

您可能会发现限制搜索特定命名空间中的页面很有用。例如，只搜索User页面。 选中您本次需要搜索的命名空间。

下面提到的所有關鍵字都是區分大小寫、且是採用小寫。

改善了什麼？

CirrusSearch较之于默认的MediaWiki搜索三大改进，主要有：

• 更好的支持以不同语言搜索。
• 更快的更新搜索索引，即页面修改能更快在搜索引擎中显示出来。
• 展开模板，即在一個模板中的全部内容也能被搜索引擎搜索到。

搜索索引的更新频率如何？

有两种主要的搜索索引：

第一种是Special:Search中的全文搜索。 这个索引是接近实时更新的。 页面更新将在几分钟内出现在搜索结果中，不过30分钟后才出现也属于系统的正常运作。 对模板的变更将会在数分钟内对包含其的条目起作用，根据使用该模板的页面数量可能最多会花费几个小时。 对文章进行空编辑也会强制系统进行刷新——所以，在正常情况下不要进行这样的操作。

第二种索引是标题搜索的自动完成模糊索引。 这种索引会每天更新一次，并且會在索引被更新的時間點，同步镜像全文搜索中所找到的內容。 依時間點而定，一個新網頁可能需要兩天才能在模糊標題自動完成中找到。 如果這對於特定的使用情況是不可接受的，在使用者搜尋選項中，將標題完成方式變更為使用全文搜尋索引的典型前綴搜尋。

搜索建议

當您在下拉候選頁面的搜尋方塊中輸入內容時，所得到的搜尋建議會依據條目品質的粗略標準排序。 这會考慮到链入的wiki链接数量、页面大小、外部链接数量、标头数量、和重定向数量。

搜索建议可以跳过，然後查询将直接指向搜索结果页面。 在查询前面添加個波浪符号~即可。 例如“~Frida Kahlo”。 搜索建议仍将出现，但在任何时候敲击回车键将带您进入搜索结果页面。

某些語言會開啟字母轉寫(Accent/diacritic folding)功能；細節則依語言而定。

用于排序建议的算法在Extension:CirrusSearch/CompletionSuggester#Ranking criteria 处有更详细的说明。

全文搜索

「全文搜索」是「索引搜索」。 所有頁面被儲存在維基的資料庫內；所有非重定向頁的單詞被儲存在搜尋資料庫內，並實際上是對維基全文的索引。 每個可見單詞都被索引到能找到該單詞的頁面列表中，因此搜索單詞的速度與查找單個記錄的速度一樣快。 此外，搜索索引會对于措辞的任何变化，在几秒钟之内更新。

有許多wiki「全文」的索引，以便於多種類型的搜尋之所需。 完整的wikitext會被多次索引到許多特殊用途的索引之中，每個索引都會以最佳化其使用的方式來解析 wikitext。 索引範例包括有：

• 「輔助」文字，包括頂註、標題、目錄、以及任何由HTML屬性class=searchaux所分類的wikitext。
• 「前導」文字是頁面頂端與第一標題之間的wikitext。
• 「分類」文字可索引底部的清單。
• 模板會被索引。如果某個模板的嵌入字詞有改變，則會更新所有嵌入該模板的頁面 (這可能需要很長的時間，視工作佇列而定)。如果某個模板所使用的子模板有改變，則索引也會更新。
• 儲存於File或Media命名空間的文件內容現在已被索引了。可識別數千種格式。

现在已经支持了多种语言，但是我们希望能支持所有的语言。 在elasticsearch.org之中列出了現在支持的語言；查看貢獻中的文檔以提交各種請求或補丁。 第三方開放原始碼程式庫也用來支援其他Elasticsearch未涵蓋的語言。

CirrusSearch會優化您的查詢，並執行查詢。所產生的標題會依相關性加權，並進行大量後處理，每次處理20個標題，用於搜尋結果頁。例如，會從條目中擷取片段，並以粗體字強調搜尋詞彙。

搜索结果通常会附带各种初步报告，包括“您是否想找”（拼写纠正），以及当原本无法找到结果时会显示的“显示以下搜索结果”（查询纠正）和“改为搜索”（您的原始查询）。

搜索功能还包括：

• 按入链数量对导航建议进行排序。
• 以波浪号~开头，以此禁用导航和建议，同时保留页面排名。
• 通过将非键盘字符规范化（或“折叠”）为键盘字符，实现智能匹配字符。

在搜索结果页面上，匹配的词语会以粗体形式突出显示。高亮显示功能属于视觉分析器，而实际定位页面的搜索索引分析器可能与其不完全同步，尤其是在处理正则表达式时。高亮器的匹配精度可能高于或低于索引器的匹配精度。

词、短语、修饰符

基本搜索词是一个词或一个"用半角引号包裹的短语"。 具体细节因语言而异，特别是对于没有空格的语言，但搜索通常会把以下内容识别为“词”：

• 一连串数字
• 一连串字母
• 字母/数字转换中出现的子单词，例如 txt2regex
• 用 camelCase 描述的复合词中的子单词。

一个"停止单词"是一个被忽略的单词（因为它太常见，或者其他原因）。 停止单词的列表特定于语言，不是所有语言都有停止单词。 給定的搜索詞與"內容"匹配(在頁面上呈現)。若要與 wikitext 匹配,請使用insource 參數(請參閱下面的 章節)。每個搜索參數都有自己的索引,並按自己的方式解釋其給定術語。

在字、词组、参数之间留空格，并输入进参数，可以包含大量空格实例及“灰色空间字符”。 “灰色空间字符”即所有非字母数字字符~!@#$%^&()_+-={}|[]\:";'<>?,./。 混合了“灰空格字符”与空白字符的字符串即为“灰空格”，它被视为一个大型单词边界。 灰色空間是索引的創建和查詢的解釋方式。

有两种例外情况：一是当embedded:colon作为整体单词时（冒号被视为字母），二是当嵌入逗号,出现在数字中（如1,2,3）时，该逗号会被识别为数字组成部分。 其余情况下，灰度字符通常会被忽略——除非查询语法允许它们被解析为修饰符字符。

修饰符为~ * \? - " ! ， 根据其在语法中的位置，它们可应用于术语、参数或整个查询。 词与短语修饰符包括通配符、邻近度和模糊搜索。 每个参数均可拥有专属修饰符，但通常而言：

• 模糊词或模糊短语搜索可在末尾添加波浪符~字符（以及一个表示程度的数字）。
• 在查询的首个词前加上波浪符号~，可确保获得搜索结果而非可能的导航跳转。
• 单词中的通配符可以是代表单个字符的（转义）问号\?，或代表零个或多个字符的星号*字符。
• 真值逻辑能够解析AND与OR运算符，但参数不具备此功能。请注意：当前AND和OR运算符并不遵循传统的真值逻辑运算规则！详见逻辑运算符说明。
• 真理逻辑理解以-或!为前缀的术语，会将术语的通常含义从“匹配”反转为“排除”。

以-或!开头的词汇，例如-in-law或!Kung，能够精确匹配标题与重定向页，但同时也会匹配到所有不包含否定词的文档——这类文档通常几乎涵盖了全部文献。 若需搜索除标题或重定向精确匹配之外的其他此类术语，请使用insource搜索参数（详见下方章节）。

• 词语两侧的引号表示“精确短语”搜索。对于参数而言，引号同样用于界定多词输入内容。
• 词干提取是自动进行的，但可以通过使用“精确短语”来关闭此功能。

两个通配符是星号和（转义后的）问号，它们均可出现在单词的中间或末尾。 转义问号\?代表单个字符，星号*则代表任意数量的字符。 由于许多用户倾向于以提问而非输入查询的方式表达需求，因此除非特意使用\?转义以表示通配符含义，否则所有问号均被忽略。

短语搜索可通过多种提示方式启动， 每种提示方式会对词语序列的匹配宽容度产生不同影响。 针对「间隔符」、「驼峰式大小写」或「文本转数字」等提示类型：

• 给定words-joined_by_greyspace(characters)或wordsJoinedByCamelCaseCharacters，它会找到words joined by...characters，无论是它们的原始形态还是灰空间形态。
• txt2number将匹配txt 2 number或txt-2.number。
• 针对灰色空格或驼峰式短语边缘情况，停用词功能已启用。 使用the、of和a的示例是the_invisible_hand_of_a在文本meetings invisible hand shake中匹配invisible hand。

当短语中一个普遍未知的词汇被忽略时，系统会触发“替代搜索”报告。

以下各类短语匹配方式均包含并扩展了前一种匹配的容错范围：

"精确短语" "引号内" 将允许（匹配）灰色空格。给定"exact_phrase"或"exact phrase"时，它会匹配"exact]phrase"。

• greyspace_phrase会触发词干提取和“停用词”检查。
• 如果输入CamelCase，它会“额外”匹配camelcase（全小写形式），因为CirrusSearch在匹配时不区分大小写。 请注意，CamelCase匹配功能并未针对所有语言启用。

某些参数能够解析灰空间短语，但其他参数（如insource）仅支持常规的"带引号短语"解析。

在搜索术语中，支持"词干提取"意味着搜索"swim"时也会包含"swimming"和"swimmed"，但可能不会包含不规则形式如"swam"。

搜索词组	parserfunction	parserFunction	parser function	parser-function	parser:function	parSer:funcTion
parserfunction			N	N	N	N
"parser function"	N	N			N	N
parser_function	N				N	N
parserFunction					N	N
"parser:function"	N	N	N	N
"parser_function"	N	N			N	N
"parSer_funcTion"	N	N			N	N
parSer_FuncTion	N	N

请注意，所有词干都不区分大小写。

请注意“精确短语”搜索如何将embedded:colon字符视为字母，但未将embedded_underscore字符视为字母。类似的情况也出现在数字内部的逗号,字符上。

在“精确短语”语境下（包括“insource”参数语境），给定in:this:word时，CirrusSearch将不会匹配in、this或word，而只会匹配in:this:word。

否则，请记住，对于CirrusSearch而言，词语由字母、数字或两者组合构成，且大小写无关紧要。

常见词汇搜索采用空格字符，并在词干提取上较为激进，当相同词汇通过灰空格字符或驼峰式连接时，系统会对短语和子词进行强力匹配。

当“of”或“the”这类常见词汇出现在灰空间短语中时，系统会自动忽略它们以实现更广泛的匹配。

greyspace_phrase类搜索词、驼峰命名法格式词或txt2number类词项，均可与它们所指代的词语互换匹配。 你可以使用三种形式中的任何一种。 现在camelcase能匹配camelCase是因为搜索不区分大小写，而camelCase能匹配camelcase是因为camelCase的匹配规则更为宽泛。 与搜索的其他部分一样，子词“单词”不区分大小写。相比之下，“精确短语”以灰空间为导向，忽略数字或字母大小写转换以及词干提取。“引号短语”不区分大小写。

从表中可以推断，基础搜索parser_function -"parser function"是基础搜索parserFunction和parser<stems> function<stems>之和。

用数字查询，我们会发现：

• Plan9或Plan_9匹配任何： plan9, plans 9, planned 9th, (planned) 9.2, "plans" (9:24)
• "plan9"僅符合plan9(大小寫不敏感)
• Plan*9匹配plan9或planet4589。

星号*通配符匹配已渲染单词中的一串字母和数字，但绝不匹配首字符。 *字符之前必须有一个或多个字符。

• 当*匹配数字时，逗号被视为数字的一部分，而小数点则被视为分隔字符，会将数字一分为二。
• 在“精确短语”内部，*被视为灰空间字符而非通配符，因此它起到单词分隔符的作用。

\?通配符代表一个字母或数字；*\?也是可接受的，但\?*不被识别。

通配符用于基本单词，短语和内容搜索，也可以是（某些）高级正则表达式搜索的替代（稍后介绍）。

在单词或短语后面加上波形符号~字符可激活模糊搜索。

• 对于短语而言，这被称为“邻近”搜索，因为系统允许其中的词项在位置上保持大致的邻近关系，而不要求完全匹配“精确短语”。
• 例如，"exact one two phrase"~2匹配exact phrase。
• 就词而言，这指的是额外的字符或“已更改”的字符。
• 对于短语，模糊搜索需要一个整数来指定允许插入的额外单词数量；而对于单词，模糊搜索则可以使用小数（默认为word~0.5或word~.5），这意味着单词中最多有两个字母可以发生互换、更改或增添，但首字母不得变动。
• 对于邻近短语，可以使用较大的数值，但这属于“高开销”（速度较慢）的搜索。
• 对于一个单词，word~2的模糊程度最高（编辑距离为2，即默认值），word~1的模糊程度最低，而word~0完全不模糊。

	flowers algernon	Flowers for Algernon	flowers are for Algernon	Flowers a1 2b 3c 4f 5j 6l 7j 8p q9 z10 for Algernon
"flowers algernon"		N	N	N
"flowers algernon"~0		N	N	N
"flowers algernon"~1			N	N
"flowers algernon"~2				N
"flowers algernon"~11
"algernon flowers"~1	N	N	N	N
"algernon flowers"~2		N	N	N
"algernon flowers"~3			N	N
"algernon flowers"~4				N
"algernon flowers"~13

对于按反向（从右向左）顺序匹配所需的邻近度数值，请先数出并剔除所有多余的单词，然后取剩余单词总数的两倍再减去1。 （换句话说，增加两倍的句数）。 关于完整的邻近度算法，请参阅Elasticsearch slop。

一些情况下，您还可以点击浏览器中的「回到上一步」按钮返回到链接媒体查看器中图像的页面。

	flowers	flower	Flowers for Algernon	flower for Algernon
flowers					字詞搜尋也有效。
"flowers"		N		N	邻近搜索会关闭词干提取。
"flowers"~					通过添加波浪号实现邻近匹配与词干提取。
"flowers for algernon"	N	N		N	邻近搜索会关闭词干提取。
"flowers for algernon"~	N	N			通过添加波浪号实现邻近匹配与词干提取。
"flowers algernon"~1	N	N		N	邻近搜索会关闭词干提取。
"flowers algernon"~1~	N	N			通过添加波浪号实现邻近匹配与词干提取。

源代码搜索

≥ 1.24 Gerrit change 137733

源代码搜索（Insource）功能可被用于查找任何在页面上渲染的“文字”，但它主要用于查找您可能很难找到词——包含MediaWiki标记，在重定向以外的任何頁面上。这个搜索词完全忽略灰色空间：insource: "state state autocollapse"匹配|state={{{state|autocollapse}}}。

insource: word insource: "word1 word2"	灰度字符将被忽略，就像它们在单词搜索和精确短语搜索中一样。
insource:/regexp/ insource:/regexp/i	这些是正则表达式。它们并不高效，所以我们一次只允许在搜索集群上使用几个，但是它们非常强大。正则表达式預設區分大小寫匹配，可以使用額外的i來選擇不區分大小寫匹配，但效率會更差。

insource补充了自己。一方面，它立即对wikitext中的任何单词进行全文搜索。另一方面，它可以处理任何字符串的正则表达式搜索。 正则表达式扫描给定页面列表中的所有文本字符；它们没有单词索引来加快速度，如果运行时间必须超过20秒，则进程被中断。 正则表达式在查询的最后阶段执行，因此为了减少不必要的字符级扫描，每个正则表达式查询都应包含其他搜索词，以缩小需要扫描的文档范围。 通常，适合添加到正则表达式查询insource:/arg/中的最佳候选是insource:arg，其中arg部分相同（且不包含通配符）。

正则表达式的语法是：insource:（无空格），然后是/regexp/。（其他参数均不允许空格。除insource:/regexp/外，所有参数的冒号后都允许有空格。）

Insource的索引搜索和正则表达式搜索角色在许多方面都很相似：

• 两者均仅搜索维基文本。
• 两者均无法检索由嵌入引入的内容。
• 两者均不支持词干搜索、模糊搜索或邻近搜索。
• 两者均倾向于返回较少的结果，且在配合其他查询条件使用时运行速度更快。

然而，基于索引的搜索都会忽略灰度字符；通配符搜索也无法匹配灰度字符。因此，若要查找包含“任意”字符的精确字符串（例如连续两个空格），正则表达式是唯一可行的途径。 正则表达式是一类截然不同的搜索工具，它既能轻松实现字面字符串匹配（适用于基础或入门级操作），也能在维基上支持通过元字符表达式进行匹配（适用于进阶操作）。 请参阅下方的#正则表达式搜索。

“insource”参数将包含冒号的词视为单个词。这会影响针对模板、解析器函数、URL、维基链接、HTML标签及注释的搜索查询。

请尽可能避免进行单纯的正则表达式搜索。请参阅下文#正则表达式搜索，了解如何始终避免此类操作。

若要搜索以-或!开头的单词（例如-in-law或!Kung），请结合使用不区分大小写的insource查询与针对该词“普通”形式（即不含特殊前缀的形式）的简单搜索，以避免进行单纯的正则表达式搜索。例如，使用"in-law" insource:/-in-law/i或"kung" insource:/!kung/i。

前缀和名字空间

在搜索查询前加上像file:这样的命名空间前缀，可将搜索结果限制在特定的命名空间 内，而不是搜索整个wiki。 默认命名空间是“Main”。

通过搜索框查询只能设置一个命名空间名称。 它必须是查询中的第一个词项；或者，如果作为prefix:词项的一部分使用，则必须作为查询中的最后一个词项出现。

您可以在每个搜索结果页面（Special:Search）顶部的搜索栏中的“高级”面板内，同时搜索两个或更多命名空间。 您可以在此处设置搜索域（即命名空间配置）。 随后，命名空间列表将显示在后续搜索结果的第一页上，以标明搜索结果所属的搜索域。 若要取消此设置，请选择默认命名空间（显示在括号内），勾选“记住”，然后点击“搜索”。

搜索栏以图形化方式设定并标示搜索范围。“内容页面”（主名字空间）、“多媒体”（文件）、“全部”（“全部”加上文件）、“翻译”等均为超链接，点击即可在相应范围内启动查询，随后这些链接会变为非活动状态（变暗）以示标识。不过，具体的查询操作会覆盖搜索栏的设定。 当查询中使用了命名空间或前缀时，搜索栏的激活状态及相关提示可能会产生误导；因此，搜索栏与搜索框是设定搜索范围的两种互斥（而非互补）方式。

命名空间会覆盖搜索栏中的内容，而prefix:则会覆盖命名空间。

若要指定命名空间名称，请在其前面加上冒号，例如talk:。 使用all:在“所有”命名空间中搜索，或使用 :（单个冒号）仅在主条目命名空间中搜索。

全部不包含文件（File）名字空间。 文件包括在Commons（例如PDF）中保存的媒体内容，这些内容都是索引和可搜索的。 当涉及到文件时，一个命名空间修饰符 local: 有作用，否则它被忽略。

如同搜尋的參數一樣，local:和all:必須小寫。 不過，命名空間的名稱是不區分大小寫的。

命名空间的别名 也是可接受的。

talk: "Wind clock"	查找讨论命名空间中标题或正文包含短语“wind clock”的页面。
file: "Wind clock"	查找文件命名空间中标题、正文或媒体内容包含短语“wind clock”的页面。
file: local: "Wind clock"	过滤来自共享资源wiki的结果。
local: "Wind clock"	已忽略。 搜索主命名空间。除非涉及文件命名空间，否则忽略本地选项。

prefix:

prefix:参数匹配同一命名空间内所有页面名称开头的任意数量字符。 当起始字符与命名空间名称及冒号匹配时，搜索域会发生变化。

仅给定一个名称空间，prefix:将匹配其所有页面名称。 如果仅指定一个字符，则该字符不能是-（连字符）、'（单引号）或"（双引号）。 最后一个字符不能是冒号。

对于相匹配的页面名称，其子页面标题根据定义也是匹配的。

prefix:参数不允许在命名空间前出现空格，但允许在页面名称前出现空白字符。 该项总是位于末尾，以便页面名称字符中可以包含引号(")。

prefix:cow	查找主名字空间中标题以字母c o w开头的页面。
domestic   prefix:cow	查找主名字空间中标题以c o w这三个字母开头，且包含单词“domestic”的页面。
domestic   prefix:cow/	列出Cow的所有现有子页面，但仅限包含单词domestic的页面。 这是一种非常常见的搜索，通常使用名为prefix=的特殊URL参数来实现。
domestic   prefix:Talk:cow/	列出“Talk:cow”的所有子页面，但仅限包含单词domestic的页面。
1967   prefix:Pink Floyd/	列出“Pink Floyd”的所有子页面，但仅限包含“1967”这一词汇的页面。

Translate扩展会为页面的翻译版本创建一种“语言命名空间”。 然而，与创建初始搜索域的namespace或prefix不同，inlanguage参数是对该搜索域的一种“过滤”。（详见下一节。）

搜索中的重定向

执行全文搜索时，仅返回非重定向页面。 If a redirect influenced the ranking it is shown next to the redirected-to page, such as Relative density (redirect from Specific gravity).

可以通过两个前缀关键字来改变这种行为。 这些关键字必须出现在查询的开头，在其他任何位置均无效。

onlyredirects:

当查询以onlyredirects:为前缀时，重定向处理逻辑会反转。 非重定向页面将从结果中排除，仅重定向页面会作为搜索结果显示。 此模式可与大多数其他关键字及排序方式（例如insource:, intitle:等）结合使用。

withredirects:

当查询以withredirects:关键字为前缀时，系统会使用相同的查询同时搜索重定向页面和非重定向页面。 受相关性排名机制的影响，重定向页面在搜索结果中的排名往往较为靠后，非重定向页面的排名通常会高于它们。 该模式还可以与大多数其他关键字及排序方式结合使用。

noredirects:

When a query is prefixed with the noredirects: keyword the redirect pages are completely excluded from the query. Redirect pages themselves will not be returned, and pages will not be matched based on page titles that redirect to them. This mode can also be combined with most other keywords and sort orders.

从搜索索引中排除内容

可以通过添加class="navigation-not-searchable"将内容排除在搜索索引之外。这将指示CirrusSearch在构建搜索索引时忽略该内容（更多背景信息请参阅T162905）。

此外，可以通过添加class="searchaux"将内容标记为辅助信息。 这将指示CirrusSearch将内容从正文移至一个辅助字段，该字段在搜索及摘要高亮显示中的重要性较低。 这种区分用于图像缩略图描述、“另见”章节等项目。

过滤器

过滤器可以有多个实例或否定实例，也可以作为独立组件运行，对搜索域进行过滤。 查询由用于筛选搜索域的词项构成。

增加额外的词语、短语或参数会进一步筛选结果。对于高度精确的搜索结果，如果需要逐一处理结果中的每一页，可能会涉及大量的“是/否”筛选条件（在这种情况下，排序已基本无关紧要）。 在添加正则表达式项时，筛选至关重要；你应当在应用正则表达式之前尽可能减少待处理页面的数量（因为正则表达式搜索无法利用预先构建的索引）。

命名空间是一个指定的搜索域，但它不是过滤器，因为命名空间无法独立运行。 “前缀”起否定作用，因此它是一种过滤器。 以下搜索参数是过滤器，可能同時有多個項目。

“Insource”（上文已述）也是一种过滤器，但insource:/regexp/并非过滤器。过滤器及所有其他搜索参数均使用小写字母。（命名空间是个例外，不区分大小写。）

在标题中與在指定分类中

单词和短语搜索会匹配标题以及页面底部的分类框。不过，利用这些参数，您可以选择“仅限标题”或“仅限分类”。

• cow*
  • 搜尋標題或內文由cow開頭的頁面
• intitle:foo
  • 查找标题包含foo的条目。词干提取对foo启用。
• intitle:"fine line"
  • 查找标题中包含“fine line”的文章。已禁用词干提取。
• intitle:foo bar
  • 查找标题包含foo或包含bar的条目。
• -intitle:foo bar
  • 查找标题既不包含“foo”、也不包含“bar”的词条。
• incategory:Music
  • 查找属于“Music”分类的词条
• incategory:"music history"
  • 查找属于“Music_history”分类的词条
• incategory:"musicals" incategory:"1920"
  • 查找同时属于“Musicals”和“1920”分类的词条
• -incategory:"musicals" incategory:"1920"
  • 查找属于“1920”分类，但不属于“musicals”的词条

“intitle”和“incategory”是旧有的搜索参数。incategory不再自动搜索子分类，但现在您可以手动添加多个分类页面名称。

≥ 1.31 Gerrit change 413896

从MediaWiki 1.31-wmf.23 版本开始，intitle支持正则表达式搜索：

intitle:/regex/, intitle:/regex/i

#正则表达式搜索中所述的所有内容（包括警告）同样适用于这些搜索。

请尽可能避免进行单纯的正则表达式搜索。请参阅下文#正则表达式搜索，了解如何始终避免此类操作。

Deepcategory

深度分类搜索功能支持在指定类别及其所有子类别中进行搜索。目前，搜索的层级深度限制为5级（可配置），类别数量限制为256个（可配置）。该深度搜索利用了WDQS的SPARQL分类服务。关键词为deepcategory或deepcat。示例如下：

• deepcat:"musicals"
  • 查找属于“Category:音乐剧”分类或其任何子分类的文章。

此前实现该参数的DeepCat小工具已于2020年1月停用。

链接到(linksto)

“Linksto”查找的是指向特定“名称”的维基链接，而非指向“内容”的链接。输入内容应为区分大小写的页面标准“名称”。 它必须与内容页的标题行完全一致（在对标题的大小写进行任何修改之前）。 （它必须与{{FULLPAGENAME}}匹配，例如Help:CirrusSearch/zh。）

“Linksto”无法查找重定向。它仅查找[[维基链接]]，即使这些链接是由模板生成的也不例外。 它无法识别由URL构成的链接，即使该URL是内部维基链接。

若要查找所有指向“Help:Cirrus Search”的维基链接（其中“Help:Searching”和“H:S”均为指向该页面的重定向）：

1. linksto: "Help:Cirrus Search"
2. linksto: Help:Searching
3. linksto: H:S

CirrusSearch -linksto: Help:CirrusSearch用于查找提及“CirrusSearch”但未将其作为维基链接的文章。

包含模板(Hastemplate)

您可以使用hastemplate: template來指定模板的用法。輸入規範的頁面名稱找到該模板的「所有用法」，但使用其任何重定向的頁面名稱可以找到「僅有命名」。命名空間的別名是可接受的、完全忽略大小寫、並找到重定向，所有這些都在一個名稱搜尋中完成。(比較：「助推模板(boost-template)」沒有預設命名空間；「链接到(linksto)」沒有命名空間別名、有區分大小寫、沒有重定向；「在标题中(intitle)」沒有重定向)。

“Hastemplate” 用于检测页面中是否存在二级（或元）模板的使用情况：它会搜索模板展开后的包含内容。这与检测模板中包含的“词语和短语”所遵循的逻辑相同，只不过此处针对的是模板中包含的“模板”。即使页面源代码中未直接显示该内容，系统仍会将该页面列为包含该内容。

• hastemplate: "quality image"：在您的默认搜索域（命名空间）中查找"Template:Quality image"的使用情况。
• hastportal：查找Portal命名空间中“Contents/TOCnavbar”模板在主命名空间的使用情况。

对于安装了Translate扩展的系统，当Template:Translatable template name包裹了某个可翻译模板的名称时，针对该模板进行的hastemplate搜索会受到干扰。请改用insource。

在指定语言中(Inlanguage)

對於有使用翻譯擴充功能的安裝，inlanguage對於高度精準的搜尋和頁面計數非常重要。

inlanguage: 语言代码

將只產生該語言的搜尋結果。

例如

• 计数wiki上的所有日语页面

all: inlanguage: ja

• 在帮助名字空间中过滤掉德语和西班牙语页面

help: -inlanguage: de -inlanguage: es

• 忽略翻译，如果英语是基本语言，则添加

inlanguage:en

Contentmodel

contentmodel:关键字允许将搜索范围限定为特定内容模型的页面。关于可用模型，请参阅内容处理器。例如：

• 只查看JSON页面：

contentmodel:json

子页面是属于

要查找子页面。

subpageof: 父页面

例如

• 查找所有子页面是属于CirrusSearch。

subpageof:CirrusSearch

• 如果父頁面包含有空格，請使用雙引號。

subpageof:"Requests for comment"

若要排除子页面，请添加一个包含斜杠的标题排除词。 由于斜杠是一个元字符，因此必须使用正则表达式格式并对斜杠进行转义：

-intitle:/\//

與「前綴prefix:」不同，關鍵字值中不包含頁面命名空間。如果您要限制特定命名空間的子頁面，請使用命名空間篩選器。

Articletopic

articletopic:关键词允许按主题筛选搜索结果。 关于可能的主题，请参阅Help:CirrusSearch/articletopic 。 例如，输入articletopic:books会将搜索结果筛选为关于书籍的文章。 articletopic:books|films将筛选出关于书籍或电影的文章。 articletopic:books articletopic:films将筛选出同时涉及书籍和电影的文章。

只有主名字空间的条目才属于主题，且主题功能仅在维基百科上可用。 与其他过滤器不同，articletopic还会进行页面加权：与特定主题匹配度更高的条目将在搜索结果中排名靠前（而完全不涉及该主题的条目则会从结果集中彻底剔除）。

主题模型是通过机器学习 推导出来的。 任何一篇条目都会在数十个不同的主题上获得评分，因此可能会出现在不同的关键词之下。 例如，关于阿尔伯特·爱因斯坦的条目可能会同时归类为“物理学”条目和“传记”条目。 所有维基百科版本都提供评分数据——其中一些版本拥有涵盖所有条目的本地语言主题模型。 其他语言版本没有本地模型，而是使用针对同时存在于英语维基百科的本地语言条目所赋予的英语评分。 拥有此类“跨维基”评分的语言并不能实现100%的覆盖——具体取决于语言，可能仅有约60%的条目拥有相关主题内容。

≥ 1.45 Gerrit change 1191677

该关键字允许设置一个“提升”（boost）因子，以影响您想要搜索的各个主题的重要性：

• articletopic:books^2.0|fashion^0.2 – 列出关于书籍或时尚的条目，但会更侧重于关于书籍的条目。
• articletopic:books^100 – 相对于其他排名标准（如其他关键词或词汇、入站链接数量或页面热度等），赋予该关键词极高的重​​要性。

这个“增强”因子必须是一个正数。

Articlecountry

该关键词允许根据条目国家模型作出的预测，对页面进行筛选和排序。

其支持的值记录在Help:CirrusSearch/articlecountry ：

• articlecountry:and – 筛选可能与安道尔相关的页面
• articlecountry:bel|fra – 筛选可能与比利时或法国相关的页面。

与articletopic类似，该关键字可以接受一个“加权”（boost）因子。

Pageid

pageid:关键字将搜索结果限制在指定的页面ID集合内。 这对于人工搜索而言并无太大用处；它主要供软件工具使用，用于检查一组页面是否符合给定的搜索条件（例如，用于重新验证缓存的搜索结果）。

creationdate / lasteditdate

您可以使用两个筛选条件，按日期筛选搜索结果：

• lasteditdate: – 针对页面最后一次编辑的时间
• creationdate: – 针对页面最初创建之时（即首次修订的日期）。

这使您能够查找最近更新的内容、长时间未更新的页面，或在特定时间段内创建的页面。 所有日期查询均使用您正在搜索的维基站点的本地时区；您的个人时区设置不会影响查询结果。

您可以在任何日期前添加比较运算符，以限定搜索范围：

運算子	含義	示例	说明
>	之後	creationdate:>2024	2024年之后创建的页面
>=	在……当天或之后	lasteditdate:>=2024	最后编辑于2024年或之后的页面
<	之前	creationdate:<2025	2025年之前创建的页面
<=	在……或之前	lasteditdate:<=2020	最后编辑于2020年或更早之前的页面

如果不使用运算符，搜索将查找该时间段内的精确匹配项。

搜索的精确度取决于日期的提供方式。 提供绝对日期时，具体取决于日期的精确程度：

精度	示例	描述
年	creationdate:2025	2025年任何时间创建的页面
月	lasteditdate:2025-09	页面最后编辑于2025年9月
日	creationdate:2025-09-01	于2025年9月1日创建的页面

或者，您也可以使用now或today来指定相对日期。 搜索的精确度将取决于所使用的关键词。 该关键字后可接一个减号（-），随后是一个数字和一个后缀。 可使用以下后缀：

关键词	精度	示例	描述
now	小时	lasteditdate:now	当前小时内最后编辑的页面
now	小时	creationdate:now-1h	过去一小时内创建的页面
now	小时	lasteditdate:>=now-1d	过去24小时内最后编辑的页面
today	日	creationdate:today	今天创建的页面
today	日	lasteditdate:today-1d	页面于昨天最后编辑
today	日	creationdate:>today-1y	过去一年内任何时间创建的页面

虽然没有单一的“范围”运算符，但您可以通过在同一查询中组合两个日期筛选器来创建日期范围。

示例	描述
creationdate:>=2010 creationdate:<2020	创建于2010年代（2010年1月1日至2020年1月1日）的页面。

hasrecommendation

该关键字可用于筛选机器学习模型已针对其给出推荐建议（通常是关于可进行的改进）的页面。

• hasrecommendation:image – 筛选出模型建议添加图片的页面。

推荐类型取决于已启用该系统的模型和Wiki。

例如，在WMF维基站点上，存在一些可能会进行标记的模型：

• image – 可以添加页面图像的条目。
• image_section – 可向其某个章节添加图像的条目。
• link – 可添加链接的条目

This keyword is generally used by other tools such as Growth/Personalized first day/Structured tasks .

如果推荐结果连同其“置信度评分”一并存储，则可利用该关键词，结合“阈值”和/或“加权因子”来进行筛选或加权处理。 For instance if you want to filter pages where a recommendation of type tone has a confidence score above 0.5 you can use: hasrecommendation:tone>0.5. Similarly if you want the hasrecommendation to influence the ranking of the search results you can use a boost factor: hasrecommendation:tone^1.0. You can also combine these two with: hasrecommendation:tone^1.0>0.5.

• 置信度评分“阈值”必须是0到1之间的小数。
• the boost factor must be a positive number

该关键词高度依赖于特定Wiki上启用的推荐模型，因此可能无法在所有WMF Wiki上生效。

页面权重

权重决定了摘要、建议内容及页面相关性。默认权重为1，额外的权重则通过乘数来设定。

If the query is just words, pages that match them in order are given a boost. If you add any explicit phrases to your search, or for certain other additions, this "prefer phrase" feature is not applied.

更类似

• morelike:page name 1|page name 2|...|page name n
  • 查找与给定文章的文本最接近类似的词条。
• morelike:wasp|bee|ant
  • 查找有关昆虫叮咬的词条。
• morelike:template:search|template:regex|template:usage
  • 查找在本wiki上在模板名字空間使用的有關regex的查找结果。

morelike is a "greedy" keyword, meaning that it cannot be combined with other search queries. If you want to use other search queries, use morelikethis in your search:

• morelikethis:bee hastemplate:"featured article"
  • Find articles about bees that also have the "featured article" template.

The morelike: query works by choosing a set of words in the input articles and run a query with the chosen words. You can tune the way it works by adding the following parameters to the search results URL:

• cirrusMltMinDocFreq – Minimum number of documents (per shard) that need a term for it to be considered.
• cirrusMltMaxDocFreq – Maximum number of documents (per shard) that have a term for it to be considered.
• cirrusMltMaxQueryTerms – Maximum number of terms to be considered.
• cirrusMltMinTermFreq – Minimum number of times the term appears in the input to doc to be considered. For small fields (title) this value should be 1.
• cirrusMltMinWordLength – Minimal length of a term to be considered. Defaults to 0.
• cirrusMltMaxWordLength – The maximum word length above which words will be ignored. Defaults to unbounded (0).
• cirrusMltFields (comma separated list of values) – These are the fields to use. Allowed fields are title, text, auxiliary_text, opening_text, headings and all.
• cirrusMltUseFields (true | false) – use only the field data. Defaults to false: the system will extract the content of the text field to build the query.
• cirrusMltPercentTermsToMatch – The percentage of terms to match on. Defaults to 0.3 (30 percent).
• 例如：

  &cirrusMtlUseFields=yes&cirrusMltFields=title&cirrusMltMinTermFreq=1&cirrusMltMinDocFreq=1&cirrusMltMinWordLength=2
  

These settings can be made persistent by overriding cirrussearch-morelikethis-settings in System message.

Prefer-recent

Adding prefer-recent: anywhere in the query gives recently edited articles a slightly larger than normal boost in the page-ranking rules. Prefer-recent is only applied when using the default relevance sort order.

It defaults to boost only 60% of the score, in a large, 160-day window of time, which can be entered in the query as prefer-recent:0.6,160. This plays well with other page ranking rules, and is intended for most searches.

You can manipulate the rules: prefer-recent:boost,recent Technically, "boost" is the proportion of score to scale, and "recent" is the half life in days. The boost is more than the usual multiplier, it is an exponential boost. The factor used in the exponent is the time since the last edit.

例如

prefer-recent:,7

Pages older than 7 days are boosted half as much, and pages older than 14 days are boosted half as much again, and so on. For a simple "sort by date" in highly refined search results, where page ranking and boosting are largely meaningless, just boost the entire score.

• prefer-recent:1,7 – weeks
• prefer-recent:1,1 – days
• prefer-recent:1,0.0007 – minutes
• prefer-recent:1,0.0001 – 8.64 seconds
• prefer-recent:1,0.00001 – seconds

助推模板(Boost-templates)

你可以根据所包含的模板来助推搜索结果的頁面評分。這可以透過MediaWiki:Cirrussearch-boost-templates宣告助推來應用到所有的搜尋查詢，或透過 boost-templates:"" 運算子宣告助推來應用在個別查詢中的端對端查詢。如果在查詢中設定了boost-templates運算符，則會忽略cirrussearch-boost-templates的內容。 類似於 prefer-recent 功能，助推模板被應用在做為預設relevance排序順序的一部份。它對其他搜尋順序沒有影響。

訊息的語法如下：

• 從 # 符號到行尾的所有內容都會被視為註解、且會被忽略。
• Every non-blank line is interpreted as the exact name of a template that should receive boosting (including namespace prefix), followed by a pipe "|" character, followed by a number, followed by a "%" character.

Good examples:

 Template:Important|150%
 Template:Very_Very_Important|300%
 Template:Less_important|50%

Bad examples:

 Template:Foo|150.234234% # decimal points are not allowed.
 Foo|150% # technically valid, but acts on transclusions of Foo (main space article) instead of Template:Foo.

舉一些例子：

boost-templates:"Template:Quality_Image|200%" incategory:china

查找中国分类中的文件、高质量图片排序在先。

boost-templates:"Template:Quality_Image|200% Template:Low_Quality|50%" incategory:china

查找中国分类中的文件、高质量图片排序在最先、低质量的图片排序在最後。

boost-templates:"Template:Quality_Image|200% Template:Low_Quality|50%" popcorn

尋找有關爆米花的檔案，將高质量图片排序在最先、低质量的图片排序在最後。請記住，透過使用 cirrussearch-boost-templates 訊息，這可以縮小到只有 popcorn。

百分比的數值中不允許使用小數點。搜尋評分時，百分比的小數點不太可能產生什麼作用。

請注意，如果您透過 cirrussearch-boost-templates 加入一些非常低或非常高的百分比，則它們會毒害全文的評分。 For example, if Wikipedia were to boost the "Featured article" template by 1 million percent, then, searches for any term mentioned in featured articles, would rank the featured article above even the dedicated article about that term.

Phrase matching would be similarly blown away, so a search like brave new world would return a featured article as first result even if it merely has those three words mentioned throughout it, instead of the more relevant article about Brave New World itself.

正则表达式搜索

警告：	Try to avoid running bare insource:/regex/ searches. They are likely to timeout, giving partial results, and they can block the regex queries of other users.

A basic indexed search finds words rendered visibly on a page. Punctuation and symbols--like periods, dashes, brackets, slashes, math and computing symbols, etc.--are merely boundaries for the words. They are generally not included in an indexed search. Mostly that search behavior is wanted by the user. However, sometimes one needs a more precise search. To get around the limits of index-based searches regex searches can be used. These specify a regular expression that the raw wikitext of the page being searched for has to match.

How regex searches work

On large wikis with millions of pages, running a regular expression on every single one (or every single one in a set of namespaces) would be impossible to implement efficiently. In order to optimize regex searches, the search system attempts to extract three-character sequences of text that any string matching the regular expression must also contain. These are known as trigrams. For example, the regex foo(bar|baz)? can only match strings starting with "foo".

If any such trigrams are found, they are checked against a separate index of all pages' wikitext, and the regex is only run on pages containing the relevant trigrams. If at least one trigram is relatively rare, such as ||}, then the search will complete relatively fast – searching for that on this wiki completes in only a few seconds.

On the other hand, if trigrams cannot be extracted from a regex (possibly because the regex is too complicated to parse or doesn't require the wikitext to contain any specific 3-character strings), or the only trigrams that can be extracted are extremely common (like the), then the domain of pages to run the regex on will be extremely large. The search system has to scour these character-by-character, which is very slow and likely to time out (resulting in incomplete results).

Using the index first to filter results

Hence, when using an insource:// (a regex of any kind), consider adding other search terms that will limit the regex search domain as much as possible. There are many search terms that use an index and so instantly provide a more refined search domain for the /regex/. In order of general effectiveness:

• insource:"" with quotation marks, duplicating the regex except without the slashes or escape characters, is often helpful.

• intitle (without regex search), incategory, and linksto are excellent filters.

• hastemplate: is a very good filter.

• "word1 word2 word3", with or without the quotation marks, are good.

• namespace: is practically useless, but may enable a slow regex search to complete.

For example, the following regexes in italic each match one specific string, with an index-based search limiting the domain of the regex in bold:

• insource:"debian.reproducible.net" insource:/debian\.reproducible\.net/
• insource:"http://www.mediawiki.org" insource:/http:\/\/www\.mediawiki\.org/
• insource:"c:\program files (x86)" insource:/C\:\\Program Files \(x86\)/i
• insource:"<tag>{{template}}</tag>" insource:/"<tag>{{template}}<"\/"tag>"/
• insource:"</references>" insource:/\<\/references>/
• insource:"[[title|link label]]'s" insource:/"[[title|link label]]'s"/

To test a bare regex query you can create a page with test patterns, and then use the prefix parameter with that fullpagename. 匹配项会被高亮。 It searches that page (in the database) and its subpages.

For example: [[Special:Search/insource:/regex/ prefix:{{FULLPAGENAME}}]] finds the term regex on this page.

This example works from a link on a page, but {{FULLPAGENAME}} doesn't function in the search box.

Search terms that do not increase the efficiency of a regex search are the page-scoring operators: morelike, boost-template, and prefer-recent.

Regular expression syntax

元字符

此节包含如何在regexp搜索中，避免元字符（metacharacters）的内容 For the actual meaning of the metacharacters see the explanation of the syntax.

Searching for an exact string requires a regex, but using a regex term warrants limiting the search domain if possible. Add a regex term, rather than search with a bare regex, when possible. Start by noting the number of pages in a previous search before using an exact string search. Querying with an exact string is best with a filtered search domain.

例如：

• to search a namespace, gauge the number of pages with a single term that is a namespace. This will list the number of pages in that namespace.

• starting out to find again what you may have seen, like "wiki-link" or "(trans[in]clusion)" start with namespace and insource filters.

There are some notable differences from standard regex metacharacters:

• The dot . metacharacter stands for any character including a newline, so .* matches across lines.

• The number # sign means something, and must be escaped.

• The ^ and $ are only available for intitle:// searches, but not for insource://.

When matching titles ^ and $ match the beginning and end of the title. Like "grep" (global per line, regular expression, print each line), each insource:// is a "global per document, regular expression, search-results-list each document" per document.

• < and > support a multi-digit numeric range like [0-9] does, but without regard to the number of character positions, or the range in each position, so <9-10> works, and even <1-111> works.

Character classes

Regex search supports a minimal set of character classes. While negated shorthands such as \W are not available the classes can be negated as part of a character class, as in [^\w].

CirrusSearch	Description
\w	Matches any alphanumeric ascii character and the underscore. Equivalent to [A-Za-z0-9_]
\s	Matches the space character and a variety of unicode spaces. Equivalent to [\f\n\r\t\v\u0020\u00a0\u1680\u2000-\u200a\u2028\u2029\u202f\u205f\u3000\ufeff]
\d	Matches any ASCII digit. Equivalent to [0-9]

Escape codes

Regex search also supports a few escape codes that make it possible to search for unprintable characters.

CirrusSearch	Description
\r	carriage return (CR)
\n	line feed (LF)
\t	tab
\uHHHH	Can represent any unicode character. It must be provided exactly 4 hexadecimal characters representing the codepoint. Surrogate pairs are represented with two sequences in a row. Searching for half a surrogate pair will not return any results.

Escaping metacharacters

There are two ways to escape metacharacters. They are both useful at times, and sometimes concatenated side-by-side in the escaping of a string.

• Backslash-escape one of them \char.

The insource:/regex/ uses slashes to delimit the regex. Giving /reg/exp/ is ambiguous, so you must write /reg\/exp/.

• Put a string of them in double quotes "string". Because escaping a character can't hurt, you can escape any character along with any possible metacharacters in there. Escaping with quotes is cleaner.

• You can't mix methods, but you can concatenate them.

Double-quotes escaping using insource:/"regex"/ is an easy way to search for many kinds of strings, but you can't backslash-escape anything inside a double-quoted escape.

• /"[[page/name|{{temp-late"/ instead of /\[\[page\/name\|\{\{temp\-late/

• /"literal back\slash"/ is as good as /literal back\\slash/

• But /"This \" fails"/ always.

• And /"This \/ depends"/. It finds the \/ literally, which is not the / you probably wanted.

Backslash-escape using insource:/regex/ allows escaping the " and / delimiters, but requires taking into account metacharacters, and escaping any:

• To match a / delimiter character use \/.

• To match a " delimiter character use \".

• The escaped metacharacters would be \~\@\#\&\*\(\)\-\+\{\}\[\]\|\<\>\?\.\\.

• The equivalent expression escaped with double-quotes is "~@#&*()-+{}[]|\<>?.\".

The simplest algorithm to create the basic string-finding expression using insource:/"regex"/, need not take metacharacters into account except for the " and / characters:

1. Write the/str"ing out. (The /" delimiters "/ are not shown.)
2. Replace " with "\"" (previous double-quote: stop, concatenate, quote restart).
3. Replace / with "\/" (stop, concatenate, start).
4. You get insource:/"the"\/"str"\""ing"/, showing concatenation of the two methods.

While refining a regex on a search results page, keep in mind that the snippet "wikitext" has modified spacing. Regexes are sensitive to space characters, so copying from snippets is dangerous.

The square-bracket notation for creating your own character-class also escapes its metacharacters. To target a literal right square bracket in your character-class pattern, it must be backslash escaped, otherwise it can be interpreted as the closing delimiter of the character-class pattern definition. The first position of a character class will also escape the right square bracket. Inside the delimiting square brackets of a character class, the dash character also has special meaning (range) but it too can be included literally in the class the same way as the right square bracket can. For example both of these patterns target a character that is either a dash or a right square bracket or a dot: [-.\]] or [].\-].

For general examples using metacharacters:

• insource:"2+2=4" insource:/"2+2=4"/ matches "2 + 2 = 4", with zero spaces between the characters.

• insource:"2 + 2 = 4" insource:/2 ?\+ ?2 ?= ?4/ match with zero or one space in between. The equals = sign is not a metacharacter, but the plus + sign is.

• insource:"<tag>[[link|2\3?]]\</tag>" insource:/"<tag>[[link|2\3?]]<"\/"tag>"/
• insource:"</references>" insource:/\<\/references>/

Regex on titles

The insource keyword only searches the source content of each page. To run regex searches on the title strings intitle:/regex/ can be used.

高级示例

For example, using metacharacters to find the usage of a template called Val having, inside the template call, an unnamed parameter containing a possibly signed, three to four digit number, possibly surrounded by space characters, and on the same page, inside a template Val call, a named argument fmt=commas having any allowable spaces around it, (it could be the same template call, or a separate one):

hastemplate:val insource:"fmt commas" insource:/\{\{ *[Vv]al *\|[^}]*fmt *= *commas/ insource:/\{\{ *[Vv]al *\|[^}]*[-+]?[0-9]{3,4} *[|}]/

Note that the = sign in "fmt commas" is not needed but that adding it would not change the search results. It is fast because it uses two filters so that every page the regex crawls has the highest possible potential.

地理搜索

Searching based on the (primary) coordinates associated with pages. Depends on Extension:GeoData（地理数据） and {{#coordinates:}}

有界限

你可以將搜索的頁面限制在指定的地理坐標附近。 坐標可以使用<緯度>, <經度>的格式，也可以提供頁面標題來當作指定的坐標。 如果有需要，可以限制搜索範圍的距離。例如： 示例：

• neartitle:"San Francisco"
• neartitle:"100km,San Francisco"
• nearcoord:37.776,-122.39
• nearcoord:42km,37.776,-122.39

已提高

You can alternatively increase the score of pages within a specified geographic area. The syntax is the same as bounded search, but with boost- prepended to the keyword. This effectively doubles the score for pages within the search range, giving a better chance for nearby search results to be near the top.

• boost-neartitle:"San Francisco"
• boost-neartitle:"100km,San Francisco"
• boost-nearcoord:37.776,-122.39
• boost-nearcoord:42km,37.776,-122.39

文件属性搜索

≥ 1.28 Gerrit change 311061

Since MediaWiki 1.28, CirrusSearch supports indexing and searching of properties of files in the File: namespace. This includes:

• file media type

• MIME type

• size

• width & height

• resolution

• bit depth for files that support these

While these predicates are useful only for files, they by themselves do not limit search to the File: namespace. It is recommended to include this namespace in a search or restrict the search to only this namespace when using these conditionals.

文件类型

文件類型搜索允許根據分類搜索文件，例如辦公室文件、影片、點陣圖、向量圖等。目前存在以下類型：

• UNKNOWN
• BITMAP
• DRAWING
• AUDIO
• VIDEO
• MULTIMEDIA
• OFFICE
• TEXT
• EXECUTABLE
• ARCHIVE
• 3D

This list may be extended in the future. See also MEDIATYPE_* constants in defines.php.

The syntax of the search is: filetype:{type}. Example:

filetype:video – looks for all videos

The filetype search is not case-sensitive.

文件mime

Matches file MIME type. The syntax is:

filemime:{MIMEtype} – look for files of this MIME type

The argument can be quoted to specify exact match. Without quotes, partial matches to components of MIME type will be accepted too.

示例：

• filemime:"image/png" – look for files with MIME type exactly image/png
• filemime:pdf – look for all PDF documents
• -filemime:pdf – skip all PDF documents (notably on Commons)

The MIME type search is not case-sensitive.

文件大小

搜索指定大小的文件，單位為千位元組（1024位元組）。語法為：

• filesize:{number}或filesize:>{number} – file with size at least given number
• filesize:<{number} – file with size no more than given number
• filesize:{number},{number} – file with size between given numbers

示例：

• filesize:>20或filesize:20 – 至少20KB的文件
• filesize:<1024 – 小于1MB的文件
• filesize:100,500 – 大小在100KB到500KB之間的文件

文件尺度

可以搜尋特定的檔案尺度：寬度、高度、解析度（定義為高度×寬度的平方根）和位元深度。並非所有檔案都有這些屬性。語法為：

• {measure}:{number} – 檔案裏的尺度等於給定的數量
• {measure}:>{number} – 檔案裏的尺度大於給定的數量
• {measure}:<{number} – 檔案裏的尺度小於給定的數量
• {measure}:{number},{number} – 檔案裏的尺度介於給定的那些數量

measure可以是：

• filew或filewidth - 文件的宽度
• fileh或fileheight - 文件的高度
• fileres – 文件的解析度（見上方）
• filebits – 文件的位元深度

示例：

• filew:>800 fileh:>600 – 大小大於800x600像素的文件
• filebits:16 – 有16位元色彩深度的文件
• fileheight:100,500 – 像素高度在100到500之間的文件

Wikibase搜尋

Wikibase 擴充功能定義了一些搜尋關鍵字，以便更容易搜尋某些Wikibase的項目。 這對 Wikidata 和其他 Wikibase 網站很有用，包括搜尋 维基共享资源 上有結構化資料的圖片。 详情请见Help:WikibaseCirrusSearch 。

跨維基搜索結果

There are two kinds of cross-wiki results that may be shown when searching on Wikipedia.

Cross-project search (also known as interwiki search, sister search, or sister projects search) shows additional results from other projects (Wiktionary, Wikisource, Wikiquote, etc.) shown to the side on the Wikipedia results page. Cross-project search is available on most Wikipedias with sister projects.

Cross-language search (see blog post) refers to additional results shown below the main results that are from a Wikipedia in a different language. Cross-language search uses a heavily modified and optimized version of a light-weight language detector called TextCat . Cross-language search is currently only available on a few Wikipedias (see TextCat link for details).

指定排序方式

In addition to the default relevance based sort, CirrusSearch can provide results using a few other explicit sort orders. Specifying a sorting order other than relevance will disable all search keywords that affect scoring, such as prefer-recent or boost-templates. The keywords will still be parsed, but they will have no effect.

Sorting options are currently available from the MediaWiki API by providing the srsort parameter.

Guidance:

Sorting options can be manually added to a search URL by adding &sort=order, for example:

• https://www.mediawiki.org/w/index.php?search=foo&sort=last_edit_desc

Valid sort orders include:

&sort=incoming_links_asc

Lowest to highest number of incoming links. This is approximately from least to most popular.

&sort=incoming_links_desc

Highest to lowest number of incoming links. This is approximately from most to least popular.

&sort=last_edit_asc

From least recently to most recently edited

&sort=last_edit_desc

From most to least recently edited

&sort=create_timestamp_asc

From least to most recently created

&sort=create_timestamp_desc

From most to least recently created

&sort=just_match

A simple relevance sort based only on text matching

&sort=random

Randomized

&sort=relevance

A relevance sort taking into account many features of the document

&sort=title_natural_asc

Sort by title ascending

&sort=title_natural_desc

Sort by title descending

&sort=user_random

Randomized, but stable per user. Each user will see a unique, seemingly random order of results, but that order will remain the same every time that specific user runs the same search.

&sort=none

Unsorted, arbitrarily ordered lists. Preferred for large result sets.

Interaction among search options

Some search options when used together may interfere with or modify their operation when used alone.

• Search options that impact relevance such as prefer-recent, boost-templates, and boost-neartitle have no effect when sort is not relevance. Keyword morelike may have marginal impact.

用于高级选项的界面

高级搜索界面

The AdvancedSearch extension adds an improved interface to the search page allowing the use of several options described above in a user-friendly manner. See here for the user manual.

参阅

• Extension:CirrusSearch

• Completion Suggester – the incremental search feature of CirrusSearch

• Wikimedia Search Platform/Search/Glossary – definitions, context, and links for terms related to search.

• See Help:搜索 for MWSearch, used by the many wikis that don't have a search extension.

外部链接

• From Lucene, highly relevant documentation.

• 浏览器测试中的完整说明 截至2017年
• Extension:CirrusSearch/Profiles – sets of tunable parameters that influence various aspect of the indexing
• Wikimedia blog articles related to search
• WMF Global Search