よくある質問
バイト数が文字数より多いのはなぜですか?
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` 系の関数がこれを表現します。