인코딩별 문자열 바이트 수 계산기

입력한 텍스트가 UTF-8, Shift_JIS, EUC-JP, UTF-16, JIS(ISO-2022-JP)에서 각각 몇 바이트가 되는지 측정합니다. 데이터베이스 컬럼 길이 제한이나 레거시 폼 입력 상한을 확인할 때 유용합니다.

팁

  • UTF-8에서는 반각 영숫자가 각각 1바이트를 차지하지만, 히라가나·가타카나·한자 등 일본어 문자는 대부분 3바이트를 차지하므로, 같은 문자 수라도 영어와 일본어 텍스트의 바이트 수는 크게 달라질 수 있습니다.
  • VARCHAR(255)처럼 컬럼에 바이트 기준 길이 제한을 적용하는 오래된 시스템에서는, 같은 문자 길이라도 일본어를 포함한 텍스트가 영어 텍스트보다 훨씬 빨리 한도에 도달합니다.
  • 대부분의 이모지는 두 개의 코드 단위로 이루어진 서로게이트 쌍으로 표현되어 UTF-8과 UTF-16 모두에서 4바이트를 차지하므로, SNS의 글자 수 제한이 예상보다 빨리 채워지는 원인이 되기도 합니다.
  • 이미 바이트 수를 알고 있고 이를 KB·MB 등 다른 단위로 변환하고 싶다면, 자매 도구인 "바이트 단위 변환기"를 이용하세요. 이 도구는 텍스트에서 바이트 수를 구하는 반대 방향의 계산을 담당합니다.

자주 묻는 질문

문자 수는 문자열에 보이는 문자가 몇 개인지를 세는 것이고, 바이트 수는 그 문자열을 컴퓨터 데이터로 저장하거나 전송할 때 필요한 바이트(옥텟) 수를 나타냅니다. 순수 ASCII 텍스트에서는 두 값이 일치하지만, 일본어처럼 멀티바이트 문자를 포함한 텍스트에서는 바이트 수가 문자 수보다 몇 배나 커질 수 있습니다.

UTF-8은 문자마다 1~4바이트의 가변 길이로 인코딩하는 방식이며, 대부분의 일본어 문자(히라가나·가타카나·상용한자)는 3바이트를 차지합니다. 반면 Shift_JIS는 대부분의 일본어 문자를 2바이트로 인코딩하므로, 같은 일본어 텍스트라도 일반적으로 UTF-8 쪽이 Shift_JIS보다 바이트 수가 더 큽니다.

데이터베이스 종류와 컬럼의 문자셋 설정에 따라 다릅니다. MySQL의 VARCHAR(n)는 기본적으로 "n자"로 제한되지만, 인덱스에 사용할 수 있는 최대 키 길이처럼 내부적으로 별도의 바이트 기준 제한도 존재하기 때문에 이모지를 포함한 텍스트에서 오류가 발생하는 경우가 있습니다. 정확한 동작은 사용 중인 DBMS의 공식 문서를 확인하세요.

반각 영숫자와 기호는 UTF-8, Shift_JIS, EUC-JP 어느 쪽에서도 1바이트로 표현되지만, 전각 문자(히라가나·가타카나·한자·전각 기호)는 인코딩에 따라 2~3바이트를 차지합니다. 같은 "10자" 텍스트라도 반각으로만 이루어지면 10바이트, 전각으로만 이루어지면 20~30바이트로 큰 차이가 생깁니다.

이 도구는 텍스트를 입력하면 각 인코딩별로 해당 텍스트의 바이트 수를 계산합니다. 반면 "바이트 단위 변환기" 도구는 이미 알고 있는 바이트 수(예: 1,500,000바이트)를 KB·MB·GB 등의 단위로 변환하는 도구입니다. "텍스트 → 바이트 수"를 구하고 싶을 때는 이 도구를, "바이트 수 → 다른 단위"로 변환하고 싶을 때는 바이트 단위 변환기를 사용하세요.
ツールくん

여담 ― SNS 글자 수 제한과 바이트 수의 알려지지 않은 관계

예전 버전의 MySQL이 사용하던 "utf8" 문자셋에는 뜻밖의 제약이 있었습니다. 실제로는 U+10000 이상의 유니코드 보조 문자, 즉 대부분의 이모지를 저장할 수 없었던 것입니다. UTF-8 자체는 문자당 최대 4바이트까지 지원하는 가변 길이 인코딩이지만, MySQL의 "utf8"은 역사적인 이유로 최대 3바이트까지만 처리할 수 있었기 때문에 이모지를 포함한 텍스트를 INSERT하려 하면 오류가 발생하는 문제가 오랫동안 보고되었습니다. 현재는 4바이트 전체 범위를 올바르게 처리할 수 있는 "utf8mb4"로의 마이그레이션이 권장되며, 이는 문자 인코딩과 바이트 수의 관계를 정확히 이해하는 것이 실무에서 왜 중요한지를 보여주는 대표적인 사례입니다.

트위터(현 X)가 140자 제한을 채택했던 시절, 일본어 사용자는 140자로도 충분히 긴 문장을 쓸 수 있는 반면 영어 사용자는 140자로는 단어 수로 20~30개 정도밖에 쓸 수 없어 불공평하다는 논쟁이 있었습니다. 이는 영어가 알파벳 1자=1문자인 데 비해, 일본어는 한자 한 글자에 훨씬 많은 정보량이 담겨 있기 때문입니다. 이후 트위터는 일본어 등의 언어는 "1문자=1카운트", 영어 등 일부 언어는 "2바이트=1카운트"로 계산하는 독자적인 가중치 방식을 도입해 언어 간 공평성을 조정했습니다.

휴대전화 SMS에도 비슷한 사정이 있습니다. GSM 방식의 SMS는 보통 한 통에 160자까지 보낼 수 있지만, 이모지나 일본어 문자처럼 7비트 GSM 문자셋에 포함되지 않는 문자가 단 하나라도 들어가면 인코딩 방식이 UCS-2(대략 UTF-16에 해당)로 전환되어 한도가 단숨에 70자까지 줄어듭니다. "일본어를 단 한 글자만 사용해도 보낼 수 있는 글자 수가 절반 이하로 줄어든다"는 현상은, 이 글의 주제인 문자 인코딩과 바이트 수의 관계가 만들어내는 전형적인 예입니다.

같은 카테고리의 도구