UTF-16 길이를 글자 수라고 부르기
JavaScript 문자열 길이는 UTF-16 코드 유닛 수입니다. 결합 문자·보조 평면 문자·연결 이모지가 있으면 사용자가 보는 문자 수보다 커질 수 있습니다.
단어 수 세기 | 확장 자소군·코드 포인트·UTF-8 바이트 비교
텍스트브라우저에서 실행(업로드 없음)
Unicode 단어형 세그먼트, 확장 자소군, 공백 제외 문자, 문장, 문단, 논리 줄, 코드 포인트, UTF-16 코드 유닛, UTF-8 바이트와 예상 읽기 시간을 로컬에서 계산합니다.
다음에 할 작업
관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.
작업 가이드
README와 글을 게시하기 전에 Markdown을 안전하게 미리보기
Markdown 미리보기는 모든 게시 환경이 같은 결과를 만든다는 보증이 아니라 게시 전 검토 단계로 사용할 때 가장 유용합니다. 이 절차는 작업 문서를 브라우저에 둔 채 자주 쓰는 확장 문법과 정제된 HTML을 확인하고, 원격 이미지를 명시적인 개인정보 결정으로 다루며, 콘텐츠 마크업과 대상 환경의 스타일을 구분합니다. 마지막에는 내보낸 HTML 조각이나 원본 Markdown을 실제로 게시할 시스템에서 다시 테스트합니다.
열기관련 도구CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기
로컬 파일의 원본 CRLF, LF, CR 및 Unicode 줄 구분자를 셉니다.
열기관련 도구Markdown 미리보기 | 정제 HTML 변환기
Markdown을 로컬에서 미리 보고 표, 작업 목록, 코드, 수식, 각주가 포함된 정제 HTML을 만듭니다.
열기관련 도구텍스트 분석 워크벤치 | 유니코드 빈도, 가독성, 어휘 성향, 유사도
유니코드 분절과 명시적 한도를 적용한 여섯 가지 텍스트 측정을 로컬에서 실행합니다.
열기이 도구 사용 방법
정확한 줄바꿈과 바이트가 필요하면 분석 전 원문이나 원본 파일을 보존합니다.
UTF-8 기준 1,048,576바이트 및 논리 줄 200,000개 이하의 텍스트를 붙여넣거나 TXT·CSV·TSV·LOG·Markdown 파일을 불러옵니다.
분당 단어형 세그먼트 수를 50~1,000 사이로 설정합니다. 이 값은 읽기 시간 추정에만 영향을 줍니다.
Worker 분석을 실행하고 단어형 세그먼트, 확장 자소군, 문장, 문단, 줄, 코드 포인트, UTF-16 코드 유닛, UTF-8 바이트를 비교합니다.
형식 문자, U+FFFD 대체 문자, 혼합 줄바꿈, CJK 읽기 시간 한계 경고를 확인합니다.
보고서를 복사하거나 내려받은 뒤 대상 시스템이 실제로 제한하는 계산 단위를 다시 확인합니다.
이 도구를 써야 할 때
원고와 과제 분량 점검
출판사·학교가 요구하는 단어 정의와 Unicode 단어형 수치를 비교하고 문단·문장·줄 근거를 보존합니다.
API 및 저장공간 제한 확인
데이터베이스 열, API 본문, 메시지 필드, 검증 규칙이 사용하는 자소군·코드 포인트·UTF-16·UTF-8 단위를 정확히 선택합니다.
다국어 UI 길이 예산 검토
악센트, 이모지, CJK 텍스트가 있는 UI 문구에서 화면상 문자와 코드 유닛·바이트의 차이를 확인합니다.
읽기 시간 계획
명시한 읽기 속도로 글의 시간을 추정한 뒤 코드 블록, 표, 미디어, 독자 배경을 반영해 조정합니다.
텍스트 무결성 사전 점검
가져오기·비교·중복 제거·게시 전에 혼합 줄바꿈, 형식 문자, U+FFFD를 찾아 원본 손상 여부를 점검합니다.
흔한 실수
모든 언어에서 공백 토큰을 단어로 보기
공백 분리는 공백 없는 일본어 문장 전체를 토큰 하나로 만듭니다. Unicode 세그먼트가 더 유용하지만 그 경계도 모든 언어학·출판 규칙을 대표하지는 않습니다.
모든 길이 제한에 화면상 문자 수 사용하기
플랫폼은 UTF-8 바이트, UTF-16 유닛, 코드 포인트 또는 화면상 자소군을 제한할 수 있습니다. 잘못된 단위를 쓰면 유효한 입력을 거부하거나 문자 중간을 자를 수 있습니다.
형식 문자를 무시하거나 일괄 삭제하기
보이지 않는 joiner와 형식 문자는 이모지·문자 체계에서 의도적일 수도 있고 식별자에 실수로 섞였을 수도 있습니다. 모두 자동 삭제하지 말고 용도를 확인해야 합니다.
예상 읽기 시간을 정확한 값으로 게시하기
읽기 시간은 계획용 추정치입니다. 코드, 표, 낯선 용어, 언어, 독자 수준이 단순 분당 단어 계산보다 큰 영향을 줄 수 있습니다.
예시
짧은 두 문단
빈 줄이 문단 두 개를 나누며 LF 두 개가 논리 줄 세 개를 만듭니다.
입력
Hello, world!
Second paragraph.출력
단어형 세그먼트 4개, 확장 자소군 32개, 문장 2개, 문단 2개, 논리 줄 3개, 코드 포인트 32개, UTF-16 코드 유닛 32개, UTF-8 바이트 32개.결합 문자와 연결 이모지
분해된 악센트와 연결된 가족 이모지는 확장 자소군·코드 포인트·코드 유닛·바이트를 따로 봐야 하는 이유를 보여 줍니다.
입력
é 👨👩👧👦출력
단어형 세그먼트 1개, 확장 자소군 3개, 코드 포인트 10개, UTF-16 코드 유닛 14개, UTF-8 바이트 29개, 이모지 joiner로 쓰인 형식 문자 3개.계산 계약과 한계
단어와 문장은 페이지 로케일을 사용한 ECMAScript Intl.Segmenter 경계를 순회합니다. isWordLike가 true인 세그먼트만 단어로 세므로 문장부호나 단독 이모지를 임의로 단어로 만들지 않습니다.
기본 문자 수는 확장 자소군입니다. 공백 제외 수치는 Unicode White_Space로만 이루어진 자소군을 뺍니다. 독자가 보는 단위에 가깝지만 모든 API가 이 단위를 사용한다고 가정하지 않습니다.
코드 포인트는 Unicode scalar 순회로, UTF-16 코드 유닛은 JavaScript 문자열 표현으로, 바이트는 UTF-8 인코딩 후 계산합니다. 짝이 없는 surrogate는 U+FFFD로 조용히 바꾸지 않고 오류로 거부합니다.
CRLF·LF·CR을 구별해 각각 논리 줄바꿈 하나로 처리하고 혼합 여부를 알립니다. 문단은 하나 이상의 빈 줄로 나뉜 공백 아닌 블록입니다.
예상 읽기 초는 단어형 세그먼트 수를 선택 속도로 나눈 뒤 올림합니다. CJK 사전 분할은 공백 없는 글에 유용하지만 언어학적 인증이나 실제 독서 속도 측정은 아닙니다.
입력은 UTF-8 1,048,576바이트, UTF-16 코드 유닛 1,048,576개, 논리 줄 200,000개로 제한합니다. 전용 Worker는 2초 뒤 중단되며 원문을 분석 이벤트나 외부 요청에 넣지 않습니다.
자주 묻는 질문
이모지는 언제나 한 문자로 계산되나요?
기본 문자 수는 확장 자소군을 사용하므로 결합 문자가 붙은 글자나 연결된 이모지가 사용자가 보는 한 문자로 계산될 수 있습니다. 소프트웨어 제한은 코드 포인트나 UTF-16 코드 유닛을 사용할 수 있어 보고서에 세 단위를 따로 표시합니다.
한글·일본어·중국어의 단어 수는 어떻게 세나요?
페이지 언어를 힌트로 전달한 Intl.Segmenter의 단어형 세그먼트를 셉니다. 공백이 없는 여러 문자 체계를 단순 공백 분리보다 잘 처리하지만 브라우저 사전 경계, 언어학적 정의, 기관별 원고지 기준은 서로 다를 수 있습니다.
마지막이 줄바꿈인 텍스트에 빈 줄 하나가 추가되는 이유는 무엇인가요?
CRLF 한 쌍, 단독 LF, 단독 CR을 각각 줄바꿈 하나로 셉니다. 따라서 비어 있지 않은 입력의 논리 줄 수는 줄바꿈 수보다 하나 많고, 마지막 줄바꿈 뒤의 빈 줄도 포함됩니다.
읽기 시간은 실제 측정값인가요?
아닙니다. 선택한 분당 단어형 세그먼트 수를 이용한 추정치입니다. 언어, 문장 난도, 독자, 표, 코드, 미디어에 따라 실제 읽기 시간은 크게 달라질 수 있습니다.
API나 플랫폼 길이 제한에는 어떤 수치를 써야 하나요?
서비스마다 확장 자소군, Unicode 코드 포인트, UTF-16 코드 유닛, UTF-8 바이트 중 다른 단위를 사용합니다. 대상 규격을 확인한 뒤 보고서에서 같은 단위를 선택해야 합니다.
붙여넣거나 올린 텍스트가 서버로 전송되나요?
브라우저가 선택한 파일을 읽고 전용 Worker 안에서 분석합니다. 원문은 업로드하지 않으며 분석 이벤트에는 실행 방식과 집계 수치만 기록하고 입력 내용은 넣지 않습니다.
대체 문자 경고가 나오면 어떻게 해야 하나요?
U+FFFD는 대개 이 분석 전에 바이트를 잘못 해석했거나 정보가 빠졌다는 뜻입니다. 원본 파일 바이트로 돌아가 인코딩을 확인해야 하며 대체 문자를 세거나 정규화해도 잃은 문자는 복구되지 않습니다.
이 도구를 검증한 방법
관리 및 검수 SimpleWebUtils검토일
검증 방법: “UTF-8 31바이트 표시 이름 필드 시험” 문서 입력을 단어 수 세기에 그대로 넣었습니다. 수행 순서는 “원본 증거를 정확히 보존하기”, “가능한 모든 단위 측정하기”였고 브라우저 결과를 예시 출력과 대조했습니다. 실패 경계는 “문자를 JavaScript length로 가정하기”, “임의의 문자열 slice로 자르기” 두 항목으로 나눠 검토했습니다.
기대 결과: NFC fixture는 grapheme 6개·code point 12개·UTF-16 unit 16개·UTF-8 31바이트였고, 분해형은 정규화 전 32바이트라 문서화된 NFC 저장 계약에서만 허용됐습니다.
검증한 작업 가이드 열기관련 작업 가이드
도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.
작업 가이드
README와 글을 게시하기 전에 Markdown을 안전하게 미리보기
Markdown 미리보기는 모든 게시 환경이 같은 결과를 만든다는 보증이 아니라 게시 전 검토 단계로 사용할 때 가장 유용합니다. 이 절차는 작업 문서를 브라우저에 둔 채 자주 쓰는 확장 문법과 정제된 HTML을 확인하고, 원격 이미지를 명시적인 개인정보 결정으로 다루며, 콘텐츠 마크업과 대상 환경의 스타일을 구분합니다. 마지막에는 내보낸 HTML 조각이나 원본 Markdown을 실제로 게시할 시스템에서 다시 테스트합니다.
작업 가이드게시·초안 비교 전에 텍스트 측정치를 감사하는 방법
편집자, 연구자, 지원팀, SEO 검토자가 초안의 단어 반복, 목표 구문 과다, 읽기 난이도, 부정적 표현, 다른 버전과의 유사성을 물을 때 사용하는 절차입니다. 분석 전에 단위·언어·정규화·분모·한도·해석을 고정하고 결정론적 근거와 편집 판단을 분리합니다.
작업 가이드재현 가능한 텍스트 픽스처와 장식 샘플을 안전하게 준비하기
테스트, 목업, 터미널 데모, 문서 예시 또는 실패해도 해가 없는 시각 실험에 생성·재배열 텍스트가 필요할 때 사용하는 절차입니다. 구조 작업과 장식을 구분하고, 원문과 구분자 동작을 보존하며, 모든 seed와 제한을 기록합니다. FIGlet·미러·거꾸로·영어 점자 부분집합·Zalgo가 글꼴·보조 기술·검색·복사 환경을 통과하지 못할 수 있으면 항상 평문 대체 내용을 함께 둡니다.
작업 가이드Unicode 계산 단위별 텍스트 길이 제한 검증
신뢰할 수 있는 길이 검증은 대상 시스템의 계약에서 시작해 원본 표현을 보존하고, 여러 Unicode 단위를 측정하며, 정규화와 보이지 않는 문자 fixture를 포함하고, 제한값 전후를 실행한 뒤 저장·전송 결과를 다시 읽어 확인합니다.
관련 도구
관리 중인 다른 작업 흐름을 이어서 사용해 보세요
CRLF, LF 및 혼합 텍스트 파일 줄바꿈 감지기
로컬 파일의 원본 CRLF, LF, CR 및 Unicode 줄 구분자를 셉니다.
텍스트
Markdown 미리보기 | 정제 HTML 변환기
Markdown을 로컬에서 미리 보고 표, 작업 목록, 코드, 수식, 각주가 포함된 정제 HTML을 만듭니다.
포맷팅
텍스트 분석 워크벤치 | 유니코드 빈도, 가독성, 어휘 성향, 유사도
유니코드 분절과 명시적 한도를 적용한 여섯 가지 텍스트 측정을 로컬에서 실행합니다.
텍스트
Unicode 정규화 | NFC·NFD·NFKC·NFKD 비교
코드 포인트 근거와 호환 손실 경고를 제공하는 Unicode 정규화 도구입니다.
인코딩
제로 폭 문자를 안전하게 검사하고 제거하기
제로 폭 제어 문자 6종의 위치를 찾고 승인한 종류만 제거합니다.
텍스트