一串以兩個英文字母開頭的帳號字元，通常就是 IBAN。它的外觀看起來只是字母與數字的排列，但這串字元其實被切成幾段有意義的部分，而其中最外層的那道校驗，用的是模 97 家族的算法。本文說明 IBAN 結構的公開規則，以及拆開來看時每一段各自在說什麼。
IBAN 的結構分成哪幾段?
依國際標準公布的結構，IBAN 從左到右分成三段。第一段是兩個英文字母的國家代碼，指出這個帳號屬於哪一個國家的登記體系。第二段是緊接在後的兩位數字，也就是 ISO 校驗位，用來驗證整串字元的自洽性。第三段是 BBAN，也就是實際的帳戶識別部分。
關鍵在於第三段。國際標準規範了前兩段的角色與整體的校驗方式，但 BBAN 的內部結構與整串的總長度，是由各國自行規定的。換句話說，標準統一的是「外層怎麼驗」，而不是「裡面長什麼樣」。
這也解釋了為什麼討論 IBAN 時，「長度」這個問題必須追問到國家層級才有答案。任何試圖用單一固定長度處理所有國家的做法，都會在遇到別的國家時出錯。
還有一個判斷上的界線值得先畫出來：結構的「公開」並不等於結構的「完整」。國際標準規範的欄位是所有採用該標準的體系都必須具備的，但各國可以在自己的規定裡加入額外的限制，例如某些位置的合法字元更窄、某些前綴不開放。因此一份能驗某個國家的實作，未必能直接套用到另一個同樣採用該標準的國家。
| 段落 | 內容 | 由誰規定 |
|---|---|---|
| 國家代碼 | 兩個英文字母 | 國際標準 |
| ISO 校驗位 | 兩位數字 | 國際標準 |
| BBAN | 帳戶識別主體 | 各國自行規定 |
國家代碼與兩位 ISO 校驗位
國家代碼的功能很直白：它告訴你接下來該套用哪一套 BBAN 規則。少了它，後面的字元就無法被解讀，因為同樣長度的字元在不同國家可能代表完全不同的意思。
兩位 ISO 校驗位則是整串字元的自洽證明。它的值不是任意的，而是由整串字元（包含國家代碼本身）按公開方式算出來的。因此只要有人更動了中間任何一個字元，這兩位數字就會對不上。
值得注意的是，這兩位數字同時也參與後續的計算。也就是說，驗證時是把整個字串一起送進算法，而不是先驗前四段、再驗後面。這種整體綁定的設計，讓局部被改動過的字串很難僥倖通過。
另一個常被問到的問題是大小寫。國家代碼習慣以大寫呈現，但使用者可能貼上小寫，或混著兩種。這屬於正規化的範圍，應該在進入計算之前統一處理，而不是讓算法去接受兩種寫法。
BBAN 裡為什麼還有本國校驗位
BBAN 是各國自己的部分，而許多國家在自己的規則裡又嵌了一層本國校驗位。也就是說，同一串 IBAN 可能同時受到兩套校驗約束：外層的 ISO 校驗位，以及內層屬於該國制度的校驗位。
這在實務上帶來一個具體後果：當校驗不成立時，必須分清楚是哪一層不成立。如果只回報一句「校驗失敗」，使用者完全不知道自己該檢查國家代碼、外層校驗位，還是帳號主體的那一段。分層回報的資訊量遠大於單一結論。
分層回報也讓除錯更容易。外層不成立通常意味著貼上時漏字或多字；內層不成立則比較像是帳號本身抄錯。兩者的處理建議完全不同，把它們混為一談，等於把兩種修法都藏了起來。
還有一種情況是內層校驗位在某些國家並不存在。這時候「內層沒有回報」與「內層不成立」必須用不同的字眼，否則使用者會拼命去找一個制度裡根本沒有的檢查項。
把字母換成數字：mod-97 的算法思路
整串字元裡混著字母與數字，無法直接做算術，所以第一步是把字母按固定規則換成數字，讓整串變成純數字序列。這個轉換是公開且可逆的，目的只是讓後續的加權與取模能夠進行。
接著按規則重新排列字串的順序，再對 97 取模。若餘數落在標準指定的值上，這串字元就通過外層校驗。這裡的重點是思路而不是步驟清單：真正實作時，該做的是照標準公布的方式執行，並用標準或各國公布的樣本自檢，而不是憑印象簡化。
還有一個容易忽略的細節：把整串數字當成一般整數處理，在長度較長時會超出常見整數型別的範圍。這也是這類校驗在實作上比看起來麻煩的原因之一。
實作上的建議是用字串運算處理取模，而不是把整串轉成數值型別。逐段取模或使用支援大數的工具都可以，重點是不要依賴某個語言的整數上限，因為那個上限會隨長度增長而被突破，而且失敗時的錯誤訊息通常不會指向真正的原因。
通過校驗為什麼不代表帳戶存在?
ISO 校驗只證明這串字元自洽，不代表那個帳戶真的存在、屬於誰、能不能收款。「在冊」是另一層完全不同的查詢，需要向對應的登記體系確認，而且會受到對方系統的可用性、回應時間與存取權限影響。
把兩件事混在一起，最常見的後果是錯誤提示寫成「帳號不存在」。當系統其實只是算不出校驗位時，這句提示會讓使用者去改一個根本沒問題的號碼。誠實的說法應該是：格式是否符合、外層校驗是否成立、以及是否已向登記體系確認，這三件事分開講。
想理解這種分態結論的一般原則，可以讀沒有校驗位的號碼；想先看家族層級的比較，讀校驗位演算法家族。
給開發者：長度差異與按國家分流
既然長度與 BBAN 結構逐國不同，實作時就不該在流程裡寫死任何一個國家的形狀。比較穩定的切法是先解出國家代碼，再依它去查對應的長度與結構描述，最後才進入校驗。
- 第一步永遠是正規化：去掉空白與連字號，統一大小寫。
- 第二步只解前兩個字母，先確認國家代碼是否在支援範圍內。
- 第三步用查表得到該國允許的長度與字元集，再比對。
- 最後才計算外層校驗，並在需要時一併回報本國校驗位的結果。
分流之後，新增一個國家就只是加一筆資料，而不是改流程。這對規則會變動的領域特別重要：長度或結構調整時，你只需要更新那一筆描述，不必回頭翻找散落各處的條件判斷。
另外建議把「支援範圍」與「規則內容」分開記錄。前者回答這個國家能不能驗，後者回答怎麼驗。當某個國家的規則暫時不確定時，你可以先把它標成不支援，而不是讓它帶著一份可疑的描述進入流程。
下一步
拿一組明顯是構造值的示範字串，先用紙筆拆出國家代碼、兩位校驗位與 BBAN 三段，再開號碼校驗工具看看它列出的段落是否與你拆的一致。如果它顯示「僅格式」或「無規則」，先確認是不是國家代碼本身就沒有被收錄，而不是急著懷疑帳號。
這裡出現的字串只用來演示 mod-97 的判斷思路，是刻意構造的占位內容，不是任何真實銀行帳戶，也不具備任何可收款或可轉帳的意義。