银行卡BIN码JSON实战：从卡号校验到降级匹配与数据保鲜

简介：面向前端开发者的银行卡BIN码对照数据集，以JSON键值对组织，可直接嵌入表单校验或支付页面，解决用户输入卡号时无法即时识别发卡行、卡类型与币种的问题。压缩包内共1个json文件，体积约33KB，以六位BIN码为键，对应值记录银行名称、卡类型、货币等字段，结构扁平、解析成本低，便于按需裁剪或导入本地缓存查询。已有1753人学习下载。读者可据此实现输入六位数字即回显发卡行信息、按卡类型分流校验逻辑，以及查不到匹配项时的兜底提示，同时获得一份可直接对照的银行清单，用于测试用例构造与数据更新维护。数据仅含发卡机构标识，不涉及敏感信息，适合在HTTPS通道下加载使用。

1. 一份 BIN 码 JSON 能做什么：从卡号前 8 位读出四件事

风控同学丢过来一个 CSV，十万行卡号，要求半小时内标出每行属于哪家发卡行、是借记卡还是信用卡、卡号有没有录错。没有外网接口，没有生产库权限，手上唯一能给的就是一份 JSON 格式的银行卡 BIN 码表。这种场景下，BIN 表的价值就体现出来了：它本质上是一张前缀字典，把卡号开头 6 到 8 位数字映射到发卡行、卡组织、卡类型、国家与币种，本地查表、毫秒级返回，不依赖任何外部服务。

它解决的是「拿到一串数字，先判断它像不像一张正常的卡」这件事。支付路由要知道走哪条通道，对账系统要按发卡行分组，注册表单要在提交前拦住明显乱填的卡号，测试同学要批量造合规的测试数据——这些活儿都能用同一份表。写这篇东西的起因是身边不少同行把 BIN 表当成一个黑匣子，slice(0, 6)一把梭，结果 19 位卡号识别不出来、同一张卡今天能过明天不能过。第 2 章先把判定边界讲清楚，后面几章落到代码、参数和踩过的坑。

2. 判定边界：6 位还是 8 位，模 10 校验到底能证明什么

2.1 从 ISO/IEC 7812 看 BIN 在卡号里的真实位置

卡号（PAN）不是一串随机数字，它的结构由 ISO/IEC 7812 系列标准定义，从高位到低位大致分四段。第一段是主行业标识（MII），占 1 位，用来区分航空、银行金融、商业金融、医疗等大类；第二段是发卡行识别码，也就是大家嘴里的 BIN，历史上固定 6 位，后来扩展到最多 8 位，标准里的正式叫法是 IIN；第三段是个人账户标识，长度由发卡行自己定；最后一位是校验位，参与模 10 校验。

这张表解释了一个常见困惑：为什么同一份 JSON 里bin字段有的 6 位、有的 8 位。BIN 从 6 位向 8 位迁移是一个持续多年的过程，不同数据源、不同采集时间的记录混在一起很正常。你手上的表如果是近几年整理的，大概率 6 位和 8 位并存，绝对不能假设长度统一。

再补一个容易忽略的点：PAN 总长度标准允许 8 到 19 位，市面上常见的是 13、15、16、19 位。有些老系统硬编码len == 16，遇到 19 位卡直接判非法，这是后面第 5 章要展开的一个坑。

2.2 6 位与 8 位混用，错在哪一步

假设某家发卡行历史上拿到的是 6 位前缀620000，后来把它拆成两个 8 位子段62000001和62000002，分别对应借记和信用两个产品线。如果你的查表逻辑永远只取前 6 位，这两条记录在哈希表里会互相覆盖，谁最后写入谁生效，结果就是同一批卡里借记卡被标成信用卡。

反过来也出错。假如数据源只提供 6 位记录，而你的代码按 8 位精确匹配，table.get(pan[:8])会全部落空，十万行数据跑出来全是「未知 BIN」，排查半天才发现是宽度不匹配。

