템플릿:검색 링크

템플릿 설명서[보기] [편집] [이력] [이력] [이력]

{{sl}}

이 템플릿은 위키백과 검색 상자 쿼리를 저장하는 데 사용할 수 있는 링크를 만든다.검색 링크는 Talk 페이지와 대부분의 다른 페이지에서 공동 검색에 유용하지만, 기사에서는 사용하지 않는다.기사에 사용할 경우 상기 경고를 출력한다.

기본 사항

{{Search link first second third}}

첫 번째 매개 변수는 검색 또는 쿼리에 대한 것이다.
두 번째 파라미터는 링크의 라벨이다.
세 번째 매개 변수는 검색 도메인이다.

템플릿 이름은 검색 링크 또는 줄여서 sl 입니다.
두 번째와 세 번째 파라미터는 선택 사항이고 기본값이 있기 때문에 짧은 형식은{{sl query}}.

검색 링크와 검색 상자는 모두 동일한 검색 엔진으로 이동한다.같은 질의가 같은 결과를 낳는다.

기본 검색은 기사를 포함한다.그것은 글자와 숫자로 구성된 단어와 구를 매우 빨리 찾지만, 기본적인 검색은 또한 페이지 내용이나 페이지 위키텍스트에서 볼 수 있는 구두점, 수학 및 기타 기호를 포함하는 문자열을 포함하는 모든 기사를 쿼리할 수 있다.

검색 링크를 사용할 때의 기본 검색 원리
1	`{{Search link "search engine query"}}` "검색 엔진 쿼리"	검색어 1개, 즉 리디렉션을 포함해 18개의 결과를 내는 구절이 있다.한 용어로 페이지 순위 규칙은 간단하다. 제목 일치, 맨 위에."Search Engine Query"에 2페이지, "[Search Engine (컴퓨팅) Search Engine]] 쿼리에 1페이지가 올랐다.
2	`{{Search link "search engine query" insource:/"search engine query"/}}` "검색 엔진 쿼리" 리소스:/"검색 엔진 쿼리"/	용어 추가: insource:/ "슬래시 구분 regex"/이제 15개다.regex가 정확한 문자열만 일치하기 때문에 세 개가 필터링되었다.다른 모든 검색은 항상 대문자, 구두점, 수학 및 위의 ]]와 같은 기타 기호를 무시한다.검색 1: only insource: search wikitxt와의 기본적인 차이점 입증.다른 모든 용어는 렌더링된 항목을 검색한다.
3	`{{Search link search engine query}}` 검색 엔진 쿼리	검색어는 세 가지다.그들은 1169개의 결과를 낸다.많은 페이지 순위 규칙은 가장 가능성이 높고 가장 낮은 페이지 순위를 만들기 위해 적용된다.
4	`{{Search link search engine query insource:/"search engine query"/}}` 검색 엔진 쿼리 소스:/"검색 엔진 쿼리"/	검색 3과 마찬가지로, regex는 동일한 1169페이지의 필터를 통해 문자별로 탐색하여 동일한 15개의 결과를 만들어냈다.보기만 해도 1169는 위키에서 5549만3979페이지에 노출된 무필수(무반주)레그스를 가동해 15여개의결과를 내는 것과 비교하면아무것도 아니다.[1]
5	`{{Search link insource:/"2 + 2"/ prefix:Arithmetic "Arithmetic" titles & "2 + 2"}}` "산술" 제목 & "2 + 2"	regexp는 첫 번째 용어지만, 접두사: term first는 A-r-i-t-h-m-e-t-c 문자로 시작하는 몇 개의 제목을 제외한 모든 제목을 필터링한 다음 regexp는 문자순으로 스크롤한다.아마도 그런 라벨은 이것을 당신의 팀에게 전달할 것이다.

이 템플릿은 동일한 기호를 검색할 때 표면적으로 검색 상자와 다르다.검색창에서는 그냥 이라고 말하지만, 여기서는 반드시 5자 문자열{=}}^[2]을 사용해야 한다.

검색 5에서 검색 패턴 주위에 큰따옴표가 필요함을 알 수 있다.insource:/"slash delimited regexp"/. 이것들은 어떤 등장인물들이 regex 메타카락터로 해석되는 것을 방지하고 문자 그대로 해석되도록 보장한다.기본 검색에서는 항상 wikitxt에서 정확한 문자열 검색을 활성화하기 위해 인용구를 사용한다.고급 검색에서는 큰따옴표가 사용되지 않으므로 메타캐랙터가 일반화된 패턴을 생성하기 위해 조건부 및 분기 연산자 역할을 할 수 있다.

검색 2는 모든 regexp 검색과 함께 적용하기 가장 쉬운 필터를 예시한다.같은 구절만 취해서 별도의 용어로 만들 뿐이다.어떤 regexp가 주어지면, 그냥 그것에 따라 .후기는 항상 완벽한 필터처럼 작용하며, 모든 영숫자와 일치하며, 모든 비 영숫자를 무시하며, regexp가 도저히 일치할 수 없는 페이지를 걸러내기 위해 색인된 검색을 빠르게 통과한다.다른 필터에 대해서는 네임스페이스가 약하지만, 추가 용어마다 regex 검정력이 증가한다.

다음 섹션에서는 검색 링크 인수에 대해 자세히 다룹니다.

고급

다음은 Search 링크의 템플릿 매개 변수들이다.

1	또는 `query=`	검색 쿼리.검색 링크의 텍스트(링크가 어떻게 표시되는지)가 되어 이를 수락한다. `text=`.
2	또는 `label=`	기본 텍스트를 대체할 레이블.링크에 대한 새로운 외관을 제공하므로, 이 링크는 또한 `link=`. 검색 쿼리를 표시하는 기본값.
3 ⋮ 20	3 4 5 … 20 또는 `ns=`	검색 도메인: 하나 이상의 네임스페이스가 "nsx"로 축약된 경우, 여기서 x는 모든 네임스페이스 번호임. `nsx nsx nsx … nsx`또는`ns=nsx&nsx&nsx…&nsx`또는`ns=all`. 기본값은 ns0이다.
	`limit=`	첫 번째 페이지의 검색 결과 수입니다.명명된 매개 변수만, 위치가 아님.

위키백과 데이터 구조
네임스페이스
제목 네임스페이스		대화 네임스페이스
0	(주/기사)	이야기하다	1
2	사용자	사용자 대화	3
4	위키백과	위키백과 대화	5
6	파일	파일토크	7
8	미디어위키	미디어위키토크	9
10	템플릿	템플릿 토크	11
12	도움	헬프토크	13
14	카테고리	카테고리 토크	15
100	포털	포털톡	101
118	초안	드래프트 토크	119
710	TimedText	TimedText talk	711
828	모듈	모듈토크	829
사용되지 않음
2300	가젯	가젯토크	2301
2302	가젯 정의	가젯 정의 토크	2303
가상 네임스페이스
-1	특별한
-2	미디어

검색 도메인에 대해 둘 이상의 네임스페이스 프로필을 원하는 경우에만 매개 변수 3-20을 사용하십시오.그렇지 않으면 쿼리의 시작 부분에 네임스페이스 이름(또는 전체)을 말하거나 쿼리의 끝 부분에 접두사 매개 변수를 말하십시오.

쿼리가 이 템플릿을 통과할 때 기본 검색 도메인은 기본 사용자와 마찬가지로 아티클 공간이다.로그인 여부에 관계없이 사용자의 기본 검색 도메인은 사용자가 자신의 기본 설정을 지정하지 않는 한 문서 공간이다.^[3]그러나 누가 검색 링크를 사용하든 결과는 항상 동일할 것이다."잘라서 붙여넣기"는 검색에 대해 동일한 결과를 결코 보장할 수 없지만 검색 링크는 검색 도메인이 모든 사용자를 위한 기사 공간일 뿐이거나 검색 도메인은 모든 사용자를 위해 설정한 네임스페이스 집합이기 때문에 가능하기 때문이다.

검색 도메인 프로필의 번호를 알고 있는 경우ns=ns0&ns1&ns2600. (네임스페이스 테이블에서 오른쪽으로 이동 가능)그렇지 않으면 고급 인터페이스가 네임스페이스 번호를 모르는 상태에서 네임스페이스를 선택하고 조정하도록 설계된 검색 결과 페이지에서 쿼리 및 검색 도메인을 세분화하십시오.만족스러운 결과를 생성하면 브라우저의 주소 표시줄에 있는 URL에서 네임스페이스 문자열을 복사하여 붙여넣으십시오. ns=검색 결과 페이지 검색 상자에서 쿼리를 가져와 쿼리로 붙여넣으면 검색 링크가 된다.

검색 링크에 네임스페이스가 하나만 있고 문서 공간이 아닌 경우, 다음과 같이 지정하거나 매개변수 위치 3 이상에서 ns10" 지정할 수 있다.

{{sl "search link" namespace ns10}}→ "검색 링크" 네임스페이스

하나의 네임스페이스에 대해 명시적 이름이 선호된다.

{{sl Template:"search link" namespace}}→ 템플릿:"검색 링크" 네임스페이스

검색 링크를 게시하거나 저장하려는 경우 명시적 이름이 선호된다.이렇게 하면 나중에 실행될 때 검색 도메인이 사용자에게 알리기 위해 검색 결과 페이지의 검색 상자 시작 부분에 명시적으로 나타난다.그렇지 않으면 사용자에게 알리기 위해 검색 결과 페이지에 URL과 네임스페이스 프로파일 대화 상자 프레임만 나타난다.둘 이상의 네임스페이스인 경우 쿼리는 하나의 네임스페이스(첫 번째 용어로만)만 허용하기 때문에 항상 이러한 일이 발생한다.그러나 모든 것은 또한 정보적인 질의로, 검색에 대한 사이비 네임스페이스일 뿐이다.쿼리가 로 시작하는 경우 URL에 모든 네임스페이스 매개 변수가 로드된다.

{{Search link}}의 "all"을 사용하여 모든 네임스페이스를 지정할 수 있다.

{{sl query ns=all}}</nowiki>

{{sl query label all}}</nowiki>

하지만 다시 말하지만, 말하는 것이 훨씬 더 낫다.

{{sl all:"search link" namespace}}→ all:"검색 링크" 네임스페이스

사용하는 것보다:

{{sl "search link" namespace all}}→ "검색 링크" 네임스페이스

위와 같은 이유로그러나 "all"을 명기할 때, 위키에는 기사가 있는 것보다 더 많은 페이지가 있기 때문에 질의 시간은 약 7배 더 많다.좀 더 타겟팅된 검색이 가능하다면 '모두' 검색보다 훨씬 더 빨리 실행된다.

예를 들어, 검색 도메인이 10과 11인 것을 알고 있는 쿼리가 있고 레이블을 원하지 않는 경우 매개 변수 3이 필요하지만 매개 변수 2가 필요하지 않으므로 템플릿 매개 변수 규칙에 따라 검색 링크는 다음과 같은 네 가지 일반적인 방법으로 만들 수 있다.

{{sl query ns10 ns11}}매개변수 1의 이름을 밝히지 않은 경우, 매개변수 2가 이름 없는 경우("빈 문자열"로 정의됨), 매개변수 3은 이름 없는 것으로 정의할 수 있으며, 매개변수 4는 이름 없는 것으로 정의할 수 있다.ns11, 등등.모든 것이 정의되어 있기 때문에 아무것도 명명되지 않는다.
{{sl query 3=ns10 4=ns11}}매개변수 2는 정의되지 않았지만, 매개변수 3 이상의 이름은 모두...
{{sl query ns=ns10&ns11}}또는 다음 중 빈 위치 파라미터가 필요하지 않음 ns=그 이름을 정의한다.
{{sl query=query label= ns=ns10&ns11}}모든 것이 명시적으로 명명되어 있다.

다른 예로 "Wikipedia"와 "Help" 네임스페이스를 선택한 다음 쿼리를 실행하면 URL이 표시되며ns4=1&ns12=1복사하여 붙여넣기 ns=ns4=1&ns12=1. (주: URL에서 "=1" 부분을 무시해도 된다.)

URL에 ns0, ns1, ns2 및 ns3가 포함된 방법과 해당 URL을 얻은 방법을 참고하십시오.

{{sl systems operations 3=ns2 4=ns1 ns=ns3 20=ns0}}→ 시스템 운영

{{sl query = systems operations ns2 ns1 ns3 ns0}}→ 시스템 운영

{{sl systems operations 3=ns2&ns1&ns3&ns0}}→ 시스템 운영

30개의 네임스페이스 중 매우 정교한 검색 도메인을 개발해야 하는 경우 고급 검색 도메인 선택기를 사용하여 검색 결과 페이지에서 이 도메인을 개발하십시오.그런 다음 찾은 검색 도메인 네임스페이스의 URL에서 전체 문자열을 잘라내어 붙여넣고 명명된 하나의 매개 변수에 붙여넣으십시오. ns=.

레이블 없이 네임스페이스 0, 2, 4, 5, 7 및 9를 입력하는 가장 쉬운 방법은 다음과 같다.

{{sl query ns0 ns2 ns4 ns5 ns7 ns9}}
{{sl query ns=ns0&ns2&ns4&ns5&ns7&ns9}}

순서는 무관하다.

고급 예제

이 모든 것은 관련된다.insource:/slash delimited regex/ 필터가 달린검색 링크에 다음이 포함됨insource:/regex/검색은 항상 검색 도메인을 가능한 많이 필터링(제거)할 수 있는 추가 쿼리 용어를 제공해야 한다.이 템플릿은 네임스페이스를 지정하지 않은 경우 기본적으로 문서 공간으로, 필터로 지정된다.

인용

기사에서 동등을 일치시킬 필요성은 놀랍지도 않고, 기본이다.{{=}} 또는 {{}}을(를) 사용해야 한다. query=또는 1=검색 엔진에 대한 질의에 동등의 기호를 입력하기 위해, 또는 {{!2}}: 파이프 문자를 검색 엔진에 가져오기파이프 문자와 등호 부호는 모든 템플릿에 대해 템플릿에 민감하므로 템플릿 내부와 같이 항상 곱슬 괄호로 묶어서 인용할 수 있다.검색 상자는 = 그리고 직접 사용할 수 있지만, 그렇지 않으면 매개 변수 의미가 있기 때문에 검색 링크에서 견적이 필요하다.

regex는 문장 부호, 괄호, 수학 및 기타 기호 문자에 민감하며, 집합적으로 "구문"이라고 알려져 있으므로 인용한다. 다른 경우 regex 메타차박터 의미가 있기 때문이다.사이러스서치의 "메타카락터"들은 대부분의 구두점 문자를 그들의 regex의 함수로 주장해 왔지만, 말 그대로 대상으로 검색하기 위해서만 메타카락터 기능을 모두 알 필요는 없다.위키텍스트에서 문자 그대로의 대상으로 검색하기 위해 모든 문장 부호를 간단히 인용할 수 있다.전체 regexp의 모든 문자를 쉽게 인용하는 방법은 전체 용어를 인용구에 넣는 것이다.

