SoupCalc

문자열 길이 계산기 - 유니코드 문자 및 UTF-8 바이트

이 도구가 계산하는 것

이 계산기는 유니코드 코드 포인트에 기반한 문자 중심 개수와 UTF-8 바이트에 기반한 저장 중심 개수를 보고합니다. 내부적으로 검증된 도우미는 UTF-16 코드 유닛도 구분하므로, 일부 이모지 및 보충 문자에 대해 JavaScript 문자열의 네이티브 길이가 가시적 결과와 다를 수 있는 이유를 설명합니다.

"문자"는 컴퓨팅에서 여러 의미를 가집니다. 코드 포인트 개수는 UTF-16 유닛을 세는 것보다 더 유니코드를 인식하지만, 여전히 사용자에게 인식되는 자소 클러스터의 수와 항상 같지는 않습니다.

입력값

공백, 줄바꿈, 이모지, 결합 표시 및 비라틴 문자를 포함한 모든 텍스트를 입력하거나 붙여넣으십시오. 계산은 브라우저에서 발생하며 텍스트를 길이 서비스로 보낼 필요가 없습니다.

바이트 제한이 중요한 경우 정확한 줄 끝을 보존하십시오. Windows CRLF 줄바꿈은 두 개의 코드 포인트와 두 개의 UTF-8 바이트를 사용하는 반면, LF 줄바꿈은 하나를 사용합니다. 유니코드 정규화도 겉보기 텍스트를 변경하지 않고 코드 포인트와 바이트 개수를 변경할 수 있습니다.

계산 방법과 공식

코드 포인트 개수는 원시 UTF-16 유닛을 인덱싱하는 대신 유니코드 코드 포인트로 문자열을 반복합니다. UTF-16 개수는 언어 런타임의 코드 유닛 길이입니다. 바이트 개수는 문자열을 UTF-8로 인코딩하고 결과 옥텟을 셉니다.

기본 ASCII 문자는 하나의 UTF-16 유닛과 하나의 UTF-8 바이트를 사용합니다. 많은 악센트 문자가 하나의 코드 포인트를 사용하지만 두 개의 UTF-8 바이트를 사용합니다. 보충 이모지는 일반적으로 하나의 코드 포인트, 두 개의 UTF-16 코드 유닛 및 네 개의 UTF-8 바이트를 사용합니다.

제로 너비 결합자로 결합된 이모지 시퀀스와 같은 자소는 하나의 기호로 보이면서 여러 코드 포인트를 포함할 수 있습니다. 이 도구는 자소 분할을 적용하지 않습니다.

계산 예시

A😀é를 입력합니다.

  • 유니코드 코드 포인트: A, 😀, é로 총 3개.
  • UTF-16 코드 유닛: A에 1, 😀에 2, é에 1로 총 4개.
  • UTF-8 바이트: A에 1, 😀에 4, é에 2로 총 7개.

가시적 계산기는 3자와 7바이트를 보고합니다. 문서화된 UTF-16 값 4는 순진한 JavaScript .length 개수가 왜 일치하지 않는지 설명합니다.

결과 해석 방법

코드 포인트로 명시적으로 정의된 프로토콜이나 데이터 규칙을 검증할 때는 코드 포인트를 사용하십시오. 인코딩된 바이트로 정의된 페이로드, 데이터베이스 또는 API 제한에는 UTF-8 바이트를 사용하십시오. 어느 것도 자소 클러스터, 표시 너비, SMS 세그먼트 또는 글꼴 글리프로 정의된 제한을 대체해서는 안 됩니다.

제품 제한을 적용할 때는 단위와 정규화 형식을 문서화하십시오. 인터페이스가 "문자"라고 말하면서 백엔드가 바이트를 거부한다는 이유만으로 사용자가 텍스트를 잃어서는 안 됩니다.

정확성 및 한계

바이트 개수는 구체적으로 UTF-8을 사용합니다. UTF-16, UTF-32, 레거시 인코딩, 압축, 이스케이핑, JSON 구문 및 전송 프레이밍은 다른 크기를 가집니다. 이 도구는 텍스트를 정규화하거나 자소 클러스터, 단어, 줄, 열, 글리프 또는 렌더링된 너비를 계산하지 않습니다.

시각적으로 동일한 문자열이 다른 인코딩을 가질 수 있습니다—예를 들어, 미리 조합된 악센트 문자 대 기본 문자와 결합 표시. 보안에 민감한 식별자는 길이만으로는 충분하지 않은 문서화된 유니코드 정책이 필요합니다.

출처

편집 기록

작성자: SoupCalc Editorial Team

마지막 검토일: 2026년 8월 14일

검토 범위: 코드 포인트 반복, UTF-16 서로게이트 동작, UTF-8 인코딩, 자소 한계, 표준 참조, 그리고 A😀é의 3, 4, 7 개수를 확인했습니다.