正确的做法是降级匹配：先按 8 位查，查不到退到 7 位，再退到 6 位，并且把命中的宽度一块返回。宽度本身携带信息量——8 位命中说明数据源覆盖到了细粒度号段，6 位命中只能说明大方向对，置信度要打折。我在风控侧一般会给 8 位命中打满分、7 位次之、6 位再降一档，具体权重看业务容忍度。

提示：降级顺序必须是长到短。反过来先查 6 位，一旦命中就返回，就等于主动放弃了 8 位记录能提供的区分度。

2.3 模 10 校验的证明力：它只证明「不像手滑打错的」

Luhn 模 10 校验是所有卡号校验里最容易被高估的一环。算法本身不复杂：从最右位往左，偶数位（从右数第 2、4、6… 位）乘 2，乘积大于 9 就减 9，全部相加，总和能被 10 整除即通过。

它挡住的是单字符录入错误和相邻位颠倒，大约能过滤掉七成的随机手滑。但它挡不住伪造——随便凑一串满足校验位的数字在算法层面完全合法。所以校验通过只能说明「这串数字不像打错的」，不能说明这张卡真实存在、没有挂失、额度够用。反过来，校验不通过也不一定是假卡，某些内部测试号段、部分非标准发卡体系就不遵循这套规则。

工程上的结论很直接：把模 10 当成格式校验的一环，和长度检查、BIN 匹配并列，但不要把它当成真实性验证。字段设计里我一般会带一个luhn布尔值，因为少数号段在数据源里明确标注不走校验，硬套算法会误杀。

2.4 一份能落库的 BIN 记录该长什么样

原始 JSON 的字段命名各家不同，card_type/type、bank/issuer、brand/network混着来。加载时做一次字段归一，比在业务代码里到处做兼容要省事得多。

pan_lengths这个字段值得单说。它让长度校验从「全局允许 8 到 19 位」收紧成「这个 BIN 只允许 16 位或 19 位」，误判率会明显下降。如果数据源没给，退化成默认集合(16,)也比不校验强，只是要接受一定的漏判。

3. 把 JSON 装进内存：字段清洗、前缀索引与降级匹配

3.1 读取：先兼容外层结构，再谈性能

同一份「JSON 格式 BIN 大全」在不同来源里可能有三种外层结构：裸数组、{"data": [...]}、以 BIN 为键的对象。直接json.load然后按下标取，遇到结构不符就是一场空。第一步做结构探测和字段归一。

import json from typing import Any, Dict, Optional BIN_MIN, BIN_MAX = 6, 8 def _norm_bin(value: Any) -> Optional[str]: """把各种写法的 BIN 收敛成 6~8 位纯数字字符串""" if value is None: return None s = str(value).strip().replace(" ", "").replace("-", "") if not s.isdigit() or not (BIN_MIN <= len(s) <= BIN_MAX): return None return s # 注意不要转 int，前导零会丢 def load_bin_table(path: str) -> Dict[str, dict]: with open(path, "r", encoding="utf-8") as f: raw = json.load(f) # 兼容三种常见外层：裸数组 / {"data": [...]} / {"bins": {...}} if isinstance(raw, dict) and isinstance(raw.get("data"), list): records = raw["data"] elif isinstance(raw, dict) and isinstance(raw.get("bins"), dict): records = [{"bin": k, **v} for k, v in raw["bins"].items()] else: records = raw table: Dict[str, dict] = {} dropped = 0 for rec in records: code = _norm_bin(rec.get("bin")) if code is None: dropped += 1 continue table[code] = { "bin": code, "brand": str(rec.get("brand") or rec.get("network") or "").upper(), "type": str(rec.get("type") or rec.get("card_type") or "unknown").lower(), "issuer": rec.get("issuer") or rec.get("bank") or "", "country": rec.get("country") or "", "pan_lengths": tuple(rec.get("pan_lengths") or (16,)), "luhn": bool(rec.get("luhn", True)), } if dropped: print(f"[warn] 丢弃 {dropped} 条非法 BIN 记录") return table

