대화:대소문자 구분

사용자 이름

언제부터 사용자 이름이 대소문자를 구분하는가? 대부분의 시스템에서 나는 사용자 이름이 케이스를 잊어버린 사용자처럼 많은 문제를 피하기 위해 대소문자를 구분하지 않는다는 것을 안다. 다노브레가 추가(토크 기여) 08:54, 2010년 9월 8일(UTC)[]

11월

사례 민감도에 대한 정보/토론은 Wikimedia( 위키백과의 백본): http://meta.wikimedia.org/wiki/Case_sensitivity. rs2 22:30, 2005년 11월 19일 (UTC)[]


이것은 잘못된 것이다: "...독일어에는 날카로운 s("ß"")에 대한 대문자 형식이 없다. 날카로운 s의 대문자 형태는 "SS"이다. 기사 윗부분의 편집 버튼을 찾을 수 없어서 내가 직접 수정할 수 없어.


나는 위키피디아 자체가 사례를 박살내기 위해 자원봉사를 하는 것을 무시하는 것을 본다. 예를 들어, 사례 민감성과 사례 민감성이 같은 기사가 아닌 것은 아니다.

위키피디아를 주최하는 서버의 작업을 눈에 띄게 줄인 중요한 예와는 별개로, 위키피디아에 사건을 무마하는 것이 실제로 사람들을 돕는 예가 있는가?


브리온 당신은 내가 일종의 반미 나치라고 생각할지도 모른다 :-)

왜 그럴까? 대소문자 구분은 아마도 사례를 보여주는 글쓰기 시스템의 아주 작은 부분을 사용하는 모든 언어에 공통적일 것이다. --Briion

페이지 제목은 대소문자를 구분한다는 것을 알았다(첫 번째 글자 제외). 그러나 그것에 대한 어떤 설명도 찾지 못했다. 여기선 완전히 주제와 동떨어진 얘기일 수도 있지만, 그게 말이 돼? 그 주제에 대해 어떤 토론이나 설명이 있는데, 나는 그것을 찾지 못했어?

감사합니다, 사용자:닐스비

하이픈에 민감한

나는 "대소문자 민감도"가 옳다고 생각하겠지만, 형용사나 부사로써 "대소문자 구분"과 "대소문자 구분"등이 되지 않을까?양육의 별종 (토크x) 04:59, 2005년 11월 2일 (UTC)[]

동의한다. 두 단어를 하나의 형용사로 사용할 때는 하이픈이 필요하다. 닥스훈2k3 (토크) 02:04, 2008년 9월 30일 (UTC)[]

대소문자를 구분하는 웹 검색 엔진?

여기가 이런 걸 요구하는 정확한 장소는 아닐지 모르지만, 나는 사례에 민감한 웹 검색을 해야 해서 생각해냈어. 아무 것도 없어요.

구글만큼 이 기능이 부족하다. 알타 비스타는 아마 이것을 가지고 있었을 것이지만, 더 이상 가지고 있지 않다. 좋은 의견이라도 있나? 위키피디아에 대한 내용은? 오늘 밤 (2009년 12월 8일) 이 기사를 방금 보았는데, 필자는 이 기사가 구글을 대소문자를 구분하지 않는 검색 엔진으로 언급하지 않아 대문자 또는 소문자로 입력하면 구글에서 대소문자를 구분할 수 있을 것으로 알고 매우 놀랐다. 이것은 구글에서 오랫동안 내가 이해한 것이다. 그렇지 않은가? ACEOREVIVEED (토크) 22:14, 2009년 12월 8일 (UTC)[]

CaseSensitiveSearch.com 참조 — 108.168.232.255(토크) 02:55, 2013년 5월 10일(UTC)[]이(가) 추가된 선행 서명되지 않은 주석

반달리즘

이 기사가 왜 마지막 날이나 2일 동안 그토록 많은 반달리즘의 표적이 되었는지 감히 추측할 수 있는 사람이 있는가? - smjg (대화) 22:17, 2008년 10월 29일 (UTC)[]