템플릿과 검색 엔진을 통해 파이프 문자를 wikitxt의 문자로 지정하려면 이를 두 번 인용해야 하므로 고급 검색 링크에서 6자를 자주 사용해야 한다.등호괘는 메타카락터가 아니므로 파이프 문자처럼 두 번 인용할 필요가 없다.파이프 캐릭터는 OR을 의미하는 메타차박터다.

고급 regex 검색을 생성하려면 {{regex}}에서 검색을 수행하는 방법을 참조하십시오.

검색 엔진 기능

검색엔진 캔

날짜별로 분류하다
인격을 중용하다A는 a와 일치하고 , 그리고 일치한다.
페이지나 또는 어떤 것이 있을 때 또는 있을 때 이해하다.
이해와 , 그리고 두 가지 형태는 그렇지 않다.
단어 철자를 흐릿하게 검색하다
지정한 단어와 가까운 단어를 찾으십시오.
와일드카드표현과 정규표현을 찾다

검색은 화면과 인쇄 미리보기에 렌더링된 내용과 일치한다.원시 "소스" 위키텍스트는 파라미터를 사용하여 검색할 수 있다.이 두 종류의 검색에서 단어는 전체 단어 또는 구와 일치하는 연속된 문자와 숫자의 문자열이다.문장 부호, 대괄호 및 슬래시, 산술 및 기타 기호와 같은 기타 모든 키보드 문자는 일반적으로 검색할 수 없다.

기본적으로 검색은 단어들의 줄임말과 일치하는 단어들도 찾을 것이다.그것은 이것들의 빈도와 위치에 따라 결과를 자동으로 정렬하지만, 또한 시간, 템플릿 사용량 또는 심지어 다른 페이지와의 유사성에 따라 페이지 순위를 증가시킬 수 있다.

검색은 인덱스 데이터베이스를 쿼리하여 전체 텍스트 검색을 수행하는 검색 엔진이다.그것은 위키피디아를 검색할 수 있는 다른 공공 검색 엔진의 능력과 통제력을 초과하는 검색 구문과 매개변수를 제공한다.

페이지 점수

검색 상자가 주어졌다고 가정하십시오.검색은 두 개의 인덱스 검색으로 시작되며, 두 결과는 논리적 AND와 결합된다.그러나 검색 결과로 표시되기 전에 모두 최종 점수를 할당해야 상위 20위(첫 페이지에 나열됨)를 표시할 수 있으며, 스니펫과 하이라이트로 포맷해야 한다.페이지 순위는 통계적으로 접근하고 데이터를 통해 여러 페이지를 훑어봄으로써 매우 많은 페이지를 빠르게 처리한다.

각 단어의 빈도와 위치에 따라 첫 번째 정렬이 결정된다.^[4]
단어 순서에 따라 두 번째 정렬이 결정된다.만약 그 두 단어가 한 페이지에서 같은 순서로 발견된다면, 그 페이지는 다시 증가된다.
들어오는 링크 수입니다.^[5]

단어에 대한 이러한 속성은 페이지에 더 높은 점수를 받는다.

직함
선두 부분에 위치
반복
질의의 다른 단어에 근접함.

몇 가지 다른 점수 매커니즘이 있을 수 있다.제어할 수 있는 파라미터는 , , 및 입니다.

일반 설명

현재 여러 네임스페이스를 검색하는 다양한 접근방식에 대한 11개의 매개변수가 있다.7개의 새로운 매개변수 중 4개는 현재 이러한 페이지 특성을 대상으로 제공한다: 및 insource:/regexp/.나머지 세 가지는 현재 페이지 순위를 목표로 제안한다: 혼자서 작업하고, 어떤 질의에도 용어를 추가할 수 있으며, 현재 매개변수도 있다.완전히 다시 작성된 이전 버전의 검색에서 이름만 보존된 나머지 4개는 , , , 및 네임스페이스다.

모든 검색에서 이러한 접근 방식 중 하나를 사용할 수 있음

페이지 순위에 의존하고, 대부분의 결과를 무시하며, 한 번 실행하십시오.
단순 regexp를 사용하여 정확한 문자열을 검색하고 작은 검색 도메인을 미리 테스트하십시오.
정확한 페이지 수만을 고려하여 고도로 정교한 페이지 특성 집합을 해킹하고, 샌드박스와 검색 결과 페이지에서 세분화하십시오.

검색 도메인의 개념은 이 모든 것에 중요한 역할을 한다.기본적으로 문서 공간일 뿐이지만 일반적으로 검색 도메인은 네임스페이스 집합으로 시작하여 검색 결과의 모든 페이지로 끝난다.

쿼리의 한 용어는 동일한 쿼리의 다른 용어에 대한 검색 도메인을 설정한다.순서는 검색엔진에 의해 최적화된다.쿼리는 검색 도메인을 두 번 변환하여 검색 결과를 얻는다.예를 들어, 빈 네임스페이스는 네임스페이스의 페이지를 반환한다.쿼리는 검색 도메인 크기를 줄이기 위해 처음 두 용어에 크게 의존한다.

regexp가 아닌 경우 쿼리의 모든 용어는 인덱스 검색입니다.인덱스된 용어는 단어별로 즉시 실행되며, regexp는 문자별로 느리게 실행된다.정확한 문자열을 찾기 위해 regexp를 가장 기본적으로 사용하더라도 항상 검색 도메인의 크기를 가능한 한 적게 제한해야 한다.이것은 질의의 각 용어가 페이지 수를 줄이는 경향이 있기 때문에 몇 개의 용어를 추가하는 것만큼 간단할 수 있다.특히 사용자 프로필이 Everything(모든 것)으로 사전 설정된 경우에는 Wiki에서 기본 regexp를 실행하지 마십시오.검색 엔진은 한 번에 실행할 수 있는 regexp 검색 수를 제한한다.적절한 필터를 regexp와 함께 실행하지 않으면 최대 20초 동안 실행되며 HTML 시간 초과가 발생한다.

검색 결과 페이지에서 쿼리가 실행된 초기 검색 도메인은 다음 항목으로 표시되며, 다른 도메인을 재정의할 수 있는 파워가 증가된다.

사용자가 네임스페이스 프로파일을 미리 설정한 경우 네임스페이스 대화 상자
내용 페이지 또는 멀티미디어 또는 모든 것: 만약 그 중 하나가 초기 검색 도메인이었다면, 그 텍스트의 색상은 (링크 색) 파란색에서 (프레젠테이션) 검은색으로 바뀌었을 것이다.
쿼리의 네임스페이스 매개 변수
매개 변수가 그들 모두를 무시한다.

예를 들어, 만약에 네임 스페이스를 매개 변수는 모든, 처음에 검색 도메인의 크기가 될 것이다 55,493,979 페이지 모든 네임 스페이스:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,100,101,102,103,104명, 105,106,107,460,461,490,491,828년, 829년, 1198년, 1199년, 2300년, 2301,2302,2303,2600 붙이는 경칭어. 매개 변수를 지정하는 그저 그런 북한의.특히전체 또는 부분적으로 에이스.초기 검색 도메인이 기본값인 경우, 내용 페이지의 크기는 네임스페이스 0의 6,475,762페이지(문서 공간)이다.

검색을 전문화하고 검색을 공유하기 위한 링크로 설정할 수 있다.이러한 쿼리는 항상 사용자 프로필 불일치를 방지하기 위해 초기 검색 도메인을 지정하여 완전히 지정해야 한다.이렇게 하면 같은 결과를 얻을 수 있다.예를 들어 네임스페이스가 둘 이상 필요한 경우 {{search link}}^[6]을(를) 사용하십시오.

검색 엔진 기능에 대한 다른 유용한 접근법은