几个参数要交代清楚。_norm_bin里坚持返回字符串而不是整数，是因为 BIN 可以以 0 开头（MII 为 0 属于标准分配段），转成int会丢掉前导零，后续pan.startswith(bin)永远失败。pan_lengths统一转成 tuple 而不是 list，tuple 可哈希，方便后面做缓存 key。dropped计数不是摆设，它是数据质量的第一道观测口——如果一份表加载完丢弃率超过 1%，大概率是字段名对不上或者混进了区间格式的记录。

性能方面，十万条以内的表用内置json.load完全够，单次加载几百毫秒量级。真正需要注意的是解析后的内存膨胀：JSON 文本 20MB，转成 Python 字典嵌套结构后占用往往是文本体积的 5 到 10 倍。内存紧张的环境要么裁剪字段（issuer这种只用于展示的可以先不入表），要么换成按需加载。

3.2 建索引：哈希表是默认解，区间数据才需要二分

绝大多数 BIN 表是「精确前缀」形式，一条记录对应一个 6/7/8 位数字串。这种数据用dict就是最优解，单次查找微秒级，实现成本最低，没必要上什么前缀树。我见过有人为了「显得专业」手写 Trie，结果内存翻了三倍，查询速度没提升——因为哈希表的比较是 O(1)，Trie 的深度遍历反而有常数开销。

真正需要特殊处理的是区间式数据源，记录形如bin_start=400000, bin_end=400099。这种数据用哈希表查不了，得先按起始值排序，再二分。

import bisect from typing import Optional, Tuple, List def build_range_index(records: List[dict]) -> Tuple[List[int], List[tuple]]: rows = sorted( ((int(r["bin_start"]), int(r["bin_end"]), r) for r in records), key=lambda x: x[0], ) return [r[0] for r in rows], rows def lookup_range(pan_digits: str, index) -> Optional[dict]: starts, rows = index n = len(pan_digits) for width in (8, 7, 6): # 与精确表保持同样的降级顺序 if n < width: continue key = int(pan_digits[:width]) i = bisect.bisect_right(starts, key) - 1 if i >= 0: s, e, rec = rows[i] if s <= key <= e: return {**rec, "matched_width": width} return None

这段代码有一个隐含前提：区间之间不重叠。bisect_right - 1只能定位到「起始值小于等于 key 的最后一个区间」，如果两个区间互相覆盖，它会漏掉前面那个。真实数据里跨行共用号段、历史号段未清理的情况并不少见，所以建索引前应该先做一次区间合并，或者老老实实退化成扫描。我在生产里吃过这个亏，某批数据里有两个区间的起始值相同，排序后顺序不稳定，跑出来的结果时对时错，排查了大半天。

3.3 降级匹配：8→7→6 的顺序和提前返回

精确表的查询逻辑短，但细节不少。核心是把「宽度」和「命中记录」一起返回，让上层能根据命中宽度决定置信度。

from typing import Dict, Optional def match_bin(pan_digits: str, table: Dict[str, dict]) -> Optional[dict]: """pan_digits 必须是已归一化的纯数字串""" n = len(pan_digits) for width in (8, 7, 6): if n < width: continue rec = table.get(pan_digits[:width]) if rec is not None: return {**rec, "matched_width": width} return None

if n < width: continue这行不能省。有些短卡号只有 8 位，前 8 位就是全号，此时 7 位、6 位的前缀依然有意义；但如果输入只有 6 位，去取前 8 位会得到 6 位字符串，虽然dict.get不会报错，但语义上已经错了，容易掩盖上游的脏数据。{**rec, ...}的写法会复制一份字典，好处是调用方改返回值不会污染原表，坏处是高频调用时多一次分配——十万次批量跑下来差异肉眼可见。对性能敏感的场景可以改成返回(rec, width)元组，让调用方自己决定要不要复制。