MediaWiki에서 연결됨:문서 텍스트 없음, MediaWiki:(리디렉션 대/소문자를 구분하여) NoexactmatchMediaWiki:2008년 10월 25일에 생성된 Noexactmatch-nocreate (Through case sensitive) 따라서 이 시스템 메시지의 가시성은 대소문자 구분 교통량[1]의 중요한 증가를 설명할 수 있지만 대소문자 구분 교통량만 상대적으로 감소할 수 있다. 이것은 누적된 교통량 그리고 그래서 이곳의 공공 기물 파손의 수준을 설명한다. 세나륨 01:39, 2008년 11월 1일 (UTC)[]

웹 사이트 주소가 대소문자를 구분하는지 여부

대/소문자 구분 데이터의 예시 목록 아래 웹 사이트 주소가 나열되는 이유를 헷갈린다. 도메인 이름은 대소문자를 구분하지 않지만, 나는 웹 호스팅 소프트웨어에 따라 페이지 이름이 대소문자를 구분할 수 있다고 믿는다. example.com은 예시와 같다.COM, 그러나 example.com/index.html이 반드시 example.com/INDEX.HTML과 같지는 않을 수 있다.

나는 웹 사이트 URL이 혼동을 일으킬 수 있기 때문에 여기서 삭제되어야 한다고 생각한다. Good morning2255(대화 기여) 03:48, 2010년 2월 13일(UTC)[]에 의해 서명되지 않은 코멘트 추가

일반적으로 URL은 대소문자를 구분하며, 다음과 같은 여러 가지 카운트:
  • 많은 웹 서버는 유닉스 기반이어서 파일 시스템은 대소문자를 구분한다.
  • 임의의 쿼리 문자열은 URL의 일부분이며, 일반적으로 말하면 대소문자를 구분한다.
  • 대/소문자를 구분하지 않는 파일 시스템에서도 서버측 또는 클라이언트측 스크립팅은 페이지에 액세스하는 자본화를 사용할 수 있다.
  • 쿼리 문자열을 제외하더라도 URL은 실제 파일 이름과 일치하지 않을 수 있으므로, 서버는 해당 파일 시스템이 대/소문자를 구분하는지 여부에 관계없이 URL을 대/소문자를 구분하거나 구분하지 않는 것으로 취급할 수 있다.
  • 주어진 웹사이트의 경우 이 중 어느 것도 해당되지 않더라도, 사용자 에이전트는 이를 알지 못하므로 페이지.html, 페이지를 취급해야 한다.HTML 및 페이지.HTML을 구별하십시오.
어쨌든 헷갈리는 진술을 처리하는 방법은 그것을 제거하는 것이 아니라(아마도 임시방편일 수 있음은 제외한다) 혼란을 피하기 위해 어떻게 써야 할지 방법을 강구하는 것이다. --smjg (대화) 13:36, 2010년 5월 3일 (UTC)[]

QBASIC은 대소문자를 구분한다고 하는데 - 확실히 틀렸다!

또는 "대소문자 구분"이 무엇인지 이해할 수 없다.

QBASIC IDE에서 입력 가능

X=10
x를 인쇄하다

그런 다음 마지막 줄에서 Enter 키를 누르고 마지막으로 사용된 케이스(x)로 변환된 X의 모든 인스턴스를 누르십시오. (그리고 그것을 실행하면 10개가 인쇄된다)

IDE 외부에서 이러한 프로그램을 만들면 로딩 시 변환된다.

