Help:CirrusSearch

注意: このページを編集すると、編集内容が CC0 のもとで公開されることに同意したと見なされます。詳細はパブリック・ドメインのヘルプ ページを参照してください。

MediaWiki で情報を見つけるための最も速い方法は直接探すことです。 ページに検索ボックスがあります。

CirrusSearch（シーラスサーチ）は MediaWiki の拡張機能で、既定の MediaWiki 検索よりも強化された検索機能を提供するためにElasticsearchを使っています。 ウィキメディア財団は、ウィキメディアプロジェクト群のすべてのサイトにシーラスサーチを使っています。 このページではシーラスサーチの機能を説明します。 疑問がここで解消しない際には遠慮なくトークページでお尋ねください。誰かがお答えします。

MediaWiki 拡張機能の情報は、Extension:CirrusSearch を参照してください。

ウィキデータでの使用については、Help:Extension:WikibaseCirrusSearch をご参照ください。

使い方

キーワード（単語）やキーフレーズ（句）を入力し、Enter や Return キーを押します。または、虫眼鏡アイコン、または「検索」ボタン、（設定により）「表示」ボタンをクリックしてください。

入力文字と同じ名前のページが存在すれば、直接そのページを表示します。 見つからない場合には、ウィキのすべてのページを検索し、検索項に合致する記事の一覧を表示するか、合致する記事が存在しないことを知らせます。

検索ボックスに入力せずに「検索」ボタンをクリックすると、追加の検索オプションがある「Special:Search」に移動します（この検索オプションは、検索結果の画面でも常に利用できます）

検索対象を特定の 名前空間、たとえばUserページのみから探すように指定すると役に立つことがあります。 そうするには、その名前空間のチェックボックスをオンにします。

以下に紹介するキーワードはすべて大文字小文字を区別し、小文字のみで記します。

改良点

CirusSearch は、標準の MediaWiki 検索と比較して、主に以下の3つの改良点があります:

• さまざま言語での検索への対応を改善
• 検索インデックスの更新の高速化。これにより記事に加えられた変更が大幅に高速に検索結果に反映されるようになります。
• テンプレートの展開。つまり、テンプレートからすべての内容が検索結果に反映されるようになります。

検索インデックスの更新頻度

考慮すべき基本的な検索インデックスが2つあります：

1つ目は Special:Search 上の全文検索です。 このインデックスはほぼリアルタイムに更新されます。 ページを変更すると数分以内にそれが検索結果に現れるはずですが、それでも通常の運用では30分が考慮されます。 テンプレートへの変更は、そのテンプレートを参照読み込みしている記事に反映されるまでに数分、テンプレートを使用しているページの数によっては数時間かかるはずです。 記事に対して空編集を行うことで強制的に反映させることが可能ですが、うまくいっていれば特に必要ないはずです。

考慮すべき2つ目のインデックスはあいまい(fuzzy)自動補完タイトル検索です。 このインデックスは1日1回更新され、インデックスが更新された時点の全文検索インデックスを反映します。 タイミングによっては新しいページがあいまいタイトル自動補完で見つかるようになるのに2日かかる可能性があります。 特定の使用事例でこれが受け入れられない場合、利用者検索オプション内でタイトル補完を全文検索インデックスを使うクラシックな前方一致検索に変更できます。

検索候補の表示

検索ボックスに入力するとドロップダウンで表示される候補のページは、記事の品質の大まかな評価順に並んでいます。 その候補の選別には、内部リンクされている数、ページサイズ、外部リンクの数、見出しの数、リダイレクトの数が考慮されます。

検索候補はスキップでき、クエリは検索結果ページに直接移動します。 クエリの前に、半角チルダ~を追加してください。 例えば、"~Frida Kahlo"です。 検索サジェスチョンはその後も表示されますが、Enter キーを押すと検索結果ページへ飛びます。

言語によっては、アクサンやダイアクリティカルマーク（発音区別符号）がオンになります。詳細は言語ごとに特定されます。

The algorithm used to rank suggestions is described in more detail at Extension:CirrusSearch/CompletionSuggester#Ranking criteria.

全文検索

「全文検索」は「インデックス検索」です。 すべてのページはウィキ・データベースに格納されており、リダイレクトページではないページにある全ての単語は、実質、そのウィキの全文をインデックスにした検索データベースに格納されています。 それぞれの知られた単語はそれが見つかったページの一覧としてインデックス化されているので、ある単語の検索は、単一レコードを調べるのと同じくらい速いです。 さらにいかなる文言の変更も数秒以内に検索インデックスに反映されます。

ウィキの「全文検索」のインデックスは多数あり、必要な検索のさまざまなタイプに対応しています。 ウィキテキスト全体に対して、インデックスを個別の目的ごとに付与し、それに基づいて解析するため、あらゆる方法で柔軟に利用できます。 インデックスの例をあげます。

• 「補助」テキスト ‐ HTML属性class=searchauxで分類された、ハットノートやキャプション、目次および任意のウィキテキストが含まれます。
• 「導入部」テキスト ‐ ページの上部と最初の見出しの間にあるウィキテキストです。
• 「カテゴリ」テキスト ‐ ページ最下部の一覧をインデックス化します。
• テンプレートがインデックス化されます。テンプレートの参照読み込みされた単語が変更された場合、それを参照読み込みしているすべてのページが更新されます。（ジョブキューによっては時間がかかります。）テンプレートが呼び出すサブテンプレートが変更された場合、インデックスが更新されます。
• FileやMediaの名前空間に格納されたドキュメントの内容も、インデックス化するようになりました。数千のフォーマットが認識されます。

この機能は多言語で提供されていますが、すべての言語での対応が望まれています。 現在サポートしている言語の一覧は外部サイトelasticsearch.orgにあります。パッチや要望の連絡先は投稿の説明文書を参照してください。 Elasticsearch が対象としない言語は、外部第三者のオープンソースなライブラリを使って対応します。

CirrusSearchはクエリを最適化して実行します。結果のタイトルは関連性によって重み付けされ、20件ずつ検索結果ページに出力します。記事から抜粋したり、検索項を太字で強調したりします。

検索結果には、しばしばさまざまな予備的な報告が付いています。「クエリの修正候補」（スペル修正）を示す場合や、どうしても結果が見つからなかった場合には「○○に対する検索結果」（クエリの修正）と（ユーザー指定のクエリの）「代わりに○○を検索」と表示します。

その他の検索機能の要素：