사전 제작된 전문 검색을 제공하는 {{ templatestemplate usage}과 같은 템플릿.
이 페이지 하단에 있는 것과 같은 입력란 설정은 이러한 템플릿으로 작업하도록 만들 수 있다.
페이브리케이터에서 새 기능 요청 또는 개선 기능 요청 실행

구문

그리스페이스 문자는 영숫자가 아닌 문자 입니다.~!@#$%^&*()_+{} []\:";'<>?,./그리스페이스 문자 및/또는 공백 문자의 문자열은 "그리스페이스"이다.

그리스페이스는 구문에서 수식어로 의미가 있는 경우를 제외하고는 무시된다.

+term "뜻한" 제안 끄기
_term 해당 용어에 대한 "뜻한" 제안 끄기
-term 그렇지 않다는 뜻이다.포함에서 제외로 의미를 바꾼다.
!term 또한 그렇지 않다는 의미도 있다.
콜론 문자는 검색 도메인으로 "기사 공간"을 지정할 수 있으며, 경우에 따라서는 단어 안에 있을 때 문자나 숫자의 역할을 할 수 있다(간격이 없음).이것들은 아래에 설명되어 있다.
tilde 문자는 일반적으로 더 많은 검색 결과를 찾는데 연관된다.
- ~query 탐색 대신 검색 결과를 보장한다.
- word~ 그 단어에 대한 "추적 검색"을 할 수 있다.
- "exact phrase"~ 각 단어에 대해 어원을 붙인다.
- "exact phrase"~n 정확한 문구에 추가 단어를 입력하지 않고 "자동 검색"을 한다.

매개변수 또한 단어와 구를 수용하지만, 각 매개변수는 다음과 같이 자신의 색인을 검색하고 자신의 주장을 해석할 수 있다.

네임스페이스 필요 여부 또는 네임스페이스 별칭 허용 여부
보고 리디렉션 여부
페이지 이름 입력의 경우: 대소문자를 구분하는지 여부, 공백 문자 대신 밑줄 문자를 수락하는지 여부
거기 있는 인수의 구분 기호
그들만의 수식어 문자 구문의 의미

구분 기호:

네임스페이스에는 구분 기호가 필요 없지만 왼쪽은 공백, 오른쪽은 그리스페이스 허용
접두사는 네임스페이스와 페이지 이름 사이의 공백만 허용하고 왼쪽의 그리스페이스를 허용한다.
insource:/arg/ 공백은 필요 없지만 다른 모든 파라미터는 최소 공백 이상 허용
그리스스페이스 문자로만 구분된 두 단어가 그리스스페이스 구를 만들어 내는데, 이는 파생될 수 있다.
"더 큰따옴표:"는 정확한 구문을 만들고, 더 많은 수식어를 추가함으로써 의미와 근접성을 가능하게 한다.
그리스페이스는 무시된다.
- 큰따옴표 안에 있는 어느 곳이나
- 네임스페이스 이전이 아닌 검색 상자 쿼리의 시작 문자
- 단어와 구문 사이에, 그리스스페이스 구문을 제외하고.
공백 문자는 중요할 때만
- 페이지 이름(linksto, 접두사, 범주화, boost-interestory, more like)의 경우
- 두 매개 변수 사이(인수를 구분하기 위해)

콜론 : 문자:

네임스페이스로서 문서 공간을 의미한다.
접두사로서, 그것은 기사 공간을 의미한다.
소스 또는 "구문"은 문자 그대로의 결장을 의미하며, 공백이 없는 결장일 경우 문자나 숫자처럼 행동한다.

단어와 구

검색은 하나 이상의 용어가 포함된 쿼리입니다.쿼리는 실제로 페이지 데이터베이스를 검색하는 것이 아니라 사전 구축되고 지속적으로 유지되는 검색 인덱스 데이터베이스를 검색한다.위키에서 단어의 검색 색인을 만들거나 쿼리를 입력할 때 단어 경계가 그리스페이스가 된다.그리스페이스 문자는 다중 단어_문자를 만들 수 있다.우리는 그 캐릭터들을 우리의 질의에 넣을 수 없더라도 탭과 뉴라인을 말해야 한다; 이것은 위키텍스트에서 행해지는 동일한 분석이 질의에서도 행해진다는 중요한 사실 때문이다.단어 경계는 공백 문자(탭, 공백 또는 줄) 또는 그리스페이스 문자.æ(ae)나 á(a)와 같은 특수 문자를 표준 키보드 문자로 접듯이 그리스페이스 문자와 공백 문자를 모두 하나로 접는다.

구절은 단어 순서를 표현하며,^[7] 구절이 얼마나 공격적으로 일치하기를 원하는지에 따라 세 가지 방법으로 하나를 만들 수 있다.

"수치 자국"
가입_with_non-alphanumer(영숫자)
camelCaseNaming 또는 문자222숫자 전환

"견적 표시" 구절은 정확한 표현이기 때문에 "정확한 문구"라고 불리는데, 이는 "정확한 문구"에서 유래, 퍼지 검색, 와일드카드가 사용되지 않는다는 것이다.다른 검색어처럼 "정확한 문구"는 단어 사이의 공간을 허용한다.영숫자가 아닌 문자로만 가입하는 것은 단어에서 비롯된다.CamelCaseNaming 또는 문자 222숫자 전환, greyspace의 구문과 일치하고, 단어 자체와 추가로 일치한다.매개변수는 입력에 공백이 포함되도록 인용 부호를 요구할 수 있다.

wikitxt는 insource 매개 변수를 사용하여 검색된다.자원 매개변수 또한 그리스페이스 문자를 무시한다.

예를 들어, 구문을 찾으려면http://en.wikipedia.org/wiki/Search_engine, 사용 또는 사용.

단어를 검색할 때, 그 단어는 단지 색인에서 검색된다.색인화된 검색은 위키 자체를 검색할 필요 없이 모든 검색 결과 제목으로 즉시 종료된다.

페이지의 내용(제목의 내용)에서 볼 수 있는 각 단어는 이미 인덱스에 있으며, 여기서 미리 정해진 다른 모든 결과를 가리킨다.단어는 텍스트에 표시되거나 제목에만 표시되는 페이지 이름 목록에 색인화된다.

인덱스된 각 단어는 다음과 같이 표시됨

알파벳 문자 a-z 또는
숫자 0-9 또는 숫자 문자열
영숫자 a-z, 0-9의 문자열
camelCase 단어 안에 있는 토큰

소문자에서 대문자(또는 camelCase)로 전환하고 문자에서 숫자로 전환하는 경우:

이것은 두 단어다.
첫 번째 전환만이 그런 말을 둘로 나눈다.
null 공간은 비 영숫자와 일치한다: 게임 포크들은 게임 포크들과 일치한다.

또는 숫자 문자로 이 일치 항목을 단독으로 또는 함께 일치시키십시오.다시 말해, 공간이 필요하지는 않지만, 그것은 또한 낙타 케이스의 "단어"나 영숫자를 혼합한 단어를 찾는 데도 효과가 있다.공백이 필요하지 않고 영숫자가 아닌 문자는 해당 null 공백으로 처리된다.

우리는 이러한 "단어" 문자나 "영숫자" 문자들을 "단어" 경계로서 기능하는 것을 제외하고는 무시되는 "단어" 문자와 반대로 "영숫자" 문자라고 부를 수도 있다.보통 단어 경계는 단지 공간 문자일 뿐이다.

이러한 단어들은 대소문자를 구분하지 않는다: a-z는 A-Z와 같기 때문에 검색 상자는 대문자와 상관없이 페이지 이름으로 이동한다(Wikilink와 URL은 초기 문자와는 별도로 대문자와 일치해야 함에도 불구하고).

각 단어는 모든 단어 계통에 별칭이 붙기 때문에 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름 구름이 모두 같은 지수 엔트리를 가리킬 것이다.

검색에서 문자는 무시된다.공백 문자와 단어가 아닌 문자의 조합은 회색-공간이라고 할 수 있다.그렇다면 그레이스페이스는 이중따옴표 문자를 제외한 모두 비단어 문자로, 이 문자는 무시되지 않는다.

회색 공간은 괄호, 수학 기호, 구두점 및 공백과 같은 하나 이상의 문자로 이루어진 문자열이다.이제, 회색 공간 사이에 검색 색인화된 단어가 발견될 것이고, 회색 공간은 검색 질의에서 두 단어의 묵시적인 AND이지만, AND가 항상 암시되는 것은 아니다: 두 구절이 나란히 존재할 때 AND가 필요하다.

색인화된 "단어"에 대한 예외는 다음과 같다.

숫자에서 영숫자로 변경하는 것은 영숫자 단어의 추가 단어 경계다.
영숫자에서 숫자 문자로 변경하는 것은 영숫자 단어의 단어 경계다.
소문자에서 대문자로의 변경은 알파벳의 단어 경계다.

이러한 숫자 부분과 알파벳 부분 사이의 단어 경계는 회색 공간을 포함하거나 포함하지 않을 수 있지만, 구문 검색은 "정확한 구문 검색"이기 때문에 그레이 스페이스로 구분된 영숫자 단어만 일치하는 구문 내의 단어들이 부분 지정을 해제한다.

영숫자가 아닌 문자로만 결합한 단어들은 구절처럼 취급된다.그래서 word1_word2&word3는 "word1 word2 word3"과 같다.그러나 그들은 또한 camelCase와 문자 번호 전환도 일치시킬 것이다.정확한 구문 검색은 camelCase 또는 문자 번호 전환과 일치하지 않는다.예를 들어 wgCanonicalNamespace 및 !wgCanonicalSpecialPageName과 같은 용어를 찾을 수 있음canonical page name.

예를 들면 다음과 같다.

C10k와 같은 가수는 근접성의 한 단어로 간주되지만 일치의 두 단어로 간주된다.
"2010년대"와 같은 복수형 숫자

다음은 단항과 일치한다. txt2regEx 페이지에서: , , , , , , , . 구 검색에서 일치하는 부분이 없으며, "txt2regex"만 일치한다.^[8]

다음은 두 용어와 일치한다. 2 + 2 : , , , , , , , 또는 각 용어는 쿼리, 회색 공간은 AND이다.

퍼지 검색, 와일드카드 및 파생

에스트로겐은 "암살하게"라는 의미와 일치하는, 숫자를 끌어모으기 위해, 가능한 의미적 매칭을 위해, 또한 일치하는 것을 찾는 방법이다.running shoes. easing은 어떤 사전에만 의존하는 철자 알고리즘이다.^[9]알고리즘은 같은 단어를 찾으려고 하지만 모든 단어의 엔딩을 찾으려고 시도한다.

모호한 검색은 다른 단어와 일치할 것이다.단어(구문 제외)는 대략적인 문자열 일치 또는 "퍼지 검색"을 허용한다.이 "소리 같은" 검색에는 길드 캐릭터가 추가된다.다른 단어는 두 글자 이상 차이가 나지 않아야 한다.

처음 두 글자는 아니에요.처음 두 글자는 일치해야 한다.
두 글자가 맞바꾸었다.
두 글자가 바뀌었다.
두 글자가 더해지고, 두 글자가 감산되거나, 한 글자가 감산되고 한 글자가 더해졌다.

그러나 이런 면에서 그것은 한 글자 차이로 다를 수 있다.모호한 검색은 단어와 그것과 같은 단어와 정확히 일치한다.

이것~,→이것과 같이 쿵, 쿵, 쿵, 그리고 then 그리고 that, 그러나 그의 또는 엉겅퀴는 아니다.
찰리~ 파커~ → 찰리 파커와 찰리 파머, 찰리 파크스

와일드카드를 사용하면 처음 두 글자를 포함하여 어떤 문자가 변경되는지 지정할 수 있으며, 변경할 수 있는 글자 수를 늘릴 수 있다.와일드카드에는 다음과 같은 고유한 규칙이 있다.

* 0개 이상의 문자 또는 숫자
*\? 하나 이상의 문자 또는 숫자.
\? 한 글자 또는 숫자
*도 \?도 첫 글자와 일치할 수 없고, 중간이나 끝에 들어갈 수 있다.
\?와 *는 한 단어로 여러 번 사용할 수 있음
이것* → 엉겅퀴와 This1234 와 This*
g\?it\?r → 게이터 기타 g8it9r
키* → 키패드 및 키펀치

단어 인덱스가 작성되고 업데이트되는 동안, 발생된 단어 인덱스는 자동으로 대부분의 항목에 별칭을 추가한다.실제 사전은 사용되지 않는다.대신에 그것은 단어 엔딩에 일반 영어 구문 규칙을 적용하는 알고리즘을 실행한다.결과가 불완전하다.^[10]심지어 철자가 틀린 단어나 비단어, 숫자가 들어간 단어도 색인화하여 이런 식으로 줄인다.인덱싱된 검색 질의에 동일한 단어의 다른 형식을 추가함으로써, 이는 검색 엔진들이 보다 많은 검색 결과를 공격적으로 수집하여 수많은 페이지 순위 규칙을 실행할 때 사용하는 표준 방법이다.

예를 들어, 기원은 구름, 구름, 구름, 구름 등을 가명으로 한다.그것은 구름이라는 단어를 가칭하지 않고, 비단어 구름에 다양한 형태의 구름들을 가칭할 것이다. 왜냐하면 -ion은 흔한 단어의 끝이기 때문이다.

리소스 검색의 경우 Easing이 자동으로 해제됨:

어림짐작으로 단어를 따옴표로 묶는 것은 "정확한 문구" 검색이다.^[11]

예: gameFolks, game!folks, game:folks와 PeopleSoul이 일치함

근접성

근접 검색은 제목을 검색하지 않는다.
근접성은 더 높게 계산하면 거꾸로 작용한다.
근접 검색은 시작되지 않는다.

제목에 a 또는 will이 일치한다.그리고 구를 만드는 것은 단지 기인(그 단어들에 합류함으로써 구를 형성하는 것과 같다)으로 바뀐다.그러나 그 순서에 맞는 단어와 일치하는 단어를 더하면 두 단어 사이에 한 단어라도 더 넣을 수 있다.

예를 들어,

"exact second phrase"~2 두 개의 추가 단어가 두 번째 학기 어느 쪽이든 들어맞도록 허용한다.
"exact phrase"~3 또한 "정확한" 단어를 찾는다(반복적인 순서의 두 단어)
"Shift-Alt-P" 또는 "Alt_Shift-P" 중 하나를 찾으십니까?아니다.아니에요.대신 쓰세요.
"등뼈"~2와 "등뼈(또는 흉부) 척추"가 일치한다.
"3개의 단어"~5는 "3개의 w-1 w2% 추가 w:3 w_4 $w5"와 일치한다.

"hitch4 hiker2" 그 순서대로 두 개의 "단어"를 찾으며(구문법이나 괄호 또는 수학 기호 같은 기타 키보드 기호로 구분), 인용문이 없으면 같은 글에서 단어를 찾는다.두 경우 모두 공간이 논리적 AND 의미를 만족하면 기사가 나열된다.

hello_dolly 하는 것과 같은 일을 하지만, 큰따옴표 버전은 근접 필터를 제공한다.마감 인용문 뒤에 tild ~와 모든 용어 사이에 허용되는 총 단어 수를 나타내는 숫자를 추가하십시오.

"WordOne wordTwo" 구절(사이에 단어 0개)을 의미한다.
"Word1 word2" → word1 <[!@#] <<:$%^*()()> <<+-*/>> 워드2
"워드3 워드4"~1 → 워드3 엑스트라1 워드4
"워드5 워드6 워드7"~2 → 워드5 엑스트라1 워드6 엑스트라2 워드7
"Word8 word9 word10"~2 → word8 word9 extra1word extra2word10

역방향 근접성도 작동하지만 각 세그먼트 사이에 두 개의 최종 단어를 포함한다.근접성은 마지막 말이 첫 번째 단어와 근접하게 만들 수 없다.근접성은 500이나 1000처럼 큰 숫자가 될 수 있다.

페이지에 워드1 워드2 워드3가 있다고 하자.^[12]

"WordB wordA"~4 → wordA extra1word extra2wordB
"WordC wordB wordA"~6 → WordA wordB extra1word extra2wordc

따옴표가 없는 두 개의 검색어는 필터 두 개와 페이지 순위 규칙 한 묶음이다.

검색 논리

진실논리는 AND, OR, 그리고 아니다.

쿼리는 괄호를 허용하지 않는다.따라서 여러 용어를 하나의 논리적 용어로 그룹화할 수 없다.
매개 변수가 AND 또는 OR을 허용하지 않지만 AND 또는 OR을 허용하지 않음
word word2 윌 앤더슨 두 가지 조건.
word AND word2 윌 앤더슨 두 가지 조건.(iii)
word OR word2 OR the twill
-word 단어와 일치하는 페이지를 제외하고 해당 용어는 포함되지 않는다.
!word 이 용어는 사용하지 않을 것이다(영문).

논리적 OR은 결과를 증가시키는 반면, 논리적 AND는 결과를 감소시킨다.논리적 not은 접두사 매개 변수를 제외한 모든 종류의 용어를 제거하여 쿼리를 세분화하는 좋은 방법이다.

예를 들어 .while -refining -unwanted search results예를 들어 "카드" 및 "신용"이 있는 모든 기사를 찾으십시오credit card -"credit card".

접두사 및 네임스페이스

접두사와 네임스페이스는 유일한 위치 매개변수이며 네임스페이스는 이름 없는 검색 매개변수다.이들 중 하나 또는 다른 하나는 사용자 프로파일 또는 검색 줄에 의해 설정된 초기 검색 도메인을 재정의하기 위해 쿼리에 사용된다.그것들은 함께 사용되지 않는다: 접두사는 네임스페이스를 재정의한다.

네임스페이스 인수는 쿼리의 시작 부분에 있어야 하며 매개 변수는 쿼리의 끝에 있어야 한다.

네임스페이스

Namespace: 쿼리 시작 부분에 나타나는 이름 없는 검색 매개 변수.^[13]네임스페이스 뒤에 콜론이 오고, 공백이 0자 이상이며, 네임스페이스 이름과 일치한다.네임스페이스 이름과 "모두"는 예상대로 작동하지만, 검색 상자에서 하나를 본다고 해서 아래와 같이 검색 결과를 나타내는 것은 아니다.

일반적인 네임스페이스 이름 및 별칭 외에

all 위키에서 모든 네임스페이스를 검색하십시오.^[14]
file 위키와 커먼스위키를 검색한다.
- 파일 페이지에 있는 단어와 구문을 검색한다.
- 업로드된 모든 첨부파일의 텍스트 내용이 검색됨^[15]
- 일치하는 내용이 pdf(또는 이와 유사한) 내에서 이루어진 경우 이는 검색 결과에 다음과 같이 표시된다. (매치 파일 내용)
file:local 하원에 대한 검색을 해제하다.
all Commons를 검색하지 않음
네임스페이스 이름은 대소문자를 구분하지 않지만 "all" 및 "local"은 소문자여야 한다.
All: 검색 네임스페이스가 아니며 단어로 처리될 것이다.
local: 멀티미디어 또는 모든 것을 활성화할 때 검색 줄에 있는 파일 네임스페이스와 같은 파일 네임스페이스가 관련되지 않는 한, 단어처럼 취급되지 않고 대신 자동으로 무시된다.
쿼리에서 파일 네임스페이스 뒤에만 효과가 있다.

네임스페이스가 없는 페이지는 7대 1로 페이지 수를 앞지른다.

검색 결과 페이지의 검색 표시줄

모든 것이 검색되며 Commons 및 File 네임스페이스가 추가된다.
모두(네임스페이스)를 선택한 경우 고급은 모든 항목과 동일함
멀티미디어는 로컬 위키와 커먼스의 파일 및 미디어 네임스페이스를 검색한다.

이는 help:file 페이지의 pdf에 있는 검색어와 일치하는 네임스페이스 "all"과 다르다.

예를 들어 파일: "885.7초"는 pdf 내에서 일치하지만 모두: "885.7초"는 일치하지 않는다.

접두사

prefix:namespace: string 네임스페이스를 페이지 이름의 시작 문자와 일치하는 문자열이 하나 이상의 페이지로 필터링하십시오.^[16]예를 들어, "T"로 시작하는 도움말 페이지 이름을 찾으십시오.

문자열이 0자일 경우 지정된 네임스페이스의 모든 페이지가 검색된다.
문자열에서 모든 문자를 페이지 이름으로 지정하면 한 페이지가 발견된다.
문자열은 대소문자를 구분하지 않는다.
네임스페이스는 에 대해와 같이 네임스페이스 별칭이 될 수 있다.
네임스페이스와 페이지 이름 사이의 공백이 허용된다.
접두사의 네임스페이스는 기본적으로 아티클 공간으로 설정되어 있다.
접두사가 리디렉션과 일치하지 않음(하지만 특수: 참조):접두사색인).
접두사를 필터로 사용할 수 없음: 대시는 무시됨.-prefix:WP: ab 검색 도메인만 "Wikipedia:아브"
페이지 이름 문자는 무시되지 않는다.공백 문자조차도 페이지 이름의 일부분이고, 이것이 접두사가 끝에 가야 하는 이유다.

접두사는 네임스페이스 필터의 기능을 수행할 수 있고, 또한 단일 문서를 분리할 수 있지만, intitle은 분리할 수 없다.접두사에 하위 페이지가 있는 경우 접두사는 한 페이지를 분리할 수 없다.

접두사 쿼리의 대안은 특수:접두사 색인:

한 페이지에 수백 개의 페이지 이름을 나열할 수 있는 다중 열 보고서
대소문자 구분.
목록도 리디렉션됨

와 비교하여

네임스페이스 및 접두사 매개 변수 비교:

접두사와 네임스페이스 모두 초기 검색 도메인을 설정하는 데 사용할 수 있다.
주어진 네임스페이스에서 그것들은 동일하다.
둘 다 제목을 걸러낸다.
둘 다 네임스페이스 별칭을 허용하지만 접두사는 "all"을 인식하지 못한다.
둘 다 초기 검색 도메인을 하나의 네임스페이스로 제한한다.
네임스페이스는 시작에만 가고 접두사는 끝에만 간다.

네임스페이스별로 초기 검색 도메인을 설정하는 방법은 다음과 같다.

문서 공간을 기본으로 하는 .
쿼리의 시작 부분에 있는 네임스페이스 인수(기본적으로 사용자의 기본 검색 도메인이 됨)
URL 파라미터
검색 결과 페이지의 "고급 프로필" GUI

이것들은 우선 순위에 있다.접두사가 네임스페이스를 재정의하면 GUI가 재정의된다.접두사 매개변수에 대한 인수는 네임스페이스를 전달하는 풀파게네임이다.

검색 도메인을 여러 기법과 교환할 때, 그리고 우선순위 때문에 반복할 가치가 있다: 검색란 표시를 확인하라; 가장 미묘하다.^[17] 검색 줄의 고급 네임스페이스 선택 창은 그리 미묘하지 않다.그것은 "향후 검색을 위한 선택 기억"이 시행되는 한 계속 유지될 것이다.문서 공간을 "기억"한 다음 1) 내용을 누르고 2) 다른 검색란 검색 도메인을 선택하거나 3)의 모든 인스턴스 제거&profile=advancedURL에서.