(대소문자 구분 Basics의 예로서 나는 Liberty Basic / Just Basic을 인용할 수 있다. 그 안에서, 위의 프로그램은 "있는 그대로" 유지한 다음 실행하면, 0 (x가 정의되지 않았기 때문에) 212.92.128.7 (토크) 06:24, 2010년 4월 22일 (UTC)[] 인쇄한다.

대소문자 구분

스타트랙: 보이저 소설에서, 등장인물 중 한 명이 여성 Q를 만나 Q. "아니, 난 Q야"라고 묻자, 그녀는 "더 낮은 케이스가 들리지 않니?"라고 대답한다. 하급 사건을 어떻게 들으라는 겁니까? JIP Talk 22:01, 2011년 11월 9일 (UTC)[]

그녀는 Q야, 물론 소문도 들을 수 있지. 가이 해리스 (대화) 23:41, 2017년 12월 3일 (UTC)[]

2012년 11월 9일 요청 편집

섹션 제목 변경: 인도 정부의 컴퓨터 시스템을 사용하여 다음을 실현하십시오. 컴퓨터 시스템에서 사용 이유: 분명히 인도는 이 주제와 아무 관련이 없으며, 이 제목 외에 다른 곳에는 인도에 대한 언급이 없다. 아부야클 (대화) 2012년 11월 9일 19:21 (UTC)[]

됐어. 이전에 잡히지 않았던 오래된 반달리즘을 되돌렸어. 위키피디아의 발전을 도와줘서 고마워.KuyaBrieBrieTalk 20:05, 2012년 11월 9일 (UTC)[]

Windows - NTFS

"NTFS와 같은 현재 Windows 파일 시스템은 대/소문자를 구분하며, 이는 Readme입니다.txt와 readme.txt는 동일한 디렉토리에 존재할 수 있다. 윈도우는 이러한 작업을 위해 설계되지 않은 구형 소프트웨어와의 호환성 문제로 인해 사용자가 다른 두 번째 파일을 만들 수 없도록 하고 있다. 오래된 소프트웨어만이 아니다. 그것과 호환되는 어떤 새로운 소프트웨어도 찾기 힘들 것이다. 77.73.168.99 (대화) 16:28, 2014년 1월 14일 (UTC)[]

파일 이름

컴퓨터에서는 대소문자를 구분하는 데이터의 예를 몇 가지 들 수 있다.

[...]
*필름
[...]

임호 이것은 틀렸다:대부분의 컴퓨터는 윈도우를 사용하고 그것이 가능하지만 NTFSVFAT와 함께 윈도우에서 대문자와 소문자 파일 이름을 사용하는 것은 대/소문자를 구분하지 않는다: 파일 이름의 유일한 차이점은 문자의 경우와 모든 파일 시스템 작업일 때 동일한 폴더에서 두 개의 파일을 만드는 것은 불가능하다. 대소문자를 구분하지 않음. --MrBurns (대화) 00:03, 2014년 6월 27일 (UTC)[]

그 기사는 더 이상 그런 광범위한 주장을 하지 않는다. 가이 해리스 (대화) 23:39, 2017년 12월 3일 (UTC)[]

언제 사용하는가?

이러한 접근방식 중 하나가 언제 사용되는가? 많은 기사목록들은 그들이 저장되는 방법의 사례들을 사용한다. 그러나 사례 민감성 대 불감증 이면의 실제 철학은 무엇일까? 보통 Unix의 명령줄에서 무언가를 찾으려고 하면 머릿속이 텅 비어 있다: 검색하려는 파일 이름(예: 큰 NAS)이 기억나지 않는다. 그래서 나는 대소문자를 구분하지 않는 검색을 사용하는 거야. 그러나 대부분의 명령과 기본값은 대개 Unix에서 대소문자를 구분한다. 나는 단지 왜 그것이 사실인지 궁금할 뿐이다. 그렇다면 프로그래머는 종종 대소문자를 구분하는 검색(SQL, C, Java 등의 대문자 정의)이 필요하다는 것을 알고 있다.

저장 대 검색, 컴퓨터 대 인간, 컨텐츠 대 파일 이름, 다양한 애플리케이션 및 사용 사례. 유닉스는 사건 민감성을 선호하고 인기 있는 시스템은 불감증을 선호하는 이유는? 내게는 여전히 완전히 명확하지 않으며 "정확한 일치에 대한 대소문자 구분"도 항상 그렇지는 않을 수 있다: 때로는 사물이 (파일이 아닌) 용기로 저장되고 사용자가 이름을 선택한다(즉, 구글 드라이브 스타일). 시스템 사용자 쪽이 많을수록 일반적으로 더 많은 사례 불감증이 있다. Beoldhin (대화 기여) 10:18, 2017년 12월 16일 (UTC)[]이(가) 추가된 이전서명되지 않은 논평

해프닝?

내가 보기에는 "사례 민감도"는 두 가지를 의미하는데 사용되는 것 같다.

  1. 대소문자를 구분하는 품질 - "이 시스템은 대소문자를 구분한다."
  2. 가능한 사례 처리 방법 영역 - "이 시스템의 사례 민감도는 무엇인가?

이 글의 대부분은 두 번째 의미에 관한 것이지만, 리드는 첫 번째 의미만을 정의한다. "대소문자 구분"과 "대소문자 구분"과 함께 두 번째 의미에서의 "대소문자 구분"을 정의하도록 바꾸겠다. NisJørgensen (대화) 22:13, 2019년 7월 2일 (UTC)[]

프렌들리 파이어

@Guy Harris: 이 문제는 WP에서 설명한다.INTDABLINKWP:HowTodab. -- John of Reading (대화) 17:49, 2020년 5월 3일 (UTC)[]

@Guy Harris: 나는 교육 목적을 이해한다. 그러나 위의 John of Reading이 제공한 두 링크에서 설명했듯이 DAB 페이지로 직접 연결되는 링크가 오류라는 사실은 남아 있다. 링크(DPWL)가 있는 디스암호화 페이지를 통해서든, 아니면 다른 방법으로든, 미래의 어느 때든 '친근한 불'에 이 링크를 접하게 되는 경험이 있는 DABfixer라면 누구나 내가 어제(당신이 되돌아간) 했던 것과 정확히 같은 방법으로 고칠 것이다.
이 문자 같은 건 어때? 그것은 같은 서술적 가치를 가질 것이고, 운이 좋으면 편집자 한 두 명이 고정이 필요한 링크를 추가하는 것을 막을 수 있다.
예를 들어 [[영어 위키피디아]에서 "친절한 화재"를 검색하면 군 기사 "[친절한 화재]"가 반환되지만, "친절한 화재"(자본화된 "화재")를 검색하면 "[친절한 화재(해체)]"가 반환된다.(지침으로 [WP:INTDABLINK] 및 [[WP:HowTODAB]]는 오류가 되지 않도록 (해제) 한정자를 통해 연결되어야 한다.
사용자:DPL 봇은 DAB 페이지에 대한 모든 직접 링크를 오류로 기록한다(문서 공간에서만, 첫 단락의 링크와 WP:DPL남아 있는 링크와 같은 링크는 무시한다). 나는 DPWL을 통해 반복적으로 자전거를 타는데, 현재 약 4개월이 걸린다. 오늘, 나는 (해체) 예선전을 통해 연결함으로써 DAB 페이지에 대한 9개의 의도적인 링크를 고쳤다; 어제, 14개 (이것은 포함하지 않음), 전날, 13개. 그 숫자들은 전형적이다. 10년 퇴역군인과 WP가 편집한 내용을 되돌리고 수정했다. 가지 지침을 몰라서 오류를 도입한 관리자. (나는 또한 사용자들이 올바른 링크를 검색하는 노력보다는 (해체) 한정자를 통해 연결함으로써 DPL 봇 고약한 프로그램에 응답한 편집도 수십 건을 발견했지만, 그것은 또 다른, 그리고 삭제된 이야기 입니다. 이런 나쁜 고리는 우연히 발견되고 고쳐질 뿐이다.) 나르키 블러트 (대화) 18:54, 2021년 1월 18일 (UTC)[]