• ナビゲーション提案はリンク元の数によって並べ替えられます。
• チルダ文字~から始めると、ページランキングも維持するような方法でナビゲーションや提案を無効化します。
• 文字のスマートマッチング ‐ 外字（キーボードにない文字）をキーボード文字に正規化します（または「折りたたむ」）。
• マッチする単語や句は検索結果のページにおいて太字で強調されます。強調表示器が見た目を分析する一方で、検索インデックス分析器が実際にページを見つけるので、両者が100％同期しない可能性があります（特に正規表現の場合）。強調表示器がインデックス分析器よりも正確に一致することも不正確なこともあります。

単語、句、および修飾子

基本的な検索項は、単語（ワード）または「引用符〈"〉で囲んだ句（フレーズ）」です。 詳細は言語ごとに、特にスペースを使わない言語では様々ですが、検索は典型的には以下のものを「単語」と認識します：

• 一連の数字
• 一連のレター（訳注：数字、記号ではない文字）
• txt2regexのように、レターと数字の間で遷移する部分語（サブワード）
• キャメルケースを使ったcompoundName（複合語）内の部分語

「ストップワード」はあまりにも一般的などの理由で無視されます (英語の a、the 他)。 ストップワードの一覧は言語ごとに固有であり、またストップワードのない言語もあります。 指定した検索項は（ページ上に描画された）コンテンツとマッチさせます。そうではなくウィキテキストとマッチさせるには、insource検索パラメータを使います（下記の節参照）。それぞれの検索パラメータは独自のインデックスを持ち、指定された項を独自の方法で解釈します。

単語、句、パラメータ、およびパラメータへの入力の間のスペーシングには、ホワイトスペース文字およびグレースペース文字をいくつでも含めることができます。 「グレースペース文字」とはアルファベットではないすべての文字~!@#$%^&()_+-={}|[]\:";'<>?,./のことです。 グレースペース文字とホワイトスペース文字の混合文字列は、「グレースペース」であり、大きなひとつの単語境界として扱われます。 グレースペースはインデックスを作成し、クエリを解釈する方法です。

例外が2件あります。1)「embedded:colon」 は1単語（埋め込まれたコロンはレターとして扱われます）。2）「1,2,3」のように埋め込まれたカンマ「,」は数字として扱われます。 グレースペース文字は、クエリ構文により、修飾子の文字として解釈できる場合を除き無視されます。

修飾子とは「~ * \? - " ! 」のことです。構文のどの位置にあるかにより、項、パラメータ、クエリ全体のいずれかを修飾します。単語および句を修飾するものは、ワイルドカードと近似(proximity)検索、あいまい(fuzzy)検索です。パラメータごとに修飾子が異なる場合もあるものの、一般原則は次のとおりです：

• fuzzy-word または fuzzy-phrase 検索はチルダ ~ 文字（および程度を示す数字）を接尾辞に使用できます。
• チルダ ~ 文字をクエリの最初の項の接頭辞に使うと、いかなる可能なナビゲーションでもなく検索結果を表示することを保証します。
• 単語内のワイルドカード文字は、1文字に対しては (エスケープされた) 疑問符 \? を、ゼロ文字以上に対してはアスタリスク文字 * を使うことができます。
• 真理・論理は AND および OR を解釈できますが、 パラメータはできません。 AND および OR 演算子は現在のところ、伝統的な真理・論理のやり方で機能しないことに注意してください！ 詳細は 論理演算子 を参照してください。
• 真理・論理は接頭辞として項に与えられた - や ! を理解し、項の通常の意味を「一致する」match から「除外する」exclude に入れ替えます。

-in-law や !Kungのように、 - や ! から始まる単語は、ページ名やリダイレクトと正しくマッチしますが、 否定された単語を含まないすべての文書にもマッチし、通常ほとんどすべての文書が対象になります。 ページ名やリダイレクトの完全一致以外でそれら項を検索するには、insource検索パラメータを使います (下記の 節 をご参照ください)。

• 単語を引用符で囲むと、「完全一致句」検索になります。パラメータに対して、複数の単語の入力を区切るためにも必要とされます。
• 語幹解釈 (stemming) は自動処理されますが、無効化するには「完全一致句」検索を使います。

2種類のワイルドカード文字はアスタリスク「*」と（エスケープされた）疑問符で、どちらも単語の中でも末尾でも使えます。 エスケープされた疑問符「\?」は1文字を表し、「*」は任意の数の文字を表します。 多くの利用者は、クエリを書く代わりに、質問を書くため、疑問符単体では無視されます。意図的にエスケープされた「\?」を使わないと、ワイルドカードとして認識されません。

句検索は、検索エンジンにさまざまなヒントを与えて実行します。そのヒントの与え方にはそれぞれ副作用があり、単語の組み合わせに対する検索結果の許容範囲が異なります。greyspace、camelCase、あるいはtxt2numberに対するヒントは：

• words-joined_by_greyspace(characters) または wordsJoinedByCamelCaseCharacters を与えると words joined by …… charactersが、そのままの形式またはグレースペース形式で見つかります。
• txt2numberはtxt 2 numberまたは txt-2.numberにマッチします。
• ストップワードはgrey_space またはcamelCase 句の境界文字（周辺）に対して有効化されます。 the、of、およびaを使う例では、テキストmeetings invisible hand shake内でthe_invisible_hand_of_aがinvisible handにマッチします。

普遍的に知られていない単語が句で無視されると、「○○の代わりに検索」のレポートが発動します。

以下の種類の句マッチングのそれぞれのものは、前のものの許容範囲を広げます：

• 「引用符で囲んだ」「完全一致句」はグレースペース（でのマッチ）を許容します。「"exact_phrase"」あるいは「"exact phrase"」を与えると「"exact]phrase"」にマッチします。
• greyspace_phraseにより語幹解釈およびストップワードのチェックが始まります。
• 「CamelCase」を与えると、すべて小文字を許容して、追加で「camelcase」がマッチします。なぜならば、CirrusSearchはマッチングにおいてケースセンシティブではない（大文字と小文字を区別しない）からです。 CamelCaseマッチングはすべての言語に対して有効ではないことに注意してください。

パラメータによってはグレースペース句を解釈するものの、「insource」などのようなその他のパラメータは、通常の「引用符で囲んだ句」のみを解釈します。

検索用語で言う「語幹解釈」(stemming) のサポートとは、「swim」の検索に「swimming」と「swimmed」も含むが、「swam」のような不規則な活用形は含まないという意味です (訳注: swim の過去形は swam であり、swimmed は正しくない活用形)。

検索する句	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のように埋め込まれたアンダースコアの文字はレターとして解釈しなかったことに注意してください。数字の羅列内の半角カンマ,の文字にも似たような事象が発生します。

