貼り付け・入力・推敲

原稿の構造とペースを測定

対話型ワークスペースは複数の単位を並べて報告します。再現可能な言語の前提が必要な場合は、自動ではなく日本語・韓国語・スペイン語・英語・中国語・タイ語を明示的に選択してください。

ワードカウンターを読み込んでいます…

テキストを解析するにはJavaScriptを有効にしてください。下の分割方式、構造の定義、時間のガイダンスはそのまま利用できます。

空白ではなく境界

ロケール対応の単語計数の仕組み

text.split(/\s+/)のような単純な方法は、空白の間のすべての区間を単語として扱います。これはすべての単語の間に空白を置かない文字体系では破綻し、句読点や繰り返しの区切り文字に偶然の意味を与えます。このカウンターはIntl.Segmenterに単語セグメントを要求し、実装が単語様とマークしたセグメントを数えます。

選択したロケールは明示的な分割コンテキストを与えます。自動はブラウザーのロケールネゴシエーションに従い、明示的な選択はja、ko、en、es、zh、thを要求します。同じインターフェースが文の境界には文単位を使います。APIの標準的背景はECMA-402 Intl.Segmenter定義とUnicode Standard Annex #29を参照してください。

これらの標準は、すべての入力に対して1つの永遠の合計を約束しません。Unicodeデータ、ロケール調整、辞書分割、実装定義のisWordLike分類は、ブラウザーエンジンやバージョンによって変わることがあります。計数が契約的な出版・課金業務の一部なら、ロケール、ブラウザー、規則を記録してください。

単語
ブラウザーが単語様と分類したロケール対応セグメント。
文
ロケール対応の文境界分析が返す空でないセグメント。
段落
1つ以上の空行で区切られた空でないブロック。
行
認識されたUnicode改行文字で区切られた論理行。
時間
単語数を選択した読了・発話速度で割った値。

4つの関連する測定

単語・文・段落・行は異なる問いに答えます

指標活用境界規則
単語数編集分量、課題、コンテンツ計画空白分割ではなくロケール対応の単語様セグメント。
文数ペースとおおよその読みやすさ確認ロケール対応の文分割。ピリオドだけですべての事例が決まるわけではありません。
段落数文書構造と流し読み1つ以上の空行で区切られた空でないテキストブロック。
行数台本、字幕、原文、エクスポートCRLFは1つの改行。CR、LF、NEL、U+2028、U+2029も行を作ります。

空の入力は0行です。テキストが存在すれば、認識されたすべての改行が1つの行を終わらせ別の行を始めるため、末尾の改行は意図的に最後の空行を追加します。このインターフェースでは、テキストエリアのHTML動作が解析前にCRLFとCRをLFへ変換します。論理行の合計は変わりませんが、バイト・コードユニットの比較ではこの変換を織り込む必要があります。

透明な経験則

調整可能なペースで読了・発話時間を推定

読了時間と発話時間は同じ単語合計から計算されますが、別々の1分あたり単語数設定を使います。算術は意図的に単純です。単語数を1分あたり単語数で割ります。速度を上げると推定は短くなり、下げると長くなります。

速度は文書の属性ではありません。密度の高い技術文、馴染みのない名前、数式、画面での実演、聴衆の質問、劇的な間、言語学習者のペースは、すべて実際の時間を汎用的な既定値から遠ざけます。コントロールで特定の読者や発表をモデル化し、時間が決まった発表はリハーサルしてください。

多言語テキストでは、単語分割と発話ペースは別々の選択です。日本語やタイ語を選ぶと境界の要求方法が変わりますが、1つの汎用的なWPM値ですべての言語を比較できるという意味ではありません。

プラットフォームの上限が必要ですか?

単語数は編集分量を推定します。ユーザー名、メッセージ、データベース列、APIペイロードは書記素、UTF-16ユニット、コードポイント、バイトを指定することが多いです。

文字数カウンターを開く →

契約を再現可能に

