校驗和的原理
信用卡號、IBAN、稅號以及加密貨幣地址都包含一兩個根據其他數字計算得出的隱藏位元。只要輸入錯一個字元，運算結果就不會吻合——驗證器正是憑此特性，能在離線狀態下立刻標記出輸入錯誤，無需向銀行或區塊鏈網絡詢問。
何謂校驗和？
校驗和（或檢查位元）是刻意設計的冗餘機制。當數字被產生時，其中一或多個位元並非隨意選擇，而是依照固定規則根據其餘位元計算得出。只要知道該規則，任何人都能重新計算這些位元並加以比對。若結果相符，代表該數字內部一致；若不相符，則表示有輸入錯誤、讀取錯誤或資料損毀的情形。
校驗和僅能保證上述功能而已。它無法證明帳戶是否存在、誰是帳戶持有人，或是帳戶內有什麼資產——本網站的每個驗證器都會反覆強調這一點，因為這兩者很容易被人混淆。
實際範例1——Luhn，信用卡號演算法
Visa、Mastercard以及大多數其他支付卡都採用Luhn演算法。以經典範例7992 7398 713為例：從最右邊的位元開始，每隔一個位元就將其數值乘以2；若乘積為兩位數，則將其各位數字相加。最後把所有數值加總。
| 數字 | 從右邊算起的位址 | 加倍？ | 算作 |
|---|---|---|---|
3 | 校驗位 | — | 3 |
1 | 從右數來第2位 | 1 × 2 = 2 | 2 |
7 | 第3位 | — | 7 |
8 | 第4位 | 8 × 2 = 16 → 1 + 6 | 7 |
9 | 第5位 | — | 9 |
3 | 第6位 | 3 × 2 = 6 | 6 |
7 | 第7位 | — | 7 |
2 | 第8位 | 2 × 2 = 4 | 4 |
9 | 第9位 | — | 9 |
9 | 第10位 | 9 × 2 = 18 → 1 + 8 | 9 |
7 | 第11個 | — | 7 |
右側欄位的數字加總結果為 3 + 2 + 7 + 7 + 9 + 6 + 7 + 4 + 9 + 9 + 7 = 70。70可被10整除，因此該號碼有效。只要更改任意一個數字，總和就會不再為10的倍數。您可以在信用卡驗證上試試看——它會在您的裝置上執行完全相同的運算。
實作範例2 — 加權總和（ISBN-10）
許多國家身份證號碼都採用加權總和機制：將每個數字乘以固定的權重，再將結果加總並檢查餘數。ISBN-10是最清晰的示範。以0-306-40615-2為例，各數字的權重從10遞減到1：
0×10 + 3×9 + 0×8 + 6×7 + 4×6 + 0×5 + 6×4 + 1×3 + 5×2 + 2×1 = 132
132正好是11 × 12，因此對11取模後的餘數為零，該ISBN號碼有效。巴西的CPF、波蘭的PESEL以及數十種其他識別碼都採用相同的模式，只是權重與模數不同——正因如此，一台批次證件驗證就能在一秒鐘內驗證上千個號碼。
實作範例3 — IBAN與模97
國際銀行帳號採用ISO 7064 mod 97-10標準，這是一種更嚴謹的機制，包含兩個校驗位。以標準範例GB82 WEST 1234 5698 7654 32為例：
- 先確認該國家的長度：英國的IBAN有22個字符。✓
- 將前四個字符移到末尾：
WEST12345698765432GB82。 - 將每個字母替換為兩位數字（A = 10 … Z = 35）：W→32、E→14、S→28、T→29、G→16、B→11，最終得到
3214282912345698765432161182。 - 將該數字除以97，餘數必須恰好為1 — 事實上確實如此。
由於97是質數且大於任何兩位數的交換，因此模97機制能偵測出所有單個字符錯誤及順序顛倒的情況；只有約1/97的隨機字串能僥倖通過驗證。IBAN 驗證會顯示每一個驗證步驟是通過還是失敗。
加密貨幣地址：以雜湊值為基礎的校驗和
比特幣與以太坊地址的要求更為嚴格，因為一旦輸入錯誤，資金就會永久性地匯入無人能取用的帳戶。舊版比特幣地址（1…、3…）採用 Base58Check：將地址內容透過 SHA-256 運算兩次，再把結果的前四個位元組作為校驗和附加在後面。只要有一個字元錯誤，就會完全改變雜湊值，因此錯誤被漏過的機率約為四十億分之一。較新的 bc1… 地址則使用 Bech32 或 Bech32m，這是一種錯誤校正碼，能確保偵測出涉及最多四個字元的任何錯誤。以太坊的 EIP-55 則將校驗和隱藏在大小寫字母的排列模式中。
各種校驗機制一覽
| 校驗機制 | 應用範圍 | 可偵測的錯誤類型 | 隨機錯誤被漏過的機率 |
|---|---|---|---|
| Luhn 演算法（模 10） | 信用卡與金融卡、IMEI、多種國家身分證號碼 | 所有個位數錯誤以及大多數相鄰字元交換錯誤 | 約為十分之一 |
| ISO 7064 取模 97-10 | IBAN、部分稅務與公司編號 | 每一個錯誤以及每一次數字順序顛倒 | 約為 1/97 |
| 加權總和，取模 10 或 11 | ISBN-10、巴西 CPF、波蘭 PESEL 以及許多身分證號碼 | 單一錯誤以及大多數數字順序顛倒情況 | 約為 1/10 或 1/11 |
| Base58Check（雙重 SHA-256，4 位元組） | 比特幣舊版地址（1…、3…） | 任何拼寫錯誤，發生的機率極高 | 約為 1/40 億 |
| Bech32 / Bech32m (BCH 編碼) | Bitcoin SegWit 與 Taproot 地址 (bc1…) | 保證：任何錯誤最多只會影響 4 個字元 | 低於十億分之一 |
| EIP-55 (keccak-256 大小寫處理) | Ethereum 地址 | 拼寫錯誤，透過大小寫字母的排列模式來偵測 | 混合大小寫輸入時的錯誤率極低 |
為何驗證器應該在您的裝置上執行？
上述所有運算都是針對您已有的數字進行計算。沒有任何理由讓驗證器將卡號、稅務編號或錢包地址傳送到伺服器——而且有充分的理由不這麼做。本網站上的每個驗證器都在本地執行；離線工具列表將其歸類，而我們的檢查工具是否上傳您資料的指南則說明如何在二十秒內確認任何網站的相關情況。
常見問題
擁有有效的校驗和是否代表該數字是真實或有效的？
不是。校驗和僅能證明這些數字在內部是一致的——也就是說該數字有可能存在。它無法告訴您該帳戶是否開啟、誰是擁有者，或是其餘額是多少。本網站上的每個驗證器都會在頁面上註明此點，因為這種區別很重要。
錯誤數字仍通過校驗的機率有多高？
這取決於所使用的算法。單一 mod-10 校驗位會讓大約 1/10 的隨機錯誤通過；IBAN 的 mod 97 算法則讓約 1/97 的錯誤通過；4 位元的 Base58Check 校驗和則讓約 1/40 億的錯誤通過。重要的是，常見的人為錯誤——即輸入錯誤的數字或數字順序顛倒——都能被這些算法偵測出來。
為何有些識別碼根本沒有校驗和？
較舊或較簡單的算法是為了能在登記處查詢而設計，而非用於離線校驗；有些編號系統甚至早在這種做法出現前就已存在。對於這類識別碼，驗證器只能檢查其長度與格式。
把我的卡片號碼或身分證號碼貼到驗證器中安全嗎？
前提是校驗作業是在你的裝置上執行。校驗和是針對你已有的數字進行運算，因此驗證器沒有任何正當理由將這些數字傳送到伺服器。你可以依照我們《如何確認工具是否會上傳你的資料》指南中所述的飛航模式測試，來確認該工具是否在本地運作。
校驗和、雜湊值與加密技術之間有什麼差別？
校驗是一種用來偵測意外輸入錯誤的短校驗位。密碼學雜湊值是一種很長的指紋，即使是刻意修改也能被偵測出來，且無法還原原始內容。加密技術會將資料轉換，只有憑藉金鑰才能解讀。Base58Check 利用雜湊值來產生校驗和，這就是它極難因意外而出錯的原因。