文字数カウンター

文字数・単語数・行数・バイト数(UTF-8)をリアルタイムでカウント。

Loading…

すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。

使い方

テキストエリアに貼り付けるか入力すると、5 つの数値がリアルタイムで更新されます。総文字数(バイトではなく Unicode コードポイント単位)、空白を除く文字数、単語数(空白区切りで連続する塊)、行数(`\r\n` / `\r` / `\n` のいずれかを区切りとして数える)、バイト数(UTF-8 エンコード後の長さ)です。すべて即時反映 — 送信ボタンもサーバとの往復もありません。

長さが重要な場面で使ってください。メタディスクリプション(Google は約 155〜160 文字で打ち切る)、Twitter 投稿(絵文字対応の 280 文字)、SMS(GSM-7 で 160、UCS-2 で 1 セグメントあたり 70)、YouTube コメント(10000 文字)、厳密な `VARCHAR(255)` 制限のあるデータベース列など。バイト数表示は、「文字数」上限が実は UTF-8 バイト上限であるケースで特に役立ちます。古い MySQL の列や一部 API のクォータでよく見られます。日本語や韓国語のテキストは UTF-8 で 1 文字あたり 3 バイトに膨らむため、100 文字の日本語段落はおよそ 300 バイトになります。

典型的なメタディスクリプション

入力
Open-source web utilities — JSON, Base64, UUID, regex, and more. Everything runs in your browser, no upload required, no signup.
出力
Characters:           134
Characters (no WS):   116
Words:                21
Lines:                1
Bytes (UTF-8):        134

134 文字なので、Google のソフト上限約 160 文字に収まり、ページタイトルの接頭辞分の余裕もあります。文字数とバイト数が一致しているのはテキストが全 ASCII で、各コードポイントが 1 バイトに収まるためです。同じ文を日本語に訳すと、バイト数はおよそ 3 倍に膨らみ、文字数は減ります。

日本語・韓国語 — バイト数と文字数は別物

入力
안녕하세요, 오늘 날씨가 참 좋네요.
出力
Characters:        20
Characters (no WS): 18
Words:             4
Lines:             1
Bytes (UTF-8):     53

可視文字 20、UTF-8 バイト 53(約 2.65 倍に膨張)。各韓国語音節(`안`・`녕`・`하` など)は UTF-8 で 3 バイト、句読点とスペースは 1 バイトずつです。`VARCHAR(20)` の列がこの文字列を受け入れるかは、データベースが文字数(PostgreSQL)で測るかバイト数(古い MySQL の latin1、GBK 系エンコーディング)で測るかに依存します。必ず確認してください。

絵文字と結合文字

入力
👨‍👩‍👧 안녕! café 🌸
出力
Characters:        18
Characters (no WS): 14
Words:             3
Bytes (UTF-8):     45

家族絵文字 `👨‍👩‍👧` は **7 コードポイント** ですが(人物絵文字 3 つ + ゼロ幅結合子 2 つ、肌色なしのデフォルト形)、表示は 1 つのグリフです。`café` の `é` は事前合成なら 1 コードポイント、`e` + 結合用アキュート記号なら 2 コードポイントです。`[...text].length` はコードポイント数、`text.length` は UTF-16 コード単位数(家族絵文字だけで 16)を返します。Twitter・Discord・現代の多くのシステムは家族絵文字を 1 として数える書記素クラスタカウントを使い、本ツールのどの数値とも一致しません。

よくある質問

バイト数が文字数より多いのはなぜですか?

UTF-8 は ASCII(U+0000〜U+007F)に 1 バイト、続く約 1900 文字(ラテン拡張・ギリシャ・キリル・ヘブライ・アラビアなど)に 2 バイト、BMP の残り(韓国語・中国語・日本語・その他多くの文字)に 3 バイト、補助面(多くの絵文字・古代文字・希少な CJK)に 4 バイトを使います。純粋な ASCII 英文は 1 文字 1 バイト。日本語は 1 文字 3 バイト。絵文字だらけの文では可視グリフあたり 4 バイト + ZWJ シーケンスのオーバーヘッドが加わります。ストレージ層や多くの API が測っているのはこのバイト数です。

絵文字のカウントが多すぎるように見えるのはなぜですか?

本カウンタは Unicode の *コードポイント数* を測っており、可視の *書記素* 数ではありません。`👨‍👩‍👧‍👦`(4 人家族)のような 1 つの絵文字グリフは、実際には 7 コードポイント(人物絵文字 4 + ゼロ幅結合子 3)です。ユーザが「1 文字」として見る書記素クラスタを得るには `Intl.Segmenter` API(または `grapheme-splitter` のようなライブラリ)を使います。Twitter・Discord・現代の SNS は書記素を数えるためコードポイントとは合いません。書記素数が必要なら、Twitter の下書き欄に貼り付けて実際の数字を確認するか、DevTools で `Array.from(new Intl.Segmenter("en", { granularity: "grapheme" }).segment(text)).length` を実行してください。

スペースのない言語(中国語・日本語)で「単語」はどう数えますか?

