Dev Tools
回文章列表·5 min

台灣測試資料深入解析:身分證演算法、統編 7 位規則、Luhn 信用卡

在金融科技、電商、政府專案做 QA,大量資料測試是日常 — 但用真實資料測試在 GDPR / 個資法下是違規的。這篇講為什麼需要假資料、台灣官方校驗演算法怎麼算,以及這些資料在 QA 流程的真實應用。

為什麼一定要用假資料(合規面)

台灣個資法第 6 條明確規定:個人身分證字號屬於敏感個資,非經本人同意不得蒐集、處理、利用。內部開發 / 測試環境若使用真實身分證號(即使是員工的),被稽核出來就是違規。

實務上:

  • 金融業 QA:KYC 流程測試需要大量身分證,不能用真的 → 必須產合法格式的假資料
  • 電商:會員系統壓測 1 萬筆假帳號,身分證要過格式驗證
  • 政府 / 醫療 API 整合:沙箱環境需要過格式檢查的測試資料
  • 風控規則測試:模擬不同年齡 / 性別 / 地區的客群

重點:假資料要「格式合法」(過得了驗證器),但內容是假的(對應的真人不存在)。

台灣身分證演算法(內政部官方公式)

10 碼:[A-Z] + [12] + 8 個數字。

步驟:

  1. 字母對應:A=10、B=11、C=12…I=34、O=35、X=30、Y=31、Z=33(I/O 跳出順序是歷史原因)
  2. 把字母拆成兩位數 N1 N2
  3. 加權公式:N1 × 1 + N2 × 9 + d1 × 8 + d2 × 7 + d3 × 6 + d4 × 5 + d5 × 4 + d6 × 3 + d7 × 2 + d8 × 1
  4. 校驗碼 = (10 - 加權和 mod 10) mod 10
  5. 第 2 碼:1 = 男、2 = 女(新住民會用 8、9,本工具不產生)

例:A123456789,A → 10、9 → 18(權重 1+9)、123456789 加權 → 總和 % 10 → 應為 0 才合法。

統一編號(8 位)的官方規則

8 位數,加權 [1, 2, 1, 2, 1, 2, 4, 1]

演算法:

  1. 每位數乘對應權重
  2. 若乘積 ≥ 10,個位與十位數相加(例:7 × 2 = 14 → 1 + 4 = 5)
  3. 全部相加得 sum
  4. 若 sum mod 10 == 0 → 合法
  5. 特殊情況:若第 7 位是 7,則 (sum + 1) mod 10 == 0 也算合法

這個第 7 位是 7 的特殊規則,是國稅局歷史上為了避免亂碼撞號加的。自己寫驗證器一定要記得這條,否則會誤殺合法統編。

本站 TW 測試資料工具 的演算法跟國稅局官方一致,可以直接拿去過大多數驗證器。

Luhn 信用卡演算法(全球通用)

Luhn 是國際信用卡產業通用的校驗碼演算法,Visa / Mastercard / JCB / Amex 都用。也用在 IMEI、加拿大社會保險號等。

步驟(從右往左):

  1. 最右一位是校驗碼,先放著
  2. 從右二開始,每隔一位數字 × 2
  3. 若 × 2 後 > 9,減 9(等價於個位 + 十位)
  4. 所有數字(含校驗碼)相加
  5. 總和 % 10 == 0 → 合法

例:4532015112830366

4 5 3 2 0 1 5 1 1 2 8 3 0 3 6 6
×1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2  (從右算 — 校驗碼這位是 ×1)

Stripe 測試卡號:4242424242424242(Visa)、5555555555554444(Mastercard)— 這些都過 Luhn 但都是專門的測試號碼,Stripe 不會真的扣錢。

QA 真實使用場景

我在金融科技 QA 工作中,這些假資料每天都用:

  • 開戶流程壓測:產 10000 筆過驗證的身分證 + 統編 + 信用卡,用 JMeter / k6 跑開戶 API
  • 風控規則回歸測試:用不同性別 / 地區字母的身分證,確認規則沒誤判
  • 海外用戶 onboarding:測新住民身分證(2 開頭非 1/2)走特殊流程的分支
  • 信用卡綁定:測 Visa / Master / JCB 不同卡頭的 BIN 識別邏輯
  • 資料庫 seed:測試環境一開機,seed 100 筆假帳號讓 QA 跟 PM 進去 demo

重要:tw-test-data 工具上的資料僅供格式測試,不要拿去申辦業務、開戶、註冊真實服務 — 那就變偽造文書。

立刻試:用 TW 測試資料工具 產 100 筆身分證,把結果丟到你公司的驗證器,看是否 100% 通過。

搭配工具
台灣測試資料產生器
開啟工具