バイト・カウンター

テキストを貼り付けて、UTF-8、UTF-16、ASCIIでのバイトサイズを確認します。データベースのカラム制限を確認するのに最適です。

結果

テキストを入力して「バイトをカウント」をクリックしてください。

使い方

  1. テキストを入力または貼り付けます： 任意のテキストを入力フィールドに入力または貼り付けます。
  2. バイト数を確認： このツールは、UTF-8、UTF-16、ASCII、その他のエンコーディングのバイト数を即座に並べて表示します。
  3. 制限を確認： バイト数を一般的な制限（SMS：160文字、HTTPヘッダー：8 KB、データベースフィールドなど）と比較して、コンテンツが収まるかどうかを確認します。

なぜバイトカウンターを使うのか？

文字数とバイト数は同じではありません。1つの絵文字はUTF-8で4バイトになることがあります。中国語とアラビア語の文字はそれぞれ2〜3バイトを占めます。多くのシステムでは、文字数ではなくバイト数の制限が適用されています, MySQLのVARCHARフィールド、Redis値、HTTPヘッダー、SMSメッセージ、クラウドストレージのオブジェクト名などが該当します。バイトカウンターは、各エンコーディングにおけるテキストの実際のバイトサイズを明らかにするため、システムの制約内に収まるようにすることができます。

機能

よくある質問

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

UTF-8では、多くの文字が1バイトを超えるサイズになります。ASCII文字（A〜Z、0〜9、句読点）はそれぞれ1バイトです。拡張ラテン文字（アクセント付き文字）は2バイトです。中国語、日本語、韓国語、アラビア語の文字は通常3バイトです。絵文字は通常4バイトです。

ほとんどのウェブシステムはどのエンコーディングを使用していますか？

UTF-8は、ウェブコンテンツ、APIs、JSON、データベースで主流のエンコーディングです。MySQLとPostgreSQLはデフォルトでUTF-8を使用します。バイト制限を確認する際は、システムが別途指定しない限り、UTF-8の列を使用してください。

なぜSMSメッセージには160文字の制限があるのですか？

従来のSMSは7ビットGSMエンコーディングを使用しており、1セグメントあたり160文字が許容されます。非GSM文字（スマートクォート、絵文字、非ラテン文字など）を含めると、メッセージはUCS-2エンコーディングに切り替わり、1セグメントあたりの制限が70文字に下がります。

バイトとは本当に何か?

1バイトは8ビットで、256の異なる値を保持できます。テキストでは、これら256の値はエンコーディングを介して文字にマッピングされます、「このバイト列はこの文字に等しい」と言うルールブックです。同じバイト列は、異なるエンコーディングの下では全く異なるテキストを意味する可能性があります:バイト0xE9はLatin-1では「é」、UTF-8では3バイト列の開始、UTF-16ではコードユニットの一部です。エンコーディングがすべての物語です。

テキストをディスクに保存したり、ネットワーク経由で送信したり、データベースに格納したりするとき、実際に永続化されるのは文字ではなくバイトです。テキストエディタで見る文字数は、バイトが復号された後、表示時に計算されます。両側のエンコーディングが一致しないと、文字化けが発生します:間違ったエンコーディングで復号されたテキストは意味不明な文字として現れます(Windows-1252のバイトをUTF-8として読んだときの古典的なéの代わりにé)。

バイトカウントは、データベースのカラム制限、HTTPヘッダーバッファ、SMSペイロード、クラウドストレージのオブジェクトキーすべてが測定するものであり、テキストが「どのように見える」かに関係ありません。このカウンターは、あなたが最も気にする可能性のある4つのエンコーディングでバイトサイズを報告します:UTF-8(現代のデフォルト)、UTF-16(Windows / Java / JavaScriptの内部フォーマット)、ASCII(英語ラテンテキストにのみ有効)、Latin-1(単一バイトのレガシーフォールバック)。隣の文字数は参考のために示されています。

UTF-8:その物語

UTF-8は1992年9月2日の夜にベル研究所でケン・トンプソンとロブ・パイクによって、ニュージャージーのダイナーのプレースマットの上で、Plan 9チームがUnicodeのためのASCII互換の可変長エンコーディングを必要とした後に、スケッチされたと伝えられています。デザインには、他のほとんど何も同時に持っていない3つの特性があります:ASCIIテキストは有効なUTF-8でもあります(文字あたり1バイト、同一のバイト)、エンコーディングは自己同期します(任意のバイトの高位ビットが、それが新しい文字を開始するか既存の文字を続けるかを教えてくれます)、そしてバイトオーダーの曖昧さがありません。これら3つの特性が一緒になって、UTF-8がウェブ上のすべての競合エンコーディングを置き換えた理由を説明します。

