字串位元組數統計(按編碼方式)

測量輸入的文本在 UTF-8、Shift_JIS、EUC-JP、UTF-16 和 JIS(ISO-2022-JP)編碼下各佔多少位元組。適用於確認資料庫欄位長度限制或舊式表單輸入上限等場景。

字元數與位元組數並非一回事

十個字元佔去三十個位元組,一旦沾上非拉丁文字便是家常便飯。同一串文字,位元組數會隨編碼而變:UTF-8 裡一個漢字佔三個位元組,一個表情符號佔四個;Shift_JIS 裡一個日文字元則只用兩個。本工具會把您輸入的內容,同時按 UTF-8、Shift_JIS、EUC-JP、UTF-16 與 ISO-2022-JP 五種方式,各算出多少位元組。

一併列出的「UTF-16 碼元數」,正是 JavaScript 的 .length 所回傳的那個數。 這是最常被漏看的陷阱:表情符號與某些字元要用兩個碼元組成的代理對來表示,故而人眼算作一個字的東西,.length 會算作兩個。 用 .length 做長度限制時,含表情符號的輸入之所以比預想更早被擋下,緣故就在這裡。資料庫那一側同樣如此——VARCHAR(255) 究竟按位元組還是按字元計,隨產品與設定而異,兩個數字都看在眼裡,判斷便不會出錯。

使用方法

  1. 輸入文字 一貼進去便即刻統計,含換行也無妨。
  2. 對照字元數與位元組數 一個字元在 UTF-8 中照樣可能是三個位元組。
  3. 讀取所關心那一種編碼 看您的儲存或目的地實際所用的那一列便是。
  4. 查看 UTF-16 碼元數 若限制是用 JavaScript 的 .length 施加的,決定結果的正是這個數。

用好本工具的小技巧

  • 在 UTF-8 編碼下,半形英數字每個佔 1 位元組,而平假名、片假名、漢字等日文字元通常每個佔 3 位元組,因此即使字元數相同,英文和日文文本的位元組數也會相差很大。
  • 如果資料庫欄位(如 VARCHAR(255))採用的是舊式基於位元組數的長度限制,包含日文的文本會比同樣字元數的英文文本更快達到上限。
  • 大多數表情符號(emoji)由兩個代理對程式碼單元組成,在 UTF-8 和 UTF-16 中都佔 4 位元組,這也是社交媒體的字數統計有時會比預期更快達到上限的原因。
  • 如果你已經知道位元組數,想將其換算成 KB、MB 等單位,請使用姊妹工具「位元組單位換算」——本工具負責的是從文本反向計算位元組數。

這些情境會用到

防止資料庫欄位溢位

當儲存按位元組設限時,中日文所能容納的還不到您所設想的三分之一。 寫入之前便可核實。

設計表單的輸入上限

它為「按字元設限還是按位元組設限」提供了判斷的材料。

對接老舊系統

在定長檔案與 Shift_JIS 的交換中,位元組數就是欄的位置。

檢驗表情符號的處置

可以確認含代理對的字串,是否被當作您所期望的長度來對待。

字元編碼的術語

UTF-8
以一至四個位元組的變長來表示世上文字的方式。大略而言,ASCII 佔一個,漢字佔三個,表情符號佔四個。
Shift_JIS
面向日文的方式,一個日文字元恰好容納於兩個位元組。 在老系統與定長檔案中至今仍在使用。
EUC-JP
長期用於 UNIX 系統的日文方式。一個日文字元通常佔兩個位元組。
UTF-16
以十六位元為單位表示字元的方式。JavaScript 的字串正是按這種單位來計數的。
代理對
把一個容不下於單個 UTF-16 單位的字元,以兩個單位成對表示的安排。表情符號與某些字元屬於此類。
ISO-2022-JP
以跳脫序列切換字元集的方式,長期用於日文郵件,亦逕稱作 JIS。

常見問題

字元數指的是字串中可見字元的數量,而位元組數表示將該字串作為計算機資料儲存或傳輸時所需的位元組(八位組)數量。對於純 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 個單詞。這是因為一個日文漢字所承載的資訊量遠超一個英文字母。2017 年 11 月,Twitter 將上限放寬到 280,同時引入了加權計數:拉丁字母等字元每個計為 1,中日韓(CJK)文字每個計為 2。這樣英語可以寫滿 280 個字元,而日語實際上仍然是 140 個字,以此縮小語言之間的差距。

手機簡訊也存在類似的現象。標準 GSM 編碼的簡訊每條最多允許 160 個字元,但只要其中包含哪怕一個不在 7 位 GSM 字元集範圍內的字元——比如表情符號或日文字元——編碼方式就會切換為 UCS-2(大致相當於 UTF-16),上限也會驟降到僅 70 個字元。“只用了一個日文字元,可傳送的字數就驟減一半以上”,正是本工具所要測量的字元編碼與位元組數關係的一個生動例證。