🔤 字數／字元計算器

📖 深入了解：字數、字元數與位元組數的差異

字數 vs 字元數 vs Byte 數：中文使用者特別需要搞懂的差異

英文的「字數（word count）」通常是用空白把單字隔開來算，一個句子有幾個單字一目瞭然；但中文沒有空白分隔，每一個中文字本身就承載完整的意義，所以中文語境下講的「字數」，實務上大多是指「字元數」——也就是每一個中文字、標點符號都算一個單位。這也是為什麼本工具把「字數（含空白）」與「字元數」這兩個數字都列出來：一般情況下兩者數值相同，差異只會出現在使用 emoji 或部分少見符號時——因為電腦內部（JavaScript 字串）是用 UTF-16 編碼儲存文字，多數 emoji 在編碼上其實是由兩個「代理對（surrogate pair）」組成，如果用最原始的編碼長度去算，一個 emoji 可能會被算成 2，但如果用正確辨識 Unicode 字元邊界的方式去算，同一個 emoji 就會正確算成 1。除了字元數，還有一個更容易被忽略的維度是「位元組數（byte count）」：在最常見的 UTF-8 編碼下，一個英文字母只占 1 byte，但一個中文字通常要占 3 bytes，這對某些以「位元組」而非「字元」計算長度限制的系統（例如早期簡訊 70 字上限、部分資料庫欄位長度）影響很大——同樣輸入 100 個中文字，佔用的儲存空間可能是輸入 100 個英文字母的 3 倍。

為什麼每個社群平台的字數上限都不一樣

字數上限的設計，反映的其實是每個平台想營造的內容風格與使用情境。X（Twitter）的 280 字元上限，源自它最初設計成「簡短、即時更新」的資訊流平台，逼使用者精簡表達；Threads 的 500 字、Instagram 貼文的 2200 字，則是給圖片配文與長文敘事更多空間；YouTube 影片標題只給 100 字，是因為標題主要用途是在搜尋結果與縮圖旁快速抓住眼球，太長反而會被截斷、也不利 SEO；YouTube 說明欄給到 5000 字，則是因為說明欄常常需要放時間戳、來源連結、字幕資訊等大量補充內容。理解每個平台字數限制背後的「使用情境」，發文時就能更精準地決定要寫長文還是精簡摘要。

中文使用者發文到「英文設計」平台時常見的誤區

很多社群平台的字數上限，最早是以英文使用情境去設計的，但中文的「資訊密度」比英文高很多——同樣是 100 個字元，一段中文能表達的內容量，往往遠超過 100 個英文字母能表達的內容量（因為中文每個字元都是一個完整的音節與語意單位，英文則平均要 4–5 個字母才拼出一個單字）。這代表中文使用者在字元數限制較嚴格的平台（例如 X 的 280 字元）上，實際上擁有比英文使用者更大的表達空間，同一個字數上限，中文版本往往可以塞進更完整的一段話。反過來也要提醒：因為中文資訊密度高，很容易不小心寫超過字數上限而不自覺，所以發文前用計算器先檢查一次，比單純用肉眼估算可靠。

實際範例：同一句話在不同平台的字數表現

以「今天天氣很好，我們一起去海邊玩，順便拍幾張美美的照片留念，晚上再去吃海鮮大餐！」這句話為例，扣掉標點符號後大約是 30 個中文字，加上標點符號後的字元數約 39 字元。這樣的長度放進 X 的 280 字元上限，只用掉不到 14% 的額度；放進 YouTube 影片標題的 100 字上限，也還有很大的空間；但如果把同樣的敘事風格，用英文重寫成語意相近的句子（例如 "The weather is great today, let's go to the beach, take some nice photos, and have seafood for dinner tonight!"），字元數通常會膨脹到 100 字元以上——這正好說明了前一段提到的「中文資訊密度較高」在實際數字上的展現，也是中文使用者常常覺得「同樣講一件事，中文比英文省字」的原因。