それは最初に1996年10月のRFC 2044として標準化され、1998年1月にRFC 2279として改訂され、現在のRFC 3629(2003年11月)に置き換えられ、Unicodeの最終的なコードポイント上限U+10FFFFに一致させるためにUTF-8を1文字あたり最大4バイトに制限しました。W3Techsは2010年から公開ウェブのエンコーディング使用を継続的に追跡しています;UTF-8は2011年のウェブサイトの56%から2026年には約98%に増加しました。HTML5仕様は新しいコンテンツにUTF-8を義務付けています;HTTP/2とHTTP/3はHPACK / QPACKを介してUTF-8でヘッダーを送信します;RFC 8259はシステム間のJSON交換にUTF-8を義務付けています。すべてに1つのエンコーディングを選ばなければならないなら、過去15年間の答えはUTF-8であり、今後15年間の答えも同じです。

UTF-8は可変長で、1文字あたり1から4バイトです:

コードポイント範囲 バイト 典型的なコンテンツ
U+0000, U+007F1ASCII文字、数字、一般的な句読点
U+0080, U+07FF2ラテン拡張(é、ñ)、ギリシャ文字、キリル文字、アラビア文字、ヘブライ文字
U+0800, U+FFFF3ほとんどのCJK表意文字、デーバナーガリー、タイ、ハングル、€記号
U+10000, U+10FFFF4絵文字、補助CJK、歴史的文字

実用的な結果:UTF-8の英語テキストは平均で1文字あたり~1バイト;中国語は~3バイト;絵文字が多いメッセージは可視文字あたり4バイトに達することがあり、組み合わせ絵文字(家族ZWJシーケンス)は1文字のように見えるもののために簡単に20-30バイトに達します。

UTF-16とサロゲートの罠

UTF-16はWindows NT(1993)、Java 1.0(1996)、JavaScript(1995)、.NET、Mac OS X Cocoa NSStringに選ばれたエンコーディングでした。Basic Multilingual Plane(U+0000 – U+FFFF)の各文字に2バイトを使用し、その外側のものにはサロゲートペアを使用します:高サロゲート(D800–DBFF)プラス低サロゲート(DC00–DFFF)、合計4バイトです。UTF-16は、ビッグエンディアン(UTF-16BE、FE FF)とリトルエンディアン(UTF-16LE、FF FE)を区別するために、ディスク上にバイトオーダーマーク(BOM)が必要です;Windowsはデフォルトでリトルエンディアンを使用します。

罠:JavaScriptで、"😀".length === 2。MDNは直接述べています:lengthプロパティは「文字列の長さをUTF-16コードユニットで含む」。これが、😄のような単一の絵文字が長さ2を報告する理由です(補助プレーンに住んでいてサロゲートペアが必要)、そして家族ZWJシーケンス👨‍👩‍👧‍👦が長さ11を報告する理由です(4つの2コードユニット絵文字プラス3つのゼロ幅ジョイナー)。同じ1文字の家族絵文字は、各言語の文字列モデルに応じて、JavaScriptで11、Python 3で5、Swiftで1としてカウントされます。JavaScriptで正しい可視文字カウントのためには、字素粒度でIntl.Segmenterを使用してください(2021年以来のすべてのエバーグリーンブラウザ)。

ASCII、Latin-1、Unicode以前の混乱

ASCII(American Standard Code for Information Interchange)はASA X3.4-1963として標準化され、X3.4-1968として改訂され、再びANSI X3.4-1986として改訂されました。7ビットコード、128文字:95印刷可能プラス33制御。33の制御文字にはBEL、BS、CR、LF、DELなどのテレタイプの遺産と、現代のプロトコルで生き残るいくつか(NUL、TAB、LF、CR、ESC)が含まれます。ASCIIは依然としてUTF-8の厳格なサブセットとして機能します、それが「純粋なASCIIテキスト」もまた有効なUTF-8である理由であり、英語のみのシステムにとってUTF-8への移行が無痛だった理由です。

Latin-1 / ISO-8859-1(1987)は、西ヨーロッパのアクセント付き文字、通貨記号、一般的な句読点を追加した、単一バイト256文字の拡張でした。1995年から2008年頃にUTF-8がそれを置き換えるまで、西洋のウェブコンテンツのデファクトエンコーディングでした。Windows-1252はLatin-1のMicrosoftのスーパーセットで、C1制御範囲(0x80-0x9F)に「スマートクォート」、em-ダッシュ、ユーロ記号を追加します;CSVファイルがMacとWindowsの間でメールでやり取りされるとき、それが片方がWindows-1252バイトをUTF-8として読むときの古典的なé文字化けの源です。