3.4 返回值约定：把「不确定」也表达出来

接口设计上最容易犯的错是只返回「命中/未命中」两态。实际业务里「BIN 没查到但格式合法」和「BIN 查到但长度不对」是两回事，前者可能是新号段，后者大概率是脏数据，处理策略完全不同。我的做法是让匹配层只负责查表，返回{bin, brand, type, issuer, pan_lengths, luhn, matched_width}或None，状态判定交给上层的校验函数，职责分开，测试也好写。

线程安全方面，加载完成后这张表就是只读的，多线程并发查dict在 CPython 下是安全的（GIL 保护读操作），不需要加锁。真要更新数据，整体替换引用而不是原地修改，避免读到一半表被改了。

4. 接入业务链路：清洗、分级、批量校验的完整实现

4.1 归一化：空格、连字符、全角数字和掩码卡号

真实输入从来不是干净的数字串。用户从各种地方复制粘贴，可能带空格、带连字符、带全角数字，日志导出后还可能带****掩码。归一化要做的第一件事是字符层面的收敛。

import re import unicodedata MASK_CHARS = set("*xX#•·") def normalize_pan(raw) -> str: """只做字符归一，不做长度与合法性判断""" if raw is None: return "" s = unicodedata.normalize("NFKC", str(raw)) # 全角数字、全角符号转半角 s = re.sub(r"[\s\-_.·]", "", s) # 常见分隔符 return s def is_masked(s: str) -> bool: return any(ch in MASK_CHARS for ch in s)

unicodedata.normalize("NFKC", ...)这一行解决的是最隐蔽的问题：从某些网页或文档里复制出来的数字是全角字符，"１２３".isdigit()返回True，但ord('１') - 48得到的不是 1，直接丢进模 10 校验会算出莫名其妙的结果。NFKC 归一化会把全角转半角、把各种兼容字符统一，属于零成本的必要步骤。

掩码卡号要单独处理。is_masked判断出来之后，不能直接送进校验，也不能简单丢弃——风控场景下掩码卡号本身有价值，可以只取可见前缀做 BIN 匹配。我在批处理里对掩码数据的策略是「只匹配、不校验」，返回状态里显式标出来。

4.2 三道闸：长度、前缀、校验位，顺序很重要

校验逻辑的顺序会影响错误信息的可读性和计算成本。我的习惯是先做最便宜的检查：非数字 → 长度越界 → BIN 匹配 → 长度集合匹配 → 模 10。BIN 匹配放在模 10 前面，因为查表比逐位计算便宜，而且能给出更有意义的错误原因。

def luhn_ok(digits: str) -> bool: total = 0 for i, ch in enumerate(reversed(digits)): d = ord(ch) - 48 if i & 1: # 从右数第 2、4、6… 位加倍 d <<= 1 if d > 9: d -= 9 total += d return total % 10 == 0 def validate_pan(raw, table: Dict[str, dict]) -> dict: digits = normalize_pan(raw) if not digits or not digits.isdigit(): return {"status": "INVALID", "reason": "non_digit"} if not (8 <= len(digits) <= 19): return {"status": "INVALID", "reason": "length_out_of_range"} hit = match_bin(digits, table) if hit is None: return {"status": "UNKNOWN_BIN", "pan_len": len(digits)} if len(digits) not in hit["pan_lengths"]: return {"status": "SUSPECT", "reason": "length_mismatch", "bin": hit} if hit["luhn"] and not luhn_ok(digits): return {"status": "SUSPECT", "reason": "luhn_failed", "bin": hit} return {"status": "HIT", "bin": hit}

i & 1比i % 2 == 1快一点点，含义是从右往左数第二位开始加倍，这个位置关系一定要对——写反了会导致所有卡号都校验失败，或者反过来让大量假号通过，属于那种上线才发现的错。hit["luhn"]为False时跳过校验，是给特殊号段留的后门。