数えません。本カウンタは空白で分割するため、空白のない日本語文は長さに関係なく 1 単語として数えられます。真の単語分割には形態素解析器(日本語は kuromoji、中国語は jieba、韓国語は KoNLPy など)が必要で、言語依存です。CJK コンテンツでは文字数こそが長さの意味ある指標で、出版社(NHK・朝日・読売など)が伝統的に翻訳料を請求してきた単位であり、Twitter が CJK 投稿を重く扱う仕組み(1 文字 = 2 文字分として 280 文字制限に算入、実質上限は CJK で 140 文字)とも一致します。

知っておくべき主な長さ制限は?

**SEO メタディスクリプション**: 約 155〜160 文字で Google が打ち切ります。**HTML の `<title>`**: デスクトップで約 60、モバイルで約 50。**Twitter / X**: 280 文字(CJK は 2 倍重みづけで実質 140)。**Bluesky**: 300 文字。**Mastodon**: 既定 500 文字(インスタンスごとに設定可能)。**SMS**: GSM-7 で 160 文字、UCS-2(Unicode)で 1 セグメントあたり 70 文字。これを超えると複数セグメントに分割され、それぞれ別料金です。**YouTube コメント**: 10000 文字。**GitHub コミットメッセージ**: 厳密な上限はないが 50 / 72 の慣例(件名 / 本文の折り返し)。**データベースの VARCHAR**: 状況依存 — MySQL の `VARCHAR(255)` はバイト数(古い設定)か文字数(現代の utf8mb4)かで違うため、列の文字セットを確認してください。

末尾の改行は行数にどう影響しますか?

末尾の `\n` はカウントを 1 増やします。改行のあとに空行ができるためです。`hello\nworld` は 2 行で、`hello\nworld\n` も多くのエディタでは 2 行ですが、本ツールが採用する「区切り文字で分割して数える」方式では 3 行になります。分割が `["hello", "world", ""]` の 3 要素を返すためです。POSIX のテキストファイルは慣例として `\n` で終わりますが、「内容のある行数」を数えたい場合は `wc -l`(末尾の改行を明示的に数える)と同じ数字が欲しいはずです。下流の消費者の慣例に合わせて選んでください。

トークン数(LLM のコンテキストウィンドウ向け)も数えられますか?

本ツールでは扱いません — トークン化はモデル固有です。OpenAI は tiktoken(BPE)、Anthropic Claude は別の BPE 変種、Google Gemini や Llama はそれぞれ独自のトークナイザを持ちます。経験則は 1 トークン ≈ 英語 4 文字 ≈ CJK 0.5 文字なので、本ツールの文字数を 4 で割ると英語の概算が得られます。正確に数えたいなら OpenAI の `tiktoken` ライブラリをローカルで動かすか、プレイグラウンドを使ってください。Anthropic なら `count_tokens` エンドポイントを使えます。

関連する概念

「このテキストはどのくらいの長さか」は見かけより重層的な問題です。同じ文字列に対して合理的な答えが 5 つあります。**バイト数** はストレージの尺度で、UTF-8 エンコード後の長さです(`wc -c` の戻り値)。**コード単位** は多くの文字列型のインメモリ表現の尺度で、JavaScript や Java の UTF-16 では `"hello".length` は 5 ですが `"𐀀".length` は 2 です(補助面の 1 文字が 2 コード単位を占める)。**コードポイント数** は Unicode の抽象尺度で、JavaScript の `[...str].length` や `wc -m` が返す数値です。**書記素数** はユーザに見える尺度で、`👨‍👩‍👧‍👦` は書記素 1 だがコードポイント 7。`Intl.Segmenter` がこの数を提供します。**単語数** はラテン系では空白区切り、CJK では形態素区切りであり、どのツールも全言語で正しく数えるのは不可能です。

この差は「文字数制限」が課されるあらゆる場面で意味を持ちます。280 文字の Twitter 投稿は書記素であり、コードポイントでもバイトでもありません。MySQL の 255 文字 `VARCHAR` は、列が `latin1` ならバイト、`utf8mb4` なら文字です。SMS の制限は 1 セグメントあたり GSM-7 で 160 セプテット、UCS-2 で 70 コード単位です。ブラウザはメタディスクリプションを文字数ではなくピクセル幅で視覚的に切り詰めるため、`Wide W` ばかりの文字列は `iiiiii` より早く切れます。下流の消費者に合った尺度を選ぶほうが、「きりの良い」丸め数字を選ぶより役立ちます。

隣接する 3 つの概念があります。**正規化**(NFC と NFD)はコードポイント数に影響します。`é` は NFC では 1 コードポイント、NFD では 2 コードポイントなので、比較前の正規化が重要です。**双方向(bidi)テキスト** は左から右と右から左のスクリプトを混在させます。カウントは変わりませんが視覚的長さは直感に反します。**幅**(等幅フォント時)は East Asian Width に依存します。全角の韓国語文字はターミナルで 2 桁、半角ラテン文字は 1 桁を占めます。`wcwidth` 系の関数がこれを表現します。

関連ツール