위키백과:스타일/컴퓨팅 설명서(제안 실패)

이 페이지에는 컴퓨터, 소프트웨어, 네트워킹, 인터넷 및 정보 기술에 관한 기사를 작성하고 편집하기 위한 스타일 지침이 포함되어 있다. 다른 정책과 지침도 따라야 하며, 형식 매뉴얼의 일반 규칙도 적용된다.

상표

기본 페이지: 위키백과:스타일/상표 설명서

컴퓨터 기술 상표의 경우, 상표에 관한 위키백과 정책 및 스타일 지침을 준수하십시오. 모든 대문자 또는 모든 작은 글자의 상표에 대해서는 영문 고유 명사와 함께 표준과 같이 초기 대문자를 사용하십시오. 예를 들어 UNIX 대신 Unix. 각 기사의 본문에 이것을 설명할 이유가 없다.

일반적인 실수를 피하십시오.

위키피디아가 아닌 것을 명심해라. 사전이 아니기 때문에 각 용어나 제품이 항상 고유의 글을 얻는 것은 아니다. 종종 그것들은 하나의 고급 백과사전 기사의 주제가 될 수 있는 주제들로 결합된다.

제품 디렉터리

제품에 대한 기사에는 제품의 개발과 주요 개선 내역이 포함되어야 한다. 그러나 위키피디아가 디렉토리도 무차별도 아닌 정신으로, 모든 발표나 업데이트에 대한 완전한 단계별 기록은 피해야 한다. 포함할 세부사항의 수준과 관련하여 상식이 적용되어야 한다.

피쳐 목록은 광고 또는 저작권 위반으로 날짜가 표시되거나 제거될 수 있으므로 기사에만 붙여넣지 마십시오. 상대 시간 참조(예: "현재", "현재" 또는 "지금")는 피하십시오.

버전 대 제품 이름

각 소프트웨어 제품 버전은 가장 일반적인 이름으로 참조되어야 한다.

소프트웨어 공급업체는 소프트웨어 제품의 특정 버전을 참조하기 위해 종종 다음 방법 중 하나를 사용한다.

  1. 참조에 버전 번호(예: WinRAR 4, WinRAR 버전 3 및 WinRAR v2)가 포함되어 있다.
  2. 이들은 각 릴리스(예: Windows Vista 및 Windows 7)에서 제품 이름을 변경한다.

비디오 게임은 이 계획에 반전을 더한다. 비디오 게임 판매상들은 종종 그들의 가장 주목할 만한 제품들을 위해 속편과 프리퀄을 만든다. 그들은 그들의 관계를 보여주기 위해 비디오 게임 타이틀에 숫자를 사용한다. 예를 들어, 적색 경보 2와 적색 경보 3은 구별되지만 관련된 비디오 게임이다. 그러나 제목의 일부인 번호는 버전 번호가 아니다. 별도의 버전 번호를 여전히 사용할 수 있다. 예를 들어, Red Alert 2 v1.008은 Red Alert 2의 업데이트된 버전이다.

가장 일반적인 제품 이름을 일관되게 사용 예를 들어 윈도우즈 v5.1 또는 윈도우즈 NT v5.1이 아닌 윈도우즈 XP를 사용하십시오. 이러한 방법을 혼동하고 결합하지 마십시오. 예를 들어, 적색 경보 v2 또는 적색 경보 버전 2를 사용하여 적색 경보 2를 참조하지 마십시오. 새로운 짧은 형태와 약어를 발명하지 마라.

서비스 팩

서비스 팩이나 서비스 릴리즈는 버그를 고치거나 개선하도록 다른 컴퓨터 소프트웨어를 수정하는 컴퓨터 소프트웨어다. 서비스 팩을 언급할 때는 서비스 팩을 통해 서비스되는 소프트웨어 제품 버전과 서비스 팩 자체를 적절히 구분하십시오.

서비스 팩을 참조하려면 서비스 팩의 전체 이름을 입력하십시오. 예를 들면 다음과 같다.

  • Windows XP 서비스 팩 2
  • WinZip 9 서비스 릴리스 1

서비스 팩으로 업데이트된 소프트웨어 제품을 참조하려면 [서비스 팩 이름]을(를) 사용하여 [제품 이름]을(를) 기록하십시오. 예를 들면 다음과 같다.

  • Windows XP(서비스 팩 2 포함)
  • WinZip 9(서비스 릴리스 1 포함)

