인코딩별 문자열 바이트 수 계산기
입력한 텍스트가 UTF-8, Shift_JIS, EUC-JP, UTF-16, JIS(ISO-2022-JP)에서 각각 몇 바이트가 되는지 측정합니다. 데이터베이스 컬럼 길이 제한이나 레거시 폼 입력 상한을 확인할 때 유용합니다.
글자 수와 바이트 수는 다른 것입니다
열 글자인데 서른 바이트라는 일은, 비라틴 문자를 다루다 보면 날마다 겪게 됩니다. **같은 문자열이라도 인코딩에 따라 바이트 수가 달라지기** 때문으로, UTF-8에서는 한글이나 한자 한 글자가 3바이트, 이모지가 4바이트를 차지하는 데 비해 Shift_JIS에서는 일본어 한 글자가 2바이트에 들어갑니다. 이 도구는 넣은 문자열이 UTF-8·Shift_JIS·EUC-JP·UTF-16·ISO-2022-JP의 다섯 방식에서 각각 몇 바이트가 되는지를 한꺼번에 보여 줍니다.
**함께 표시되는 「UTF-16 코드 단위 수」는 자바스크립트의 `.length`가 돌려주는 바로 그 값입니다.** 여기가 가장 자주 놓치는 함정으로, 이모지와 일부 문자는 두 단위로 이루어진 서로게이트 쌍으로 표현되므로 **사람이 한 글자로 세는 것을 `.length`는 둘로 셉니다.** 입력란의 길이 제한을 `.length`로 구현했을 때 이모지가 든 입력이 생각보다 일찍 막히는 까닭이 이것입니다. 데이터베이스 쪽도 마찬가지여서, `VARCHAR(255)`가 바이트를 세는지 글자를 세는지는 제품과 설정에 따라 다르므로 두 숫자를 함께 보아 두면 판단을 그르치지 않습니다.
사용하는 방법
- 문자열을 넣습니다 붙여 넣는 순간 집계되며 줄바꿈이 들어 있어도 무방합니다.
- 글자 수와 바이트 수를 견줍니다 **글자는 하나여도 UTF-8에서는 3바이트가 되는 일이 있습니다.**
- 관심 있는 인코딩의 줄을 읽습니다 저장하는 곳이나 보내는 곳이 실제로 쓰는 방식의 줄을 보시면 됩니다.
- UTF-16 코드 단위 수를 확인합니다 **자바스크립트의 `.length`로 제한을 걸고 있다면 결과를 가르는 것은 이 숫자입니다.**
더 잘 활용하기 위한 팁
- UTF-8에서는 반각 영숫자가 각각 1바이트를 차지하지만, 히라가나·가타카나·한자 등 일본어 문자는 대부분 3바이트를 차지하므로, 같은 문자 수라도 영어와 일본어 텍스트의 바이트 수는 크게 달라질 수 있습니다.
- VARCHAR(255)처럼 컬럼에 바이트 기준 길이 제한을 적용하는 오래된 시스템에서는, 같은 문자 길이라도 일본어를 포함한 텍스트가 영어 텍스트보다 훨씬 빨리 한도에 도달합니다.
- 대부분의 이모지는 두 개의 코드 단위로 이루어진 서로게이트 쌍으로 표현되어 UTF-8과 UTF-16 모두에서 4바이트를 차지하므로, SNS의 글자 수 제한이 예상보다 빨리 채워지는 원인이 되기도 합니다.
- 이미 바이트 수를 알고 있고 이를 KB·MB 등 다른 단위로 변환하고 싶다면, 자매 도구인 "바이트 단위 변환기"를 이용하세요. 이 도구는 텍스트에서 바이트 수를 구하는 반대 방향의 계산을 담당합니다.
이럴 때 쓸 수 있습니다
데이터베이스 칸의 넘침을 막을 때
**저장하는 쪽이 바이트로 제한한다면 한글·한자는 짐작의 3분의 1밖에 들어가지 않습니다.** 넣기 전에 확인할 수 있습니다.
폼의 입력 상한을 설계할 때
글자로 제한할지 바이트로 제한할지를 정하는 재료가 됩니다.
레거시 시스템과 연계할 때
고정 길이 파일이나 Shift_JIS를 전제한 연계에서는 바이트 수가 곧 자리의 위치입니다.
이모지의 처리를 검증할 때
**서로게이트 쌍이 든 문자열이 뜻한 길이로 다뤄지는지 확인할 수 있습니다.**
문자 부호화 용어
- UTF-8
- 세상의 문자를 1~4바이트의 가변 길이로 나타내는 방식입니다. **어림잡아 ASCII는 1바이트, 한글·한자는 3바이트, 이모지는 4바이트**입니다.
- Shift_JIS
- 일본어를 위한 방식으로 **일본어 한 글자가 2바이트에 들어갑니다.** 오래된 시스템과 고정 길이 파일에서 아직도 쓰입니다.
- EUC-JP
- 유닉스 계열에서 오래 쓰여 온 일본어 방식입니다. 일본어 한 글자는 보통 2바이트입니다.
- UTF-16
- 16비트를 단위로 문자를 나타내는 방식입니다. **자바스크립트의 문자열은 이 단위로 세어집니다.**
- 서로게이트 쌍
- **UTF-16의 한 단위에 담기지 않는 문자를 두 단위의 짝으로 나타내는** 장치입니다. 이모지와 일부 문자가 여기에 듭니다.
- ISO-2022-JP
- 이스케이프 시퀀스로 문자 집합을 바꾸는 방식으로, 일본어 메일에서 오래 쓰였습니다. JIS 코드라고도 부릅니다.
자주 묻는 질문
여담 ― 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자까지 줄어듭니다. "일본어를 단 한 글자만 사용해도 보낼 수 있는 글자 수가 절반 이하로 줄어든다"는 현상은, 이 글의 주제인 문자 인코딩과 바이트 수의 관계가 만들어내는 전형적인 예입니다.