한 번 붙여넣으면 모든 표기법이 동시에 나옵니다. 필드 목록을 데이터베이스와 JSON API, TypeScript 모델 사이에서 옮길 때처럼 계층마다 다른 표기를 요구하는 상황에 씁니다.
식별자 이름을 언어 사이에서 옮긴다는 것은 서로 호환되지 않는 관례 사이를 오간다는 뜻입니다. 자바스크립트 변수는 camelCase, 클래스와 컴포넌트는 PascalCase, 파이썬과 SQL 컬럼은 snake_case, URL과 CSS는 kebab-case, 환경 변수는 CONSTANT_CASE입니다.
여기서는 구분자뿐 아니라 대소문자가 바뀌는 경계에서도 단어를 나눕니다. 그래서 HTTPResponse와 http_response가 모두 제대로 분해되고 한 덩어리로 뭉개지지 않습니다. 단순한 변환기가 실패하는 지점이 바로 이 약어 처리입니다. 함께 있는 줄 단위 도구 — 정렬, 중복 제거, 공백 정리, 번호 매기기, 뒤집기 — 는 그렇지 않으면 일회용 스크립트를 짜야 하는 자잘한 텍스트 작업을 대신합니다.
자주 부딪히는 두 관례는 이름을 붙여 둘 값어치가 있습니다. HTTP 헤더 이름은 관례적으로 Content-Type, X-Request-Id 같은 Train-Case 이고, 같은 값이 대부분의 언어에서는 snake_case 나 camelCase 로 나타납니다. 변환기들이 서로 다르게 판단하는 지점은 이름 가운데 들어간 약어입니다. XMLHttpRequest, XmlHttpRequest, XML_HTTP_REQUEST 는 같은 이름에 대한 모두 나름대로 타당한 해석입니다. 구분자뿐 아니라 대소문자 경계에서도 쪼개는 것이 HTTPResponse 를 하나의 뭉뚱그려진 단어로 만들지 않고 HTTP 와 Response 로 갈라내는 방법입니다.
줄 단위 유틸리티는 안 그러면 일회용 스크립트가 될 일들을 대신합니다. 순서를 유지한 채 중복 없애기, 대소문자를 무시한 정렬, 붙여넣기에 딸려 온 줄 끝 공백 지우기, 참조용으로 줄 번호 매기기, 순서 뒤집기 같은 것들입니다. 편집기에서 하면 1분, 여기서는 1초 걸리고, 어느 것도 터미널을 열 만한 일은 아닙니다. 페이지 안에서 처리하므로 텍스트가 밖으로 나가지 않는다는 점도 중요합니다. 목록이 고객 이름이나 내부 호스트명일 때 특히 그렇습니다.
표기 변환이 언제나 되돌릴 수 있는 것은 아니고, 어디서 멈추는지 알아 두면 도움이 됩니다. camelCase 를 snake_case 로 바꿨다가 되돌리면 원래대로 돌아오지만, 문장부호가 있는 문장을 어떤 프로그래밍 관례로 바꾸면 되돌아오지 않습니다. 문장부호가 인코딩되지 않고 버려지기 때문입니다. 비 ASCII 문자도 경계입니다. 한국어, 일본어, 중국어에는 대소문자 자체가 없으므로, 섞인 문자열에서는 라틴 문자만 바뀌고 나머지는 그대로 남습니다. 원하는 동작이 맞고, 결과가 절반만 변환된 것처럼 보이는 이유이기도 합니다.
대소문자 변환이 로케일에 따라 달라지는 악명 높은 자리가 하나 있습니다. 터키어에는 점 없는 i와 점 있는 i가 따로 있어서, i의 대문자가 대부분의 언어에서는 I이지만 터키어에서는 점 있는 대문자이고, I의 소문자는 점 없는 쪽입니다. 파일 이름이나 헤더 이름, 언어 태그를 비교하려고 문자열을 대문자로 바꾸는 코드는 터키어 환경에서 틀린 답을 내놓고, 그 버그는 해당 로케일 사용자에게만 나타납니다. 이 페이지는 브라우저 로케일이 아니라 불변 규칙으로 변환합니다. 결과가 어디서나 같고 식별자로 써도 안전한 이유입니다.
됩니다. 단어 분리에 유니코드 문자·숫자 분류를 쓰기 때문에 한국어, 일본어, 악센트가 붙은 라틴 문자가 사라지지 않고 보존됩니다. 대소문자 변경은 대소문자가 있는 문자에만 적용됩니다.
거의 같지만 url-slug는 앞뒤 구분자를 추가로 제거합니다. 제목에서 URL 경로를 만들 때 필요한 처리입니다.
아니요. 모든 변환은 브라우저 안에서 자바스크립트로 처리합니다. 서버로 전송되지도, 저장되지도 않습니다.