MySQL「utf8」の罠

MySQLはバージョン4.1以来、悪名高い文字セットの欠陥を持っています:utf8文字セットエイリアスは実際にはUTF-8ではありません。これは3バイト最大のサブセットで、U+FFFFを超える文字を表現できません、つまり絵文字や補助プレーン文字を保存できません。utf8カラムに「🎉」を挿入すると、sql_modeに応じて「?」またはエラーが発生します。修正はutf8mb4で、MySQL 5.5.3(2010年3月)で追加されました;MySQL 8.0(2018年4月)でutf8mb4が新しいデフォルトになりました。しかし、8.0より前に作成されたスキーマは、まだデフォルトで3バイトバージョンを使用していることがよくあります。ユーザー入力から絵文字が静かに消えていくのを見たら、これがほとんど常に原因です。PostgreSQLには同等の罠はありません、本物のUTF-8をネイティブで受け入れます。

SMS、GSM-7、160バイトのペイロード

160文字のSMS制限は、1985年のFriedhelm Hillebrandの計算に遡ります、GSMワーキングパーティのエンジニアで、伝えられるところによるとタイプライターに座って、ランダムな文を打ち、「ほとんどのメッセージは160文字以下で表現できる」と数えました。160は、7ビットアルファベットを使用して140バイトのペイロードに収まるように逆算されました(140 × 8 ÷ 7 = 160)。エンコーディングの詳細は3GPP TS 23.038(元はGSM 03.38)で正式に定められており、今日もSMS課金を支配しています。

バイトで:単一のSMSは線上で140バイトです。GSM-7では160文字です;UCS-2(GSM-7アルファベットの外側のもののために使用される2バイト固定幅エンコーディング)では70です。マルチパートメッセージは、再組み立てに使用されるUser Data Headerにセグメントあたり7 GSM-7文字または3 UCS-2文字を失います、そのため長いメッセージはセグメントあたり153 GSM-7文字または67 UCS-2文字に制限されます。1つのスマートクォート、em-ダッシュ、または絵文字がメッセージ全体をUCS-2にダウングレードし、セグメントあたりの制限を半分にします。Twilioの「Smart Encoding」は、マーケティングキャンペーンをより安いエンコーディングに保つために、カールしたクォートをまっすぐなものに自動的に置き換えます。

バイト制限が本当に噛むところ

バイト(文字ではなく)制限があなたを捕まえる3つのカテゴリ:

HTTPリクエストヘッダー。正式な仕様の最大値はなく、各サーバーが1つを強制します。ApacheのLimitRequestFieldSizeはデフォルトでヘッダーあたり8 KB;Nginxのlarge_client_header_buffersはデフォルトで4 × 8 KB;IISは16 KB;AWS Application Load Balancerはヘッダーあたり16 KB、合計60 KBを受け入れます;Cloudflareは32 KBを許可します。膨張したクレームセットを持つJWTは日常的にApacheの8 KBデフォルトを超えます、これはトークンベース認証の最も一般的な本番障害モードです。

クラウドオブジェクトストレージキー。S3とGCSはどちらもオブジェクトキーを1024バイトのUTF-8に制限します。Azure Blob Storageはブロブ名を1024文字に制限します(内部UTF-16)。S3の場合、CJKヘビーなファイル名(文字あたり3バイト)は~341文字で上限に達します;絵文字ヘビーなもの(文字あたり4バイト)は~256で、開発者が予想するよりずっと前です。

データベース行とインデックス制限。MySQL InnoDBはDYNAMIC行フォーマットで65,535バイトの行サイズと3072バイトのインデックスキープレフィックス制限(古いCOMPACTでは767)を持っています。VARCHAR(255) utf8mb4カラムは1020バイト(255 × 4)のインデックススペースを必要とします、DYNAMICでは大丈夫、COMPACTでは壊れます。MongoDB BSONドキュメントは16 MBで上限。DynamoDBアイテムは400 KBで上限(属性名を含む)。Redis値は512 MBで上限。

一般的なユースケース