CirrusSearchは「完全一致句」の文脈（insource パラメータの文脈を含む）でin:this:wordを与えると、in、this、あるいはwordにはマッチしませんが、in:this:wordにだけはマッチします。

それ以外は、 CirrusSearch に対して単語はレター、数字、あるいはその2つの組み合わせであり、大文字小文字は無関係であることを覚えておいてください。

一般的な単語検索では空白文字を採用して語幹解釈を積極的に行い、同じ単語がグレースペース文字またはキャメルケースで結合されているときには、句および部分語に対して積極的になります。

"of" あるいは "the" のような一般的な単語がグレースペース句に含まれているときには、これらは無視され、より積極的にマッチするようになります。

A greyspace_phrase search term, or a camelCase, or a txt2number term, match the signified words interchangeably. You can use any of those three forms. 現在、camelcase は camelCase にマッチします。なぜなら、検索が大文字と小文字を区別しないためです。しかし、camelCase は camelcase にマッチします。これは、camelCase の方が優先されるためです。 検索の他の部分と同様に、部分語 "words" は大文字/小文字が区別されません。対照的に、"exact phrase" は空白に基づいており、数字や文字の大文字小文字の遷移、語幹変化を無視します。"引用符で囲まれた語句" は大文字/小文字が区別されません。

表からは、基本検索 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にマッチします。

アスタリスク * ワイルドカードはレンダーされた単語内のレターおよび数字の文字列にマッチしますが、開始文字には決してマッチしません。 1文字以上が * 文字の前になければなりません。

• * が数字群にマッチするとき、コンマは数字の一部とみなされますが、小数点はグレースペース文字とみなされ、2つの数字群に区切ります。
• 「完全一致句」の中では、 * はワイルドカード文字ではなく、グレースペース文字として扱われ、したがって単語を区切ります。

\? ワイルドカードは1つのレターまたは数字を表します; *\? も受け入れられますが、 \?* は認識されません。

ワイルドカードは基本的な単語、句、およびinsource検索に対するものであり、（いくつかの）高度な正規表現検索（後述）の代替にもなるかもしれません。

単語または句のあとにチルダ~文字を置くとあいまい検索が有効化されます。

• 句(phrase)に対しては、完全一致句(exact phrase)よりも、近似な(proximal)単語群が許容されるので近似(proximity)検索と呼ばれます。
• 例えば、"exact one two phrase"~2はexact phraseにマッチします。
• 単語に対しては、余分な文字または変更された文字を意味します。
• 句に対しては、あいまい検索は余分な単語をいくつ含めて良いか示す数が必須ですが、単語に対しては、あいまい検索は小数を持つことができ、word~0.5（word~.5）を既定とし、この場合には最大で2つのレターを入れ替え、変更、または追加できるものの、先頭の2つのレターは常に除外します。
• 近似的な句に対しては、大きな数字を適用できますが、「費用のかかる」（遅い）検索になります。
• wordに対しては、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 を引いたものを 2 倍にしてください。 (言い換えると、セグメントの数を 2 倍にしてください)。 For the full proximity algorithm, see Elasticsearch slop.

引用符は語幹解釈をオフにしますが、"but appending"~のようにチルダを付加すると語幹解釈を再開します。

	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			チルダ接尾辞によって近似に語幹解釈を足す。

insource検索

≧ 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 complements itself. On the one hand it has full text search for any word in the wikitext, instantly. On the other hand it can process a regexp search for any string of characters. Regexes scan all the textual characters in a given list of pages; they don't have a word index to speed things up, and the process is interrupted if it runs for more than twenty seconds. 正規表現はクエリの最後に実行され、不必要な文字レベルのスキャンを制限するようになっており、あらゆる正規表現クエリはスキャンする必要がある文書の数を制限するために他の検索項を含めるべきです。 しばしば正規表現クエリ insource:/arg/ に追加する最善の候補となるのは insource:arg です。ここで、 arg は同一（かつワイルドカードを使わない）です。

正規表現の構文は insource: スペースなし、それから/regexp/です（他にスペースを禁じるパラメータはありません。insource:/regexp/以外のパラメータはコロンのあとにスペースを許容します。）

Insourceインデックス検索と正規表現検索の役割は多くの側面で似ています：

• どちらもウィキテキストのみを検索します。
• どちらも参照読み込みによって「ソースされている」ものを見つけません。
• どちらも語幹解釈、あいまい、あるいは近似検索をしません。
• どちらも最小限の結果を求め、どちらも他の条項を伴うとより速く動作します。

しかしインデックス化された検索はすべてグレースペースを無視します; ワイルドカードはグレースペースにマッチしないので、正規表現が「任意かつすべて」の文字の完全一致文字列、例えば連続する2つのスペース、を見つける唯一の方法です。 正規表現は、文字通りの文字列に簡単にマッチングさせたり（基本的な、初心者向けの使い方）、メタ文字表現によるマッチングを可能にしたりする（高度な使い方）、全く異なる分類のウィキ上の検索ツールです。 後述の#正規表現検索をご参照ください。

insourceパラメータはコロンが埋め込まれた単語群をひとつの単語として扱います。これはテンプレート、パーサー関数、URL、ウィキリンク、HTMLタグ、およびコメントに対する検索クエリに影響します。

可能なときには、むき出しの正規表現検索を行わないようにしてください。常にこれを可能にする方法を以下の#正規表現検索で参照してください。

-in-law や !Kung のように、 - や ! から始まる単語は、大文字と小文字を区別しない（ケース・インセンシティブ）なinsourceクエリを「プレーン」なバージョンの項と共に使ってください (むき出しの正規表現検索を避けるため) 。例えば、 "in-law" insource:/-in-law/i や "kung" insource:/!kung/i のようにしてください。

接頭辞と名前空間

Prepending a namespace term like file: to a search query limits results to a specific namespace , instead of searching the entire wiki. The default namespace is "Main".

検索ボックスのクエリからは単一の名前空間のみ設定できます。 It must be the first term in the query, or, if used as part of a prefix: term, must appear as the last term in the query.

各検索結果ページ、Special:Searchの上部に現われる検索バーにある高度な検索枠から2個以上の名前空間を入力して検索できます。 ここで検索ドメインを、名前空間のプロファイルとして、設定できます。 このときの名前空間の一覧は、将来の検索時に1ページ目に表示され、検索結果の検索対象ドメインがわかります。 この設定を解除するには、既定の名前空間 (丸カッコ内に表示) を選択、「記憶」を選んで「検索」ボタンを押します。