페이지 속성

이 다섯 개의 검색 매개변수는 입력 단어나 구에 따라 네임스페이스를 필터링한다.

수술실 없음. 예를 들어, 수술실 없음.
위치 요구사항이 없으며, 예를 들어 모든 기능이 독립 실행형일 수 있음
여러 입력(파이프 문자 간)만 허용
그리스스페이스 구문만 허용 및 사용 안 함
오직 대소문자를 구분할 뿐이다.
공백이 없는 대장:문자에만 민감하다.

이 매개변수 이름은 소문자로 모두 표시되어야 한다.

제목

Intitle은 페이지 이름에서 단어나 구문을 찾는다.단어 또는 구문 검색이 발생하거나 모호한 검색이 적용될 수 있다.

단어 입력은 두 개의 "질문"에 입력되어 기어를 끌 수 있다.
한 구절 입력은 greyspace를 사용하여 freason을 켤 수 있다.
단일 단어 입력은 모호한 검색을 위해 tilde ~ 문자와 접미할 수 있다.
와일드카드 검색을 위해 단일 단어 입력은 별표 * 문자와 접미할 수 있다.
인티틀은 리디렉션을 검색하지 않는다.
근접 검색은 제목 검색에서 선택사항이 아니다.

리디렉션 제목에서 일치 항목을 찾거나 제목에 근접 검색을 적용하려면 페이지 순위 지정 소프트웨어를 사용하여 내용이 일치하기 전에 제목 일치 항목을 증가시킬 수 있다.그래서 기본적인 단어나 구문 검색, 즉 근접 검색은 억양의 대안이 된다.

예를 들어,

intitle: "숲 능선"이 하나를 찾는 동안 근접 검색

「숲 능선」~3호는 관련 직함을 12개나 즉시 찾아낸다.

intitle: image_lights는 intitle에서 파생된 shows: "image label"은 그렇지 않다.

intitle:저글 쇼가 파생되었다.

intitle:sun intitle:moon은 한 제목에서 두 단어를 검색하는 방법을 보여준다.

인카테고리

인카테고리 형식은 일반 형식이다.

incategory: "category category ... category"

그리고 검색 도메인에도 있는 페이지인 지정된 카테고리 페이지의 페이지 섹션에서 선택한다.

범주형 입력은 대소문자를 구분하지 않는다.
범주형 입력은 공간에 민감하다.카테고리 주위에 공백 없음.입력 내 공간에 대해서는 전체 식 주위에 "더블 따옴표"를 사용하십시오.
검색 결과에는 하위 범주가 포함되지 않는다.이를 위해 딥캣 검색 매개 변수가 있으며, JavaScript 및 CSS 파일에 라인을 추가하여 사용할 수 있다.^[18]
쿼리의 300자 제한까지 복수의 카테고리를 적용할 수 있다.

메인 스페이스 외부의 많은 페이지도 분류되기 때문에 검색 도메인이 전체 wiki가 아닌 한 카운트가 범주와 일치하지 않는 경우가 많다.

모두: 범주: 기록(전체 70페이지)
범주: 역사(기사 공간, 36쪽)
포털: 범주: 기록(포털 공간, 2페이지)

다중 카테고리 입력은 페이지를 한 번만 계산한다.다음의 두 카테고리는 기사공간에 209페이지가 있으며, 두 카테고리 모두에서 6페이지가 발견된다.

범주:"정보 검색 기술" 범주:"자연어 처리"(6)

범주: "자연어 처리"(159)

범주: "정보 검색 기술"(50)

범주: "정보 검색 기술 자연 언어 처리"(203:= 209-6)

한편, 이러한 범주는 상이한 범주로 분류된다.

all: 범주: Kames(산 23페이지)
all: 범주: 슬루프(선박에 대한 18페이지)
all: incategory: Kames 슬루프(41:=23+18)

위키피디아의 특성 때문에:카테고리화(categorization) 이러한 카테고리는 페이지를 공유하지 않는다.

all: incategory: history incategory: math incategory: physics(전체/및 0페이지)
모두: 범주: 역사(70페이지)
모두: 범주: 물리학(57쪽)
all: incategory: 수학(30페이지)
모두: 범주: 역사물리학(127쪽)
모두: 범주: 역사수학(100쪽)
모두: 범주: 물리수학(87쪽)
모두: 범주: 역사수학물리학(157쪽)

카테고리와 검색은 시너지 효과를 낸다.

카테고리 제목을 검색하고 카테고리 페이지에서 링크 및 텍스트를 검색하려면 카테고리 네임스페이스를 검색하거나 카테고리를 사용하십시오.트리 또는 제목 검색의 카테고리).
두 범주가 밀접하게 관련되어 있지만 부분 집합 관계가 아닌 경우, 범주 페이지 텍스트에 이들 사이의 링크를 포함할 수 있다.
단어 또는 구문은 종종 분류 제목과 정확하게 일치할 수 있다: 그것은 모든 페이지의 하단에 있는 카테고리 상자 안에서 일치할 수 있다.이 경우 검색 결과에 괄호 플래그("카테고리 페이지 이름")가 포함된다.

다음 예에서는 범주 네임스페이스의 페이지 설명이 페이지 크기 대신 범주 크기를 표시하는 방법을 참조하십시오.

범주: intitle: disambigation(이 단어로 제목에 대한 범주 네임스페이스 지정)
카테고리: history Texan(카테고리 페이지 제목 또는 본문에 있는 두 단어에 대한 카테고리 네임스페이스 검색)
아낙시루스(분류해야 할 페이지도 그 용어로 리디렉션이 없기 때문에 쉽게 찾아낼 수 있다.)

해스템플릿

Hastemplate 지정된 템플리트를 초월한 페이지를 찾으십시오.템플리트 내용 자체가 어떤 방식으로든 사용된 모든 페이지를 찾기 때문에 이름 패턴이 아닌 템플리트 사용량을 찾는다.네가 주는 가명에 따라 결과가 조금씩 달라.

해스템플릿

표준 페이지 이름(제목 줄에 있음)을 지정하면 모든 별칭(제목)의 사용법도 찾을 수 있으며, 상위 템플릿에서도 하위 페이지 링크를 찾을 수 있다.
별칭 지정(리디렉션의 페이지 이름에서) 리디렉션의 이름 패턴 찾기
대소문자를 구분하지 않음
기본 템플릿 네임스페이스({template}} 호출 자체와 동일) 이외의 템플릿(호밍됨) 사용을 찾기 위해 풀파게네임을 수락함

페이지의 wikitxt에서 검색된 템플릿 이름을 찾지 못하면 표준 페이지 이름을 지정했지만 별칭을 찾았다는 의미 또는 wikitxt에 표시되는 템플릿을 통해 보조 템플릿으로 호출되었다는 의미일 수 있다.표시되는(기본) 호출만 찾으려면 를 사용하십시오.

인소스

Insource: term wikitxt에서 단어나 구문을 찾는다.

그리스페이스_프린스 없음.
기인할 수 없다.
근접성이 없다.
그래 와일드카드. 하지만 단어만을 위한 것이지, 그 용어가 "정확한 문구"일 때는 아니다.
공백이 없는 결장을 취급하다 : 문자를 보통 문자처럼 처리하다.
인소스는 주석이나 nowiki 태그 외에는 .js 또는 .css 파일에서 검색하지 않는다.

일반적인 검색 소스와는 달리, 교차로에 의해 "소싱된" 것들을 발견하지 못한다.

인스소스는 두 가지 방법으로 위키텍스트를 목표로 한다.그것들은 비슷하게 보이지만, regexp 양식은 regexp를 구분하기 위해 슬래시/문자를 사용한다.^[19]

insource: term 인덱싱된 단어 또는 구문을 찾으십시오.
insource:/regexp/ 패턴이 있든 없든 페이지당 하나의 긴 문자열을 사용하여 검색 도메인에 있는 모든 페이지의 전체 Wikitext를 대상으로 한다.이것은 "정규식"(또는 regexp, 또는 regex)이다.그것의 메타카락터는 진실논리, 그룹화, 계수, 그리고 발견될 문자들을 수정하기 위해 메타카락터를 사용하여 한 페이지 내의 문자 위치나 다양한 문자 위치들에 대한 여러 가능성을 나타낼 수 있다.

기본적인 regexp는 아래와 같이 특정한 것을 쉽게 찾을 수 있는 방법이다.큰따옴표는 필드 구분 기호 입니다.그들은 그들 사이의 모든 문자 집합을 인용하고, 그들의 해석을 문자 그대로 유지하는 탈출 캐릭터들이다.

고급 regexp는 일반적인 문자열 패턴을 프로그래밍하기 위해 메타카락터를 사용한다.그것은 모든 것, 심지어 단어의 조각과 부분까지도 "단어"라는 개념은 전혀 전달하지 않고 단지 일련의 문자열을 순차적으로 전달한다.메타카락터는 백슬래시, 큰따옴표 또는 대괄호로 인용되지 않는 한 해석된다.regex에 대한 섹션을 참조하십시오.분명한 예로는, 문자 그대로의 슬래시와 일치하는 대신, 닫는 슬래시 구분 기호로 해석되지 않도록 패턴의 슬래시를 인용해야 한다는 것이다.regexp는 모든 메타카락터를 해석한다.regexp 패턴을 책임감 있게 테스트하기 위해 검색 도메인 제한 필요

페이지 이름 필터를 사용하여 단일 페이지로 만들기
검색 도메인을 필요한 만큼만 제한하는 접두사 매개 변수 또는 기타 필터
시험 위키

regexp를 남용하는 것은 위키백과의 성과를 해치지 않지만, regex 검색 정보가 다른 곳으로 흘러가는 것을 제한한다.

regex만 greyspace 문자를 해석하십시오.다른 곳과 마찬가지로 일반 인서스는 그리스페이스 문자를 무시한다.그렇게insource:"M S"성냥, 하듯이insource:"M-S" 그리고insource:"m=s"하지만insource:/M\/S/일치하는 내용이 있을 것이며, 필터링된 버전insource:"M/S" insource:/M\/S/필터는 두 위키텍스트 단어가 구두점과 공간에 의해서만 구분되는 가장 명백한 필터다.대상 문자열이 다음과 같다고 가정하십시오.

insource:"val 9999 ul m s fmt commas" → 매치
hastemplate: val insource:"9999 ul" → 매치
hastemplate: val insource:"999" → 맞수 없음
hastemplate: val insource:"fmt commas" → 매치
hastemplate: val insource:"ul m" → 매치
hastemplate: val insource:"ul M S" → 매치
hastemplate: val insource:fmt → 매치