또는 해당하는 경우 소프트웨어 제품의 버전 식별자를 지정하여 구체화하십시오. 예를 들면 다음과 같다.

  • 윈도 XP SP2
  • WinZip 9 SR-1

이 두 가지 스타일 중 하나만 기사 전체에서 일관되게 사용하도록 하라. 두 가지 형태를 모두 사용하는 것은 독자들이 두 형태가 동일한 실체를 참조한다는 것을 이해하지 못할 수 있기 때문에 거의 기술적 지식이 없는 독자들을 혼란스럽게 할 수 있다. 그러나 두 가지 형태가 주류 미디어에서 자주 사용되는 경우(마이크로소프트 윈도 서비스 팩의 경우처럼) 기사는 두 가지 형태를 모두 소개하고 관계를 정립한 후에야 비로소 일관되게 하나를 사용할 수 있다.

x86 대 IA-32

바로 가기

"x86"이라는 용어를 사용하는 동안 주의를 기울이십시오. 이는 모호성을 야기할 수 있기 때문이다. x86은 인텔이 처음 개발한 CPU의 일종이며, 나중에 다른 사람들이 개발한 CPU의 일종이다. 널리 사용되는 x86에는 IA-32와 x86-64의 두 가지 다른 변형이 있다. 그러나 IA-32의 우세로 인해 'x86'이라는 용어는 흔히 메타니를 통해 IA-32를 가리키는 말로 쓰인다. 따라서 이러한 용어는 주의하여 사용해야 한다.

사용 예
올바른 사용법 잘못된 사용 메모들
"이 컴퓨터 프로그램은 IA-32 또는 x86-64로 실행된다." "이 컴퓨터 프로그램은 x86이나 x86-64로 운영된다." x86-64는 x86 변종 중 하나이기 때문에 "x86 또는 x86-64"라고 쓰는 것은 기껏해야 중복된다.
"이 컴퓨터 프로그램은 IA-32에서 실행되지만 x86-64는 실행되지 않는다." "이 컴퓨터 프로그램은 x86에서 실행되지만 x86-64는 실행되지 않는다." x86-64는 x86이기 때문에 "x86은 아니지만 x86-64는 자기 모순이다.
"이 컴퓨터 프로그램은 x86, ARM 및 PowerPC에서 실행되며" "이 컴퓨터 프로그램은 x86에서 실행된다" x86, ARM 및 PowerPC는 호환되지 않는(상호 배타적인) CPU 아키텍처이므로 정확도가 더 기술적인 맥락에서 충분하지 않을 수 있지만 교차 아키텍처(매크로스코픽) 수준에서 비교하는 것은 정확하다. 다만 'x86'만으로는 애매하기 때문에 추가 예선 없이 사용해서는 안 된다.

32비트 및 64비트

컴퓨터, CPU 또는 소프트웨어 아키텍처를 지칭하는 데 "32비트", "64비트" 또는 기타 비트 길이의 용어를 사용하지 마십시오. 이 용어들은 너무 모호하고 많은 모호성이나 잘못된 정보를 야기할 수 있다.

이러한 용어는 흔히 잘 알려진 두 가지 CPU 아키텍처 유형, 즉 IA-32(x86의 32비트 변종)과 x64(x86의 64비트 변종)를 가리키는 데 사용된다. 그러나 IA-32는 세계에서 유일한 32비트 CPU 아키텍처도 아니며 x64는 사용 가능한 유일한 64비트 CPU 아키텍처도 아니다.

올바른 사용 예:

  • "이 소프트웨어 애플리케이션은 x64 CPU에서만 실행된다."
  • "이 제품의 IA-64 에디션 [...]"
  • "질로그 Z80과 호환 가능한 CPU를 위해 특별히 만들어진 .z80 빌드 [...]"

잘못된 사용의 예:

  • "이 소프트웨어 애플리케이션은 64비트 CPU에서만 실행된다."
  • "이 제품의 32비트 에디션 [...]"

Linux 대 GNU/리눅스

지름길
참고 항목: 토크:리눅스/아카이브 41 § 페이지 이동: GNU/리눅스 및 토크:Linux/이 기사 참조

