IOSOR

IOSOR 知識庫

簡訊分段計費：為何一則簡訊不是一筆支出

定價指南：GSM-7 與 UCS-2、多段拼接開銷，以及如何把每次發送與預付錢包逐行對帳，而不是靠猜。

使用者只打了一則訊息，預付錢包卻扣了三個計費單位。這不是故障——而是分段計費。不理解 GSM-7 與 UCS-2、以及多段拼接的財務團隊，會對本就按設計運作的計費引擎開工單。本指南面向營運預付白標訊息的財務與產品負責人，讓支出可解釋，而不是「相信發票」。

IOSOR 把每一行簡訊扣款都還原為段數、編碼與目的地——而不是不透明的平台費。接近每月 USD 1,000+ 平台用量時，分段紀律決定的是乾淨月結，還是反覆出現的「為什麼更貴」升級。

為何一則簡訊不是一筆支出

發送方看到的 錢包看到的
「我發了一則簡訊」 依編碼與長度計費 1–3 個單位
末尾加了一個表情 整則訊息切到 UCS-2
範本變數多了幾個字元 訊息越過了段邊界

GSM-7 與 UCS-2：字元集會改寫數學

  • GSM-7 涵蓋有限拉丁字母與少量符號；每字元占用的「段預算」更低，標準為 160 個字元。
  • UCS-2（GSM-7 以外的字元——表情、多數非拉丁文字、部分標點）會把整則訊息推進更寬編碼，每段字元上限更低，標準為 70 個字元。
  • 一個「看不見」的字元（文件智慧引號、勾選符號、表情）就能靜默把整則從 GSM-7 翻到 UCS-2，即使訊息主體仍以 GSM-7 為主。

多段分割與拼接開銷

編碼 單段上限 多段時每段上限 為何多段更短
GSM-7 160 字元 153 字元 拼接通訊頭占用空間（約 7 字元）
UCS-2 70 字元 67 字元 同樣頭長度，字母預算更小（約 3 字元）

越過單段上限不會「優雅地四捨五入」——訊息拆成多段，每段都帶著拼接通訊頭開銷，並據此重新計費。例如，一則 161 字元的 GSM-7 訊息會被拆成兩段，總計扣款為 2 個計費單位（153 + 8 字元，但實際扣款是兩段的費用）。

段數藏在哪裡

  • 編輯器預覽顯示「1 則訊息」，實際編碼卻產出 2–3 個計費段，尤其當包含表情符號或非拉丁文字時。
  • 範本變數只對部分收件人把長度推過邊界，導致該收件者的訊息被拆分，而其他人則否。
  • 特定語言字元（聲調符號、非拉丁文字）在一種語言的 QA 通過，卻在另一種語言放大成本，因為它們會觸發 UCS-2 編碼。

每一行扣款應顯示：目的地、訊息長度、偵測編碼、段數與單價——而不是一條混合的「簡訊費」。若財務無法把錢包扣款對回這五個欄位，帳本就不是可對帳的，只是憑信仰信任。

  1. 發送前按錢包將採用的同一規則估算編碼與段數，並在主控台預覽。
  2. 範本編輯越過段邊界時發出警告——不要靜默放行，並顯示預計段數。
  3. 在編輯器展示偵測到的編碼 (GSM-7/UCS-2)，而不只是字元數。
  4. 用真實收件人語言測試，不要只測撰寫語言，以捕捉編碼差異。

段數、編碼、目的地區帶與單價——無論發送來自 API、群發活動還是 workshop 測試，呈現都要一致。只寫「簡訊」和總額的預付帳本，是裹著收據外衣的黑箱。

危險信號

  • 編輯器或 API 只報訊息則數，不報段數，或僅提供模糊的段數估計。
  • 看不到某次發送到底用了哪種編碼 (GSM-7 或 UCS-2)，或預設為 UCS-2。
  • 支援說「編碼問題很少見，別擔心」，卻無法提供具體解釋或工具。
  • 帳本行無法追溯到長度、編碼與目的地，僅顯示總金額。
  • 群發按月初估量計費，只在月末才對帳，且對帳時出現大量超出預期的扣款。
  • 未啟用 DLR (Delivery Report) 追蹤，無法確認訊息是否成功送達，進而影響對帳的準確性。
  • OTP (One-Time Password) 發送時，若未嚴格控制長度與編碼，可能因分段而顯著增加成本。

從 IOSOR 開始

請在大型群發前，先於 IOSOR 主控台檢查外寄範本酬載。設定 API 驗證關卡，標記任何超過單一區段或意外從 GSM-7 轉換為 UCS-2 編碼的酬載。確保回報網路鉤子 (webhook) 將餘費用途明確對應至實際計費區段數，而非籠統的訊息數。啟用 DLR 報告，並將其與帳本記錄對比，確保每筆扣款都有對應的送達狀態。對於 OTP 訊息，務必設定「quiet hours」或特定路由，避免在非必要時段觸發高成本的分段發送。

把這條作業寫進同一份運維清單，並在 Live 前再核對一次。 確保預付錢包餘額充足，以避免因餘額不足而導致的訊息失敗或延遲。 監控「corridor」流量，確保在高峰時段也能穩定處理訊息，避免因網路擁塞導致的額外成本或延遲。

IOSOR 要點

一則外寄簡訊很少等同於一筆費用。GSM-7 與 UCS-2 編碼的選擇，加上多部分串接的標頭負載，意味著動態文字的微小變化或單一特殊字元，就能輕鬆使每位收件者的計費倍增。預付錢包的精確對帳，依賴於對每個計費單位的細緻追蹤，從編碼到段數，再到最終的 DLR 狀態。

務必在發送端執行嚴格的字元編碼檢查與範本長度限制。切勿依賴高層級的訊息數預覽或無法追蹤的帳本列，以免掩蓋編碼切換與多區段計費罰款。透過 IOSOR 的 console，您可以清晰地看到每筆交易的細節，確保您的預付錢包支出與實際服務使用情況精確對應，避免不必要的費用浪費。

這篇指南有幫助嗎？

相關指南