正式な計数にはロケールとエンジンバージョンが必要な理由

  1. 1

    原文を保存

    公開される正確な原稿を数えます。このツールはUnicode正規化、大文字小文字の統一、句読点の書き換えをしません。ブラウザーはCRLF・CRの行末をLFとして露出します。

  2. 2

    ロケールを記録

    他のレビュアーやビルドシステムが前提を再現する必要があるなら、自動ではなく名前付きのロケールを使ってください。

  3. 3

    争点の事例をテスト

    縮約形、ハイフン、略語、絵文字、空白を持たない文字を含む例を選択した環境の回帰事例として保管してください。

ECMA-402は一部の境界の詳細を実装とその国際化データに委ねています。サーバーライブラリ、デスクトップエディター、検索インデックス、ブラウザーは、すべて標準に準拠しながら境界事例で不一致になることがあります。外部の提出ポータルが権威なら、その公開規則と最終表示の合計がこの計画ツールに優先します。

ブラウザーの文字列はローカルに保持

Unicode正規化なしでローカル計数

分析は現在のブラウザータブで実行されます。LiveParseは入力されたテキストを計数サービスに送ったり、サーバー側の文書履歴を作ったりしません。知らないリモートAPIに貼り付けるべきでない下書きに有用であり、ブラウザー拡張・クリップボード管理・デバイスバックアップ・スクリーンショットは別個のプライバシー境界です。

このツールはテキストエリアの値にNFC、NFD、NFKC、NFKD正規化を適用しません。事前合成されたアクセント付き文字と分解された文字+記号の列は区別されたままです。テキストエリアのHTML動作は解析前にCRLFとCRをLFへ変換します。コードポイント・UTF-16・UTF-8の単位は文字数カウンターで確認してください。

JavaScriptの文字列はペアのないUTF-16サロゲートを含むことがあります。ロケール分割はエンジンが保持する文字列を分析できますが、厳密なUTF-8エンコードは孤立したコードユニットをUnicodeスカラー値として保存できません。関連する文字ツールは、このような入力に対してUTF-8バイトを利用不可と報告します。

層を学ぶ

書記素クラスタ、コードポイント、UTF-16コードユニット、UTF-8バイトは、異なる上限・切り詰め動作を持つ別個の単位です。

Unicode長さ単位を比較 →

質問と回答

ワードカウンターFAQ

このワードカウンターは何を数えますか?

選択したロケールで単語様セグメントと文を数え、別々に空でない段落と論理行を数えます。単語数と1分あたり単語数の設定から読了・発話時間も推定します。

ワードカウンターによって結果が違う理由は?

単語の境界は普遍ではありません。句読点、縮約形、ハイフン、絵文字、空白を持たない文字の扱いはカウンターごとに異なります。このツールはブラウザーのロケール対応分割データを使うため、選択したロケールとエンジンが境界事例に影響します。

中国語・日本語・韓国語・タイ語も数えられますか?

はい。中国語、日本語、韓国語、タイ語を選択するか、自動のままでブラウザーの設定に任せられます。ロケール対応の分割が空白だけの分割より適切ですが、ブラウザーのUnicode・辞書データにより結果は変わることがあります。

段落と行はどう数えますか?

段落は1つ以上の空行で区切られた空でないブロックです。分析規則はCRLFを1つの改行として認識し、CR、LF、NEL、行区切り、段落区切りも認識します。空の入力は0行で、末尾の改行は最後の空行を作ります。

読了・発話時間はどう計算されますか?

各推定値は単語数を選択した1分あたり単語数で割ります。聴衆、言語、難易度、間、話し方で実際の時間は変わるため、速度は調整可能で、結果は計画用の推定です。

テキストはアップロードや正規化されますか?

いいえ。計数は現在のブラウザータブで実行され、テキストはアップロードされません。Unicode正規化なしでテキストエリアの値を分析するため、正規化等価な表記が異なるコードポイント数・バイト数を持つことがあります。テキストエリアのHTML動作は解析前にCRLFとCRをLFへ変換します。