The search bar graphically sets and indicates a search domain. "Content pages" (mainspace), "Multimedia" (File), "Everything" (all plus File), "Translations", etc., are hyperlinks that can activate the query in that domain, and then indicate this by going inactive (dark). But the query will override the search bar. 名前空間または prefix がクエリで使われたとき、検索バーのアクティベーションと表示は誤解を招くかもしれないので、検索バーと検索ボックスは検索ドメインを設定する相互排他的な（補完的でない）方法です。

名前空間項は検索バーより優先され、prefix: 項は名前空間より優先されます。

To specify a namespace name, prefix it with a colon, e.g., talk:. Use all: to search across all namespaces, or : (a single colon) to search just the main article namespace.

all: は File 名前空間を含みません。 File はコモンズに保持されている PDFのようなメディアコンテンツを含み、これはすべてインデックス化されていて検索可能です。 File が関係するとき、名前空間修飾子 local: が効果を持ち、それ以外のときは無視されます。

As with search parameters, local: and all: must be lowercase. Namespaces names, though, are case insensitive.

名前空間の別名 は受け入れられます。

talk: "Wind clock"	Talk（トーク） 名前空間で、タイトルまたは文章中に「wind clock」という句が含まれるページを見つける。
file: "Wind clock"	File（ファイル）名前空間で、タイトル、文章、またはメディアコンテンツに「wind clock」という句が含まれるページを見つける。
file: local: "Wind clock"	コモンズ・ウィキからの結果を除外します。
local: "Wind clock"	無視されます。 標準空間を検索します。 File が関係しない限り、 Local は無視されます。

prefix:

The prefix: parameter matches any number of first-characters of all pagenames in one namespace. When the first letters match a namespace name and colon, the search domain changes.

Given a namespace only, prefix: will match all its pagenames. Given one character only, it cannot be - (dash), ' (quote), or " (double quote). The last character cannot be a colon.

For pagenames that match, their subpage titles match by definition.