4.3 结果分级：四种状态和它们的下游动作

状态设计决定了这份数据在下游怎么用。四态划分在我经手的几个系统里都够用，再细就是过度设计。

SUSPECT这一档最容易被砍掉，很多人图省事把长度不符和校验失败都归到INVALID。但这两类的业务含义差得远：长度不符可能是老系统截断了卡号，校验失败可能是用户手输错了一位，都不是「恶意伪造」，直接拒绝会误伤正常用户。UNKNOWN_BIN更不能当非法处理，新号段上线总有一段时间数据源没跟上。

4.4 批量任务：十万行 CSV 的吞吐与内存

批量场景和单条校验的差别在 IO 和内存，不在算法。核心原则是流式读写，别把整个文件读进列表。

import csv from collections import Counter def batch_validate(in_path: str, out_path: str, table: Dict[str, dict]) -> Counter: stat = Counter() with open(in_path, newline="", encoding="utf-8") as fin, \ open(out_path, "w", newline="", encoding="utf-8") as fout: reader = csv.DictReader(fin) writer = csv.writer(fout) writer.writerow(["pan_masked", "status", "bin", "brand", "type", "issuer"]) for row in reader: res = validate_pan(row.get("pan", ""), table) stat[res["status"]] += 1 pan = normalize_pan(row.get("pan", "")) # 只保留前 6 后 4，中间打码，避免完整卡号落盘 masked = pan[:6] + "*" * max(len(pan) - 10, 0) + pan[-4:] if len(pan) > 10 else pan b = res.get("bin") or {} writer.writerow([masked, res["status"], b.get("bin", ""), b.get("brand", ""), b.get("type", ""), b.get("issuer", "")]) return stat

DictReader迭代时逐行解析，内存占用和文件行数无关。stat用Counter统计各状态数量，跑完打一行就够了，比在循环里打日志强得多。掩码那段逻辑要注意边界：长度不超过 10 位的卡号打码后会丢失全部信息，此时原样输出反而更合理，因为短卡号本身就不是真卡。

如果数据量上到千万行，单进程就不够了。多进程方案里有个坑：每个子进程都复制一份 BIN 表，十万条记录乘以进程数，内存直接翻倍。Linux 下fork启动的子进程能共享父进程内存页（写时复制），前提是表在fork之前加载好且之后只读；Windows 下没有这个机制，得考虑multiprocessing.shared_memory或者干脆换成一个查表服务。这一点在第 5 章还会提到。

5. 避坑排查：五条踩过的坑与现象、原因、解决

5.1 现象：同一张卡昨天识别正常，今天变成未知 BIN

原因：数据源做了一次全量更新，把 6 位记录替换成了 8 位细分记录，而查表逻辑当时只做了 6 位匹配，新表里根本没有 6 位键。

解决：把匹配逻辑固定成 8→7→6 的降级顺序，并且在数据更新后跑一次覆盖率回归——用固定的样本集统计UNKNOWN_BIN占比，波动超过 1 个百分点就拦下来人工看。后来我把这条规则写进了更新脚本，数据源再换格式也不会静默失效。

5.2 现象：19 位卡号全部校验失败，16 位正常

原因：校验函数里硬编码了if len(pan) != 16: return False，是从某个只处理标准卡的老模块抄过来的。19 位卡在模 10 计算时被提前截断，最后一位校验位压根没参与。

解决：长度判断从「等于 16」改成「在 8 到 19 之间」，并且额外用pan_lengths做 BIN 级约束。改完之后还要补一条回归用例，专门覆盖 19 位输入，否则同样的错很容易在别的地方复现。

5.3 现象：明明是借记卡，被标成了信用卡

原因：数据里同一个 6 位前缀对应两条记录，一条借记一条信用，分别带 8 位细分。加载时用 6 位做键，后写入的把先写入的覆盖了，而 JSON 数组的顺序恰好是信用在后。

