텍스트 바이트 계산기

바이트는 "글자수"와 무엇이 다른가

컴퓨터는 글자를 숫자로 저장하고, 그 숫자를 몇 바이트에 담느냐는 인코딩이 정합니다. 같은 "가"라도 UTF-8로는 3바이트, EUC-KR(실무에서는 확장형인 CP949)로는 2바이트, UTF-16으로는 2바이트입니다. 영문과 숫자는 UTF-8과 EUC-KR 모두 1바이트라서, 영어 위주 문서에서는 둘의 차이를 느끼기 어렵습니다. 한글이 많은 문서에서야 "50바이트"가 한글 16자인지 25자인지가 갈립니다. 그래서 "글자수는 같은데 바이트는 다르다"는 일이 생기고, 가입 폼이나 레거시 DB, 문자 발송 시스템에서 이 차이가 오류로 이어집니다.

인코딩별 바이트 규칙 (빌드 시 계산한 표)

UTF-8은 문자 번호가 클수록 바이트가 늘어나는 가변 길이 방식입니다. ASCII(0~127)는 1바이트, 한글 음절과 대부분의 한자·일본어 가나는 3바이트, 이모지처럼 U+FFFF를 넘는 문자는 4바이트입니다. 반면 EUC-KR은 ASCII는 1바이트, 한글과 한자는 2바이트인 고정 규칙에 가깝습니다. 이 도구의 "EUC-KR/CP949 방식" 값은 ASCII(0~127)는 1바이트, 그 밖의 문자는 2바이트로 환산한 근사치입니다. 이전 버전은 이모지 같은 문자도 같은 방식으로 2바이트로 셌는데, 실제 EUC-KR에는 이모지가 없어 전송 단계에서 깨지거나 다른 방식으로 바뀔 수 있으므로 이제 이런 문자가 있으면 경고를 따로 표시합니다.

EUC-KR과 CP949의 차이

엄밀한 EUC-KR(KS X 1001)에는 한글 음절이 자주 쓰는 2,350자만 들어 있습니다. 그래서 "똠", "뷁" 같은 글자는 표현할 수 없었고, 마이크로소프트가 이를 11,172자 전체로 확장한 것이 CP949(통합 완성형)입니다. 브라우저와 윈도우에서 말하는 "euc-kr"은 사실상 CP949입니다. 둘 다 한글 한 글자가 2바이트라서 바이트 수 계산에는 차이가 없고, 달라지는 것은 "저장할 수 있는 글자의 범위"입니다. 옛 시스템에서 사람 이름의 희귀 음절이 물음표로 바뀌는 사고가 이 때문에 생깁니다.

바이트 제한을 글자수로 환산하면

"N바이트까지 입력 가능"이라는 제한이 한글 몇 자인지는 인코딩에 따라 다릅니다. 영문·숫자만이면 N자, 한글만이면 아래 표와 같습니다(내림 계산, 한글만 입력했을 때의 최대치).

문자메시지 90바이트와 LMS

국내 문자메시지는 오랫동안 EUC-KR 계열 인코딩 기준으로 영문 1바이트·한글 2바이트를 세어, 90바이트 이하는 단문(SMS), 그보다 길면 장문(LMS)으로 나누어 왔습니다. 이 기준으로 보면 아래와 같습니다.

이 숫자는 흔히 통용되는 기준일 뿐이며, 통신사와 문자 대행 서비스마다 상한, 줄바꿈을 1바이트로 보는지 2바이트로 보는지, 제목(LMS 제목)의 별도 한도, 사진을 넣는 MMS의 구분과 요금이 다를 수 있습니다. 광고성 문자는 "(광고)"와 수신거부 안내 문구를 반드시 포함해야 하는 법적 요건도 있어 그 글자 수만큼 본문 여유가 줄어듭니다. 따라서 이 도구는 "대략 단문인지 장문인지 가늠"하는 용도로 쓰고, 최종 판정은 사용 중인 발송 서비스의 미리보기 바이트 표시를 따르세요. 이모지와 일부 특수기호는 단문/장문으로 보낼 수 없거나 MMS로 전환되는 서비스가 있습니다.

계산 예시 (스크립트와 같은 규칙으로 빌드 시 계산)

예를 들어 "안녕하세요"는 5자이지만 UTF-8로는 15바이트, EUC-KR 방식으로는 10바이트입니다. 인증번호 문자 "[Web발신] 인증번호 123456"은 EUC-KR 방식으로 25바이트로 90바이트 한도에 크게 못 미칩니다. 같은 문장은 UTF-8로는 31바이트라서, "30바이트 이내" 제한이 EUC-KR 기준이면 통과하지만 UTF-8 기준이면 초과됩니다. 같은 글이 시스템에 따라 통과하기도, 막히기도 하는 이유입니다.

DB 컬럼 길이와 바이트

데이터베이스마다 "길이"의 의미가 다릅니다. MySQL의 VARCHAR(n)은 n이 문자 수이고, utf8mb4에서는 문자당 최대 4바이트로 저장 공간을 잡습니다. 반대로 Oracle의 VARCHAR2(n)은 설정(NLS_LENGTH_SEMANTICS)에 따라 BYTE일 수도 CHAR일 수도 있어서, 문자셋이 KO16MSWIN949이면 한글이 2바이트, AL32UTF8이면 3바이트입니다. 서버를 옮기며 문자셋이 바뀌면 같은 데이터가 "값이 너무 큽니다" 오류를 내는 경우가 있습니다. 컬럼을 설계할 때는 최대 입력 글자수에 인코딩별 최대 바이트(UTF-8 한글 3, 이모지 4)를 곱한 값으로 여유를 두세요. 이 페이지의 "제한에 맞춰 자르기" 기능은 한 글자를 반으로 쪼개지 않고 코드포인트 단위로만 자르므로, 잘린 글자가 깨지는 일은 없습니다. 다만 ZWJ 이모지처럼 여러 코드포인트로 이뤄진 글자는 중간에서 끊겨 일부만 남을 수 있습니다.

흔한 실수

첫째, "글자수 제한"과 "바이트 제한"을 같은 것으로 보고 한글을 1바이트로 계산하는 경우. 둘째, JavaScript의 length를 바이트로 착각하는 경우(UTF-16 코드 유닛 수일 뿐 바이트가 아닙니다). 셋째, 서버는 UTF-8인데 화면 안내는 EUC-KR 기준으로 적혀 있어 검증이 어긋나는 경우. 넷째, 줄바꿈을 입력창에서는 1바이트로 세는데 서버로 전송될 때 CRLF가 되어 2바이트가 되는 경우입니다. 마지막으로 붙여넣은 텍스트에 눈에 보이지 않는 문자(제로폭 공백 등)가 섞이면 보이는 글자수보다 바이트가 늘어납니다. 이런 문자는유니코드 문자 정보로 확인할 수 있습니다.

관련 도구

바이트가 아니라 눈에 보이는 글자수·공백 제외·원고지 매수를 보려면 글자수 & 단어수 세기를, 두 문구가 정확히 같은지 비교하려면 텍스트 비교 도구를 쓰세요. 문자열을 이진/ASCII 코드로 바꿔 보려면텍스트 이진·ASCII 변환기, API 응답 속 한글이 유니코드 이스케이프로 보일 때는JSON 포맷터가 유용합니다.

자주 묻는 질문