よくある間違い

  1. バイトサイズのためにJavaScriptの.lengthを信頼する。.lengthはUTF-16コードユニットを返し、バイトでも文字でもありません。UTF-8バイトにはnew TextEncoder().encode(text).lengthを使用;可視文字にはIntl.Segmenterを使用。
  2. MySQLのutf8が本当にUTF-8であると仮定する。絵文字を静かに削除する3バイトサブセットです。ユーザー送信のテキストに触れるカラムには常にutf8mb4(およびコレーションにutf8mb4_unicode_ci)を使用してください。
  3. 1つの絵文字が1バイトに等しいと仮定する。単一の絵文字はUTF-8で4バイト、UTF-16で4バイト(サロゲートペア)です。家族ZWJシーケンスは1文字のように見えるもののために30バイトを超える可能性があります。
  4. UTF-8 BOMをコンテンツとしてカウントする。ファイルの先頭の3バイトUTF-8 BOM EF BB BFはメタデータで、テキストではありません。ほとんどのCLIツール(awk、head、sed)はそれを最初のフィールドの一部として扱います、これは多くの「なぜ最初のカラム名に奇妙な文字があるのか」バグの源です。
  5. 非ASCIIテキストに対して「ASCIIバイト」カウントを報告する。ASCIIはU+007Fを超える文字を表現できません。このカウンターは、入力に非ASCIIが含まれているときに警告するので、ASCIIカラムが意味がないことがわかります。

その他のよくある質問

テキスト文字がたった1バイトなのに、なぜ1つの絵文字が4バイトなのですか?

UTF-8はASCII(U+0000からU+007F)に1バイト、ラテン拡張 / ギリシャ文字 / キリル文字 / アラビア文字 / ヘブライ文字(U+0080からU+07FF)に2バイト、ほとんどのCJKおよびインド文字(U+0800からU+FFFF)に3バイト、絵文字および補助プレーン文字(U+10000からU+10FFFF)に4バイトを使用します。😀(U+1F600)のような典型的な絵文字は補助プレーンにあり、4バイトかかります。組み合わせ絵文字(例えば家族👨‍👩‍👧‍👦)は、ゼロ幅ジョイナーで一緒に貼り付けられた複数のベース絵文字から構築されています;各ベース絵文字は4バイト、各ジョイナーは3バイト、なので4人の家族は1文字のように見えるもののために4×4 + 3×3 = 25バイトかかります。

MySQL utf8は実際には何を意味しますか?

MySQLでは、文字セットエイリアスutf8は本物のUTF-8の3バイト最大サブセットです。UnicodeのBasic Multilingual Planeのすべての文字をエンコードできますが、絵文字やU+FFFFを超える文字を保存することはできません。MySQLでの本物の4バイトUTF-8はutf8mb4です、MySQL 5.5.3(2010年3月)以降利用可能、MySQL 8.0(2018年4月)以降デフォルト。スキーマを変更できる場合は、utf8mb4_0900_ai_ciコレーション(または古いサーバーではutf8mb4_unicode_ci)で常にutf8mb4を使用してください。

このカウンターはUTF-8バイトオーダーマークを含みますか?

いいえ。UTF-8バイトオーダーマークは、Windows上のExcelがUTF-8を検出するためにファイルの先頭に必要とする3バイトEF BB BFです。カウンターはあなたが貼り付けるテキストのバイトを測定します;あなたのテキストがたまたまBOMで始まる場合、それらの3バイトはコンテンツとしてカウントされます。ファイルのバイトが制限に達するかどうかを知りたい場合は、ファイルの本文のみを貼り付け、BOMは貼り付けないでください。

なぜ私の中国語テキストはUTF-8で文字あたり3バイトを表示しますか?

ほとんどすべてのCJK表意文字はUnicode範囲U+4E00からU+9FFF(CJK Unified Ideographsブロック)にあり、UTF-8はそれらをそれぞれ3バイトとしてエンコードします。したがって、100文字の中国語文は300 UTF-8バイトです。UTF-16では同じテキストが200バイトです(文字あたり2バイト)、なので主にCJKコンテンツの場合UTF-16はよりコンパクトです。混合ラテンとCJKコンテンツではUTF-8が勝ちます、ラテン文字が2バイトの代わりにそれぞれ1バイトかかるからです。

私のテキストはどこかにアップロードされますか?

いいえ。バイトカウンターはあなたのブラウザで完全に実行されます。UTF-8バイトカウントは標準のTextEncoder APIから来ます(すべての現代のブラウザがサポート)、UTF-16とLatin-1カウントは単純なループから来ます。ネットワークリクエスト、サーバーコール、ロギングはありません。ページが読み込まれると、ツールはオフラインで動作します。APIトークン、内部データ、またはサードパーティのテキストカウンターに貼り付けたくないものを検査するのに安全です。

関連ツール

キャラクターカウンター フリーワード＆文字カウンター・オンライン 読了時間計算ツール 文字列ハッシュビジュアライザー