The prefix: parameter does not allow a space before a namespace, but allows whitespace before a pagename. This term always goes at the end, so that pagename characters may contain quotation marks (").

prefix:cow	Find pages in mainspace whose title starts with the three letters c o w.
domestic   prefix:cow	Find pages in mainspace whose title starts with the three letters c o w, and that contain the word "domestic".
domestic   prefix:cow/	List any existing subpages of Cow but only if they contain the word "domestic". This is a very common search and is frequently built using a special URL parameter called prefix=.
domestic   prefix:Talk:cow/	List any subpages of Talk:cow, but only if they contain the word "domestic".
1967   prefix:Pink Floyd/	List any subpages of Pink Floyd, but only if it also contains the word "1967".

The Translate extension creates a sort of "language namespace" of translated versions of a page. However, unlike namespace or prefix, which create the initial search domain, the inlanguage parameter is a filter of it. (See the next section.)

検索インデックスからコンテンツを除外する

コンテンツを検索インデックスから除外するにはclass="navigation-not-searchable"を加えます。すると CirrusSearch は検索インデックスで当該のコンテンツを無視する指示を受けます（さらに詳しくはタスク T162905を参照してください。）

さらにコンテンツは class="searchaux" を追加することによって、補助的な情報としてマークできます。 これによって CirrusSearch に、そのコンテンツをメインテキストフィールドから、検索および抜粋表示についての優先度が低い補助フィールドへ移動させるよう指示します。 この区別は、画像のサムネイルの解説、「関連項目」セクション、などの項目に対して使われます。

フィルター

フィルターは複数のインスタンス群、または否定インスタンス群を持つか、単独で実行して検索ドメインをフィルタリングできます。 クエリは検索ドメインをフィルターする項群として形成されます。

他の単語、句、またはパラメータを追加するとさらにフィルターします。高度に洗練された検索結果は、結果にある各ページに対処するとき非常に多くの Y/N フィルターを持っているかもしれません。（この場合、ランキングは大部分が的外れです。） 正規表現項の追加にはフィルタリングの適用が非常に重要です。正規表現を追加する前にできるだけページを少なくしたいのです（なぜならば、検索のためのインデックスが用意できないからです）。

名前空間は指定された検索ドメインですが、単独で実行することはないのでフィルターではありません。 prefix は否定するのでフィルターです。 下記の検索パラメーターは複数のインスタンスを持つことができるフィルターです。

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
  • Category:Music に属する記事を見つけます
• incategory:"music history"
  • Category:Music_history に属する記事を見つけます
• incategory:"musicals" incategory:"1920"
  • Category:Musicals および Category:1920 の両方に属する記事を見つけます
• -incategory:"musicals" incategory:"1920"
  • Category:Musicals には属さないが、 Category:1920 には属する記事を見つけます

「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:Musicalsまたはいずれかの下位カテゴリにある記事を探す

以前そのパラメータを実装していた DeepCat ガジェットは2020年1月に廃止されました。

Linksto

Linksto はリンク先のコンテンツではなく名前で指定した内部リンクを探します。入力はカノニカルで、大文字と小文字を区別する（ケース・センシティブな）、ページの名前です。レターケース（大文字か小文字か）にいかなる改変も加えずに、コンテンツページのタイトル行に正確にマッチしなければなりません。 (例えばHelp:CirrusSearch/jaのように、{{FULLPAGENAME}}とマッチしなければなりません。)

Linksto はリダイレクトを探しません。テンプレートによって作られたときでも、[[wikilinks]]のみを探します。 URL がたとえ内部ウィキリンクであっても、それにより生成されたリンクは探しません。

"Help:Searching"や"H:S"が"Help:Cirrus Search"に対するリダイレクトである場合、内部リンクすべてを見つける方法は以下のとおりです：

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 finds secondary (or meta-template) usage on a page: it searches the post-expansion inclusion. This is the same philosophy as for words and phrases from a template, but here it's for templates from a template. The page will be listed as having that content even though that content is not seen in the wikitext.

• hastemplate: "quality image", finds "Template:Quality image" usage in your default search domain (namespaces).

• hastemplate: portal:contents/tocnavbar, finds mainspace usage of a "Contents/TOCnavbar" template in the Portal namespace.

For installations with the Translate extension, hastemplate searches get interference wherever Template:Translatable template name wraps the template name of a translatable template. Use insource instead.

Inlanguage

inlanguageは翻訳拡張機能のインストールとの併用では、高度な検索やページカウントにとって重要です。

inlanguage: 言語コード

の指定により、検索結果をその言語に限定します。

例えば

• そのウィキにあるすべての日本語ページを数えるには

all: inlanguage: ja

• ヘルプ名前空間にあるページでドイツ語とスペイン語を除くには

help: -inlanguage: de -inlanguage: es

• 英語が基本言語であるときに、翻訳を無視するには、次を追加

inlanguage:en

Contentmodel

contentmodel: キーワードにより、検索範囲を特定のコンテンツモデルのページに制限できます。Content handlersの使えるモデルを示します。例：

• JSON ページのみ表示：

contentmodel:json

subpageof

下位ページを検出。

subpageof: 親ページ

例

• CirrusSearch の下位ページをすべて検出。

subpageof:CirrusSearch

• 親ページ名にスペースが含まれる場合は二重引用符を使う。

subpageof:"Requests for comment"

unlike prefix:, do not include the page namespace in the keyword value. If you want to limit to sub-pages of a particular namespace use the namespace filter.

Articletopic

The articletopic: keyword allows filtering search results by topic. For possible topics see Help:CirrusSearch/記事トピック . E.g. articletopic:books will filter the search results to articles about books. articletopic:books|films will filter to articles about books or films. articletopic:books articletopic:films will filter to articles which are about both books and films.

Only mainspace articles belong into topics, and topics are only available on Wikipedias. Unlike other filters, articletopic also does page weighting: articles which are a stronger match for a topic will be higher in the search results (while articles which aren't about that subject at all will be removed from the result set completely).

Topic models are derived via machine learning from ORES. Any given article receives a score on dozens of different topics, and therefore may appear under different keywords. For instance, the article on Albert Einstein may appear as a "physics" article and a "biography" article. All Wikipedias have scores available -- some have local-language topic models that have coverage on all articles. Other languages do not have local ORES models, and are using English-language scores assigned to articles in the local language that also exist in English Wikipedia. The languages with such "cross-wiki" scores do not have 100% coverage -- depending on the language, it may only be something like 60% of articles that have topics available.

Topic-related search data is updated weekly, so recently created articles might not show up in topic-based search queries.

Pageid

pageid: キーワードは検索結果を指定したページIDの集合に制限します。 これは手動検索ではあまり役に立ちません; ページの集合が指定した検索条件の集合にマッチするかどうかソフトウェアツールによって確認（例えば、キャッシュされた検索結果の再検証）をするために使うことができます。

ページの重み付け

Weighting determines snippet, suggestions, and page relevance. The normal weight is one. Additional weighting is given through multipliers.

クエリがただの単語群である場合、単語群にマッチするページは与えられた増幅（ブースト）の順序です。任意の明示的な句を検索に追加するか、または特定の他の追加をすると、この「prefer phrase」機能は適用されません。

Morelike

• morelike:page name 1|page name 2|...|page name n
  • 指定した記事と文章がもっとも似たものを探す。
• morelike:wasp|bee|ant
  • Find articles about stinging insects.
• morelike:template:search|template:regex|template:usage
  • Find templates about regex searching for template usage on the wiki.

morelike は「欲張りな」キーワードで、つまりは他の検索クエリと組み合わせることができません。他の検索クエリを使いたい場合は、 morelikethis を検索で使ってください：

• morelikethis:bee hastemplate:"featured article"
  • bees に関する記事で "featured article" テンプレートもあるものを見つけます。

morelike: クエリは入力記事で複数の単語を選ぶことによって機能し、選択された単語でクエリを実行します。動作方法を調整するには、検索結果の URL に以下のパラメータを追加します:

• cirrusMltMinDocFreq: 考慮すべき項に必要とされる（シャード毎の）文書の数の最小値。
• cirrusMltMaxDocFreq: 考慮すべき項を持つ（シャード毎の）文書の数の最大値。
• cirrusMltMaxQueryTerms: 考慮する項の数の最大値。
• cirrusMltMinTermFreq: 考慮すべき項の文書への入力における出現回数の最小値。小さいフィールド (title) に対してはこの値は1にすべきです。
• cirrusMltMinWordLength: 考慮すべき項の長さの最小値。既定値は 0 。
• cirrusMltMaxWordLength: 単語の長さの上限値。これを超える単語は無視される。既定値は制限なし (0)。
• cirrusMltFields (コンマで区切った値のリスト): これらをフィールドとして使用。 許容フィールドは title、text、auxiliary_text、opening_text、headings、all。
• cirrusMltUseFields (true|false): 使用するフィールドデータを限定。既定値は false: システムはクエリを構築するために text フィールドのコンテンツを抽出する。
• cirrusMltPercentTermsToMatch: 一致する項のパーセント。既定値は 0.3 (30 %)
• 例:

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

これらの設定を永続化するには システム メッセージ で cirrussearch-morelikethis-settings をオーバーライドしてください。

Prefer-recent

クエリの任意の位置にprefer-recent:を追加するとページ順位付けの規則において、最近編集された記事に通常よりもやや大きく重みを付けます。 Prefer-recent は既定の relevance 並べ替え順を使用しているときのみ適用されます。

既定では、スコアを 60% のみ、160日という期間、ブーストするようになっており、クエリでは prefer-recent:0.6,160 と入力できます。これは他のページの順位づけ規則との共用がうまく働き、ほとんどの検索に向いています。

規則を操作するには: prefer-recent:boost,recent とします。 技術上、"boost" はスコアを増大させる比率、"recent" は日数で表した半減期です。 増幅は通常の乗数ではなく、指数関数的な増幅です。 指数で使われる係数は最終編集からの時間です。

例えば

prefer-recent:,7

ページの増幅は作成後7日以上経過すると半減し、14日以上経過するとさらに半減し、といった具合です。 高度に洗練された検索結果における単純な「日付順並べ替え」に対しては、ページのランキングと増幅がほぼ無意味であり、単にスコア全体を増幅します。

• prefer-recent:1,7 - 週
• prefer-recent:1,1 - 日
• prefer-recent:1,0.0007 - 分
• prefer-recent:1,0.0001 - 8.64 秒
• prefer-recent:1,0.00001 - 秒

増幅-テンプレート

ページに含まれるテンプレートに基づき、スコアを増幅できます。これは MediaWiki:Cirrussearch-boost-templates を介して増幅を宣言することによってすべての検索クエリに既定で適用するか、個別のクエリで boost-templates:"" オペレーターを介してその場限り適用できます。 boost-templates オペレーターがクエリに設定されている場合、 cirrussearch-boost-templates の内容は無視されます。 prefer-recent機能と同じように、boost-templatesは既定のrelevance並べ替え順の一部として適用されます。その他の検索順では効果はありません。

メッセージの構文は以下の通りです：

• # 文字から行の終わりまではすべてコメントとみなされ、無視されます。
• すべての空でない行は、増幅を受けるべきテンプレートの完全一致名（名前空間接頭辞を含む）、その後にパイプ「|」文字、その後に数字、その後に「%」文字と解釈されます。

良い例:

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

悪い例:

 Template:Foo|150.234234% # 小数点は許容されません。
 Foo|150% # 技術的には有効ですが、Template:FooではなくFoo（標準空間の記事）の参照読み込みについて動作します。

例:

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

China（中国）というカテゴリ内でファイルを検索し、良質な画像を最初に並べる。

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

China（中国）というカテゴリ内でファイルを検索し、良質な画像を最初に、質の低い画像を最後に並べる。

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

popcorn（ポップコーン）に関するファイルを見つけ、良質な画像を最初に、質の低い画像を最後に並べる。 cirrussearch-boost-templates メッセージの使用によって、これは単に popcorn と短縮できることを覚えておいてください。

パーセントの値に小数点は許容されません。そのようにわずかなパーセントが、検索のスコアに差を生じることはないでしょう。

cirrussearch-boost-templates を介して非常に巨大または小さなパーセンテージを追加した場合、全文のスコアリングに悪影響を及ぼす可能性があるということに注意してください。 例えば、ウィキペディアが「特集記事」テンプレートの重みを 100 万 % 増加させる場合を考えてみましょう。すると、特集記事に言及されている任意の用語の検索では、その用語に関する専門の記事よりも特集記事が上位に来ることになります。

フレーズの一致も同様に影響を受けるため、brave new world のような検索は、その記事に単にそれらの 3 つの単語が言及されている場合でも、関連性の高い記事である Brave New World ではなく、代わりに特集記事を最初の結果として返してしまいます。

正規表現検索

警告:	むき出しの insource:/regexp/ 検索を実行しないでください。責任のある利用者のクエリをブロックすると同時に、おそらく20秒後にはどちらにせよタイムアウトしてしまうでしょう。

基本的なインデックス化された検索は、ページで視覚的に描画された単語群を見つけます。ハイフネーションや句読点のマークや括弧、スラッシュやその他の数学やコンピュータの記号は、単語群に対する単なる境界です。それらをインデックス化された検索に含めることはできません。 たいていは利用者が望んでいる検索の挙動です。しかしながら、もっと精密な検索を利用したいことがときどきあります。

インデックスベースの検索の構文的欠陥を避けるために正規表現検索を使うことができます。 ただし、正規表現のみを使用するクエリは非常に遅く、リソースを消費するため、正規表現の検索ドメインが1つ以上のインデックスベースの検索の結果に制限されるように、常にインデックスベースの検索と組み合わせるべきです。

An "exact string" regexp search is a basic search; it will simply "quote" the entire regexp, or "backslash-escape" all non-alphanumeric characters in the string. All regexp searches also require that the user develops a simple filter to generate the search domain for the regex engine to search (index based search domain marked bold, regexp part marked in italics):

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

最後の例はページ上のリンクから機能しますが、 {{FULLPAGENAME}} は検索ボックスでは機能しません。

例えば: [[Special:Search/insource:/regex/ prefix:{{FULLPAGENAME}}]] とするとこのページ上の regex という項が見つかります。

名前空間および接頭辞が指定されていないクエリは、利用者の既定の検索ドメイン（検索結果ページ、つまり Special:Search で設定可能）を検索します。一部の利用者は既定の検索ドメインを「すべての名前空間」つまりウィキ全体に指定しています。大規模なウィキでこのような利用者がむき出しの正規表現検索を実行すると、おそらく検索を完了する前にタイムアウトが発生して処理に失敗します。

正規表現検索は実際に検索ドメイン内の各ページを1文字ずつ精査します。 インデックス検索はそれとは対照的に、実際はウィキデータベースとは別に維持されるデータベースにいくつかのレコードを問い合わせることで、ほぼ即座に結果を提供します。 そのため、insource://（あらゆる種類の正規表現）を使用するときには、他の検索語を追加して、正規表現検索ドメインをできるだけ制限することを検討してください。 インデックスを使用する検索項は多くあるので、/regexp/に対して、即座により洗練された検索ドメインを提供できます。一般的な効果の順に紹介します:

• 引用符で囲んだ insource:""、スラッシュがなく文字をエスケープすることを除き正規表現の複製、理想的です。
• intitle （正規表現検索なし）、 incategory、および linksto は素晴らしいフィルターです。
• hastemplate: は非常に良いフィルターです。
• "word1 word2 word3"、引用符ありまたはなし、は良いです。
• namespace: は実際には役に立ちませんが、遅い正規表現検索の完遂を可能にするかもしれません。

むき出しの正規表現クエリをテストするには、テストパターンを記入したページを作成して、その完全なページ名に接頭辞パラメータprefixを使います。 マッチは強調されます。 (データベース内の) そのページおよび下位ページを検索します。

正規表現検索の効率性向上に役立たない検索項は、morelike、 boost-template、prefer-recentなどのページスコア演算子です。

メタ文字

この節では正規表現検索でメタ文字をエスケープする方法を取上げます。 メタ文字の実際の意味は構文の解説をご参照ください。

The use of an exact string requires a regexp, but the regexp term obligates the search to limit itself. Add a regexp term, never search a bare regexp. Start by noting the number of pages in a previous search before committing an exact string search. Querying with an exact string requires 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.

標準的な正規表現のメタ文字と顕著に異なる点がいくつかあります：

• \n あるいは \r\n は改行にマッチするために予約されていません。 改行を含む文字列を検索するには、 insource:/[^\}]\}\}[^\} \|]{2}\<noinclude/i のように検索してください。これは波括弧以外、その後に2つの波括弧、その後に波括弧、スペース、あるいはパイプを除く任意の2文字、その後に ‎<noinclude> タグを意味します。 検索において「を除く任意の文字」には改行を含みます。 この検索は以下の文字列にマッチするためだけに設計されたことに注意してください：

}}