인소스는 단어들을 순차적으로 일치시키지만, {{템플릿 마크업}} 안쪽에 반드시 있는 것이 아니라 페이지의 어느 곳에서도 일치될 수 있다.이를 위해 {{템플릿 사용법}이 있으며, 템플리트 내부의 모든 리겔스와 일치한다.

철저한 정밀도를 위해 /regex/를 사용한다.예를 들어, 내부 URL을 찾으려면<ref name=name>...</ref>, 와 함께.[external link brackets label], 가능한 경우ref name=name더 간단한 방법은 사용할 수 없다. 전체 regexp를 시도하기 전에 신중하게 접근하여 1만 페이지 아래에 검색 도메인을 만드십시오.접두사 및 인소스 두 가지 필터로 시작:

insource: "ref http" prefix:A 98000은 시작하기에 너무 많다.
insource: "ref http" prefix:AA 1000이 좋다.
그러니까 넌 regex 용어를 추가해봐.insource:/\<ref[^>]\> *\[?https?:\/\/[^][<> "]+\]? */접두사의 경우 0:AA, 접두사용 하나:AB
그러니까 그냥 해 봐.insource:/\<ref[^>]\>대신 접두사를 사용해 보십시오.AA 0; AB, 1을 사용해 보십시오.
당신은 당신이 수식어를 잊어버린 것을 눈치챘다.[^>]*.
insource: "ref http" insource:/\<ref[^>]*\> prefix:AB3700개가 있는데 괜찮다.
더 실험해봐.그런 다음 AA, AB, AC, ZZ 구간에서 프로젝트를 진행하기로 결정한다.
insource:/\<ref[^>]*\> *\[?https?:\/\/[^][<> "]+\]? */ insource: ref prefix:AA

우리는 가능한 유일한 필터를 가지고 있다.insource: ref prefix:AA. 그 필터는 2300의 regex 검색 도메인을 생성한다.이 필터는 264000의 검색 도메인을 생성한다.그렇게 많은 페이지에서 regex를 실행하면 6만4000개의 결과가 나온다.

좀 더 타겟팅된 URL을 찾으려면 yahoo.brand.edgar.com이라고 하고 (또는 전체 URL을 잘라내어 붙여넣고, 점 슬래시 등의 모든 URL은 상관 없음)을 사용하십시오.https 버전을 사용하여 다른 검색을 수행하십시오.특수 검색보다 유연성이 뛰어난 검색:링크검색.필터가 필요하지는 않지만, 모든 검색은 항상 단어, 구문, 대부분의 매개변수 등 추가 정보로부터 이익을 얻는다.

에 대한 링크

Linksto 페이지 이름에 위키링크를 보고한다.

링스토는 정식 풀파게네임만 받아들인다.제목줄을 사용하십시오.제목이 대문자로 시작되지 않거나 제목 줄에 대해 잘 모를 경우 페이지 편집에서 미리 볼 수 있다.
링크스토는 대소문자를 구분한다.
네임스페이스 별칭이 검색되지만 입력으로 허용되지 않음.
링크스토는 리디렉션을 찾지 못한다.콘텐츠에 대한 모든 링크를 보려면 각 리디렉션 페이지 이름을 검색하십시오.
링크스토는 내부 섹션 대 섹션 링크가 있는 경우에도 주어진 페이지를 자신에 대한 링크로 보고하지 않는다.
Linksto는 페이지에서 URL 스타일의 위키링크를 찾지 않는다.
축소된 내비게이션 링크는 링크스토에 의해 보고되지 않지만, 왓링크스여기에 의해 보고된다.

링크스토는 Wikilink가 페이지 이름에 대해 보고한다.

한 구간까지
하위 페이지 링크에서.
전폐("위키링크를 구성하는 템플릿 뒤")에 숨겨져 있다.

링크스토는 "What links here"에 대한 검색 도메인이 전부이기 때문에 "What links here" 도구와 다를 수 있다.Linksto 검색 결과가 기본 검색 도메인에 있음(모든 검색과 마찬가지로 카운트를 보고함)

Wikitext 외에도, 그것은 내용을 초월하는 페이지 안에서 검색한다.

먼저 내용을 스캔하십시오.^[20]예를 들어,

linksto:"Mozart and scatology"

여기에 링크된 300개의 기사 목록을 "여기 링크된 것"과 같이 보고할 것이다.그러나 모차르트와 산포학은 사실 콘텐츠 작가들에 의해 15번밖에 연결되지 않는다.나머지는 모차르트와 템플릿의 산포 때문이다.원치 않는 페이지에 볼프강 아마데우스 모차르트.템플릿이 필요하지만 "링크" 참조는 아마도 아닐 것이다.^[21]

이 문제를 해결하고 기사에 대한 모든 저작자 연결 고리를 찾는 요령은 regexp 검색이다.

: insource:"pagename" insource:/\[\[ *[Pp]agename *[] ]/

이 검색은 기본 검색 도메인이 어떻게 설정되든 초기 검색 도메인을 문서 공간으로 제한하기 때문에만 기사를 찾을 수 있다.첫 번째 용어는 즉시 regexp 검색에 대한 적절한 제한을 설정하는 정제된 검색 도메인을 생성하기 때문에 모든 링크를 full regexp보다 몇 배 더 빨리 찾을 수 있다.regexp는 위키링크의 허가에 의해 허용되는 위키텍스트에서 발견되는 변형을 수용할 수 있다: 1) 메타카락터는 제목 앞과 뒤에 "제로" 이상의 공간 문자를 허용하며, 2) 처음의 [문자 클래스]는 페이지 이름에서 첫 번째 문자의 완화된 대문자를 허용하고 3) 문자 클라(cla)를 허용한다.ss는 위키링크의 파이프 문자를 통해 라벨이 부착되거나 대괄호 ]를 통해 닫히는 링크를 찾는다.

전횡에 대한 링크는 해시템플릿으로 처리된다.

결과 정렬

페이지의 전체 점수는 검색 결과의 위치를 결정한다.

더 좋은 시합은 점수를 올릴 것이다.

섹션 0(리드 섹션) 일치가 번호가 매겨진 섹션보다 낫다.
타이틀이나 헤딩 경기가 리드 부문 경기보다 낫다.
검색어 빈도가 높을수록 좋다.
스트림 매치보다 직접 매치하는 것이 좋다.
여러 문서에서 여러 단어가 모두 발견될 때, 일치하는 순서가 더 좋다.
더 높은 망사, 즉 페이지와 더 많은 링크를 연결하는 것이 더 낫다.

위키피디아 주제 "중요성"과 기사 품질 평가를 고려할 수 있다.페이지에서 검색하는 것은 그 범주, 위키다타, 그리고 지리적 위치를 고려할 수 있다.

이것을 알면, 예를 들어, 반쯤 기억된 제목을 더 잘 찾을 수 있을 것이다.억양을 사용하면 단어 순서 때문에 결과가 너무 왜곡될 수 있다.단어 검색에 사용하며 페이지 순위에 따라 달라.명언은 위에 나타날 것이다.

CirrusSearch의 작동 방식에 대한 자세한 내용은 mw:검색/이전#Search_Weighting_Ideas.

날짜별로 검색 결과를 정렬하려면 기본 설정을 사용하십시오.템플릿 사용량별로 검색 결과를 정렬하려면 부스트-템플릿을 사용하십시오.

모어라이크

검색 매개 변수는 단어 빈도와 단어 길이를 하나 이상의 지정된 기사와 비교하는 모든 기사를 나열한다.

morelike: pagename pagename2 ... pagename50

따옴표는 필요 없고, 간격도 중요하지 않다.
대문자화가 수행되고 철자가 틀린 페이지 이름은 자동으로 실패한다.
리디렉션은 허용되며, 대상 문서의 제목이 사용된다.
네임스페이스를 가진 페이지 이름이 자동으로 실패함
wp:wp는 조용히 실패한다.(기사 공간에서 프로젝트 공간으로 리디렉션되는 바로 가기입니다.)
다른 검색 매개 변수나 다른 용어는 더 이상 허용되지 않는다.

모어라이크는 다중 단어 검색을 계산한다.

: word1 word2 ... wordN

코드 조각에서 강조 표시된 항목을 참조하십시오.

Morelike는 검색 색인에서 지정된 페이지 이름을 찾고, 모든 단어에서 단어 빈도 집합과 단어 길이 집계를 만들고, 이러한 단어와 내부 변수 설정을 기반으로 다중 단어 검색을 계산한다.그것은 비싼 검색이다.

예를 들어, 검색한다고 가정해 보십시오.

morelike:William H. Stewart

그리고 그 목록에서 이름을 선택하여 추가한다.

morelike:William H. Stewart Leroy Edgar Burney

그런 다음 페이지 이름을 다섯 개 입력할 때까지 이름을 추가하십시오.그러면 당신은 다음과 같은 것들을 말하면서, 이 자동 계산된 쿼리를 맹목적으로 조정하기 시작할 수 있다: 계산된 쿼리를 만든다.

적어도 다섯 마디.
최소 낱말 길이 7
최소어 빈도 3
5개의 페이지 이름 중 4개는 반드시 그 용어를 가지고 있어야 한다.
그들 중 적어도 세 명은 그 조건을 가지고 있어야 한다.

그런 다음, 단어가 있는 입력 페이지 이름 수를 2(5개 중)로 조정하십시오.https://en.wikipedia.org/w/index.php?title=Special:Search&profile=default&search=morelike:ant%7Cbee%7Cwasp%7CEusociality%7Ctermite&fulltext=Search&cirrusMtlUseFields=yes&cirrusMltFields=opening_text&limit=1150

제목만 보고, 제목만 보고, 제목만 보고, 리드 부분만 보고 비슷한 기사를 찾을 수도 있다.

&cirrusMtlUseFields=yes&cirrusMtFields=title
&cirrusMtlUseFields=yes&cirrusMtFields=headings
&cirrusMtlUseFields=yes&cirrusMtFields=text
&cirrusMtlUseFields=yes&cirrusMtFields=보조_text
&cirrusMtlUseFields=yes&cirrusMtFields=open_text
&cirrusMtlUseFields=yes&cirrusMtFields=all

검색 결과는 내부(으)에 따라 달라진다.Mlt, 이와 유사하게) URL을 통해 설정 가능한 변수, 검색할 단어 관련:

&cirrusMLtMinDocFreq	검색어가 있는 기사 수(최소
&cirrusMLtMaxDocFreq	선택한 단어가 포함된 최대 항목 수
&cirrusMaxQueryTerms	검색어 수, 최대
&cirrusMinTermFreq	선택한 단어의 최소 단어 빈도.
&cirrusMltMinWordLength	고려할 용어의 최소 길이.기본값은 0.
&cirrusMLtMaxWordLength	단어를 무시할 최대 단어 길이.기본값은 Unbounded(0)입니다.
&cirrusMltFields	사용할 필드의 쉼표로 구분된 목록.허용된 필드는 제목, 텍스트, 보조_텍스트, opening_text, 제목 및 모든 항목이다.
&cirrusMltUseFields(true 또는 false)	필드 데이터만 사용하십시오.기본값은 false: 시스템이 쿼리를 작성하기 위해 텍스트 필드의 내용을 추출한다.
&cirrusMLtPercent용어투매치	일치할 항의 백분율.기본값은 0.3(30%)이다.

예를 들어, 다른 리드 섹션과 비교하여 두 글의 리드 섹션을 보다 유사하게 검색하기 위해 주소 표시줄(변형 검색 표시줄)이 어떻게 보이는지 알아보십시오.https://en.wikipedia.org/w/index.php?title=Special:Search&profile=default&search=morelike:William+H.+Stewart%7CLeroy+Edgar+Burney&fulltext=Search&cirrusMtlUseFields=yes&cirrusMltFields=opening_text 보다 유사한 기능을 활성화한 두 개의 추가된 URL 매개변수를 포함하는 끝을 주목하십시오.

선호도-반환급

날짜별로 검색 결과를 정렬할 수 있다.

prefer-recent:
prefer-recent:recent,boost

그것은 질문의 어느 곳이나 간다.160일을 "최근"으로 기본 설정하며, 점수의 60%를 상승 공식을 적용한다.이 공식은 일반적인 승수가 아니라 기하급수적인 승수로서 잠재적으로 훨씬 더 강력하다.이를 통해 160일이 아닌 "최근"의 기본값이 9초 미만일 수 있는 곳에서 작동할 수 있다."최근"이 9초를 의미할 경우

예를 들어, 지난 주에 변경된 비교적 적은 수의 기사에만 관심이 있다면, 대신 7을 사용하십시오.어떻게 되느냐 하면 7일 이상 된 기사는 모두 절반만, 14일 이상 된 기사는 모두 다시 절반만 올리는 식이다.

부스트는 일반적인 승수보다 더 많고, 기하급수적이다.지수에 사용된 계수는 마지막 편집 이후 시간이다.마지막 편집 이후 시간이 길어질수록 부스트가 줄어든다.공식은e여기서 t는 일 단위의 간격 또는 관심 간격이다^−t.모르겠어?

검색 시작 부분에 추가하십시오.그것은 더 최근에 편집된 기사들을 검색 결과에 활력을 줄 것이다.일반적인 형태는

prefer-recent:proportion_of_score_to_scale,half_life_in_days

이 매개 변수는 기본 설정을 조정할 수 있도록 쉼표로 구분된 두 개의 인수를 허용한다.기본적으로 이것은 마지막 편집 이후 시간에 따라 점수의 60%를 기하급수적으로 확장하며, 반감기는 160일이다.따라서 기본값은 입니다.

가중치를 증가시키기 위해 변경할 수 있다.

prefer-recent:0.8,360

또는 감소:

prefer-recent:0.4,10

비율_of_score_to_scale은 0과 1 사이의 숫자여야 한다.하프_life_in_days는 0보다 커야 하지만 소수점이 허용되므로 매우 작을 경우 가까운 편집 시간을 정렬하는 데 매우 효과적이다.

예를 들어, 8.64초의 반감기로 작동한다.

이것은 결국 위키뉴스에게 디폴트로 켜질 것이다.

부스트템플릿

부스트-템플릿:" " 주어진 템플릿 또는 템플릿(플럴)을 사용하여 페이지에 가중치를 추가한다.이 검색 매개 변수를 사용하면 검색의 일반 템플릿 상승 함수를 재정의할 수 있다.검색에 대해 템플릿 가중치를 사용하지 않도록 설정하려는 경우가 아니라면 가중치 인수를 제공하지 않고 이 검색 매개 변수를 사용하지 마십시오.

일반적인 형식은

boost-templates:"Template:pagename parameter Template:pagename parameter"

일반적으로 MediaWiki:cirrussearch-boost-template라는 시스템 메시지가^[22] 다음 전체 파일 이름의 점수를 높인다.템플릿:주요 기사 200% 템플릿:사진 200% 템플릿:사운드 200% 템플릿:추천 목록 175% 템플릿:좋은 기사 150% 템플릿:Sockpuppet 범주 5% 템플릿:유지 관리 범주 5% 템플릿:숨겨진 범주 5% 템플릿:추적 범주 5% 템플릿:범주 클래스 5% 템플릿:범주 중요도 5% 템플릿:CatTrack 5% 템플릿:템플릿 범주 5%.이것들은 실제 템플릿 이름과 실제 부스트 입니다.이것들은 부스트 템플릿 사용 중에 교체된다.

예를 들어, 검색 링크와 regexp 템플릿이 있는 "페넘" AND "렉처" 검색은 다른 모든 템플리트를 무시하고 검색 링크와 해당 페이지의 가중치 점수가 각각 1.5와 2.25로 곱된다.

phenom lecture boost-templates:"Template:search link 150% tlusage 225%"

부스트 템플릿과 다음 위치의 해시템플릿이 다름

기본 네임스페이스
gramar. boost-template는 복수형을 가지고 있고 단어 사이에 대시를 사용한다.
구문. 부스트템플릿은 따옴표를 필요로 한다.
기능을 발휘하다해시템플릿은 필터지만 부스트템플릿은 그렇지 않고 점수만 바꾼다.
부스트 템플릿에는 부스트를 제어하는 매개 변수가 있다.

검색 결과에 특정 템플릿이 있는 페이지만 포함하려면 해시템플릿을 대신 한 번 이상 사용하여 그렇지 않은 페이지를 필터링하십시오.그렇지 않으면 위에 표시된 시스템 메시지와 유사한 승수를 선택하십시오.페이지 점수에 10을 곱하는 것은 1000%로 이루어지며, 아마도 "제목에서 검색어가 일치할 때"와 같은 다른 모든 가중치 부여 기능은 검색 결과 표시에 거의 영향을 미치지 않을 것이며, 전체 목록의 순서에 영향을 미치기 때문에 권장되지 않을 것이다.

hastemplate 또는 boost-template는 쿼리의 어느 한쪽에 각각 다른 용어가 있는 쿼리의 어느 곳에도 갈 수 있는 용어로서, 쿼리의 어느 한쪽에 다른 용어가 있다.

벅스

CirrusSearch의 관련 문제:

T73123: 페이지 이름에는 큰따옴표 "을(를) 사용할 수 없음: incategory 또는 initle
tilde ~ 문자는 매개변수에 영향을 주어서는 안 된다. 예를 들어, 처음에는 ~가 탐색하지 않을 뿐만 아니라 페이지를 생성하지 않으며, 이 모든 것이 네임스페이스 인수에 간섭하지 않고 사이비 네임스페이스 "all"을 방해하지 않는다.
T124272 동일한 쿼리에서 AND와 OR을 모두 사용하는 것이 예상대로 작동하지 않음
구문 검색은 숫자 # 기호 위로 확장될 수 있지만 별표 * 문자는 확장되지 않는다.이것은 일관성이 없다.
T119806을cm2 찾을 수 없음cm²을(를) 찾을 수 없음m³여기서 위첨자는 유니코드 문자다.
검색 프로필 대화 상자는 분리하기 어렵다.검색 프로파일이 기본값으로 다시 변경된 후에도 계속 표시된다.

해결책

예를 들어, 두 개의 구문 사이에 AND를 사용하여 큰따옴표 " 마크와 관련된 여섯 개의 원하지 않는 기사를 피하십시오.

문제 해결

https://test.wikipedia.org/
URL을 접미사하여 백엔드 변경: 또는
릴리스 노트

인덱싱된 검색

첫째, 모든 페이지는 검색엔진에 의해 스캔된다.위키 전체가 검색 색인만을 위해 구축된 별도의 데이터베이스에 보관되는 하나의 "전체 텍스트"로 취급된다.책 속의 색인 같지만, 사실상 모든 단어와 숫자가 모든 페이지에 색인화되어 있다.^[23]

미리 작성된 검색 색인에서 각 단어는 이미 해당 단어가 포함된 페이지를 가리키기 때문에, 대부분의 검색어는 실제로 해당 색인에서 단일 레코드 검색입니다.(이것은 어느 정도 구문에도 해당된다.)

에 대해 업데이트된 개별 인덱스가 있음

직함
시각적 내용
위키텍스트
템플릿

각 템플릿 출력이 변환되는 모든 페이지에 색인화된 모든 단어.즉, 템플릿에 의해 변환된 모든 텍스트는 대상 페이지로 색인화된다.^[24]"인덱스 검색"은 기본적으로 실행하는 데 시간이 걸리지 않는다.그것들은 싸고 풍부하다.

검색 인덱스 작성 및 유지관리는 거의 실시간으로 백그라운드에서 이루어진다.페이지를 저장하면 몇 초 후에 방금 변경한 내용을 검색할 수 있다.많은 페이지로 변환되는 템플리트의 경우, 변경사항을 모든 ~~페이지~~ 색인 항목으로 전달하는 데 1분이 걸릴 수 있다.

인덱스는 영숫자를 기반으로 하며, 영숫자가 아닌 문자에 대한 정보는 저장하지 않는다.색인화된 검색은 구두점, 괄호, 수학 및 기타 키보드의 기호 문자를 요구할 수 있지만 경고 없이 무시된다.이제 당신은 왜 검색 인덱스가 그렇게 빠른지 이해하게 되었다.

각 regex 검색에는 10,000페이지 미만의 검색 도메인을 제공하기 위해 인덱싱된 검색 필터가 필요하다.

인덱싱된 검색

기본 인덱스 검색

문서 공간만 검색하십시오.그것이 디폴트다.
문자와 숫자만 일치시킨다.이것은 보통 문제가 아니다.
기본적으로 모든 공공 검색 엔진에 대해 동일한 방식으로 작동한다.당신은 보통 페이지 순위 소프트웨어에 의존하여 당신이 찾고 있는 정보를 검색 결과의 최상단 근처에서 찾을 수 있다.
많은 검색 결과를 얻는다.당신은 페이지 순위 규칙에 크게 의존하고 있다.그런 다음 최상위 페이지를 기준으로 검색 결과를 세분화하십시오.이 작업은 필터가 아닌 필터로 수행되며, 원하지 않는 단어의 앞면에 부착된 마이너스 기호로 표시되어 예상할 수 없었던 페이지 적중 소음을 걸러낸다.이것이 네가 가장 먼저 배우는 것이다.
입력하는 각 단어의 모든 형식을 일치시킴으로써 가능한 한 많은 페이지를 포함하는 "문자 관리인"이다.

기본적으로, "검색법"은 단지 핵심 단어일 뿐이고, 이것들은 분명히 알려져 있기 때문에, 왜 사람들이 "검색법"을 배우기를 원하는가?

고급 인덱스 검색

일반적인 정보를 찾는 대신 특정 페이지를 대상으로 한다.
페이지 순위는 전혀 필요하지 않으며 무수한 결과를 받아들일 수 없다.
검색 결과 페이지의 오른쪽에 표시되는 페이지 히트의 양에 대해 염려하십시오.

정규식

정규식은 검색 패턴을 정의하는 문자 시퀀스를 지정하기 위한 특수하지만 작은 언어다.정규식을 줄여서 regex라고 한다.

regex 검색은 실제로 검색 도메인의 각 페이지를 문자별로 검색한다.이와는 대조적으로, 색인화된 검색은 실제로 위키 데이터베이스와 별도로 유지되는 데이터베이스로부터 몇 개의 레코드를 쿼리하고 거의 즉각적인 결과를 제공한다.따라서 insource://(모든 종류의 regexp)를 사용할 때는 regex 검색 도메인을 최대한 제한하는 다른 검색어를 만드는 것을 고려해야 한다.인덱스를 사용하는 검색어가 많으므로 /regexp/에 대해 보다 정교한 검색 도메인을 즉시 제공한다.일반적인 효과의 순서는 다음과 같다.

slash 또는 이스케이프 문자를 제외하고 regexp를 복제하는 인용 부호가 있는 insource:"는 이상적이다.
intitle, incategory, linksto는 훌륭한 필터다.
hastemplate:는 매우 좋은 필터다.
"word1 word2 word3"는 인용 부호가 있든 없든 좋다.
네임스페이스: regex에는 고급 필터지만 regexp 검색이 느린 regexp 검색을 통해 장수를 완료할 수 있다는 점을 제외하면 실질적으로 유용하지 않다.

접두사 연산자는 모든 하위 디렉터리를 자동으로 검색하기 때문에 검색 템플릿, 검색 링크 또는 입력란에 {{FULLPAGENAME}}이(가) 있으면 특히 유용하다.새 regexp를 개발하거나 복잡한 regexp를 구체화하려면prefix:{{FULLPAGENAME}}대상 데이터의 샘플이 있는 페이지에

regexp 검색의 효율성을 높이지 않는 검색어는 페이지 가중치 연산자(더 유사, 부스트 템플레이트 및 선호도)이다.regex 검색의 주요 관심사는 먼저 검색 도메인을 "검색 엔진 쿼리"가 아닌 필터를 사용하는 인덱싱된 검색으로 제한하는 것이다.그런 다음 모든 페이지 문자를 문자별로 검색한다.좁게 정의된 검색 도메인의 각 페이지를 검사한다.

기본 regex 검색

regexp를 사용하여 문자열을 정확하게 패턴화할 수 있다.
가능한 한 많은 페이지를 제외하다
각 regexp를 큰따옴표로 인용하여 메타카락터를 해제한다.

고급 regex 검색

메타카락터를 사용한다.
샌드박스에서 개발됨으로써 얻는 이익

regexp는 문자 그대로 모든 문자와 일치하는 천 개의 단어 또는 regex 메타차박터 언어의 몇 개의 기호 또는 두 개의 조합이 될 수 있다.어떤 키보드에서도 어떤 캐릭터와도 매치할 수 있다.

따라서 Regex는 정확성을 생산하지만 속도가 느리고(비용) 속도를 높이기 위해 필터를 추가(비용 절감)할 책임이 있다.

regex 검색을 개발하려면 사실상 항상 시행착오가 필요하며, 이는 {{regex}}, {{template usage}}}이(가) 지원하는 반복적 개발 프로세스다.가장 쉽게 추가할 수 있는 필터는 네임스페이스, 접두사 또는 슬래시가 제거되지 않은 정규식 복사본이다.이러한 필터는 모두 색인을 사용하여 검색하며 검색하면 훨씬 빠르다.이것은 우리가 regex 검색에 대해 처음 배우는 것 중 하나이다: 필터로 검색에 동행한다.^[25]

도메인 크기 검색

자동이 아니라 자발적인 것이다.
정규식에 대한 접근성 보호
가능한 가장 진보된 검색 기능을 개방적으로 사용할 수 있도록 하다.
HTML 시간 초과를 방지하여 검색이 중단됨
{{regex}} 개발 샌드박스 생성
그들이 필요로 하는 처리 능력만 가지고, 사려깊다.

맨 regex를 실행하는 것은 위키백과:성능에 해를 끼칠 수는 없지만, 기본적인 검색 기법을 적용하지 않고 regex 검색은 다른 regex 검색자들을 제한할 수 있고, 논쟁거리가 될 수 있다.

all: insource "질문 하위 링크" 위키에 있는 페이지 수는?OK. sublinks]]?"/

