대소문자 변환기

제목 대문자는 스타일 결정이지 규칙이 아닙니다

대부분의 대소문자 변환기는 제목 대문자를 "각 단어의 첫 글자를 대문자로 만드는 것"으로 구현합니다. 어떤 스타일 가이드도 실제로 그렇게 말하지 않습니다. 모든 주요 가이드는 제목에서 첫 번째나 마지막 단어가 아닌 한 특정 짧은 단어를 소문자로 만들며, 어떤 단어가 해당하는지에 대해서는 동의하지 않습니다.

AP 스타일은 관사, 열거 접속사, 세 글자 이하의 전치사를 소문자로 만듭니다. Chicago는 길이에 관계없이 모든 전치사를 소문자로 만들며, 관사와 열거 접속사도 마찬가지입니다. 실용적인 결과는 동일한 헤드라인이 작성하는 가이드에 따라 다른 방식으로 대문자가 된다는 것입니다.

하이픈으로 연결된 복합어는 변환기가 실패하는 또 다른 부분입니다. "state-of-the-art"는 "State-of-the-Art"가 되어야 합니다 — 첫 번째 요소가 대문자이고 복합어 내의 하위 단어는 그대로. 공백으로만 분할하면 "State-of-the-art"가 되는데, 이는 AP와 Chicago 모두에서 잘못된 것입니다.

문장 대문자, 그리고 왜 먼저 소문자가 잘못인가

문장 대문자는 각 문장의 첫 단어를 대문자로 만들고 나머지는 그대로 둔다는 것을 의미합니다. 단순한 구현은 모든 것을 소문자로 만든 다음 문자 0을 대문자로 만들어 고유 명사를 파괴하고 전체 여러 문장 단락에 하나의 대문자만 있게 됩니다.

이 도구는 Unicode 문장 경계 규칙을 사용하여 텍스트를 문장으로 분할한 다음 각 문장의 첫 글자를 대문자로 만듭니다. 이는 "e.g."나 "Dr."와 같은 약어를 마침표로 분할하는 것보다 훨씬 잘 처리하며, 데바나가리 단다(।) 및 기타 비라틴 문장 종결자에도 작동합니다. 독립된 영어 대명사 "I"는 그 후 복원됩니다.

고유 명사는 여전히 실제 한계입니다: 오프라인 도구는 명명된 엔티티 모델 없이 "paris"가 "Paris"여야 한다는 것을 안정적으로 말할 수 없으며, 실행하면 텍스트를 서버로 보내게 됩니다. 솔직한 답은 문장 대문자가 길의 대부분을 개척하고 명사는 확인하는 것입니다.

프로그래머 대소문자

개발자 변환 — camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, dot.case — 모두 구분자를 대체하는 대신 먼저 입력을 토큰화하여 작동합니다. 즉, myXMLParser는 my / XML / Parser로 토큰화되어 my_xml_parser로 변환됩니다. 문자 수준 접근 방식이 생성하는 my_x_m_l_parser가 아닙니다.

• camelCase — JavaScript 변수와 함수
• PascalCase — 클래스와 React 컴포넌트
• snake_case — Python, Ruby, SQL 컬럼
• CONSTANT_CASE — 환경 변수와 상수
• kebab-case — URL, CSS 클래스, 파일 이름