<noinclude>

• ドット . メタ文字は改行を含む任意の文字を表すので、 .* は複数行にわたりマッチします。
• 番号記号 # は何か意味があり、エスケープしなければなりません。
• ^ および $ は実装されていません。"grep" （行毎にグローバルな、正規表現、各行を出力）のように、各 insource:// は文書毎に「文書毎にグローバルな、正規表現、各文書を検索結果一覧」です。
• < および > は複数桁の数値的な範囲を [0-9] と同じようにサポートしますが、数字の文字の位置、あるいは各位置での範囲を考慮しないので、 <9-10> が機能しますし、 <1-111> でさえも機能します。

いくつかのメタ文字の代用

文字クラス \n 、 \s 、 \S はサポートされていないものの、正規表現でどうしてもそれらを使う必要がある場合にはこれらの次善策を使うことができます：

PCRE	CirrusSearch	説明
\n	[^ -􏿿]	改行（タブ文字も見つける）
[^\n]	[ -􏿿]	改行およびタブ文字以外の任意の文字
\s	[^!-􏿿]	ホワイトスペース文字：スペース、改行、またはタブ
\S	[!-􏿿]	空白文字以外の任意の文字

これらの範囲で、 " "（スペース）は制御文字のすぐ後の文字、"!" はそのすぐ後の文字、そして "􏿿" はUnicodeで許容される最後の文字である U+10FFFF 文字として使われます。 したがって、 " " から "􏿿" までの範囲は、制御文字（その中で改行とタブが記事に含まれる可能性がある）を除くすべての文字を含み、一方 "!" から "􏿿" までの範囲は制御文字とスペースを除くすべての文字を含みます。

