camelCase·snake_case 포함 10가지 케이스 변환기

텍스트브라우저에서 실행(업로드 없음)

붙여 넣은 텍스트의 각 줄을 UPPERCASE, lowercase, 기계식 Title Case, camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, kebab-case, dot.case, path/case의 정확한 10개 형식으로 변환합니다. camel 표기와 약어 경계를 Unicode 기준으로 나누고, 자동 변환이 판단할 수 없는 한계를 함께 표시합니다.

다음에 할 작업

관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.

작업 가이드

코드·데이터·경로 식별자를 안전하게 이름 변경하기

케이스 변환기로 이름 후보를 만든 뒤 모든 이름 변경을 계약 변경으로 다룹니다. 사용처 조사, 약어 규칙, 잘못된 식별자, diff와 대상 환경 검증을 완료하세요.

열기 관련 도구

텍스트·코드·Unified Patch Diff 비교기

정확한 줄 hunk, 코드 포인트 강조, unified patch로 제한된 텍스트를 로컬 비교합니다.

열기 관련 도구

슬러그 생성기 | Unicode·ASCII URL 슬러그 만들기

명확한 옵션과 경고로 Unicode·ASCII URL 슬러그 후보를 로컬에서 만듭니다.

열기 관련 도구

텍스트 찾기 및 바꾸기 | 리터럴·정규식 치환

Unicode 경계, 캡처 토큰, 정확한 수치, Worker 제한으로 리터럴 또는 정규식 일치를 바꿉니다.

열기

이 도구 사용 방법

라벨 하나, 혼합된 식별자, CSV 헤더 목록 또는 여러 줄 텍스트를 입력 영역에 붙여 넣습니다.

수동으로 변환을 실행하거나, 짧은 입력은 라이브 모드를 켜 두고 입력이 멈춘 뒤 자동 갱신합니다.

여러 줄 결과를 신뢰하기 전에 원본 줄 수와 감지된 식별자 단어 수를 확인합니다.

구두점뿐인 줄, 숫자로 시작하는 결과, 약어, 길이가 달라지는 Unicode 매핑 경고를 읽습니다.

공백과 구두점을 보존하는 UPPERCASE·lowercase와 단어 경계를 정규화하는 나머지 8개 결과를 비교합니다.

필요한 결과만 복사한 뒤 대상 코드의 참조·예약어, 파일 시스템 규칙 또는 편집 스타일을 최종 검증합니다.

이 도구를 써야 할 때

변수·함수·타입·컴포넌트 이름 초안

User Display Name 같은 라벨을 camelCase나 PascalCase 후보로 만든 뒤 대상 언어의 예약어와 참조를 확인합니다.

데이터베이스·가져오기 필드명 준비

복사한 컬럼 제목의 순서와 입력 줄별 결과를 유지하면서 각 줄을 snake_case로 바꿉니다.

경로와 파일 이름 후보 검토

경로, 패키지 키, 설정 경로, 파일명을 만들기 전에 kebab-case, dot.case, path/case 후보를 비교합니다.

명명 규칙 마이그레이션 계획

기존 이름이 camel·약어 경계에서 어떻게 나뉘는지 확인한 뒤 코드, 테스트, 문서, 클라이언트의 변경 범위를 계획합니다.

제목 교정의 시작점 만들기

제목 대문자화 초안을 만든 다음 실제 매체의 조사·약어·브랜드·언어 규칙을 적용합니다.

흔한 실수

사용처를 확인하지 않고 공개 식별자 변경

필드명, 환경 변수, 선택자, 경로는 외부 계약일 수 있습니다. 기존 이름을 바꾸기 전에 참조 위치와 테스트를 확인해야 합니다.

도구가 프로젝트의 약어 규칙을 안다고 가정

XMLHttp는 xmlHttp로, APIResponse는 apiResponse로 정규화됩니다. XML, API, ID, OAuth 같은 표기를 유지해야 하면 프로젝트 규칙에 맞게 다시 검토하세요.

숫자로 시작하는 결과를 코드에 바로 사용

2026 release는 2026Release가 됩니다. 변환 결과가 일정하더라도 많은 언어에서 숫자로 시작하는 이름은 유효한 식별자가 아닙니다.

기계식 Title Case를 출판 스타일 규칙으로 오해

