단어, 문자, 읽기 시간 계산 _

단어는 어떻게 계산되나요?

이 도구는 사용 가능한 경우 브라우저의 내장 Intl.Segmenter API(Chrome 87+, Firefox 125+, Safari 14.1+)를 사용하여 단어를 계산합니다. 이 API는 유니코드 CLDR에서 파생된 언어적으로 정확한 단어 경계를 가진 라틴어, 중국어, 아랍어, 데바나가리, 일본어, 한국어, 키릴 문자 등 모든 문자 체계를 처리합니다. Intl.Segmenter를 사용할 수 없는 경우 유니코드 문자의 모든 연속에 매칭되는 유니코드 인식 정규 표현식(/\p{L}+/gu)으로 폴백합니다. 대부분의 경쟁 도구는 ASCII 공백을 기준으로 분리하여 라틴 알파벳 외의 텍스트를 조용히 잘못 계산합니다; 이 도구는 그렇지 않습니다.

계산 방법

매 키 입력마다 브라우저에서 6단계가 실행됩니다. 어느 것도 네트워크에 접근하지 않습니다. 전체 파이프라인은 일반적인 단락 길이 입력에 대해 1밀리초 미만으로 실행되며 10만 단어 원고를 프레임 드롭 없이 처리합니다.

1. 텍스트가 textarea에서 읽혀 브라우저 메모리에 저장됩니다 — 아무것도 기기를 벗어나지 않습니다.
2. 문자 수는 JavaScript의 스프레드 연산자([...text].length)를 사용하여 유니코드 코드 포인트를 계산하므로, 🙂 같은 이모지는 내부 UTF-16 인코딩과 관계없이 1문자로 계산됩니다.
3. 단어 수는 granularity: 'word'로 설정된 Intl.Segmenter를 사용하며 isWordLike가 true인 세그먼트를 필터링합니다. 단어 사이에 공백이 없는 중국어와 일본어 텍스트는 글자당 하나의 세그먼트로 계산됩니다.
4. 문장 수는 granularity: 'sentence'로 설정된 Intl.Segmenter를 사용하며, 단순한 마침표 분리보다 약어, 말줄임표, 구두점 엣지 케이스를 더 잘 처리합니다.
5. 단락 수는 하나 이상의 빈 줄(\n\s*\n)로 분리하고 빈 세그먼트를 필터링합니다.
6. 읽기 및 말하기 시간은 단어 수를 설정된 WPM 속도(기본값: 읽기 200, 말하기 130)로 나누고 결과를 분과 초로 형식화합니다.

단어를 계산하는 이유

• 에세이 및 제출 제한. 대학 지원서는 개인 진술을 650단어(Common App), 500단어(대부분의 영국 UCAS 개인 진술), 또는 4,000자(공백 포함)로 제한합니다. 제출 전 글자 수를 아는 것은 마감 직전의 막바지 삭제를 막아줍니다.
• SEO 및 콘텐츠 계획. 검색 품질 팀은 단어 수를 주제 깊이의 대략적인 지표로 사용하며, 1,500~2,500단어 사이의 롱폼 페이지가 경쟁적인 쿼리에서 얇은 포스트보다 지속적으로 높은 순위를 차지합니다. 초안을 작성하면서 수를 추적하면 불필요한 내용 채우기 없이 그 범위를 유지할 수 있습니다.
• 소셜 미디어 크기 조정. X는 게시물을 280자, LinkedIn 아티클을 110,000자, Instagram 캡션을 2,200자, 메타 설명을 대략 160자로 제한합니다. 문자 타일이 플랫폼 편집기에 붙여넣어 잘린 것을 발견하기 전에 정확한 수치를 보여줍니다.
• 녹취 및 프레젠테이션 추정. 분당 200단어의 읽기 시간은 평균 묵독 속도와 일치하고; 분당 130단어의 말하기 시간은 대화체 발화와 일치합니다. 두 수치를 사용하여 팟캐스트 세그먼트 크기를 조정하고, 5분 라이트닝 토크를 계획하거나, 녹음 세션 전에 내레이션 런타임을 추정하세요.

주요 활용 사례

단어 및 문자 계산은 글쓰기, 콘텐츠, 개발 작업 전반에서 등장하며, 도구의 유니코드 인식 엔진은 두 개 이상의 언어로 콘텐츠를 제공하는 팀에게 가장 중요합니다:

• 학술 글쓰기: 논문 챕터 목표를 향한 진행 상황을 추적하거나 제출 전에 초록이 학술지의 문자 제한 내에 있는지 확인합니다.
• 마케팅 및 UX 카피: 제목 줄, 히어로 헤드라인, 또는 CTA 버튼 레이블을 디자이너가 Figma에서 설정한 문자 예산에 맞게 측정합니다.
• 연설문 작성 및 팟캐스팅: 스크립트를 예상 지속 시간으로 변환하여 리허설 날 전에 기조연설이 길게 이어지는지 알 수 있습니다.

