도움말 대화:URLURL

Help talk:
위키백과 도움말 프로젝트 (정격 NA급, 중간중간)
WikiProject icon이 페이지는 독자와 기고자를 위한 위키백과의 도움말 문서를 개선하기 위한 공동 노력인 위키백과 도움말 프로젝트의 범위 내에 있다. 참여하려면 프로젝트 페이지를 방문하여 토론에 참여하고 열려 있는 태스크 목록을 확인하십시오. 도움말 관련 리소스를 찾아보려면 도움말 메뉴 또는 도움말 디렉토리를 참조하십시오. 아니면 당신의 토크 페이지에서 도움을 요청하면 자원봉사자가 당신을 방문할 것이다.
Non-article page NA 이 페이지에는 프로젝트의 품질 척도에 대한 등급이 필요하지 않다.
중앙의 이 페이지는 프로젝트의 중요도에 대한 중간 평가로 평가되었다.

인코딩

내가 가장 잘 알 수 있는 것은 오직 이 문자들만이 인코딩을 필요로 한다는 것이다.

sp ! " , ' ; < > ? [ ]
%20 %21 %22 %2c %3a %3b %3c %3e %3f %5b %5d

예를 들어, 문서와 달리 캐럿은 인코딩을 필요로 하지 않는다: http://en.wikipedia.org/wiki/^

아포스트로피는 wikimarkup으로 구문 분석되기 때문에 순차적 사용에 실제로 적용된다. http://en.wikipedia.org/wiki/12345

파이프는 자동으로 인코딩된다: http://en.wikipedia.org/wiki/%7C

---- Gadget850 (Ed) 21:57, 2011년 4월 7일 (UTC)[]

"="사인