Title Case 결과는 감지한 모든 단어의 첫 글자를 기계적으로 바꿉니다. 문장 케이스, 브랜드 표기, AP·Chicago 같은 편집 규칙을 구현하지 않습니다.

모든 형식이 구두점을 보존한다고 예상

단어 기반 결과 8개는 공백과 구두점을 제거하거나 다른 구분자로 바꿉니다. 원래 구두점을 유지하려면 UPPERCASE 또는 lowercase 결과를 선택해야 합니다.

예시

여러 명명 형식이 섞인 입력 변환

Http 앞의 약어 경계와 request, id 앞의 구분자를 인식해 네 단어로 처리합니다. 약어 표기를 특별히 보존하지는 않습니다.

입력

XMLHttp request-id

출력

camelCase: xmlHttpRequestId | snake_case: xml_http_request_id | Title Case: Xml Http Request Id

여러 줄을 합치지 않고 일괄 변환

브라우저 입력란에서 받은 각 줄을 독립적으로 변환합니다. textarea는 붙여 넣은 CRLF와 CR을 LF로 정규화하므로 이 예시는 원본 파일 바이트가 아니라 줄 순서를 보존합니다.

입력

First Name
APIResponse

출력

camelCase: firstName
apiResponse
 | snake_case: first_name
api_response

Unicode 단어 경계로 10개 케이스를 만드는 방식

토크나이저는 Unicode 문자, 결합 부호, 숫자를 인식합니다. 소문자 또는 숫자 다음의 대문자와, 뒤에 소문자 단어가 이어지는 약어의 마지막 대문자 앞에 경계를 넣어 XMLHttp를 XML과 Http로 나눕니다.

UPPERCASE와 lowercase는 원래 줄 전체에 Unicode 기본 대소문자 연산을 적용하므로 구두점과 공백을 유지합니다. Unicode에 여러 문자로 확장되는 매핑이 있으면 결과 길이는 달라질 수 있습니다.

나머지 8개 결과는 감지한 각 단어를 소문자로 만든 뒤 형식에 맞게 대문자화하거나 연결합니다. 문자·결합 부호·숫자 밖의 문자는 경계로 쓰이며 결과에 그대로 복사되지 않습니다.

엔진은 CRLF, LF, CR, LINE SEPARATOR U+2028, PARAGRAPH SEPARATOR U+2029를 인식하고 전달받은 문자열에 있는 구분자를 유지합니다. 브라우저 입력란에 직접 넣은 CRLF와 CR은 변환 전에 LF로 정규화되므로 결과의 구분자로 원본 파일 바이트를 증명할 수 없습니다.

기계식 Title Case는 모든 감지 단어를 소문자로 만든 뒤 첫 대소문자 문자를 대문자로 바꿉니다. 예측 가능한 후보일 뿐 문장 케이스나 언어·브랜드·출판사별 제목 규칙은 아닙니다.

정확한 입력 한도는 UTF-8 2 MiB와 논리 줄 100,000개입니다. 입력을 변경하지 않고 브라우저에서 처리하며, 10개 전체 결과를 동시에 보관하는 메모리 비용을 제한합니다.

자주 묻는 질문

어떤 케이스 형식을 만들 수 있나요?

UPPERCASE, lowercase, 기계식 Title Case, camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, kebab-case, dot.case, path/case의 정확한 10개입니다.

여러 줄 입력은 줄별로 독립 변환되나요?

네. 전달받은 각 논리 줄을 따로 토큰화하고 그 문자열의 마지막 줄바꿈도 유지합니다. 엔진은 CRLF, LF, CR, U+2028, U+2029를 보존할 수 있지만 브라우저 입력란에 직접 넣은 CRLF와 CR은 LF로 정규화됩니다. 이 도구는 원본 바이트 줄바꿈 검사기가 아닙니다.

공백, 하이픈, 이모지, 구두점은 어떻게 되나요?

UPPERCASE와 lowercase는 공백과 구두점을 보존합니다. 나머지 8개는 Unicode 문자·결합 부호·숫자를 단어로 유지하고, 그 밖의 구분자는 형식에 따라 제거하거나 공백·밑줄·하이픈·점·슬래시로 바꿉니다.

camelCase 입력과 약어는 어떻게 나누나요?

camel 경계와 약어 경계는 찾지만 약어 정책까지 추측하지 않습니다. XMLHttpRequest는 xmlHttpRequest가 되므로 API, URL, ID, OAuth, 제품명은 프로젝트 규칙과 비교하세요.

