字串位元組數統計（按編碼方式）
測量輸入的文本在 UTF-8、Shift_JIS、EUC-JP、UTF-16 和 JIS（ISO-2022-JP）編碼下各佔多少位元組。適用於確認資料庫欄位長度限制或舊式表單輸入上限等場景。
使用提示
- 在 UTF-8 編碼下，半形英數字每個佔 1 位元組，而平假名、片假名、漢字等日文字元通常每個佔 3 位元組，因此即使字元數相同，英文和日文文本的位元組數也會相差很大。
- 如果資料庫欄位（如 VARCHAR(255)）採用的是舊式基於位元組數的長度限制，包含日文的文本會比同樣字元數的英文文本更快達到上限。
- 大多數表情符號（emoji）由兩個代理對程式碼單元組成，在 UTF-8 和 UTF-16 中都佔 4 位元組，這也是社交媒體的字數統計有時會比預期更快達到上限的原因。
- 如果你已經知道位元組數，想將其換算成 KB、MB 等單位，請使用姊妹工具「位元組單位換算」——本工具負責的是從文本反向計算位元組數。
常見問題
字元數指的是字串中可見字元的數量，而位元組數表示將該字串作為計算機資料儲存或傳輸時所需的位元組（八位組）數量。對於純 ASCII 文本，兩者數值相同；但對於包含日文等多位元組字元的文本，位元組數可能是字元數的好幾倍。
UTF-8 是每個字元使用 1 到 4 位元組的可變長編碼方式，大多數日文字元（平假名、片假名、常用漢字）佔 3 位元組。而 Shift_JIS 大多數日文字元只佔 2 位元組，因此同樣的日文文本在 UTF-8 下通常比 Shift_JIS 下佔用更多位元組。
這取決於資料庫引擎以及欄位的字元集設定。MySQL 的 VARCHAR(n) 基本上是按“n 個字元”限制的，但內部通常還存在獨立的位元組數限制（例如索引可用的最大鍵長），因此包含表情符號的文本有時會導致報錯。具體行為請參考所使用資料庫管理系統的官方文件。
半形英數字和符號在 UTF-8、Shift_JIS、EUC-JP 中都只佔 1 位元組，而全形字元（平假名、片假名、漢字、全形符號）根據編碼方式不同佔 2 到 3 位元組。同樣是“10 個字元”的文本，全部為半形時只需 10 位元組，全部為全形時則需要 20 至 30 位元組。
本工具是輸入一段文本，計算該文本在各種編碼下的位元組數。而「位元組單位換算」工具則是輸入一個已知的位元組數（例如 1,500,000 位元組），將其換算為 KB、MB、GB 等單位。想從“文本”求“位元組數”時用本工具，想從“位元組數”換算成“其他單位”時用位元組單位換算工具。
閒話 ― 社交媒體字數限制與位元組數之間鮮為人知的關係
早期版本 MySQL 的 “utf8” 字元集存在一個令人意外的限制：它其實無法儲存 U+10000 以上的 Unicode 補充字元，也就是許多表情符號。UTF-8 本身是支援每字元最多 4 位元組的可變長編碼，但 MySQL 的 “utf8” 出於歷史原因最多隻能處理 3 位元組，導致插入包含表情符號的文本時經常報錯。如今推薦遷移到能正確支援完整 4 位元組範圍的 “utf8mb4”，這是理解字元編碼與位元組數關係在實際應用中重要性的一個經典案例。
在 Twitter（現 X）曾實行 140 字元限制的年代，圍繞語言間公平性曾有過長期爭論：日語使用者用 140 個字元就能表達相當完整的意思，而英語使用者在同樣限制下往往只能寫 20 到 30 個單詞。這是因為一個日文漢字所承載的資訊量遠超一個英文字母。Twitter 後來引入了一套加權計數機制，讓日語等語言按“1 字元 = 1 計數”計算，而部分其他語言的某些字元按“2 位元組 = 1 計數”計算，以此在不同語言之間取得平衡。
手機簡訊也存在類似的現象。標準 GSM 編碼的簡訊每條最多允許 160 個字元，但只要其中包含哪怕一個不在 7 位 GSM 字元集範圍內的字元——比如表情符號或日文字元——編碼方式就會切換為 UCS-2（大致相當於 UTF-16），上限也會驟降到僅 70 個字元。“只用了一個日文字元，可傳送的字數就驟減一半以上”，正是本工具所要測量的字元編碼與位元組數關係的一個生動例證。