단어 수 예시는 어떻게 생겼나요?

이 세 단락 샘플을 예로 들어보겠습니다. The quick brown fox jumps over the lazy dog. 위의 문장은 팬그램으로 — 영어 알파벳의 모든 글자를 포함하고 있어 타이포그래퍼와 폰트 디자이너가 서체 미리보기에 사용합니다. 팬그램은 전보 교환원이 전송 정확도를 테스트하기 위해 짧은 알파벳 완성 문장을 사용하던 19세기까지 거슬러 올라갑니다. 오늘날 폰트 샘플, 키보드 테스트, Figma에서 InDesign까지 모든 디자인 앱의 기본 플레이스홀더 텍스트에 등장합니다. 입력창에 붙여넣으면 지표 타일이 보고합니다: 71단어, 공백 포함 410문자, 공백 제외 340문자, 4문장, 3단락, 200 WPM 기준 약 21초 읽기 시간, 130 WPM 기준 약 33초 말하기 시간. 가장 많이 사용된 단어 패널은 the와 a 같은 불용어를 건너뛰고 지배적인 내용어를 표시합니다. 한국어, 아랍어, 힌디어 텍스트로 전환하면 모든 타일이 해당 문자 체계의 자체 분할 규칙에 맞게 다시 계산됩니다.

단어는 어떻게 계산되나요?

Intl.Segmenter를 지원하는 브라우저(Chrome 87+, Firefox 125+, Safari 14.1+)에서 이 도구는 new Intl.Segmenter(locale, { granularity: 'word' })를 사용하여 isWordLike가 true인 세그먼트를 계산합니다. 이는 중국어, 일본어, 아랍어, 데바나가리 및 다른 모든 유니코드 문자 체계를 올바르게 처리합니다. 구형 브라우저에서는 유니코드 문자의 모든 연속에 매칭되는 폴백 정규식 /\p{L}+/gu를 사용하며, 이는 라틴 문자 언어에서 잘 작동하지만 공백 부재에 관계없이 중국어나 일본어 단어 전체를 하나의 세그먼트로 처리합니다.

MS Word와 수치가 왜 다른가요?

Microsoft Word의 단어 수 알고리즘은 독점적이며 버전에 따라 하이픈 복합어, 축약어, 특수 문자를 다르게 처리합니다. 이 도구는 "won’t"를 하나의 단어(하나의 isWordLike 세그먼트)로 계산하는 반면 Word는 두 개로 계산할 수 있습니다. 대부분의 산문에서 수치는 1~2% 이내로 일치합니다; 하이픈이 많은 텍스트에서는 더 차이가 날 수 있습니다. 소스 텍스트가 동일한 UTF-8 문자열일 때 문자 수는 항상 일치합니다.

비라틴 문자(중국어, 아랍어, 키릴 문자)를 지원하나요?

네. Intl.Segmenter API는 설계상 유니코드를 인식합니다. 아랍어와 히브리어(오른쪽에서 왼쪽 문자 체계)는 올바르게 계산됩니다; 키릴 문자와 그리스어는 일반 라틴 스타일 단어 경계 분리로 계산됩니다; 중국어와 일본어는 해당 문자 체계가 단어 사이에 공백을 사용하지 않기 때문에 글자당 하나의 단어 같은 세그먼트로 보고합니다. 문자 수([...text].length 사용)는 문자 체계에 관계없이 항상 유니코드 코드 포인트를 계산하므로 이모지, CJK 문자, 강세가 있는 라틴 문자 모두 1로 계산됩니다.

텍스트가 업로드되나요?

아니요. 모든 계산은 네이티브 JavaScript API를 사용하여 브라우저 탭 내에서 실행됩니다. Ultim8Soft의 서버나 서드파티 서비스로 아무것도 전송되지 않습니다. 브라우저 개발자 도구를 열고, 네트워크 탭으로 전환하고, 로그를 지우고, 입력창에 입력하여 계산 단계에서 네트워크 요청이 전혀 나타나지 않는 것을 확인하면 검증할 수 있습니다.

이 단어 카운터는 완전히 브라우저에서 실행됩니다. 업로드 없음, 계정 없음, 벤더 라이브러리 없음, 계산된 텍스트에 대한 분석 없음. 어떤 문자 체계의 텍스트든 붙여넣고, 입력하는 동안 7개의 지표 타일이 업데이트되는 것을 보고, 필요한 것을 복사하세요. 이 도구 전체는 한 번 로드되고 첫 방문 후 오프라인에서도 작동하는 약 12 KB의 JavaScript입니다.