리눅스 커널을 기반으로 하는 운영 체제 제품군을 나타내려면 "GNU/리눅스" 대신 "리눅스"를 사용하십시오. "GNU/리눅스"라는 용어는 여전히 개별 운영 체제와 리눅스 배포판의 적절한 이름의 일부로 쓰일 수 있다.

GNU/리눅스 명명 논란은 존재하며, 'GNU/리눅스'는 자유소프트웨어재단(FSF)이 주창하는 명칭이다. 그러나 위키피디아는 가장 일반적으로 사용되는 이름을 선호한다(신뢰할 수 있는 영어 출처의 만연에 의해 결정됨). Talk에서 토론의 합의:리눅스/이름은 FSF의 관점이 일반적인 영어 사용이 아니라는 것이다.

Oft-neglected source

기본 페이지: 위키백과:검증 가능성과 위키백과:신뢰할 수 있는 소스 식별

위키피디아에서는 소프트웨어 출시 날짜, 소프트웨어 패키지 크기, 지원되는 언어의 이름과 수, 소프트웨어 제품 개발에 사용되는 프로그래밍 언어를 포함하되 이에 국한되지 않는 모든 것이 출처를 필요로 한다. "다국어", "C++" 또는 "Windows용으로 개발"을 포함하되 이에 국한되지 않는 비참조 주장을 피하십시오.

정렬

이상한 형태의 언어를 사용하지 마십시오. 반대로, 편집자들은 독자들이 편안함을 느끼도록 하기 위해 가장 흔히 사용되는 형식을 고수해야 한다. 단지 동의어라고 해서 특정 단어의 동의어를 사용하지 마십시오. 조합은 매우 중요하다.

예를 들어,

  1. 더 이상 개발되지 않은 컴퓨터 프로그램을 "유기화"라고 부른다. "잊혀진 소프트웨어" 또는 그런 새로운 용어를 사용하지 마십시오. (버너웨어 참조)
  2. 소프트웨어 제품의 개발을 중단하는 행위를 「해체」라고 한다. "폐기" 또는 이와 유사한 외래어를 사용하지 마십시오. (소프트웨어 릴리스 사이클 및 수명 만료(제품) 참조)
  3. 컴퓨터 프로그램은 특정 운영 체제나 플랫폼에서 실행된다. "아래로 실행" 또는 "아래로 실행"을 사용하지 마십시오.
  4. 컴퓨터 프로그램은 사용자 계정의 컨텍스트 또는 컨텍스트 내에서 실행된다. "밑", "편익", "온", "내부" 또는 "오버"를 사용하지 마십시오. 이러한 변형은 격식어로는 괜찮지만, 위키백과는 다음과 같다.특집 기사 기준은 전문적인 스타일의 사용을 요구한다.
  5. "로그온", "로그인", "로그인" 및 "로그인"은 모두 "인증용 공급 자격 증명"을 의미하는 동사들이다. 그러나 사용자는 "컴퓨터에 로그온"하거나 "컴퓨터에 로그인"한다. 그들은 결코 "컴퓨터에 로그인"하지 않는다. "로그인"은 인터넷을 통한 인증에만 사용된다.[a] (로그인 참조)
  6. "Disc"와 "Disk"는 모두 디지털 저장 매체를 가리킨다. 그러나 "디스크"는 콤팩트 디스크와 블루레이 디스크에서처럼 광학 미디어와 결합하고, "디스크"는 하드 디스크와 플로피 디스크에서처럼 자기 미디어와 결합한다.

긴장하다

바로 가기
참고 항목: 위키백과:스타일 매뉴얼 § 동사 시제

설명 제목(예: 프로그램, 라이브러리, 장치)이 더 이상 존재하지 않거나 지원되지 않거나 유지되지 않는 경우에도 장르, 유형 및 클래스를 설명하는 동사에 항상 현재 시제를 사용하십시오.

다음 예는 부정확하다.

  • TrueCrypt는 TrueCrypt Foundation이 출시한 디스크 암호화 프로그램이다.