한글과 다른 Unicode 문자의 대소문자는 어떻게 처리하나요?

JavaScript의 Unicode 기본 대소문자 매핑을 사용하며 특정 언어의 편집 로캘을 적용하지 않습니다. 대소문자가 없는 문자는 유지되고 결합 부호는 단어에 붙으며, ß가 SS가 되는 것처럼 길이가 바뀔 수 있습니다.

생성된 값은 항상 유효한 코드 식별자인가요?

아닙니다. 숫자로 시작하는 이름, 예약어, 정규화 후 빈 줄, 대상 언어 고유 제한 때문에 유효하지 않을 수 있습니다. 숫자 시작 줄은 경고하지만 모든 언어 문법을 검사하지는 않습니다.

붙여 넣은 텍스트가 업로드되거나 분석에 포함되나요?

변환은 브라우저에서 실행됩니다. 집계 분석에는 바이트·줄·단어·결과 수와 경고 여부만 포함될 수 있으며, 붙여 넣은 원문이나 복사한 결과는 포함하지 않습니다.

이 도구를 검증한 방법

관리 및 검수 SimpleWebUtils검토일 2026년 7월 18일

검증 방법: camelCase·snake_case 포함 10가지 케이스 변환기에서 “마이그레이션 전에 자동 후보 검토” 픽스처를 임의로 고치거나 단순화하지 않고 실행했습니다. “목표 명명 정책 작성”에서 “단어 경계와 경고 검토”로 이어지는 결과를 대조했습니다. 비성공 경로 검토에는 “마이그레이션 없이 API·DB 키 변경”, “모든 약어 변환을 그대로 승인” 조건을 사용했습니다.

기대 결과: 변환기는 xmlHttpRequestId와 2026Release를 후보로 제시했고, XMLHttp 약어 정책과 숫자로 시작하는 식별자의 유효성 위험은 수동 검토 대상으로 남겼습니다.

검증한 작업 가이드 열기

다음에 할 작업

코드·데이터·경로 식별자를 안전하게 이름 변경하기

텍스트·코드·Unified Patch Diff 비교기

슬러그 생성기 | Unicode·ASCII URL 슬러그 만들기

텍스트 찾기 및 바꾸기 | 리터럴·정규식 치환

이 도구 사용 방법

이 도구를 써야 할 때

변수·함수·타입·컴포넌트 이름 초안

데이터베이스·가져오기 필드명 준비

경로와 파일 이름 후보 검토

명명 규칙 마이그레이션 계획

제목 교정의 시작점 만들기

흔한 실수

사용처를 확인하지 않고 공개 식별자 변경

도구가 프로젝트의 약어 규칙을 안다고 가정

숫자로 시작하는 결과를 코드에 바로 사용

기계식 Title Case를 출판 스타일 규칙으로 오해

모든 형식이 구두점을 보존한다고 예상

예시

여러 명명 형식이 섞인 입력 변환

여러 줄을 합치지 않고 일괄 변환

Unicode 단어 경계로 10개 케이스를 만드는 방식

자주 묻는 질문

어떤 케이스 형식을 만들 수 있나요?

여러 줄 입력은 줄별로 독립 변환되나요?

공백, 하이픈, 이모지, 구두점은 어떻게 되나요?

camelCase 입력과 약어는 어떻게 나누나요?

한글과 다른 Unicode 문자의 대소문자는 어떻게 처리하나요?

생성된 값은 항상 유효한 코드 식별자인가요?

붙여 넣은 텍스트가 업로드되거나 분석에 포함되나요?

이 도구를 검증한 방법

관련 작업 가이드

코드·데이터·경로 식별자를 안전하게 이름 변경하기

목록과 로그의 순서를 잃지 않고 중복 줄 제거하기

가져오기 전에 고유 줄을 자연 순서로 정렬하기

URL 슬러그를 만들고 기존 링크 보존하기

목록·로그·복사한 텍스트를 반복 가능한 파이프라인으로 정리하기

관련 도구

텍스트·코드·Unified Patch Diff 비교기

슬러그 생성기 | Unicode·ASCII URL 슬러그 만들기

텍스트 찾기 및 바꾸기 | 리터럴·정규식 치환

Unicode 정규화 | NFC·NFD·NFKC·NFKD 비교

단어 수 세기 | 확장 자소군·코드 포인트·UTF-8 바이트 비교