부처님 본연의 페이지에는 다음과 같은 = 노래에 문제가 나타난다. 다음 URL은 = 기호로 인해 지정된 제목/이름 옆에 있는 참조 목록에 전체 URL로 나타난다.

  1. ^ [http://www.sgilibrary.org/view.php?page=1052 현재 형태의 불상론]

%3D를 사용하여 수정하려고 했지만 제대로 작동하지 않음:

  1. ^ [http://www.sgilibrary.org/view.php?page%3D1052 현재 형태의 불상론]

{{=}}}을(를) 사용하는 것도 효과가 없다.

  1. ^ [http://www.sgilibrary.org/view.php?page=1052 현재 형태의 불상론]

친애하는 조슈아 조나단 (대화) 08:05, 2012년 3월 7일 (UTC)[]

이 예들의 문제는 등호괘가 아니라 제목이 두 줄로 갈라져 있기 때문이다. 그것을 공백으로 대체하면 모든 것이 잘 된다.

[1]

-- John of Reading (토크) 08:15, 2012년 3월 7일 (UTC)[]

그게 다야?!? 그걸 놓치다니 정말 우스운 일이다. 고마워!!! 조슈아 조나단 (토크) 08:39, 2012년 3월 7일 (UTC)[]

나는 [1]이(가) 오해의 소지가 있다고 생각한다. 표 아래 = 및 %3d에는 "동일 부호는 URL을 이름 없는 템플릿 매개 변수로 사용할 때만 인코딩하면 된다"라고 나와 있다. 그러나 = %3d로 대체될 경우 대부분의 URL이 깨진다. 예를 들어, https://www.google.com/search?q=feral은 작동하지만 https://www.google.com/search?q%3dferal은 작동하지 않는다. 이름 없는 매개 변수에서는 둘 다 작동하지 않는다: https://www.google.com/search?q=feral(소스에는 템플릿이 있다)과 https://www.google.com/search?q%3dferal 모두 실패한다. 신뢰할 수 있는 수정은 이름 없는 템플릿 매개 변수에 설명된 대로 = {{=}}씩 교체하는 것이다. 이것은 위키백과 템플릿 구문에 관한 문제고 지원되지 않는 URL 문자는 문제가 되지 않기 때문에 여기서 언급한다면 변환표 밖에 있어야 한다고 생각한다. 프라임헌터 (대화) 12시 50분, 2012년 3월 7일 (UTC)[]
그럴 만도 하다. 나는 Gadget850의 이 표 버전으로 되돌아갔다. -- John of Reading (토크) 12:59, 2012년 3월 7일 (UTC)[]
3년 전: Prime에 주목하라.템플릿 삭제로 인해 위의 스레드에서 Hunter의 코멘트가 깨졌다.정체성. -- John of Reading (토크) 07:07, 2015년 9월 8일 (UTC)[]
Oh, 나는 자주 Template을 사용해왔다.대부분 미리보기에서 무언가를 테스트하기 위한 정체성. [2]에서 나의 용도는 삭제되었다. 코멘트의 부서진 부분의 새로운 버전: {{{2}}(소스에 템플릿이 여기에 있음)과 https://www.google.com/search?q%3dferal 모두 실패. 프라임헌터 (대화) 2015년 9월 8일 11시 58분 (UTC)[]

HTTPS 변경 사항

나는 이 페이지와 WP가 다음과 같이 생각한다."http"등이 이상 필요하지 않으므로 EL을 업데이트할 필요가 있으며, 링크의 대상(Wikimedia 내에 있는 경우)은 당신이 위키미디어 사이트의 HTTP 버전을 보고 있는지 HTTPS 버전을 보고 있는지에 따라 자동으로 변경된다. It Is Me Here 20:54, 2011년 12월 18일 (UTC)[]

[scroogle.org test] — 링크 코드에 http://(또는 https:///)가 필요한 것 같은데, 그게 나한테 효과가 있으려면?
나는 전혀 아니면 때문에 파이어 폭스와 다른 브라우저들로로 더 이상 대부분의 사람들이 단지 쓸모 없는 스팸이 필요하다 사람들까지 HTTP을 보여 주고 단계적으로 없애기 시작하고 있다 사실 대부분의 사람들이 HTTP를 볼 필요가 있는 유일한 이유는:// 이위키 피디아 같은 사이트 이 풍경이 없는 링크 분석하지 않기 때문입니다. 주인님 같이 카일(Α⇔Ω ¦ ⇒에 동의할 것이다.✉)14:22, 2012년 2월 11일 (UTC)[]
MediaWiki 소프트웨어는 CSS를 사용하여 URI 구성표를 검색하여 링크된 URL로 렌더링합니다(도움말:자세한 내용은 외부 링크 아이콘 - - - - Gadget850(Ed) 15:25, 2012년 2월 11일(UTC)[]
그래, 하지만 왜 기본이 HTTP://가 되지 않는거지?/ 99%의 링크가 그것을 사용하기 때문에, 위키피디아의 규모를 고려해서 사용자가 입력하는 것을 더 즐겁게 만들면 전체적으로 절약되는 공간이 많아질거야. 대부분의 브라우저를 보면 사람들이 HTTP://를 더 이상 입력할 필요가 없고 요즘 Firefox에서는 HTTP://를 적극적으로 숨길 수 있기 때문에대부분의 사람들은 그것을 볼 필요가 없다. 그것은 정말로 일반적인 사용을 위해 그곳에 있어서는 안 된다. 위키피디아와 같은 사이트들이 .com/.net 링크를 링크로 인식하지 못할 때만이 사람들에게 필요한 것이다! Face-smile.svg 요즘 대부분의 포럼과 소셜 네트워크는 .whatever에 대한 어떤 언급도 포착하여 모든 사람들에게 더 나은 연결고리로서 분석한다. Selina Kyle 02:17, 2012년 2월 12일 (UTC)[]
현재 체계를 변경하려면 버그를 지정하십시오. Blackle.com과의 링크가 어떻게 이와 관련이 있는지 모르겠다. ---— Gadget850 (Ed) 12:09, 2012년 2월 12일 (UTC)[]
아, 각각의 위키피디아가 작을 때, 위키피디아의 "http://"의 크기를 고려할 때, 음, 나는 수학을 하지 않았지만 전체적으로 절약된 공간이 많다고 생각해? Face-smile.svg 브라우저가 http://를 단계적으로 폐지하기 시작할 때 확실히 훨씬 더 편리함 --Mistress Selina Kyle 12:22, 2012년 2월 12일 (UTC)
성능은 걱정하지 마십시오. 브라우저는 단순히 URI 계획을 숨기고 있다. ----- Gadget850 (Ed) 12:34, 2012년 2월 12일 (UTC)[]
그래도 그 엄청난 http://를 없앤다면 (성능이 아닌) 사이즈도 좋을 것이다.
그러나 가장 중요한 것은, 브라우저가 http:///를 삭제하기 시작할 때 이것은 사람들이 http://를 보지 않고 자라기 시작할 것이기 때문에, 그리고 좋은 이유로, 정말로, 우리는 무언가를 알고 있기 때문에, 편집자를 위한 참조를 더욱 편리하게 만든다.TLD는 달리 명시되지 않는 한 항상 http이며, 컴퓨터도 이해해야 한다 - 대부분의 소셜 네트워크 사이트는 여전히 위키백과가 2000년대에 있다! --Mistress Selina Kyle, 2012년 2월 15일 (UTC)[]
http://는 URI 체계로, TLD가 아니다. .com 또는 그와 비슷한 것. 다시 말하지만, 브라우저는 URI 계획을 삭제하지 않고 숨길 뿐이다. 더 좋은 방법이 있다면 기능 향상을 요청하십시오. ---— Gadget850 (Ed) 12:14, 2012년 2월 15일 (UTC)[]
알아, 그래서 내가 "뭔가"라고 말한 거야.TLD는 항상 http" - http://에 .가 없음
글쎄, 우리는 DNS가 IP 주소로 변환되는 것도 볼 수 없고, 숨기는 것은 인간에게 좋다. *shrug* -- Mistress Selina Kyle 12:26, 2012년 2월 15일 (UTC)[]

누군가가 괄호와의 연결 행동을 명확히 할 수 있는가?

위키 텍스트 마크업은 마지막 오른쪽 괄호를 특별한 방법으로 처리한다. 고려 사항:

나는 URL이 왼쪽 괄호를 포함하지 않으면 위키피디아가 닫는 괄호를 삭제하는 것이 규칙이라고 생각한다. 이것을 확인할 수 있는 사람이 있는가, 아니면 적절한 문서에 대한 포인터를 줄 수 있는가? Blevintron (대화) 13:35, 2012년 4월 23일 (UTC)[]

MediaWiki는 URI 구성의 URL을 지정된 대로 감지하므로 URI 이전의 문자는 링크에 포함되지 않는다.
인코딩이 필요한 문자는 다음 링크에 포함되지 않는다.
그리고 링크에 일부 등장인물이 포함되어 있고, 귀뚜라미는 그렇지 않다. 나는 왜 그런지 잘 모르겠다.
---- Gadget850 (Ed) 13:49, 2012년 4월 23일 (UTC)[]
확정적인 답변: 포함/파서/파서.php에 따라 makeFreeExternalLink() 함수(1238-1243),
자유 외부 링크의 끝에서 다음과 같은 문자가 벗겨진다: 쉼표 '', 세미콜론 ';', 백슬래시 '\', 마침표 '.', 콜론 ':', 뱅 '!', 물음표 '??'
오른쪽 괄호 '')는 링크에 왼쪽 괄호 '()'가 없는 경우에만 제거된다.
Blevintron (talk) 16:06, 2012년 4월 23일 (UTC)[]
고마워. 인코딩 차트에 업데이트가 좀 필요한 것 같아. ---— Gadget850 (Ed) 19:28, 2012년 4월 23일 (UTC)[]
아니, 이건 인코딩과는 다른 문제야. 이러한 문자는 암호화되지 않은 URL 내에서 허용된다. 내 코멘트는 위키피디아가 URL에서 허용되는 문자에 대한 것이 아니라 링크를 강조하기로 선택한 방법과 관련이 있다. 인코딩 차트를 업데이트하는 것은 잘못된 것이라고 생각한다.
예: http://en.citizendium.org/wiki/Theory_(mathematics)은 유효한 링크이며, 괄호를 빼낼 필요가 없다. Blevintron (talk) 21:57, 2012년 4월 23일 (UTC)[]

지원되지 않는가?

지원되지 않는 문자가 있는 수정 링크의 표에 따라 "문자"」, 【(comma), 【(semic)】, 【(question)】, 【(文)】(질문 표시)는 지원되지 않으므로 인코딩할 필요가 있다. 그러나 내가 볼 수 있는 한 이 세 작품은 원형이 아주 잘 되어 있다. 뭔가 바뀌었거나 텍스트가 지나치게 조심스러웠나? --Lambam 19:40, 2012년 6월 6일 (UTC)[]

아, 무슨 문제인지 알겠어. 맨 url의 끝 부분(대괄호로 묶지 않은 url): 파서는 url의 일부로 구문 분석하지 않는다. 그러나 이러한 목록에 없는 등장인물에도 동일한 문제가 발생한다.

"!", ")," ".", ":" 그리고 "\."

--램밤 20:09, 2012년 6월 6일 (UTC)[]

이 도움말 페이지별로 인코딩되지 않은 공간

어떤 이유에서인지 {{urlencode:test test}}(현재)는 이 도움말 페이지에서 광고한 대로 테스트%20test가 아닌 테스트+테스트를 제공한다. /37.197.83.144 (토크) 14:10, 2013년 7월 31일 (UTC)[]

도움말의 인코딩:외부 URL이 위키백과 마크업 내에서 제대로 작동하도록 하려면 지원되지 않는 문자가 포함된 URL 수정 링크가 필요하다. urlencode 파서함수는 임의의 텍스트를 인코딩하여 URL의 일부가 되도록 하는 목적이 다르다. -- John of Reading (talk) 14:31, 2013년 7월 31일 (UTC)[]
나는 위키백과 마크업 안에 URL을 인코딩하는 것을 의미했다. 그 섹션은 구체적으로 "예를 들어, 공간은 %20으로 교체되어야 한다(파서 함수를 사용하여 이 작업을 수행할 수 있다)"고 명시되어 있다. 그래서 만약 내가 http://test.com?test test에 링크하기를 원한다면, 필요한 url은 [3]이지만, 우리는 urlencode를 제안하는 대로 사용한다. [4] 그래서 urlencode의 속성이 바뀌었고, 도움말 페이지를 업데이트하거나 버그가 몰래 들어와 보고해야 한다. /37.197.83.144 (대화) 15:09, 2013년 7월 31일 (UTC)[]
이제 무슨 말인지 알겠어. 작업은 urlencode 기능으로 수행할 수 있지만 선택적 키워드 중 하나를 사용해야 한다. {{urlencode:test test PATH}} 테스트 %20 테스트. 이것을 분명히 하기 위해 도움말 페이지에 몇 글자를 추가했다. -- John of Reading (토크) 15:23, 2013년 7월 31일 (UTC)[]
아, 설명이 되네 감사합니다 /37.197.83.144 (대화) 16:11, 2013년 7월 31일 (UTC)[]

하이퍼링크로 새 페이지 열기

Wiki의 하이퍼링크는 당신이 있는 페이지를 대체하고, 뒷면 및 앞면 화살표를 사용하여 한번 방문하면 하이퍼링크 위치를 탐색하는 것으로 보인다.

새로운 페이지를 시작하기 위한 하이퍼링크를 지정할 방법이 있는가?

도와줘서 고마워!!! 72.37.249.100 (대화) 18:55, 2015년 1월 9일 (UTC)[]이(가) 추가된 선행 미서명 의견

어떤 브라우저를 사용하십니까? Firefox에서 링크를 마우스 오른쪽 버튼으로 클릭하고 "새 탭에서 링크 열기"를 선택하십시오. 가운데 마우스 버튼으로 클릭하는 것도 이런 작용을 한다. -- John of Reading (토크) 19:08, 2015년 1월 9일 (UTC)[]
(갈등 편집) 위키피디아는 링크를 클릭하는 다른 사람들을 위해 이것을 명시할 방법이 없다. 브라우저에 Ctrl+클릭 또는 Shift+클릭 등의 기능이 있을 수 있음 등록된 사용자는 Special:에서 "새 탭/창에서 외부 링크 열기"를 선택할 수 있다.기본 설정#mw-prefection-gadgets. 프라임헌터 (토크) 2015년 1월 9일 (UTC)[]

짧은 URL

어떻게 하면 트위터를 위한 위키백과 기사의 짧은 URL을 만들 수 있을까? 스눌은 자르려 하지 않았다.Oceanflynn (대화) 2015년 3월 6일 (UTC)[]

snurl이 그것을 자르지 않으면 URL 단축에서 http://tinyurl.com과 같은 다른 서비스를 사용한다.URL 단축 서비스. 나는 방금 테스트로 https://en.wikipedia.org/wiki/URL_shortening을 위한 http://tinyurl.com/7u8sx2y을 만들었다. URL 단축 서비스는 위키피디아에서 외부 링크로 블랙리스트에 올라있기 때문에(좋은 이유로) 클릭 가능한 링크로 tiny.url을 저장할 수 없었다. 프라임헌터(토크) 17:52, 2015년 3월 6일 (UTC)[]
나는 트위터 계정이 없고 그들이 실제로 무엇을 허용하는지 모르지만 만약 여전히 문제가 있다면 물어볼 곳은 위키백과다.참조 데스크/컴퓨팅. 프라임헌터 (대화) 2015년 3월 6일 18:01, (UTC)[]
위키백과 페이지의 왼쪽 창에서 "영구적 링크"를 클릭하면 해당 페이지의 최신 수정본에 대한 링크를 얻을 수 있다. 도움말 참조:영구 링크. 나중에 페이지를 편집해도 링크는 클릭할 때 버전으로 계속 이동한다. URL은 길지만 단축할 수 있다. URL 단축을 위해 나는 현재 https://en.wikipedia.org/w/index.php?title=URL_shortening&oldid=650127212을 받고 있다. 테스트 결과, https://en.wikipedia.org/?oldid=1997212로 줄일 수 있다. 나는 그러한 URL이 계속 작동할 것이라는 보장은 하지 않으며, 만약 어떤 이유로 그 개정판이 삭제된다면 페이지 이름의 흔적도 없이 실패할 것이다. enwp.org은 현재 en으로 리디렉션되어 있다.wikipedia.org (또한 이것이 계속될 것이라는 보장은 없다) 그래서 http://enwp.org/?oldid=197212가 지금 작동하고 있다. 프라임헌터 (대화) 2015년 3월 6일 18:20, (UTC)[]
같은 페이지의 현재 수정본을 원한다면 http://enwp.org/?curid=3919945를 사용해 보십시오. --Redrose64 (토크) 19:51, 2015년 3월 6일 (UTC)[]
좋아. 페이지 아이디를 링크에 사용할 수 있는지 궁금했어. ID는 왼쪽 창에서 "페이지 정보"를 눌러 찾을 수 있다. curid 도움말에 문서화되지 않음:위키백과 페이지의 URL#URL 그러나 mw:수동:파라미터와 인덱스.php. 새로운 페이지는 8자리 ID를 가지고 있다. 프라임헌터 (토크) 2015년 3월 7일 01:00 (UTC)[]
적어도 http://enwp.org?curid=3919945이 작동하는 내 테스트에서 클릭할 때와 브라우저 주소 표시줄에 복사 붙여넣을 때 도메인 뒤의 슬래시도 삭제될 수 있다는 사실이 조금 놀랍다. 얼마나 안정적인지는 모르겠지만 5개의 테스트된 브라우저에서 모두 작동했다. 프라임헌터 (토크) 01:10, 2015년 3월 7일 (UTC)[]
나는 이 페이지에 이것에 대한 언급을 추가했다.[5]프라임헌터 (토크) 00:27, 2015년 3월 9일 (UTC)[]
아마도 위키백과 질의 문자열에 있는 것을 어디선가 언급할 만한 가치가 있을 것이다. oldid= 매개 변수 재정의 curid=, a와 마찬가지로 diff= 숫자 값 및 저 값 curid= 재지정하다 title= --Redrose64 (대화) 14:44, 2015년 3월 9일 (UTC)[]

"드롭핑 http: 및 https:" 섹션은 최근 권장 사항과 모순되는 것으로 보인다.

프로토콜 관련 URL을 사용하기 위해 본 도움말 문서에서 다음과 같이 권고한 것은 구식인 것 같다.

http: 및 https 삭제:

Wikimedia 페이지에서 Wikipedia 페이지를 포함한 다른 Wikimedia 페이지로 대괄호 [...]를 사용하여 외부 스타일 링크를 만들면 프로토콜을 삭제하는 것이 좋다. http: 또는 https:URL이 다음으로 시작되도록 //..., 예: //en.wikipedia.org/w/index.php?title=Help:URL.

그렇지 않으면 독자는 지정된 연결 방법을 사용하도록 강제된다. 만약 당신이 프로토콜을 지정하지 않는다면, 독자들은 그 페이지를 읽기 위해 프로토콜을 계속 사용할 수 있다.

반환된 URL {{SERVER}} 마법의 단어는 //로 시작된다.

  • 예: [//en.wikipedia.org/w/index.php?title=Help:URL no protocol]
  • 결과: 프로토콜 없음(http 및 https로 이 페이지 읽기)
  • 예: [{{SERVER}}/w/index.php?title=Help:URL no protocol]
  • 결과: 프로토콜 없음(http 및 https로 이 페이지 읽기)

위와 달리 도움말:§http: 및 https 링크:

http: 및 https:

2015년 중반, 위키피디아와 다른 모든 위키미디어 사이트는 HTTPS를 사용하여 모든 트래픽을 암호화하도록 변경되었다. 다음과 같은 URL 액세스 http://en.wikipedia.org/wiki/Help:Link 웹 서버가 사용자를 리디렉션할 수 있음 https://en.wikipedia.org/wiki/Help:Link따라서 내부 페이지(즉, 단일 대괄호 또는 베어 URL 사용)에 대한 외부 스타일 링크를 만들 때 https 에서와 같이 불필요한 리디렉션을 피하도록 지정되어야 한다. https://en.wikipedia.org/w/index.php?title=Help:Link&action=history.

과거에는 HTTP나 HTTPS를 통해 위키피디아를 접속할 수 있을 때 프로토콜 관련 URL을 사용하여 외부 링크(또는 내부 페이지에 대한 외부 스타일 링크)를 만들 수 있었다. http: 또는 https: 링크가 표시되는 페이지에 어떻게 액세스되었는지에 따라 다음과 같이 하십시오. [//www.mediawiki.org/wiki/Help:Links]그러나 모든 위키미디어 사이트는 현재 HTTPS를 필요로 하기 때문에 이러한 링크 스타일은 구식이므로 더 이상 사용되어서는 안 된다. http: 또는 https: 대상 사이트에 적합한지 명시적으로 지정해야 함(추적) https:, 가능한 경우).

따라서 여기서 일치하도록 업데이트해야 하는가? 즉, 후자의 블록쿼터의 설명은 실제로 기술적 수준에서 잘못되었다; 현재에는 항상 HTTPS 위키백과 페이지에서 제공되어 사용자가 다른 HTTPS 위키미디어 페이지로 이동하게 할 것이기 때문에 동료 위키미디어 페이지의 프로토콜 관련 URL로 리디렉션이 발생하지 않는다; "https://"와 "/"는 항상 r이 될 것이다.지금, 정확히 같은 요구에 응하고 있다. (음, 적어도 위키미디아가 주최하는 사이트에서 이런 일이 일어나는 한. 즉, HTTP 사이트에 있는 위키피디아의 복사본 중 하나를 탐색할 때 이 둘은 다른 결과를 얻을 수 있다. 또한 사용자가 페이지를 로컬로 저장한 경우, 사용자의 브라우저가 원본 HTML 파일을 저장할 때 URL을 자동으로 완전한 인증된 URL로 변경하지 않는 한, 브라우저가 "file://" 프로토콜로 링크된 페이지를 로드하려고 할 것이다.) —Undomelin (talk) 23:03, 2019년 1월 24일 (UTC)[]

공백으로 밑줄 친다.

나는 여기서 어떻게 브라우저(적어도 내 것)가 공간 대신 _ 캐릭터를 받아들이는지 찾을 수 없었다. 예를 들어보자 - 외부 URL로 당사의 그라비티(2013년 필름) 기사를 참조하십시오.

  • [6] 밑줄로 인코딩된
  • [7] 퍼센트로 인코딩된

일반적으로 두 가지 모두 작동한다고 가정하여 설명서를 업데이트하십시오. CapnZapp (대화) 18:45, 2021년 2월 4일 (UTC)[]

당신의 브라우저가 치료한다. %20 공간과 같은 것, 그리고 유사하게 취급하는 것. %5F 밑줄과 같은 공간과 밑줄을 다르게 취급한다(백분율 인코딩 여부 불문). 이를 동등하게 취급하는 것은 미디어위키 소프트웨어. --Redrose64 🌹 (토크) 19:44, 2021년 2월 4일 (UTC)[]
고맙지만 왜 도움말 페이지가 밑줄이 아닌 %20에 대해서만 말하는지 물어보는 겁니다. (밑줄은 정확히 한 번 언급되는데, 여기서 그 기능은 당연한 것으로 간주된다. 우리는 독자들을 브라우저 전문가와 위키 초보자로 동시에 대해서는 안 된다. 브라우저를 사용하지 않고 위키에서 URL을 사용할 수 없기 때문에, "미디어위키가 아닌 당신의 브라우저"라는 구분은 무관하다. 아니면, 아마도, 무관하지 않을 것이다 - 만약 구별이 중요하다면 언급될 수 있지만, 요점은 우리가 단지 %20을 설명할 수는 없지만 밑줄은 설명할 수 없다는 것이다. CapnZapp (대화) 22:41, 2021년 2월 4일 (UTC)[]