完全一致文字列で洗練する

• "2 + 2 = 4"、 あるいは "site.org"のように、見たいもので進行中の検索プロセスを洗練できます。これは理想的には正規表現の最良の使用法です。なぜならば、検索を洗練しつつ単一の正規表現の項として追加され、正規表現がクロールしなければならない限られた数のページがわかるからです。

完全一致文字列検索を意図し始めて構いませんが、次のことを心に留めておいてください：

• 正規表現は描画されたテキストではなくウィキテキストのみを検索するので、マークアップ周りにいくつかの差異があり、スペース文字の数さえも厳密にマッチしなければなりません。
• 付随するフィルターを適用する義務があります。
• 正規表現のメタ文字をエスケープする方法を学ばねばなりません。

メタ文字をエスケープする方法は2つあります。どちらも有用なときがあり、文字列のエスケープにおいて並べて連結させる場合もあります。

• \charでその1つをバックスラッシュエスケープ（訳注：日本語環境ではバックスラッシュではなく円マークで表示されることが多い）します。insource:/regexp/ は正規表現を区切るためにスラッシュ「/」を使います。/reg/exp/の入力はあいまいなので、/reg\/exp/と入力してください。
• それらの文字列を"文字列"のように二重引用符で囲んでください。文字をエスケープすることによって問題が発生する可能性がなく、その中に含まれている可能性のあるあらゆるメタ文字について、あらゆる文字をエスケープできるからです。引用符でエスケープする方がきれいです。
• 手法の混合はできませんが、連結はできます。

insource:/"regexp"/ を使って二重引用符エスケープをすると多くの種類の文字列を簡単に検索できますが、二重引用符エスケープの中ではいかなるものもバックスラッシュ・エスケープできません。