이 문장은 TrueCrypt가 한때는 그랬지만 디스크 암호화 프로그램이 아님을 시사한다. (TrueCrypt는 개발 수명주기 동안 그 성격을 바꾼 적이 없다고 가정한다. 문법적 삭제는 이 문장에 두 개의 "있을" 동사가 있다는 사실을 숨긴다. 그러나 더 이해하기 어려운 사실은 이 두 "있을" 동사가 문법적으로 다르다는 것이다. 첫 번째 동사는 지속시간 내내 변하지 않는 고정동사인 반면 두 번째 동사는 중단이 발생하는 지속시간 이후에 유효하지 않을 수 있는 동적 동사다.

다음 중 어느 것이 더 적절한지를 사용하십시오.

  • TrueCrypt는 단종된 디스크 암호화 프로그램이다. 트루크립트 재단이 출시했다.
  • TrueCrypt는 TrueCrypt Foundation이 출시한 디스크 암호화 프로그램이다.

선택적 스타일

참고 항목: MOS:STATION

중재 위원회는 편집자들이 단순한 스타일의 선택과 무관한 실질적인 이유 없이 하나의 가이드라인으로 정의된 스타일에서 다른 스타일로 기사를 변경해서는 안 된다고 판결했다. 선택적 스타일에 대한 리턴-워링은 허용되지 않는다.[b] 기사에서 사용할 스타일 중 어느 것을 사용할지에 대해 의견이 일치하지 않는 경우, 현상을 유지하십시오.

따라서 다음 사항에 대한 분쟁은 피하십시오.

  • 개념에 대한 여러 동의어 중 하나 선택(예: "쉐어웨어", "trialware" 또는 기타 동의어, "x64" 또는 "x86-64", "수용 소프트웨어" 또는 "폐쇄 소스")
  • 동일한 개념에 한 단어 또는 많은 단어 사용(예: "x86" 또는 "IA-32 및 x64")
  • 오름차순 또는 내림차순 정렬
  • 모든 것이 동일한 위치를 가리키고 없는 여러 URL 중 하나를 삽입하면 다른 URL에 비해 이점이 없음
  • 동일한 것의 다른 여러 형태들

소프트웨어 스크린샷

기본 페이지: 위키백과:소프트웨어 스크린샷

명령줄 요소

바로 가기

본 절에서는 셸 명령어 또는 프로그램의 구문을 포함하여, 위키백과 기사에 터미널 또는 명령줄 통역사의 요소를 통합하기 위한 지침을 개략적으로 설명한다.

일반 지침

  • 명령줄 예를 제공하거나 명령줄 요소에 대해 논의할 때는 명확성과 단순성을 유지하십시오.
  • 명령줄 요소는 단일 글꼴로 표시되어야 한다. 인라인 참조의 경우 <code>...</code> 꼬리표를 달다 여러 줄의 명령줄 코드를 표시하는 경우 각 줄에 공백 문자를 접두사하거나 모두 다음 문자로 묶으십시오. <pre>...</pre> 꼬리표를 달다
  • 환경 변수, 날짜, 작업 디렉토리, 사용자 이름 및 호스트 이름이 예에 관련되지 않는 한 참조하지 마십시오.
  • 다음 용어를 준수하십시오.
    • 옵션이나 스위치는 명령의 일반적인 동작을 수정하는 것이다.
    • 매개 변수는 파일 이름 또는 호스트 이름과 같은 특정 값이다.
    • 인수는 옵션과 매개 변수를 모두 포함하여 명령 이름을 따르는 모든 문자 집합이다. 매개변수(컴퓨팅) § 매개변수 및 인수를 참조하십시오.
  • 논거를 제시할 때 단순성을 유지하십시오. 필요한 경우에만 논거를 명료하게 명시하십시오. 위키피디아는 수동 페이지를 대신하는 것이 아니라는 것을 기억하라. 명령어와 관련된 전체 옵션 목록을 문서화하지 마십시오(백과사전적 목적이 있는 경우).
  • 기울임꼴로 논리적 이름을 가진 매개변수 자리 표시자를 식별하십시오. 이 이름에는 공백이 명령줄에서 여러 인수를 구분하는 데 사용되므로 공백을 포함하면 안 된다. 몇 가지 예는 다음과 같다.
    • (prompt) command parameter-name
    • (prompt) command ParameterName
    • (prompt) command parameter_name
    • (prompt) command parametername
  • 선택적 인수를 대괄호 [ 및 ]로 묶으십시오.
  • 다음 스타일 중 하나를 사용하여 반복 매개변수를 지정하십시오.
    • (prompt) command parameter0 [.. parameterN]
    • (prompt) command [parameter ...]
  • 전체 기사에 대해 위에서 설명한 선택적 스타일을 적용함에 있어 일관성을 유지한다.

플랫폼별 가이드라인

마이크로소프트 윈도

오늘날 사용되고 있는 가장 일반적인 데스크톱 운영 체제는 MS-DOS와 OS/2에 기반을 둔 Microsoft Windows인데, 한때는 명령줄 구문이 MS-DOS와 OS/2에 기반을 두었지만, Windows PowerShell의 인기가 높아지면서 유닉스 같은 시스템과 프로그래밍 언어의 그것 쪽으로 스타일이 옮겨갔다. 따라서 명령줄 요소에 대한 DOS 및 OS/2 지침과 명령 프롬프트 및 복구 콘솔의 예를 따르십시오. 그러나 Windows PowerShell의 경우 아래의 Unix와 유사한 시스템 및 Windows PowerShell 지침을 준수하십시오.

CP/M, DOS 및 OS/2

다음 추가 지침은 CP/M, DOS 및 OS/2 운영 체제 제품군의 명령줄 예에 대한 것이다.

  • 내부 또는 외부 명령어 이름, 파일 및 디렉토리 이름(8.3 스키마에 맞는 한) 및 환경 변수 이름을 모든 대문자(예: DIR, AUTOEXEC.BAT 또는 %PROMPT%).
  • DOS 및 OS/2(및 Windows)는 원칙적으로 두 가지 백슬래시를 모두 지원하며,\) 및 슬래시()./디렉터리의 구분 기호로 일부 프로그램(기본 구성에 있는 대부분의 셸 포함)은 백슬래시만 지원한다. 따라서 달리 표시하는 것이 중요하지 않은 경우 로컬 볼륨의 디렉터리 경로 예제에서 백슬래시를 사용하십시오.
  • 다양한 DOS 시스템은 사용자가 구성할 수 있는 SwitChar(일반적으로 슬래시(forward slash)를 지원한다./) 또는 하이픈(hypen-hypens) (-)), 그러나 모든 프로그램이 이를 준수하는 것은 아니다. 따라서 프로그램이 이를 지원하는 경우 기본값을 사용하십시오. / 다른 표시를 하는 것이 중요하지 않다면, 예를 들어.
  • 표준 옵션(양식) /C 또는 -C, where C 대소문자를 구분하지 않는 한, 대소문자를 구분해야 한다.
  • 파일 확장명을 추가하여 프로그램 이름을 내장 명령 이름과 대조하십시오. 프로그램이 특정 버전에 포함되지 않은 경우(예: XCOPY.EXE 또는 EDIT.COM() 그런 다음 포함되었다고 알려진 버전을 표시해야 한다.

Unix와 유사한 시스템 및 Windows PowerShell

  • 셸 기본 제공 명령 및 cmdlet(예: cd 및 history)는 다음과 같이 표시되어야 한다.
  • 유닉스 유사 시스템 전체에 걸쳐 쉘의 변동이 크기 때문에 가능하면 쉘별 명령이나 유틸리티(예: 루프 또는 특정 스트림 동작용)를 사용하지 마십시오. 적절한 설명을 위해 셸 고유 시퀀스가 필요한 경우, ALGOL 유사 셸(Bourne shell, Korn shell, Bash)뿐만 아니라 C 셸과 tcsh의 C 유사 구문에 대한 예도 제공한다.
  • 쉘의 대/소문자 구분 요구 사항을 준수하십시오. Unix 유사 시스템의 대부분의 명령어는 모두 소문자로 되어 있는 반면 셸과 운영 환경은 모두 대소문자를 구분한다. Windows PowerShell은 대소문자를 구분하지 않으므로 읽기 및 암기를 쉽게 하기 위해 자연 영어 형식으로 cmdlet 이름을 입력하십시오. Unix에서 파생된 별칭(예: ls 및 cp)을 소문자로 쓰십시오. 필요한 경우 소문자 제목 또는 잘못된 제목 템플릿을 사용하십시오.
  • 일반적으로 권한 있는 액세스가 필요한 명령과 그렇지 않은 명령을 구분하십시오.
  • 어떤 경우에는 매개변수 값이 일반적으로 쉘 메타카락터를 포함할 것이다. 이 경우 사용자가 자신에게 이상하고 관련이 없어 보이는 오류를 수신하지 못하도록 예에 인용문을 명시하는 것이 현명할 수 있다.
  • 항상 명령을 지원하는 셸의 최소 버전 번호(해당되는 경우 최대 버전 번호)를 지정하십시오. Linux(오픈 소스 속성에 부합)와 Windows PowerShell은 언제든지 새로운 명령을 도입할 수 있다.

샘플 출력 제공

명령어가 생성하는 출력의 샘플을 제공하는 것이 종종 유용할 수 있다. 이 경우 전체 명령어와 입력된 모든 인수가 주어진다. 따라서 명령의 출력은 환경 및 기타 변수에 한정될 것이다. 태그 <pre>...</pre>, <nowiki>...</nowiki> , 그리고 <SyntaxHighlight>...</SyntaxHighlight> (적절한 주장으로) 위키 마크업 구문과의 충돌을 방지한다.

사용 예

DOS 예제

DOS에 있는 DIR 내장 명령으로 파일 및 디렉터리 나열: 

> DIR [옵션] [패턴 ...]

MOVE 프로그램.MS-DOS에 대한 EXE, 도입 전에 행동을 에뮬레이션해야 하는 경우: 

> MOVE.EXE 소스 대상

Unix 예제

파일과 디렉터리를 나열하는 Unix 유사 시스템의 ls 명령: 

$ ls [file ...]

새 파일 시스템을 생성하는 mkfs 명령. 대개 특권적 접근이 필요하므로, 즉석문자는 # 대신에 $ 

# mkfs [-t fstype] [fs-fs] 장치

GNU 유틸리티 중 하나인 wget 프로그램. URI(Uniform Resource Identifier)가 지정된 파일을 검색한다. URI는 때때로 셸 메타캐릭터를 포함할 수 있으므로, 일반적으로 오류를 방지하기 위해 매개 변수를 인용한다. 

$wget [옵션] "URI"

구문이 다른 if-in 구조. 본 셸, 코른 셸 및 바쉬: 

$ if command; then command; ... fi; fi

C shell 및 tcsh: 

% if (reason) then command; ... 엔디프

마운트된 파일 시스템의 디스크 공간 사용량을 나열하는 df 명령의 샘플 출력: 

$ df -P 파일 시스템 512 블록 사용 /dev/hda2 39331760 7398904 29834768 20% /

면허증

컴퓨터 프로그램 기사의 주제의 라이센스 용어를 정확하고 간결하게 명시해 보십시오.

라이센스 계약은 일반적으로 다음 중 하나 이상을 지정한다.

  1. 사용 환경(예: 상업, 비상업, 개인, 교육, 비군사 등)
  2. 사용비용(예: 무료, 일회성 결제, 가입 기반 등)
  3. 적용 가능한 라이센스 소유자(예: 무제한, 컴퓨터 1대, 컴퓨터의 사용자 계정 1대, 사용자 1대, 볼륨 라이선스 등)
  4. 기타 권리(예: 학습권, 수정권, 역설계자 등) 또는 제한(예: 음란물 제작을 위한 사용권)

위키피디아는 가장 일반적인 소프트웨어 라이센스 제도에 대한 기사를 가지고 있다. 따라서 대부분의 경우, 인포박스에서 한두 개의 위키링크가 있는 단어들은 라이선스 제도를 설명할 수 있다. 예를 들어 GPL, Freemium, BSD 라이센스 또는 독점 상용 소프트웨어(Write: [P수용 소프트웨어 독점] [상업 소프트웨어]). "벤더의 EULA", "다중" 및 "알 수 없음"과 같은 모호하거나 완전히 비정보적인 문구는 피하십시오.

웹 사이트 주소

지름길
참고 항목: 위키백과:스타일/링크 설명서

노출 URL

인포박스와 같은 위키피디아의 특정 영역은 웹사이트 주소(URL)가 인쇄물에 노출될 것을 요구한다. 가독성과 정확성을 유지하기 위해 웹 주소의 특정 부분을 숨기거나 더 짧은 양식을 사용해야 할 수 있다.

웹 주소는 여러 부분으로 구성되며, 가장 흔히 볼 수 있는 몇 가지 예를 보여 준다.

계략 FQDN(정규화된 도메인 이름) 부탁한다
http:// www.wikimedia.org /
http:// windows.microsoft.com /en-US/internet-explorer/products/ie/home
https:// commons.wikimedia.org /wiki/Main_Page

그러나, 웹 브라우저와 웹 서버의 유추 능력 덕분에 독자는 이러한 다소 매력적이지 않고 기억하기 어려운 모든 아이템을 볼 필요가 없다. 흔히 다음과 같은 부분을 생략할 수 있다.

  1. 구성표: 생략 http:// 기본 링크가 아닌 표시된 URL에서 {{URL}} 템플릿은 자동으로 이 계획을 숨긴다. 다음과 같은 다른 계획 https:// , 그리고 ftp:// 남아야 할 필요가 있어라.
  2. 요청: 요청 부품이 단일 슬래시 문자일 때(/), 생략; {{URL}} 템플릿은 자동으로 이것을 숨긴다. 사용자는 유일한 요청 사양으로 단일 슬래시 문자를 생략하고 URL이 제대로 작동하기를 기대하는 경우가 많다.

누락은 기능성이 제한되지 않은 경우에만 제재된다. 항상 결과 URL을 테스트하십시오. 드물지만 www. 또는 / 필수 사항. 향후 편집자에게 알리기 위해 보이지 않는 위키 마크업 코멘트를 남길 것을 권장한다.

대상 웹 사이트 공급자가 웹 페이지에 더 짧은 대체 URL을 제공한 경우 해당 URL을 사용하십시오. 이 인스턴스의 유일한 예외는 기억하기 어려운 숫자를 사용하는 짧은 URL이다. 예를 들어,

다음 사항이 유효할 경우... ...다음 사항을 설명하다.
microsoft.com/ie windows.microsoft.com/en-US/internet-explorer/products/ie/home
https://commons.wikimedia.org/ https://commons.wikimedia.org/wiki/Main_Page
beautyoftheweb.com go.microsoft.com/fwlink/?LinkId=214371

bit.ly과 같은 URL 단축 서비스를 사용하지 마십시오. 그러한 URL은 독립된 실체에 의해 유지되며 링크 부패에 취약하다. (또한 참조: URL 단축 § 단점)

HTTP 및 HTTPS 선택

링크된 웹사이트가 HTTP 프로토콜과 HTTPS 프로토콜을 통해 콘텐츠를 서비스하는 경우, 즉, 웹 사이트가 모두 포함된 URL을 수신한다. http:// , 그리고 https:// 스키마, 다음을 준수하십시오.[c]

  • 사용하다 https:// HTTPS를 통해서만 콘텐츠를 서비스하거나 HTTPS와 HTTP를 모두 지원하는 사이트에 대한 구성표. 여기에는 또한 수락하는 웹 사이트도 포함된다. http:// 주소를 리디렉션하지만 https://.
  • 사용하다 http:// HTTPS를 전혀 지원하지 않는 사이트에 대한 구성.
  • 위키피디아는 이전에 HTTP와 HTTPS를 모두 지원하는 사이트에 프로토콜 관련 링크를 사용했다(예: https://example.com/이나 http://example.com/) 대신 //example.com/). 그러나 위키백과 자체가 HTTPS를 필요로 하기 때문에, 이것은 이제 더 이상 사용되지 않는다.

참고 항목

노트

  1. ^ 윈도 8은 처음으로 "로그인" 대신 "로그인"을 사용했지만 2012년 10월 현재 이 예외는 무시할 수 있는 소수민족으로 남아 있다.
  2. ^ 위키백과 참조:중재 요청/제국 § 원칙, 위키백과:중재/jguan 2 § 원칙 및 위키백과에 대한 요청:중재/소탄 § 원칙 요청
  3. ^ 원래의 논의는 위키백과에서 찾을 수 있다.마을 펌프(정책)/아카이브 111 § WP가 HTTPS를 사용하는 것처럼 (일부) 외부 링크도 사용해야 하는가?