文字列のバイト数カウント（エンコーディング別）
入力した文字列がUTF-8・Shift_JIS・EUC-JP・UTF-16・JIS(ISO-2022-JP)でそれぞれ何バイトになるかを計測します。データベースの文字数制限やフォームの入力上限を確認する際に便利です。
Tips
- UTF-8では半角英数字は1バイト、ひらがな・カタカナ・漢字などの日本語は多くの場合3バイトになるため、同じ文字数でも英語と日本語ではバイト数が大きく異なります。
- データベースの列がVARCHAR(255)のようにバイト数ベースで文字数制限を設けている古いシステムの場合、日本語を含む文章は英語の文章よりずっと早く上限に達してしまいます。
- 絵文字の多くはサロゲートペアという2つのコード単位で表現され、UTF-8で4バイト・UTF-16でも4バイトになるため、SNSの文字数カウントで思ったより早く上限に達する原因になります。
- すでにバイト数の数値が分かっていて、それをKB・MBなど他の単位に変換したい場合は、姉妹ツールの「バイト単位変換」をご利用ください。このツールは文字列からバイト数を求める逆方向の計算を担当します。
よくある質問
余談ですが ― SNSの文字数制限とバイト数の知られざる関係
古いバージョンのMySQLで使われていた「utf8」文字セットは、実はUnicodeの絵文字（U+10000以降の補助文字面）を保存できない仕様でした。UTF-8は本来4バイトまでの可変長エンコーディングですが、MySQLの「utf8」は歴史的経緯から最大3バイトまでしか扱えず、絵文字を含む文章をINSERTしようとするとエラーになる不具合が長年報告されていました。現在は4バイトまで正しく扱える「utf8mb4」への移行が推奨されており、文字コードとバイト数の仕様を正確に理解しておくことの重要性を示す代表例になっています。
かつてTwitter（現X）が140文字制限を採用していた時代、日本語ユーザーは140文字でも十分に長い文章を書けるのに対し、英語ユーザーは140文字では単語数にして20〜30語程度しか書けず不公平だという議論がありました。これは英語がアルファベット1文字＝1文字なのに対し、日本語は漢字1文字に多くの情報量が詰まっているためです。後にTwitterは日本語などの言語を「1文字＝1カウント」、英語などを一部「2バイト＝1カウント」で計算する独自の重み付け方式を導入し、言語間の公平性を調整しました。
携帯電話のSMSにも同様の事情があります。GSM方式のSMSは1通あたり通常160文字までですが、絵文字や日本語など7ビットGSM文字セットに含まれない文字を1つでも含むと、エンコード方式がUCS-2（UTF-16相当）に切り替わり上限が70文字まで一気に減少します。「日本語を1文字使っただけで送信可能な文字数が半分以下になる」という現象は、まさにこの記事のテーマである文字コードとバイト数の関係が引き起こす典型例です。