UTF-8에서 한 글자는 항상 한 바이트일까

UTF-8에서 한 코드 포인트는 항상 한 바이트가 아닙니다

UTF-8은 유니코드 코드 포인트를1~4바이트로 표현하는 인코딩입니다. 눈에 보이는 글자와 코드 포인트, 프로그램의 문자열 길이, 저장 바이트는 같은 수라고 보장되지 않습니다. 파일 크기나 바이트 제한을 계산할 때 실제 인코딩 결과를 기준으로 해야 합니다. 근거: MDN UTF-8, 2026-11-04.

근거: MDN UTF-8 · 2026-11-04 확인

가와ABC의 바이트 수를 로컬에서 확인했습니다

집필 중 Node.js v24.20.0에서 Buffer.byteLength('가','utf8')는3, Buffer.byteLength('ABC','utf8')도3이었습니다. 가의 UTF-8 바이트를16진수로 표시한 결과는eab080입니다. 한 눈에 한 글자인 가와 세 글자인ABC가 같은 바이트 수를 갖는 이 작은 관찰은 example-observations.json에 보존했습니다. 다른 모든 문자나 서비스의 길이 제한을 측정한 것은 아닙니다.

근거: MDN UTF-8 · 2026-11-04 확인

입력 제한에는 단위를 명시해야 합니다

가상의100자 제한과100바이트 제한은 다른 요구입니다. 웹 입력의 화면상 개수, 언어의 문자열 길이, 서버 저장 제한이 무엇인지 문서에서 확인합니다. 특히 결합 문자·이모지 등은 눈에 보이는 단위와 내부 표현이 달라질 수 있어 단순히 한글은 모두 몇 바이트라는 규칙으로 모든 문자를 처리하지 않습니다. 정확한 허용 기준이 없으면 운영 입력을 반복 잘라 제출하기보다 제공자에게 문의합니다.

근거: MDN UTF-8 · 2026-11-04 확인

문자가 깨지면 실제 저장·해석 인코딩을 대조합니다

원본을 보존하고 파일을 쓴 쪽과 읽는 쪽의 인코딩 설정, 전달 헤더, 중간 변환 여부를 확인합니다. 여러 바이트를 중간에서 잘랐거나 다른 인코딩으로 읽은 경우를 검토할 수 있지만 실제 원인은 자료로 확인해야 합니다. 깨진 표시만 다시 저장하면 복원에 필요한 원본을 잃을 수 있어 원본에서 재해석하는 순서를 우선합니다. 이 글은 파일을 변환한 사례가 아닙니다.

성공은 바이트 길이와 실제 문자열을 함께 확인합니다

계산에는 최종 인코딩된 바이트를 사용하고 역으로 읽은 내용이 기대한 문자열인지 대조합니다. 전송 본문 길이라면 압축·프로토콜의 어느 단계를 재는지도 적습니다. 결과를 보고할 때 로컬 관찰·가정 계산·실제 서비스 검증을 나누어 쓰고 미확인 문자 수 규칙을 확정값처럼 안내하지 않습니다.

옆 문서로 이어가기