解决：加载时如果发现键冲突，不要静默覆盖，打一条警告并把两条记录都留下做人工核对。更彻底的做法是优先保留更长的 BIN，短 BIN 只在长 BIN 查不到时兜底。这个改动之后，同类问题从每月几次降到零。

5.4 现象：内存 2G 的机器加载 BIN 表直接 OOM

原因：除了 BIN 表本身，代码里还保留了一份原始 JSON 的解析结果用于「查不到时打印上下文」。两份数据同时在内存里，Python 对象开销又大，实际占用是文件体积的十几倍。

解决：解析完立刻释放原始结构，只保留归一化后的精简字段；issuer这类纯展示字段改成按需回查。另外把加载时机从「每次请求」挪到「进程启动」，配合只读共享，内存曲线立刻平了。

5.5 现象：日志里出现了完整卡号

原因：校验失败时打了logger.warning(f"invalid pan: {pan}")，本意是方便排查，结果日志平台按明文存储，一下子捅了大篓子。

解决：所有日志输出统一过一遍掩码函数，只保留前 6 后 4；SUSPECT类的错误日志改成记录 BIN 和失败原因，不记完整卡号。这件事之后我养成了一个习惯：凡是涉及卡号、证件号的模块，日志函数入口先做一层脱敏，宁可少点排查信息。

6. 数据保鲜与回归样本：让这份 BIN 表三个月后还能用

BIN 表不是一次性资产。发卡行新增号段、产品线拆分、卡组织从 6 位迁移到 8 位，任何一次变动都会让旧表的覆盖率下降。我的做法是每次拿到新版本先做集合差分，看清楚到底变在哪，再决定要不要全量替换。

import json def load_bins(path: str) -> dict: with open(path, encoding="utf-8") as f: raw = json.load(f) records = raw["data"] if isinstance(raw, dict) and "data" in raw else raw return {str(r["bin"]): r for r in records} old = load_bins("bin_prev.json") new = load_bins("bin_curr.json") added = new.keys() - old.keys() # 新增号段 removed = old.keys() - new.keys() # 消失号段，重点看是否误删 changed = {k for k in new.keys() & old.keys() if new[k].get("issuer") != old[k].get("issuer") or new[k].get("type") != old[k].get("type")} print(f"新增 {len(added)}，移除 {len(removed)}，属性变更 {len(changed)}")

三个数字的解读方式不一样。新增多说明数据源在补录，正常；移除多要警惕，可能是数据源换了格式导致大面积解析失败，也可能是真的下线了号段，得抽样核对；属性变更最值得逐条看，尤其是type从 debit 变 credit 这种，直接影响下游路由。我一般会把changed里的前 50 条打印出来人工扫一遍，剩下的抽样。

光有差分还不够，得有能自动跑的回归样本。我在每个项目里都会维护一张固定用例表，覆盖那些「一改就坏」的边界，每次更新数据或改校验逻辑都跑一遍。

这张表的价值在最后两行。区间边界是最容易写错的地方——bisect_right用错成bisect_left，边界值就会漏掉一个。用例表里明确写出「等于起始值」「等于结束值」「结束值 +1」三个输入，改代码时想偷懒都难。

还有一个小技巧：把matched_width的分布也纳入监控。如果某个时间点之后 6 位命中的比例突然从 20% 涨到 80%，说明新数据的 8 位记录大面积缺失，虽然服务没报错，但识别精度已经掉了。这种「不报错的退化」比直接崩溃更难发现，靠的就是这类分布指标。

血泪经验是：BIN 表这类基础数据，出问题从来不是查表代码写错，而是数据换了、假设没跟着换。从那以后我每次更新数据源，都强制走一遍「差分 → 抽样核对 → 回归用例 → 覆盖率对比」这四步，一步都不跳。希望帮到你。

本文还有配套的精品资源，点击获取