• /\[\[page\/name\|\{\{temp\-late/ の代わりに /"[[page/name|{{temp-late"/ とします
• /literal back\\slash/ と /"literal back\slash"/ は同じです（文字通りのバックスラッシュ）
• しかし /"This \" fails"/ は常に失敗します。
• そして /"This \/ depends"/ は場合によります。おそらく求めているであろう / ではなく、文字通り \/ が見つかります。

insource:/regexp/ にバックスラッシュ・エスケープ（訳注：日本語環境ではバックスラッシュではなく円マークで表示されることが多い）を使用すると区切り文字「"」と「/」をエスケープできるものの、メタ文字を考慮する必要があり、以下のいずれかによってエスケープします：

• / 区切り文字をマッチするには \/ を使ってください。
• " 区切り文字をマッチするには \" を使ってください。
• エスケープされたメタ文字は \~\@\#\&\*\(\)\-\+\{\}\[\]\|\<\>\?\.\\ となります。
• 二重引用符でエスケープされた等価な表現は "~@#&*()-+{}[]|\<>?.\" です。

「"」と「/」を除きメタ文字を考慮に入れる必要なく、insource:/"regexp"/を使って基本的な文字列を見つける表現を作成する最も単純なアルゴリズムは：

1. the/str"ing を書き出します。（ /" 区切り "/ は表示していません。）
2. " を "\"" で置き換えます（前の二重引用符を閉じ、連結し、引用符を再開します）。
3. / を "\/" で置き換えます（閉じ、連結、開く）。
4. insource:/"the"\/"str"\""ing"/ となり、２つの手法の連結を示しています。

検索結果ページで正規表現を洗練するときは、スニペット"wikitext"がスペーシングを変更していることに留意してください。正規表現はスペース文字に敏感なため、スニペットからコピーするのは危険です。

角括弧記法で独自の文字クラスを作成すると、その中のメタ文字はエスケープもされます。文字クラスパターンの中で文字通り右角括弧を対象とするには、バックスラッシュ・エスケープしなければならず、さもなくば右角括弧は文字クラスパターンの定義を閉じる区切り文字として解釈できます。 文字クラスの最初の位置では右角括弧もエスケープされます。文字クラスの角括弧区切りの中では、ダッシュ文字も特別な意味（範囲）を持ちますが、右角括弧と同じようにして文字通りクラスに含めることができます。 例えば、これらのパターンは両方とも、ダッシュまたは右角括弧またはドットのいずれかの文字を対象とします：[-.\]] あるいは [].\-]。

メタ文字を使う一般的な例については：

• insource:"2+2=4" insource:/"2+2=4"/ は文字の間のスペースがゼロ個のものと共に、"2 + 2 = 4"にマッチします。
• insource:"2 + 2 = 4" insource:/2 ?\+ ?2 ?= ?4\./ は間のスペースがゼロ個または1個のものとマッチします。等号 = はメタ文字ではありませんが、プラス記号 + はメタ文字です。
• insource:"<tag>[[link|2\3?]]\</tag>" insource:/"<tag>[[link|2\3?]]<"\/"tag>"/

タイトルの正規表現

insource キーワードはページのソースの内容だけを検索します。 タイトルで正規表現検索を実行するには intitle:/regex/ を使ってください。

高度な例

例として、メタ文字を使って、 Val というテンプレートの使用で、テンプレート呼び出し内に、符号付きかもしれない3から4桁の数字を含むスペース文字で囲まれているかもしれない名前なしパラメーターを持ち、なおかつ同一ページで、テンプレート Val 呼び出し内に、任意のスペースで囲まれていることを許容する名前付き引数 fmt=commas を持つものを探します、（同一のテンプレート呼び出しでも、別のテンプレート呼び出しでも可）：

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

"fmt commas" に = 記号は必要ではありませんが、追加しても検索結果は変わりません。 正規表現がクロールする各ページが可能な限り高いポテンシャルを持つように2件のフィルターを使用しているので高速です。

地理検索

ページに関連付けられている（最初の）座標に基づいて検索します。 Extension:GeoData および {{#coordinates:}} に依存します

制限値

特定の地理座標の近くにあるとわかっている事物のページに検索対象を限定できます。 座標は、緯度と経度の組を直接指定することも、座標の元となるページ名を入力することもできます。 距離を制限したい場合は先頭に追加します。 例:

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

増幅

あるいは指定した地理的領域の範囲内にあるページのスコアを増やすという方法があります。 キーワードの先頭に boost- を追加することを除き、構文は制限値検索と同じです。 これにより検索範囲のページのスコアを効率的に倍増し、近隣の検索結果を上位近くに配置する確率が高くなります。

• 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

MediaWiki 1.28 以降、CirrusSearch はFile:名前空間でファイルの属性をインデックス化した検索をサポートしています。これには以下が含まれます:

• ファイルのメディアの種類
• MIME タイプ
• サイズ
• 幅と高さ
• 解像度
• ビット深度をサポートするファイルではビット深度

これらの述語はファイルに対してだけ有用ですが、それ自体は検索をFile:名前空間に限定することはありません。これらを条件として使うときには、この名前空間を検索に含めるか、または検索範囲をこの名前空間のみに制限することが推奨されます。

ファイルの種別

ファイルの種類で検索することによって、Office ドキュメント、動画、ラスター動画、ベクター画像などといった分類に応じたファイルを取得できます。現在、以下の分類が利用できます：

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

この一覧は将来的に拡張されるかもしれません。関連情報はDefines.phpのMEDIATYPE_*を参照してください。

検索の構文例は、filetype:{type}。例:

filetype:video - すべての動画を探す

ファイルタイプ検索は大文字小文字を区別しません。

filemime

MIME 形式のファイル。構文の記述：

filemime:{MIMEtype} - この MIME 形式のファイルを検索

引数を引用符ではさむと、完全一致検索を指定できます。引用符がない場合、MIME タイプの要素の部分一致も適用されます。

例:

• filemime:"image/png" - MIME 形式で image/png と完全一致するファイルを検索
• filemime:pdf - PDF 文書をすべて検索
• -filemime:pdf - PDF 形式の文書はすべて除外（Commonsに特異的）

The MIME 形式の検索では大文字と小文字は識別しません。

ファイルサイズ

キロバイト（キロバイトは 1024 バイトの意味）で指定したサイズのファイルを検索します。その構文は：

• filesize:{number} または filesize:>{number} - サイズが指定した数値以上のファイル
• filesize:<{number} - サイズが指定した数値以下のファイル
• filesize:{number},{number} - サイズが指定した数値の間のファイル

例:

• 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 - 画像サイズが 800×600 ピクセル以上のファイル

filebits:16 - 色深度が16ビットの画像ファイル

fileheight:100,500 - 画像の高さが100 - 500 ピクセルのファイル

ウィキベース検索

ウィキベース 拡張機能は 複数の検索キーワードを指定し、特定のウィキベース項目を検索しやすくします。これはWikidata およびその他のウィキベースのサイト群で利用でき、ウィキメディア・コモンズ において構造化データで画像を検索する場合などに有用です。 詳細は Help:WikibaseCirrusSearch を参照してください。

ウィキ間検索の結果

ウィキペディアで検索しているときに、ウィキ間を横断して表示される場合がある結果が2種類あります。

プロジェクト間検索（ウィキ間検索、姉妹検索、あるいは姉妹プロジェクト検索ともいう）は、他プロジェクト（ウィクショナリー、ウィキソース、ウィキクオート、など）から追加の結果を、ウィキペディアの結果ページの側部に表示します。 ほとんどのウィキペディアで姉妹プロジェクトとのプロジェクト間検索が利用可能です。

言語間検索（ブログ投稿ご参照）は、主な検索結果の下部に表示される他言語版ウィキペディアからの結果を指します。 言語間検索は TextCat という軽量言語検出器の大幅に改良および最適化されたバージョンを使っています。 言語間検索は現状、ウィキペディアのいくつかの言語版でのみ利用可能です（詳細は TextCat へのリンクをご参照ください）。

明示的な並べ替え順

既定の関連性に基づく並べ替えに加えて、CirrusSearchはその他いくつかの明示的な並べ替えを使って結果を提供できます。 並べ替え順にrelevance以外を指定すると、prefer-recentやboost-templatesのようなスコアに影響する検索キーワードはすべて無効になります。 キーワードはなおも構文解析されますが、効果はありません。

並べ替えの選択肢は MediaWiki API から利用でき、 srsort パラメータを指定します。

手引き：

検索URLに&sort=orderを追加することによって、並べ替えのオプションを手動で設定できます。例えば、

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

有効な並べ替え順には以下を含みます。

URL 補足	説明
&sort=incoming_links_asc	リンク元の少ない順。 これはおおよそ人気がない順になります。
&sort=incoming_links_desc	リンク元の多い順。 これはおおよそ人気がある順になります。
&sort=last_edit_asc	編集日時の古い順
&sort=last_edit_desc	編集日時の新しい順
&sort=create_timestamp_asc	作成日時の古い順
&sort=create_timestamp_desc	作成日時の新しい順
&sort=just_match	テキストマッチングのみに基づく単純な関連性による並べ替え
&sort=relevance	文書の多くの機能を考慮に入れた関連性による並べ替え
&sort=random	無作為
&sort=none	未整列の任意順の一覧群。 結果のセットが長大なときに向きます。

高度なオプション用インターフェース

高度な検索用インターフェース

AdvancedSearch拡張機能は検索ページに改良型のインターフェースを補い、前述のオプションを利用者にわかりやすく使えるようにします。詳細はこちらのユーザーマニュアルを参照してください。

関連項目

• Extension:CirrusSearch
• Completion Suggester - CirrusSearchの増分的な検索機能
• Wikimedia Search Platform/Search/Glossary — 定義、文脈、および検索に関連する用語へのリンク。
• MWSearch の詳細はHelp:検索 をご参照ください。独自に検索拡張機能を備えていない多くのウィキで使われています。

外部リンク

• From Lucene - クエリの概念を的確に解説
• 拡張機能のブラウザー テストの完全な仕様 2017年時点
• Extension:CirrusSearch/Profiles – インデックス化の様々な側面に影響を与える調整可能なパラメータのセット
• Wikimedia blog articles related to search
• WMF Global Search