이것은 위키에서 위키백스트 콘텐츠에 대한 질문에 답하기 시작할 수 있는 정규 표현식의 충분한 부분을 다룬다.Regex는 메타 문자를 사용하여 리터럴 문자와 일치하는 패턴을 만드는 것이다.당신이 주는 패턴은 성격에 따라 대상과 일치할 것이다.일부 포지션을 여러 가지 가능성과 일치시키려면 메타캐랙터가 필요하며, 위키텍스트에도 있는 동일한 키보드 문자 출신이다.

메타카락터스

왼쪽 곱슬 브래킷은 메타차박터(metacharctor)이므로 주어진 regexp 패턴은 모든 열린 곱슬 브래킷을 "탈출"해야 한다.\{위키텍스트의 템플리트와 일치시키려 {하는 ""모든 대상 텍스트(모든 Wikitext)는 리터럴 텍스트지만 regex 메타캐랙터들을 "탈출"할 수 있다. \. \? \+ \* \ \{ \[ \]  \" \\ \# \@ \< \~ 우리가 위키에서 그들을 문자 그대로의 캐릭터라고 언급할 때 우리는 채굴에 관심이 있다.검색은 의미가 없거나 불필요한 곳이라면 어디서든 백슬래시를 무시한다.\n성냥 등등.그러니 도망칠 필요까진 없겠지만&또는>또는}그렇게 하는 것은 안전하다.불필요한 백슬래시는 당신의 패턴을 실패하게 하는 것이 아니라, 문자 그대로 특정 문자를 사용하는 것이다. [ ] . * + ? { ( ) " \ # @ < ~

[0-9]모든 숫자와 일치한다.[a-y]z를 제외한 모든 소문자,[zZ]임의의 z(등)그래서 대괄호는 "문자 클래스"를 의미한다.
도트.뉴라인 또는 타겟 위치의 모든 문자와 일치함

이러한 기호가 일치하는 순차적 자릿수 또는 문자의 수는 정량화된 메타카락터를 사용하여 다음과 같이 표현된다.

*0 또는 그 이상을 의미한다.
+하나 또는 그 이상의 의미
?0 또는 1을 의미한다.

그 뒤에 나오는 성질의.일치하는 횟수도 범위 내에서 지정할 수 있으며,a{2} a{2,} a{2,5}정확히 2, 2 또는 그 이상 또는 2-5와 일치한다.그래서 곱슬곱슬한 괄호는 "양자"를 의미한다.

괄호는 그룹화 메커니즘이기 때문에 이전 문자보다 더 많은 양을 정량화할 수 있고, 그래서 우리는 일련의 대체 매칭에 대한 경계를 만들 수 있다.(아래 교대 참조)
따옴표는 대괄호나 백슬래시와 같은 탈출 메커니즘이다.
각 괄호는 숫자가 아니라 숫자를 나타낸다.라고 말하다<5-799>, 5~799와 1~3개의 포지션으로 매치하기 위해.이 값을 다른 옵션과 비교해 보십시오.[0-9]{1,3}0-999 또는 00-999 또는 000-999와 같은 수 십 또는 수천 개와 일치할 수 있다.
틸데~앞을 보고 다음 인물을 부정하다.즉, 패턴이 이 위치에서 일치하면, 다음 문자가 일치하면 불일치를 해제한다.~인격의

외로운 사람을 찾는 것은 안전하지 않다.@그 단일 메타카로터(metacharacter)가 말 그대로 모든 것과 일치하기 때문에, 당신은 사용할 수\@"at" 기호를 사용하는 모든 페이지를 찾으십시오.

마찬가지로 숫자 0을 사용하는 모든 페이지를 찾으면 검색은 오류를 반환하여 단독 0을 검색한다; 다음 세 가지 이스케이프 메커니즘 중 하나를 사용하십시오.0또는@.

"0"
\0
[0]

아니면 당신이 찾는 0 주위에 더 큰 패턴을 찾을 수 있다.비록 0이 메타카박터는 아니지만, 이러한 탈출 메커니즘은 효과가 있다.

위키리겔스의 나머지 부분은 꽤 간단하다.캐릭터는 메타캐릭터가 아닌 이상 자신을 상징한다.만약 그들이 메타캐릭터라면 그들은 캐릭터 클래스 밖에서 탈출한다.

캐릭터 클래스

문자 클래스는 "문학적인 문자"를 의미하며, 복수형을 의미한다.그것은 "문학"을 의미하고, 그래서 보통 캐릭터 수업에서 메타카락터 캐릭터를 벗어날 필요가 없다; 그것들은 이미 네모난 벽돌로 만들어진 것이다./slash 구분 기호/는 물론 문자 클래스 안에서도 슬래시 문자를 피해야 함을 의미한다.문자 클래스에서 슬래시를 제외한 다른 문자는 항상 이스케이프가 필요하지만, 그 이유는]그리고-캐릭터 클래스에 특별한 의미(메타카락터)를 가지고 있는데, 그들은 때때로 탈출해야 한다: 그 둘은 또한 문자 그대로의 메타카락터(metacharactor)이며, 그들이 첫 번째 캐릭터라면 탈출해야 한다. 그러나 그렇지 않으면 그들은 또한 대시처럼 탈출해야 한다: 캐릭터 클래스에서 백슬래쉬-슬래쉬만이 탈출 메커니즘으로 작용한다.

캐릭터 수업은 메타캐릭터들을 탈출시키는 역할을 할 수 있다.[- *\/.{\]]또는[] *\/.{\-]"대시 OR 파이프 또는 별 또는 슬래시 OR 도트 또는 왼쪽 곱슬 브래킷 또는 오른쪽 사각 브래킷"을 의미한다.그렇게[][.?+* \/{}()\-]"또는[-[.?+* \/{}()\]]"위키텍스트에 있는 메타캐랙터들, 백슬래시를 제외한 모든 메타캐랙터들을 찾는 일을 한다.둘 다 아니다.[\]아닌[\\]말 그대로 백슬래시를 할 수 있게 해줬어OR 백슬래시 문자에 패턴이 번갈아 나타나며\\그 사건을 담당하기 위해서요(아래 참조)

캐릭터 수업은 그 자체의 "반대"를 이해하는데, "a 또는 b 또는 c가 아니다"이다.문자 클래스는 목표 위치의 단일 문자를 의미하기 때문에 실제로 집합의 역이 아니라 문자의 NOT이다.

현재 문자 클래스는 4자의 확장으로 제한되어 있으므로 [0-9]에는 3개의 검색 [0-3], [4-7], [8-9]가 필요하다.알파벳은 일곱 번의 검색을 필요로 할 것이다.레그스가 검색엔진에 과부하를 주지 않고 작동한다는 것을 보장하기 위해서다.과제 T106685를 참조하십시오.

다음과 같은 구성 요소:\d(자리) 또는\a일부 다른 정규스 구현에서 사용되는 (알파벳자)는 허용되지 않는다.

교대

마지막으로, 교대란 AA, BB 또는 CC와 같이 경기에 대한 대체 가능성을 포함하고 있는 regex의 한 종류다.

"AA" 또는 "BB" 또는 "CC" to Word 전체 페이지 검색
AA BB CC두 글자의 위치를 다시 검색하다
(AA BB CC)교체가 가장 긴 패턴을 찾기 때문에 더 큰 regexp 내에서 사용되며, 그래서 괄호는 그 경계를 정의하지만 교체가 전체 regexp 패턴인 경우 만들 필요가 없는 경계다.

메모들

^ 일부 사용자의 기본 검색 도메인은 모두 네임스페이스다.맨 regex 검색과 같은 경우 검색 엔진은 모든 regex 검색을 제한하여 자신을 보호한다.수백만 페이지를 기어다니는 맨 리겔스는 20초 이상 걸릴 수 있으며 HTML 시간 초과까지 초래할 수 있다.그 기간 동안 다른 regex 검색은 거의 허용되지 않는다.항상 regex와 함께 필터를 사용하십시오.
^ 등호 부호를 검색하려면 regexp를 사용해야 한다.다른 템플릿과 마찬가지로 {{=}} 또는 1=같은 부호를 매개변수, 심지어 링크 라벨에 전달한다.
^ 위키피디아의 다른 페이지를 검색하기 시작하는 편집자는 때때로 기본 검색 도메인을 설정할 수 있다(Special: 특별:모두 검색(고급)검색을 모두로 설정하는 것은 "설정하고 잊어버리는" 가장 가능성이 높은 시나리오다.그것은 기사 공간을 포함하기 때문에, 일반적인 결과는 비교가 된다.
^ 페이지 순위를 매기는 다른 데이터와 달리 단어 빈도와 위치 데이터는 항상 색인에서 업데이트될 수 있다.위키의 각 단어에 대해 인덱스는 해당 단어를 찾을 수 있는 페이지 이름 목록을 저장한다.페이지 이름과 함께 단어의 위치 및 개수도 저장된다.Apache Lucene은 인덱서로서, 데이터를 유지하고, 주파수 알고리즘이라는 용어를 사용한다.이 방법은 TFIDF 유사성을 참조하십시오.
^ 검색 인덱스와 달리 페이지 순위 데이터는 즉시 업데이트되지 않는다.수신 링크 수가 20% 이상 변경되면 업데이트된다.
^ {{search link}}}}은(는) 기본적으로 아티클 스페이스로 설정되어 있기 때문에 네임스페이스가 제공되지 않더라도 항상 완전히 지정된 쿼리를 생성한다.
^ 한 구절이 총알을 포함하지 않는 한 공백에 걸쳐 확장될 것이다.구문은 주문된 목록 항목 위로 확장될 수 있지만 주문되지 않은 목록 항목은 확장할 수 없다.즉, 숫자 # 기호로 확장될 수 있지만 별표 * 문자는 확장되지 않는다.별표는 분석기에 특별한 의미를 갖는다.주문되지 않은 리스트에 있는 아이템을 만드는 데 사용되며, 검색 시 수식어로 사용된다.
^ CirrusSearch가 개발한 ElasticSearch "토키나이저"를 참조하십시오.
^ 페이지 랭킹과 마찬가지로, 에스트는 컴퓨터 알고리즘일 뿐이며, 때때로 조정이 필요한 경향이 있다.
^ CirrusSearch는 T56022에 따라 줄기 세포 패키지에 kstem을 사용한다.
^ 마찬가지로 리소스 매개 변수를 사용하여 기본 설정을 해제할 수 있다.또한 T113838에는 이 버그가 자세히 설명되어 있다는 점에 유의하십시오. 검색 결과에 나열된 페이지가 한 단어에 대해 해제된 경우(이 페이지는 스템만 변형된 것이 아니라 모두 지정된 대로 단어가 있음) 그러나 스네이킹된 줄기는 잘못 강조 표시된다는 점에 유의하십시오.
^ 이것은 이 페이지의 예시 검색에서는 증명할 수 없지만, 이 예가 포함되지 않은 다른 페이지에서 작동될 것이다.여기서 증명하듯 대담하게 보여주는 시합이 적절한 순서를 선호하기 때문이다.다른 페이지에 대상 텍스트를 입력한 다음 (검색 결과 페이지의) 쿼리를 이 페이지로 변경하여 증명할 수 있다.
^ 검색 네임스페이스는 쿼리의 첫 번째 매개 변수에서 일치한다.이것은 항법, 위키링크, 전폐 및 페이지 이름 지정에서 항상 이 분야의 첫 번째 단어와 일치한다.
^ 모든 네임스페이스를 보려면 검색 결과 페이지로 이동하여 고급을 클릭하십시오.기본 네임스페이스는 괄호 안에 표시된다.
^ 위키에 있는 모든 단어의 전체 텍스트와 업로드된 모든 첨부 파일에 있는 모든 단어의 전체 텍스트는 모두 검색 데이터베이스에서 함께 색인화된다.CirrusSearch는 수천 개의 형식을 구문 분석 및 인덱싱할 수 있다.
^ 페이지 이름에 허용되지 않는 문자는# < > [ ] { }.
^ 항상 검색 표시줄에서 해당 표시가 있는지 확인하십시오.고급 창을 활성화하면 기본 검색 도메인이 표시될 수 있으며 검색 상자는 네임스페이스 또는 접두사 용어로 매우 명확하다.이렇게 하는 한 가지 방법은 검색 단추를 클릭하는 대신 검색 줄 검색 도메인을 클릭하는 것이다.고급 탭에서 검색 도메인을 변경한 후 고급이 아닌 검색을 누르십시오.
^ 딥캣을 검색 매개 변수로 가져오려면 자동으로 생성되는 가젯을 설치하십시오.69개 이상의 하위 범주가 있는지 확인하려면 브라우저 기록에서 fwd 및 bwd로 이동하거나 검색 결과 페이지의 원본 HTML, <제목> 속성을 참조하십시오.
^ 계산에서 /정규식/을 슬래시로 구분하는 것이 일반적이다.
^ 검색은 실제로 페이지별로 이루어지는 것이 아니라, 위키에 대한 인덱스는 이런 방식으로 페이지별로 작성된다.
^ 모차르트에 관한 각 페이지에 모차르트 내비게이션 템플릿을 추가하는 등의 작업을 함으로써 위키 인프라를 강화한다.반면에 저자는 한 페이지의 산문을 한 번에 한 페이지씩 쓴다.(와의 원치 않는 링크는 제거할 수 없음) 제거할 수 없음.
^ 시스템 메시지는 MediaWiki 작동 변수의 값이다.그것은 일반 텍스트, 위키 텍스트, CSS 또는 자바스크립트의 조각으로 구성될 수 있다.메시지는 특히 독자들이 보는 사용자 인터페이스와 관련된 MediaWiki의 동작을 사용자 정의하기 위해 사용되지만, 또한 간단한 메시지로 나타나는 방식, 그리고 각 언어와 로케일에 대한 메시지도 포함된다.
^ 페이지를 검색하지 않고 검색할 때 색인(데이터베이스)에서 항목을 검색하는 경우모든 콘텐츠는 항상 "알려져 있고" 인덱스에 상주한다.따라서 "네임스페이스 검색" 또는 "페이지에서 변환된 내용 검색"을 읽을 때 "검색"을 "인덱스를 검색"으로 대체할 수 있다.
^ 이것은 또한 "페이지 검색이 끝나기 전에 페이지의 템플리트를 확장한다"라고 말하지만, 그것은 추상화에 불과하다.
^ 사용자가 4331만6373명이고 잘 필터링된 regex 검색은 밀리초밖에 걸리지 않는 반면, 맨 위키 넓이의 regex는 수십 초가 걸릴 수 있기 때문에 필터를 추가하면 얻는 이점은 엄청나다.

===별도 샌드박스에서 정규식 개발 ====

정규 표현은 작은 컴퓨터 프로그램이기 때문에 대상 데이터를 연구하면서 반드시 작성해야 하고, 잠재적인 정밀도와 철저함을 달성하기 위해 테스트해야 하는 것이 regex 검색의 특징이다.그러나 이러한 집중적인 검색 중 일부만 데이터베이스에 대해 기술적으로 한 번에 실행할 수 있다.^[1]샌드박스는 당신의 발자국을 최소화하고, 비록 당신의 기본 검색이 그렇게 할 수 있게 해준다고 할지라도, 당신이 위키의 모든 네임스페이스에서 검증되지 않은 regexp를 결코 실행하지 않을 것을 보장한다.

위키 전체를 대상으로 하는 정상적인 검색은 빨리 실행되지만, regexp 검색은 빨리 실행하기 위해 필터를 사용하여 가능한 한 적은 페이지를 대상으로 해야 한다.필터는 데이터베이스 쿼리의 일부 또는 전체.필터에는 다음이 포함된다.

단어 또는 구문
intitle:
범주:
hastemplate:
접두사: (항상 끝에 있음)
링크스토:
네임스페이스: (항상 시작 시)
리소스:"word1 word2"
insource:word

검색이 실행되기 전에 소프트웨어에 의해 최적화되기 때문에 순서는 중요하지 않다.

regex 검색을 실험하거나 개발하는 동안 한 페이지만 대상으로 지정하려면 전체 파일 이름을 대상으로 지정하십시오.검색 상자에서 필터를 사용하십시오. (대상 데이터가 있는 페이지의 모든 섹션의) 편집 상자에서는 항상 쓰기만 하면 전체 파일 이름까지 "확대"할 수 있다.기록 페이지를 편집할 수 있지만 기술적으로 "기록 페이지"는 (데이터베이스에서) 페이지가 아니므로 {{FULLPAGENAME}은(는) 데이터베이스 버전(자체 렌더링이 아님)을 가리킨다.검색 매개 변수를 저장할 필요 없이 몇 번이고 변경할 수 있지만 아직 저장되지 않은 페이지(데이터베이스에)에서는 Wikitext를 검색할 수 없다.

Fullpagename은 네임스페이스:pagename이다.이것을 알고 있으면 접두사 매개 변수를 조정할 수 있다.접두사는 한 페이지까지 필터링할 수 있지만 네임스페이스까지 필터링할 수 있으며 네임스페이스 검색 도메인을 줄이려면 페이지 이름 집합의 시작 문자도 허용한다.

Regex 샌드박스는 대상 데이터가 포함된 페이지를 편집하여 "샌드박스"로 사용(저장하기 위해 편집하지 않음)하여 만든 애드혹 샌드박스를 사용한다.그런 다음 필터 접두사와 함께 insource:/regexp/가 포함된 검색 링크를 추가함으로써 개발된다.{{FULLPAGENAME} 옆에.

샌드박스를 사용하면 필터를 사용하여 검색 도메인을 제한함으로써 가능한 최소 설치 공간을 확보할 수 있다.regexp 패턴을 연마하면 검색 도메인을 늘린다.regex 검색은 광택이 나는 렉스 익스프레스라 하더라도 필터가 아닌 필터로 실행하는 것이 가장 좋다.

샌드박스화 절차

동등의 기호와 파이프 문자를 입력하고 "구문 주위의 질문"을 입력하는 검색 상자를 사용하는 대신, 샘플 데이터와 함께 페이지에 regex 기반 검색 링크 템플릿({{regex} 또는 {{tlusage})을 사용하는 것이 여전히 가장 쉽다. 왜냐하면, 그러면 당신은 거기에서 표적 데이터에 초점을 맞추고 regexp 패턴을 쓰는 데 집중할 수 있기 때문이다.템플릿이 파이프 문자와 등가 부호를 "탈피"하는 방법을 이미 이해했다면 더 쉽다.도움말 참조:템플릿#기타 중요한 세부 정보를 위한 매개 변수.

여기서의 절차는 반복적이고, 재평가-수정 사이클이다.Regex 개발에서는 대상 데이터의 패턴을 작성하고 다시 쓰는 동안 대상 데이터를 연구해야 한다.

마이닝에 관심이 있는 Wikitext 인스턴스가 있는 페이지로 이동하십시오.또는 직접 작성한 후 쿼리가 찾을 수 있도록 데이터베이스에 저장하십시오.
Wikitext를 열고 {{regex} 또는 {{tlusage}}을(를) 입력하십시오.
미리 보기를 표시하고 검색 링크를 활성화하십시오.검색 결과 페이지에서 각 일치 항목의 굵게 표시된 텍스트를 기록해 두십시오.
브라우저로 돌아가십시오.regexp를 수정하고 완료될 때까지 주기를 수행하십시오. (아니면 뒤로 돌아가지 마십시오. 검색 상자에서 쿼리를 수정하십시오.)
검색 도메인을 확장하고 해당 결과의 정확성을 테스트하십시오.다음 접두사를 사용하여 결과 수를 트리밍하거나 확장할 수 있다.

주의사항 비우기: 즉시 재시험을 위해 대상을 변경하면 저장 및 숙청해야 하지만 regexp만 변경하면 그렇지 않다.

예

임시 샌드박스로서, 이와 같은 섹션의 위키텍스트(이미 데이터베이스에 저장되어 있음)를 보여주고, 이 페이지에 있는 regex 검색 링크 템플릿 호출의 일부 패턴을 수정하고, 미리보기 표시를 하고, 새로 구성된 regex 검색 링크를 클릭할 때 어떤 일치하는지를 볼 수 있으며, 모두 매우 안전하게 데이터베이스에서 어떤 것을 변경하지 않아도 된다.

"1ft/s, 2sq ft, 3m/s, 4m*s-2, 5ft.s-2, 6°C/J, 7J/C"를 생성하는 템플릿 호출은 다음과 같이 이 섹션의 wikitxt에 나타난다.

{{val 1 ul=ft/s fmt = commas}}
{{val 2 u=ft2}}
{{val 3 u=m/s fmt =commas }}
{{val 4 u=m*s-2}}
{{val 5 u=ft.s-2}}
{{val 6 u=C/J}}
{{val 7 ul=J/C}}

위의 표적에 번호가 매겨지는 방법을 참고한 후 아래 링크를 클릭하십시오.

질의	검색 링크	답
Q1 {{search link}}}을(를) 사용하여 이 페이지에서 템플릿 Val?	`{{sl hastemplate: Val}}`→ 해스트템플릿: 발	A. 아니오, 페이지 이름이 문서 공간이 아닌 도움말 공간에 있기 때문에.(검색 링크 기본값)1300개의 검색 결과.
Q2 {{search link}}}을(를) 책임감 있게 사용하여 Val의 fmt 파라미터를 사용하는가?	`{{sl insource:/\{[Vv]al\{{!}}[^}]fmt/ prefix:{{FULLPAGENAME}}}}`→ insource:/\{[Vv]al\ [^}]fmt/ 접두사:템플릿:검색 링크	A2.1. 검색 결과에서 1과 3을 굵은 텍스트로 검색하십시오. (적절한 필터를 추가하십시오.)
대신 {{regex}}을(를) 사용하여...	`{{slre \{[Vv]al\{{!}}[^}]fmt}}`→ insource:/\{[Vv]al\ [^}]fmt/ 접두사:템플릿:검색 링크	A2.2 {{search link}}보다 적은 입력.
{{템플릿 사용}} 대신 사용...	`{{tlre Val pattern=fmt}}`→ 테스트 `fmt` 이 페이지에	A2.3 템플릿이 가장 쉽다.
Q3. OR을 사용하는 사람? (한 글자는 다름)	`{{regex ul?=ft}}`→ insource:/ul?=ft/ 접두사:템플릿:검색 링크	A. 굵은 글씨로 1, 2, 5를 찾아라.
{{템플릿 사용법}}}	`{{tlre val pattern = ul?=ft}}`→ 테스트 `ul?=ft` 이 페이지에	Val 템플릿 내에서만 동일한 패턴 찾기
Q4. 그리고 이들 중 누가 그 이후에 fmt=commas를 사용하겠는가?	`{{slre ul?=ft.*commas}}`→ insource:/regexp/ 접두사:템플릿:검색 링크	A. 컨텍스트는 표시되지 않지만 기사 제목은 표시된다.반 버그?
누가 "commas"라는 단어 앞에 하나의 공간을 가지고 있는가?	`{{slre . commas}}`→ 인소스:/. 쉼표/접두사:템플릿:검색 링크	A. 1은 2는 아니고.
Q5. u 또는 ul 중 하나를 "ft"와 함께 사용하는 사람 또는 "fmt=commas"를 사용하는 사람.	`{{slre (ul? = ft{{!}}fmt = commas)}}` → insource:/regexp/ 접두사:템플릿:검색 링크	A. 1, 2, 3, 5. (패턴은 가능한 모든 간격과 일치한다.)
Q6. ft 또는 m을 사용하는 사용자: `u=`또는 `ul=`?	`{{slre ul? {{=}} (ft{{!}}m)}}` → 인소스:/ul? = (ft m)/ 접두사:템플릿:검색 링크	A. 1, 2, 3, 4, 5 사용 {{!교대 메타카락터 {{}}.사용 {{=}}}. (이름으로 사용했을 수 있다.`1 =` 또는 좋은 이름을 가진`pattern =` .)
Q7. 유닛 코드에서 . 또는 *를 사용하는 사람은?	`{{tlre val pattern = u = (\.{{!}}\)/}}` → 이 페이지* 테스트	A. 4, 5.
누가 파이프를 사용하니?	`{{regex \ }}`→ insource:/\/ 접두사:템플릿:검색 링크	그들 모두
Q8. - 내에서 / 또는 -를 사용하는 사람 `u=`또는 `ul=`파라메터?	`{{tlre val ul? = [^{{!}}}]+(\/{{!}}-)}}` → 이 페이지 테스트	A. 1,3,4,5,6,7.
Q9. 템플릿 네임스페이스에서 Val은 숫자만 사용하는 경우(아니오, , , 또는 매개 변수)	`{{tlre val pattern = ~(u[lp].) prefix = 10}}` → hastemplate:"val" insource:/\{\{ [Vv]al \[^}]*~(u[lp])./ 접두사:템플릿:	A. 나열된 30개 정도의 템플릿에서.
Q10. {{Convert}}의 옵션을 사용하는 기사는?	`{{tlre convert pattern=and$-$ prefix=0}}` → hastemplate:"전환" 인소스:/\{\{ [Ccc]onvert \[^}]*and$-$/ 접두사:	코스트 레인지 아크 및 스킵잭 셰이드

2분기에는 MediaWiki 소프트웨어가 매개 변수 주위의 공간을 무시하지만 4분기에는 동일한 MediaWiki 소프트웨어가 매개 변수 내부의 공간을 처리하는 방법에 주목하십시오.Q2는 'fmt'와 'val'은 전체 단어인 데다 fmt가 발 내부와 별개로 거의 보이지 않기 때문에 평이한 검색으로 풀렸을 것이다.어때?

참조

^ 검색이 위키피디아의 CirrusSearch/ElasticSearch 엔진에 미치는 영향 보기

참고 항목

위키백과 검색 템플릿

검색 링크

검색 링크는 저장된 검색에 대한 실시간 검색 결과를 제공하는 링크에 쿼리를 저장한다.그것들은 사용자 페이지와 대화 페이지에서 찾을 수 있다.하나를 사용하여 미디어위키 검색의 전체 기능 세트 또는 외부 검색 엔진의 기능을 가져와 검색 매개 변수에 익숙하지 않은 사용자를 감시하십시오.

검색 링크의 한 유형은 검색(검색 상자)의 모든 기능과 표준 위키링크 구문이 있는 위키링크 입니다.따라서 이 검색 링크는 (1) 탐색:[Special:search/Wales] → Special:search/Wales 또는 (2) 검색: → 검색/~tilde 문자에 접두사를 붙이면 Wales.

다른 모든 검색 링크는 위키링크 대신 URL을 만드는 템플릿으로 만들어진다.예를 들어 URL은 위키피디아를 검색하기 위해 외부 검색 엔진을 호출할 수 있다.

{{Search link}}은(는) 검색(검색 상자)의 모든 기능과 네임스페이스의 조합을 위한 추가(URL) 매개변수를 제공하며 페이지당 20개 결과 제한, 공유 가능: → 라벨을 벗어날 수 있는 위치를 제공한다.
{{Regex}} – 고급 regex 검색 기능 개발{{regex \<--.*--> label = Articles with comments missing the ! bang character prefix=0}} → !bang 캐릭터가 빠진 댓글 달린 기사
{{템플릿 사용}} – 템플릿 regex 검색을 개발하여 특정 템플릿-호출 세부 정보를 정확히 찾아낸다.{{Template usage Convert \{{!}}C\{{!}}F 0 Articles that convert Celsius to Fahrenheit}} → 섭씨 화씨로 전환하는 기사
{{ShortSearch}} – 세 가지 검색 링크 생성: → WP GWP G(검색 위키백과, "Google" 위키백과, Google 검색)
{{wpsearch}} – 5개의 검색 링크 생성: → 협업 검색 – 위키백과 검색 구글 검색 덕덕고 검색 야후 검색
{{Wikidata 검색 링크}} – 설명, 엔티티, 항목, 속성 등을 위한 Wikidata 검색 링크 생성 → https://www.wikidata.org/w/index.php?search=Universe&title=Special:Search&fulltext=1

검색 상자

{{검색 상자}} – 아래 또는 오른쪽에 버튼이 있는 간단한 검색 상자
{{검색 접두사}} – 여러 페이지의 하위 페이지를 한 번에 검색한다.
{{아카이브 배너}} – 아카이브 검색용.그것은 다른 많은 아카이브 템플릿과 마찬가지로 배너 스타일의 것이다.

검색 상자는 다음에 의해 만들어진다.<inputbox>태그. mw: 참조:확장:입력 상자.

페이지 제목 검색

{{Canned search}} – 특정 용어의 자동 검색 결과에 대한 링크
{{In title}} – 이름에 지정된 단어가 포함된 페이지 검색
{{보십시오}} – 지정된 단어로 이름이 시작되는 페이지 검색

정확한 일치, 대/소문자 정확히 또는 구두점 검색은 도움말을 참조하십시오.§ grep 검색 중.

기타 위키백과 편집자 도움말

{{Linksearch}} – URL과 일치하는 외부 링크 검색
{{dabsearchterm}} – 다음이 포함된 페이지 제목을 찾는 외부 도구(term)괄호 안에; 위키백과에 유용하다:해석 연구
{{Help Desk Search} – 사용자 페이지, 마을 펌프 등의 검색에 특화된 Google 페이지에 대한 링크 목록이 포함된 Navbox. 위키백과에 유용:헬프 데스크 태스크
{{Spamsearch}} – 사용자 페이지에 "we 서비스", "선도 제조업체" 등과 같은 일반적인 스팸 검색

참고 항목

도움말:검색
범주:검색 템플릿
MediaWiki:확장:입력 상자 § 일반 구문 - 다음을 사용하여 검색 상자를 만드는 방법<inputbox>...</inputbox>

위의 문서는 템플릿에서 변환됨:링크/doc 검색
편집자는 이 템플릿의 샌드박스 와 테스트케이스 페이지에서 실험할 수 있다.
/doc 하위 페이지에 카테고리를 추가하십시오.이 템플릿의 하위 페이지.

[1] 일부 사용자의 기본 검색 도메인은 모두 네임스페이스다.맨 regex 검색과 같은 경우 검색 엔진은 모든 regex 검색을 제한하여 자신을 보호한다.수백만 페이지를 기어다니는 맨 리겔스는 20초 이상 걸릴 수 있으며 HTML 시간 초과까지 초래할 수 있다.그 기간 동안 다른 regex 검색은 거의 허용되지 않는다.항상 regex와 함께 필터를 사용하십시오.

[2] 등호 부호를 검색하려면 regexp를 사용해야 한다.다른 템플릿과 마찬가지로 {{=}} 또는 1=같은 부호를 매개변수, 심지어 링크 라벨에 전달한다.

[3] 위키피디아의 다른 페이지를 검색하기 시작하는 편집자는 때때로 기본 검색 도메인을 설정할 수 있다(Special: 특별:모두 검색(고급)검색을 모두로 설정하는 것은 "설정하고 잊어버리는" 가장 가능성이 높은 시나리오다.그것은 기사 공간을 포함하기 때문에, 일반적인 결과는 비교가 된다.

[4] 페이지 순위를 매기는 다른 데이터와 달리 단어 빈도와 위치 데이터는 항상 색인에서 업데이트될 수 있다.위키의 각 단어에 대해 인덱스는 해당 단어를 찾을 수 있는 페이지 이름 목록을 저장한다.페이지 이름과 함께 단어의 위치 및 개수도 저장된다.Apache Lucene은 인덱서로서, 데이터를 유지하고, 주파수 알고리즘이라는 용어를 사용한다.이 방법은 TFIDF 유사성을 참조하십시오.

[5] 검색 인덱스와 달리 페이지 순위 데이터는 즉시 업데이트되지 않는다.수신 링크 수가 20% 이상 변경되면 업데이트된다.

[6] {{search link}}}}은(는) 기본적으로 아티클 스페이스로 설정되어 있기 때문에 네임스페이스가 제공되지 않더라도 항상 완전히 지정된 쿼리를 생성한다.

[7] 한 구절이 총알을 포함하지 않는 한 공백에 걸쳐 확장될 것이다.구문은 주문된 목록 항목 위로 확장될 수 있지만 주문되지 않은 목록 항목은 확장할 수 없다.즉, 숫자 # 기호로 확장될 수 있지만 별표 * 문자는 확장되지 않는다.별표는 분석기에 특별한 의미를 갖는다.주문되지 않은 리스트에 있는 아이템을 만드는 데 사용되며, 검색 시 수식어로 사용된다.

[8] CirrusSearch가 개발한 ElasticSearch "토키나이저"를 참조하십시오.

[9] 페이지 랭킹과 마찬가지로, 에스트는 컴퓨터 알고리즘일 뿐이며, 때때로 조정이 필요한 경향이 있다.

[10] CirrusSearch는 T56022에 따라 줄기 세포 패키지에 kstem을 사용한다.

[11] 마찬가지로 리소스 매개 변수를 사용하여 기본 설정을 해제할 수 있다.또한 T113838에는 이 버그가 자세히 설명되어 있다는 점에 유의하십시오. 검색 결과에 나열된 페이지가 한 단어에 대해 해제된 경우(이 페이지는 스템만 변형된 것이 아니라 모두 지정된 대로 단어가 있음) 그러나 스네이킹된 줄기는 잘못 강조 표시된다는 점에 유의하십시오.

[12] 이것은 이 페이지의 예시 검색에서는 증명할 수 없지만, 이 예가 포함되지 않은 다른 페이지에서 작동될 것이다.여기서 증명하듯 대담하게 보여주는 시합이 적절한 순서를 선호하기 때문이다.다른 페이지에 대상 텍스트를 입력한 다음 (검색 결과 페이지의) 쿼리를 이 페이지로 변경하여 증명할 수 있다.

[13] 검색 네임스페이스는 쿼리의 첫 번째 매개 변수에서 일치한다.이것은 항법, 위키링크, 전폐 및 페이지 이름 지정에서 항상 이 분야의 첫 번째 단어와 일치한다.

[14] 모든 네임스페이스를 보려면 검색 결과 페이지로 이동하여 고급을 클릭하십시오.기본 네임스페이스는 괄호 안에 표시된다.

[15] 위키에 있는 모든 단어의 전체 텍스트와 업로드된 모든 첨부 파일에 있는 모든 단어의 전체 텍스트는 모두 검색 데이터베이스에서 함께 색인화된다.CirrusSearch는 수천 개의 형식을 구문 분석 및 인덱싱할 수 있다.

[16] 페이지 이름에 허용되지 않는 문자는# < > [ ] { }.

[17] 항상 검색 표시줄에서 해당 표시가 있는지 확인하십시오.고급 창을 활성화하면 기본 검색 도메인이 표시될 수 있으며 검색 상자는 네임스페이스 또는 접두사 용어로 매우 명확하다.이렇게 하는 한 가지 방법은 검색 단추를 클릭하는 대신 검색 줄 검색 도메인을 클릭하는 것이다.고급 탭에서 검색 도메인을 변경한 후 고급이 아닌 검색을 누르십시오.

[18] 딥캣을 검색 매개 변수로 가져오려면 자동으로 생성되는 가젯을 설치하십시오.69개 이상의 하위 범주가 있는지 확인하려면 브라우저 기록에서 fwd 및 bwd로 이동하거나 검색 결과 페이지의 원본 HTML, <제목> 속성을 참조하십시오.

[19] 계산에서 /정규식/을 슬래시로 구분하는 것이 일반적이다.

[20] 검색은 실제로 페이지별로 이루어지는 것이 아니라, 위키에 대한 인덱스는 이런 방식으로 페이지별로 작성된다.

[21] 모차르트에 관한 각 페이지에 모차르트 내비게이션 템플릿을 추가하는 등의 작업을 함으로써 위키 인프라를 강화한다.반면에 저자는 한 페이지의 산문을 한 번에 한 페이지씩 쓴다.(와의 원치 않는 링크는 제거할 수 없음) 제거할 수 없음.

[22] 시스템 메시지는 MediaWiki 작동 변수의 값이다.그것은 일반 텍스트, 위키 텍스트, CSS 또는 자바스크립트의 조각으로 구성될 수 있다.메시지는 특히 독자들이 보는 사용자 인터페이스와 관련된 MediaWiki의 동작을 사용자 정의하기 위해 사용되지만, 또한 간단한 메시지로 나타나는 방식, 그리고 각 언어와 로케일에 대한 메시지도 포함된다.

[23] 페이지를 검색하지 않고 검색할 때 색인(데이터베이스)에서 항목을 검색하는 경우모든 콘텐츠는 항상 "알려져 있고" 인덱스에 상주한다.따라서 "네임스페이스 검색" 또는 "페이지에서 변환된 내용 검색"을 읽을 때 "검색"을 "인덱스를 검색"으로 대체할 수 있다.

[24] 이것은 또한 "페이지 검색이 끝나기 전에 페이지의 템플리트를 확장한다"라고 말하지만, 그것은 추상화에 불과하다.

[25] 사용자가 4331만6373명이고 잘 필터링된 regex 검색은 밀리초밖에 걸리지 않는 반면, 맨 위키 넓이의 regex는 수십 초가 걸릴 수 있기 때문에 필터를 추가하면 얻는 이점은 엄청나다.

[26] 검색이 위키피디아의 CirrusSearch/ElasticSearch 엔진에 미치는 영향 보기

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[1]