글자 수 세기

“글자”의 뜻이 네 가지라서, 수치도 네 가지

가족 이모지나 피부색이 적용된 엄지 척 이모지를 예로 들어 보겠습니다. 사람은 한 글자로 봅니다. 이 이모지는 보이지 않는 연결 문자로 이어진 여러 코드 포인트로 이루어져 있어서, 정규 표현식은 일곱 개로 봅니다. JavaScript는 텍스트를 16비트 단위로 저장하고 기본 범위 밖의 문자는 두 단위를 차지하므로 열한 개라고 보고합니다. 데이터베이스 열에 넣기 위해 UTF-8로 인코딩하면 25바이트를 차지합니다. 어느 수치도 틀리지 않았고 어느 하나가 정답도 아닙니다. 맞는 수치는 전적으로 무엇이 제한을 두는지에 달려 있습니다.

따라서 실제로 물어야 할 것은 누가 제한을 정했느냐입니다. VARCHAR로 선언된 데이터베이스 열은 대부분의 엔진에서 바이트를 세며, 그래서 영어 255자를 받는 필드가 일본어는 훨씬 적게 받습니다. 문자 메시지(SMS)는 자체 7비트 문자 집합으로 160자이며, 그 집합 밖의 문자가 하나라도 들어가면 메시지당 70자로 줄어듭니다. 둥근 따옴표나 이모지 하나로 메시지 한 통이 세 통이 될 수 있습니다. JavaScript로 만든 폼 검증기는 거의 항상 UTF-16 단위를 세므로, 280자라고 적힌 필드가 이모지가 많은 더 짧아 보이는 문자열을 거부할 수 있습니다.

독자가 보는 글자 수는 가장 까다로운 수치이며, 브라우저 자체의 텍스트 분절 기능으로 셉니다. 왼쪽 화살표 키를 눌렀을 때 커서가 어디로 갈지 정하는 바로 그 기능입니다. 사람이 인식하는 모든 것에는 이것이 “한 글자”의 올바른 정의이며, 단순한 방식이 놓치는 경우도 처리합니다. 기본 글자에 결합 부호를 더해 쓴 악센트 글자는 한 글자이고, 힌디어와 태국어의 글자 묶음도 그 문자를 읽는 사람이 세는 방식대로 셉니다.

일반적인 영어 글에서는 네 수치가 모두 같으며, 그래서 문제가 드러나기 전까지는 보이지 않습니다. 이모지, 악센트와 결합 문자, 라틴 문자가 아닌 문자, 수학 기호에서 수치가 갈라지며, 바로 이런 입력 때문에 데이터베이스를 만든 지 석 달 뒤 필드가 소리 없이 잘려 나갑니다.

다른 작업이 필요할 때

코드에서는 기본 길이 대신 필요한 것을 세는 함수를 쓰세요. JavaScript의 Intl.Segmenter는 독자가 보는 글자를 세고, Python 3 문자열은 코드 포인트를 세며 len(s.encode("utf-8"))는 바이트를 셉니다. PHP에는 바로 이 구분을 위해 mb_strlen과 strlen이 따로 있습니다. 대부분의 언어에서 기본값은 그 언어에 편한 방식일 뿐이며, 여러분의 제한이 뜻하는 방식인 경우는 드뭅니다.

데이터베이스 필드가 제약이라면 근본적인 해결책은 그 앞 단계에 있습니다. MySQL에서는 열을 utf8mb4로, PostgreSQL에서는 text로 선언하면 잘림 버그 한 종류가 통째로 사라집니다. MySQL의 예전 utf8은 잘 알려진 대로 글자당 3바이트까지만 지원해 이모지를 아예 저장할 수 없습니다. 폼에서 조심스럽게 글자 수를 세는 것은 처음부터 다르게 선언했어야 할 열을 위한 임시방편입니다.