텍스트·정규식
글자 수는 적은데 바이트 제한을 넘는 이유는?
사용할 도구
'20자 이내'인데 짧아 보이는 입력이 실패하거나 입력은 되는데 저장 단계에서 거부될 수 있습니다. 사용자가 잘못 센 것이 아닐 수 있습니다. 화면의 한 글자, 프로그램의 단위, 저장 단위가 항상 같지는 않습니다.
문자·바이트 수 도구로 한 입력을 여러 기준에서 재 보세요. 입력 문자열의 특징만 보여 주며 문제가 있는 서비스에 연결하거나 DB 설정을 읽지 않습니다. 원인 후보를 좁힌 뒤 실제 명세·구현과 비교하는 작은 실험입니다.
ABC, あいう, 😀를 각각 입력하기
ABC만 넣으면 자소 군집·코드 포인트·UTF-16 단위·UTF-8 바이트가 모두 3입니다. あいう로 바꾸면 앞의 셋은 3이지만 UTF-8은 9입니다. ASCII만 시험하면 일본어 입력이 훨씬 빨리 도달하는 바이트 제한을 놓칠 수 있습니다.
input | graphemes | codePoints | utf16CodeUnits | utf8Bytes
ABC | 3 | 3 | 3 | 3
あいう | 3 | 3 | 3 | 9
😀 | 1 | 1 | 2 | 4😀만 입력하면 자소 군집·코드 포인트는 1, UTF-16 단위는 2, UTF-8 바이트는 4입니다. 따라서 '이모지는 두 글자'라는 설명은 기준이 빠져 있습니다. 여러 요소가 결합한 이모지는 또 다른 수가 됩니다.
같아 보이는 é도 내부는 다를 수 있습니다
미리 조합된 é와 e 뒤에 결합 악센트를 붙인 문자열을 비교하세요. 전자는 코드 포인트 1·UTF-8 2바이트, 후자는 코드 포인트 2·UTF-8 3바이트입니다. 보통 자소 군집 분할은 둘 다 보이는 한 글자로 취급합니다.
é
é두 줄을 함께 붙이면 줄바꿈도 셉니다. 따로 시험하고 Unicode 정보에서 U+00E9와 U+0065·U+0301을 확인하세요. 정규화로 같게 만들 수 있지만 제한에 맞추려고 입력을 몰래 바꿔도 된다는 뜻은 아닙니다. 식별자·서명은 수신 측 규칙부터 확인하세요.
12바이트 칸에는 무엇이 들어갈까요?
UTF-8 12바이트 제한을 가정하면 A 12개, あ 4개, 😀 3개가 모두 경계입니다. 하나씩 더하면 각각 13·15·16바이트입니다. 임의의 긴 문장보다 경계 바로 아래·정확히 경계·바로 위를 시험하면 실패 원인이 분명해집니다.
바이트를 3으로 나눠 최대 글자 수를 정할 수는 없습니다. 영문·한자·이모지·결합 문자가 섞이면 글자당 바이트가 일정하지 않습니다. 사용자용 문자 제한과 저장 바이트 제한이 따로 있다면 둘을 설명하고 따로 검증할 수 있습니다. 제한 선택은 제품 요구사항이지 도구가 자동 결정하는 일이 아닙니다.
공백과 마지막 줄바꿈도 입력입니다
ABC 뒤에 공백 하나를 붙이면 UTF-8 4바이트입니다. 눈에 잘 띄지 않아 같은 내용을 붙였다고 생각해도 수가 다를 수 있습니다. 행 정리로 공백을 없애는 것은 입력 변경입니다. 먼저 원본을 재고 어느 변환 뒤 짧아졌는지 기록하세요.
여기서는 줄바꿈 구분자로 행을 셉니다. A 뒤에 줄바꿈 하나면 마지막 빈 행까지 2행입니다. 좁은 화면의 자동 줄 접기는 입력 줄바꿈을 늘리지 않습니다. LF·CRLF의 저장 바이트도 다르며 브라우저에 붙일 때 통일될 수 있으므로 원본 파일 크기와 같다고 단정하지 마세요.
문자열 바이트와 전송 데이터 크기는 다릅니다
12바이트 이름을 JSON에 넣으면 키·따옴표·구분자가 추가됩니다. URL 인코딩 뒤 표기 길이도 달라집니다. 파일에는 BOM·줄바꿈·압축이 관여할 수 있습니다. 전송 제한을 볼 때 원본 문자열 바이트와 실제 직렬화 데이터 크기를 구분하세요.
자소 군집 수는 브라우저 Intl.Segmenter를 사용하며 미지원 환경에서는 추정값을 넣지 않습니다. 분할은 런타임 Unicode 데이터에도 의존하므로 다른 서비스와 완전히 같다는 보장은 아닙니다. 특정 기기에서만 실패하면 같은 입력과 함께 기기·브라우저도 기록하세요.
'짧은데 실패'를 재현 가능한 보고로 바꾸기
예시·자소 군집 수·UTF-16 단위·UTF-8 바이트·거부 단계를 기록하세요. 실제 이름이나 비밀 문장 대신 같은 종류 문자의 짧은 합성 예시로 재현하면 공유하기 쉽습니다. '😀 3개는 통과, 4개는 저장 실패'가 '이모지 사용 불가'보다 조건을 잘 좁힙니다.
측정 뒤에는 화면 카운터·검증·API 제한·저장 정의를 확인할 수 있습니다. 제한 숫자만 키우기 전에 어느 단위로 일치해야 하는지 보세요. 도구가 시스템을 고치지는 않지만 일관된 약속과 이해하기 쉬운 오류 안내를 만드는 데 도움이 됩니다.
제한에 딱 맞는 입력과 그다음을 시험하기
UTF-8로 12바이트 제한이라면 あいうえ는 12바이트, あいうえお는 15바이트입니다. ABCDEFGHIJKL도 12바이트지만 눈에 보이는 길이는 다릅니다. 두 입력이 경계에서 통과하고 다음 글자에서 거부되는지 보면 글자 수 제한과 바이트 제한을 구별할 수 있습니다. ABCDEFGHIJK😀는 11+4=15바이트이므로 영문 열한 글자 뒤에 아무 문자나 하나 더 넣을 수 있는 것은 아닙니다.
임의의 바이트 위치에서 자르면 UTF-8 문자 중간을 끊을 수 있고, 코드 포인트 기준으로 잘라도 결합 문자나 이모지 묶음을 나눌 수 있습니다. 이 도구는 길이를 측정할 뿐 안전하게 줄이는 기능은 아닙니다. 입력 시스템에서는 제한을 알려 수정을 요청할지, 어떤 단위로 자를지 먼저 정해야 합니다. 표시하는 길이와 실제 제한이 같은 단위인지 확인하세요.